Hi Rob,
On Thu, Feb 10, 2022 at 06:54:13PM +0100, Lucas Stach wrote:
Am Dienstag, dem 01.02.2022 um 11:35 -0600 schrieb Rob Herring:
On Fri, Jan 28, 2022 at 06:58:29PM +0100, Uwe Kleine-König wrote:
On Fri, Jan 28, 2022 at 07:04:10AM -0600, Rob Herring wrote:
On Fri, Jan 28, 2022 at 4:59 AM Uwe Kleine-König u.kleine-koenig@pengutronix.de wrote:
From: Marian Cichy m.cichy@pengutronix.de
This files documents the device tree for the new imx21-lcdc DRM driver.
No, bindings document h/w and the h/w has not changed. We already have a binding for the LCDC.
Just to be sure we're talking about the same thing: You're refering to Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt, right?
Looks right...
I'm unsure what to do now. Should the two different bindings just be described in the same file? Should I stick to fsl,imx21-fb even for the new binding? (The hardware unit is named LCDC, so the name chosen here is the better one.) Please advise.
Yes, the name is unfortunate, but it should be 1 binding, 1 file, and unchanged (unless you want to add new optional properties).
The old FB driver binding is pretty insane. Except the reg and interrupt properties it is very confused about things. It exposes internal implementation details (like specifying verbatim register settings in the DT) and other properties are just misplaced, like the lcd-supply property that controls the panel power supply.
I really don't think that trying to stay backwards compatible here is a win for anyone. Anyone willing to switch their systems running on a 15 year old SoC to the new DRM driver probably doesn't mind if they have to modify the DTS to make it work. Can we please let the FB driver die in peace and have a clean slate driver/binding for the DRM driver?
Does this feedback change anything on your side? My expectation is that the graphics people will be happy about every fb driver being replaced by a DRM driver and there will be hardly any incentive to add a layer over the DRM driver to make it honor the old fb binding.
Assume I convert the old binding to yaml and then add the newly supported binding to that using a big oneOf, would that be an acceptable compromise?
Best regards Uwe