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@xxxxxxxxxxxxxx> wrote: > > > > > > > > > > > > From: Marian Cichy <m.cichy@xxxxxxxxxxxxxx> > > > > > > > > > > > > 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/ |
Attachment:
signature.asc
Description: PGP signature
