[PATCH v1] dt-bindings: display: Convert fsl,imx-fb.txt to dt-schema
Uwe Kleine-König
u.kleine-koenig at pengutronix.de
Mon Nov 28 17:18:28 UTC 2022
Hello,
On Wed, Nov 16, 2022 at 11:21:31AM -0600, Rob Herring wrote:
> On Thu, Nov 10, 2022 at 10:49:45AM +0100, Uwe Kleine-König wrote:
> > This is a straight forward conversion. Note that fsl,imx-lcdc was picked
> > as the new name as this is the compatible that should supersede the
> > legacy fb binding.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig at pengutronix.de>
> > ---
> > Hello,
> >
> > the eventual goal is to add drm support for this hardware. That one will
> > use a different (and more sensible) binding. However fsl,imx*-fb won't
> > go away directly, and Rob requested to describe both bindings in the
> > same file given that it describes a single hardware type.
> >
> > As a first step I convert the old binding to yaml. I tried to put the
> > new binding on top of that but I'm not sure about a few things in this
> > patch and so post only this first patch and once it's accepted add the
> > new binding which I guess is less overall work.
> >
> > What I'm unsure about is the description of the display node (Is there a
> > better description? I didn't find a schema for that.)
>
> That's going to be a challenge to describe because every panel binding
> will need a reference to those custom properties. It's a similar problem
> that spi-peripheral-props.yaml solved. But here, there may not be enough
> instances to do such a general solution. Do the panels used even have
> schemas yet?
Looking at the dts files in the tree[1] I only found sharp,lq035q7db03
in simple-panel which might match the display used in
arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts.
> It's kind of a separate problem. You could start with just creating a
> schema just listing the custom properties.
Understood that. Will try it.
> > Further I didn't find documentation about additionalProperties and
> > unevaluatedProperties. Did I pick the right one here?
>
> example-schema.yaml talks about it some. In general, if there's a
> $ref to other properties for a node not defined locally, then you need
> unevaluatedProperties. Otherwise, additionalProperties is fine.
Not sure I got the complete picture. I'll stick to additionalProperties
and rely on people and tools to tell me if I'm wrong :-)
Best regards and thanks for the feedback,
Uwe
[1]
&wvga in arch/arm/boot/dts/imx25-pdk.dts
&cmo_qvga in arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
&dvi_svga in arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
&dvi_vga in arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
&display0 in arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
&display in arch/arm/boot/dts/imx27-apf27dev.dts
&display0 in arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
&display in arch/arm/boot/dts/imx27-phytec-phycard-s-rdk.dts
&display0 in arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20221128/c3231463/attachment.sig>
More information about the dri-devel
mailing list