Padding is a new hardware module on MediaTek MT8188,
add dt-bindings for it.
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: CK Hu <[email protected]>
Signed-off-by: Hsiao Chien Sung <[email protected]>
---
.../display/mediatek/mediatek,padding.yaml | 81 +++++++++++++++++++
1 file changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml
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 <[email protected]>
+ - Philipp Zabel <[email protected]>
+
+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>;
+ };
+ };
--
2.18.0
Hi Shawn,
On Fri, 6 Oct 2023 at 08:38, Hsiao Chien Sung <[email protected]> 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 <
> [email protected]> 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 (宋孝謙) <[email protected]> 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
Hi Daniel,
On Mon, 2023-10-16 at 12:47 +0200, 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 Mon, 16 Oct 2023 at 06:23, Shawn Sung (宋孝謙) <
> [email protected]> 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
Since Padding is bypassed in the current version, we didn't mention too
many details about it. Thank you for checking.
For more information, 4-pixel alignment in width is only required when
HDR is in Dolby Vision format, and the paddings will be cropped by
video front-end in the HDR module.
Cheers,
Shawn