| Message ID | 20231006073831.10402-5-shawn.sung@mediatek.com |
|---|---|
| State | Accepted |
| Commit | d2423d8a38e724b28007abd76db08ccb59f56015 |
| Headers | show |
| Series | Add display driver for MT8188 VDOSYS1 | expand |
Hi Shawn, On Fri, 6 Oct 2023 at 08:38, Hsiao Chien Sung <shawn.sung@mediatek.com> wrote: > + Padding provides ability to add pixels to width and height of a layer with > + specified colors. Due to hardware design, Mixer in VDOSYS1 requires > + width of a layer to be 2-pixel-align, or 4-pixel-align when ETHDR is enabled, > + we need Padding to deal with odd width. > + Please notice that even if the Padding is in bypass mode, settings in > + register must be cleared to 0, or undefined behaviors could happen. If I understand the driver correctly, padding is automatically applied to compensate for unaligned dimensions. The first/last rows/columns of the overlay area will be filled with a specified colour (black?) to preserve the area. This is unfortunately not OK to do transparently. Userspace must be aware of this policy decision and specifically request it. If not, the atomic request check should fail and tell userspace that the requested configuration is not possible to achieve. Cheers, Daniel
Hi Daniel, On Fri, 2023-10-13 at 17:26 +0100, Daniel Stone wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > Hi Shawn, > > On Fri, 6 Oct 2023 at 08:38, Hsiao Chien Sung < > shawn.sung@mediatek.com> wrote: > > + Padding provides ability to add pixels to width and height of a > layer with > > + specified colors. Due to hardware design, Mixer in VDOSYS1 > requires > > + width of a layer to be 2-pixel-align, or 4-pixel-align when > ETHDR is enabled, > > + we need Padding to deal with odd width. > > + Please notice that even if the Padding is in bypass mode, > settings in > > + register must be cleared to 0, or undefined behaviors could > happen. > > If I understand the driver correctly, padding is automatically > applied > to compensate for unaligned dimensions. The first/last rows/columns > of > the overlay area will be filled with a specified colour (black?) to > preserve the area. This is unfortunately not OK to do transparently. > Userspace must be aware of this policy decision and specifically > request it. If not, the atomic request check should fail and tell > userspace that the requested configuration is not possible to > achieve. > > Cheers, > Daniel Yes, Padding works as you described, users can assign background colors for the filled area in 10bit RGB format, however, the rows and columns that are filled by Padding will be cropped by the hardware components after it to avoid situations as you mentioned, so users should not notice any difference. The reason why we add paddings to the frame and then remove it before showing it on the screen is due to the limitation of ETHDR. When HDR is enabled, the input pixels in width must be 4-pixel aligned, but for now ETHDR is bypassed so as the Paddings. Since the Paddings are always bypassed currently, the logics described above are not implemented yet, mtk_padding_config() will also be removed in the next version as the reviewer's suggestion. Cheers, Shawn
Hi Shawn, On Mon, 16 Oct 2023 at 06:23, Shawn Sung (宋孝謙) <Shawn.Sung@mediatek.com> wrote: > On Fri, 2023-10-13 at 17:26 +0100, Daniel Stone wrote: > > If I understand the driver correctly, padding is automatically > > applied > > to compensate for unaligned dimensions. The first/last rows/columns > > of > > the overlay area will be filled with a specified colour (black?) to > > preserve the area. This is unfortunately not OK to do transparently. > > Userspace must be aware of this policy decision and specifically > > request it. If not, the atomic request check should fail and tell > > userspace that the requested configuration is not possible to > > achieve. > > Yes, Padding works as you described, users can assign background colors > for the filled area in 10bit RGB format, however, the rows and columns > that are filled by Padding will be cropped by the hardware components > after it to avoid situations as you mentioned, so users should not > notice any difference. Thanks for the explanation, I hadn't realised that the added padding later gets cropped. Cheers, Daniel
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml new file mode 100644 index 000000000000..db24801ebc48 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,padding.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Display Padding + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: + Padding provides ability to add pixels to width and height of a layer with + specified colors. Due to hardware design, Mixer in VDOSYS1 requires + width of a layer to be 2-pixel-align, or 4-pixel-align when ETHDR is enabled, + we need Padding to deal with odd width. + Please notice that even if the Padding is in bypass mode, settings in + register must be cleared to 0, or undefined behaviors could happen. + +properties: + compatible: + const: mediatek,mt8188-padding + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + clocks: + items: + - description: RDMA Clock + + mediatek,gce-client-reg: + description: + GCE (Global Command Engine) is a multi-core micro processor that helps + its clients to execute commands without interrupting CPU. This property + describes GCE client's information that is composed by 4 fields. + 1. Phandle of the GCE (there may be several GCE processors) + 2. Sub-system ID defined in the dt-binding like a user ID + (Please refer to include/dt-bindings/gce/<chip>-gce.h) + 3. Offset from base address of the subsys you are at + 4. Size of the register the client needs + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + items: + - description: Phandle of the GCE + - description: Subsys ID defined in the dt-binding + - description: Offset from base address of the subsys + - description: Size of register + maxItems: 1 + +required: + - compatible + - reg + - power-domains + - clocks + - mediatek,gce-client-reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mediatek,mt8188-clk.h> + #include <dt-bindings/power/mediatek,mt8188-power.h> + #include <dt-bindings/gce/mt8195-gce.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + padding0: padding@1c11d000 { + compatible = "mediatek,mt8188-padding"; + reg = <0 0x1c11d000 0 0x1000>; + clocks = <&vdosys1 CLK_VDO1_PADDING0>; + power-domains = <&spm MT8188_POWER_DOMAIN_VDOSYS1>; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0xd000 0x1000>; + }; + };