[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 09:18:28 PST 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: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20221128/c3231463/attachment-0001.sig>


More information about the linux-arm-kernel mailing list