[PATCH 1/2] dt-bindings: display: imx: Add fsl,imx21-lcdc docs

[Uwe Kleine-König]

Hi Rob,

On Mon, Feb 21, 2022 at 02:55:36PM +0100, Uwe Kleine-König wrote:
> 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 at pengutronix.de> wrote:
> > > > > > 
> > > > > > From: Marian Cichy <m.cichy at 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?

I'd like to get forward with this driver. What would be a good way to
continue here? 

Best regards
Uwe

-- 
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/20220322/499b3f78/attachment-0001.sig>