[PATCH v3 0/2] drm/imx/lcdc: Implement DRM driver for imx21
Rob Herring
robh at kernel.org
Tue Dec 20 18:19:48 UTC 2022
On Sat, Dec 17, 2022 at 07:38:06PM +0100, Uwe Kleine-König wrote:
> On Fri, Dec 16, 2022 at 05:57:58PM -0600, Rob Herring wrote:
> > On Fri, Dec 16, 2022 at 06:50:04PM +0100, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > Changes since v2:
> > >
> > > - added allOf as Krzysztof requested
> > > - reworked driver based on Philipp's comments
> > > (improved error handling, different selects, moved driver to a subdirectory,
> > > header sorting, drm_err instead of DRM_ERROR, inlined
> > > imx_lcdc_check_mode_change, make use of dev_err_probe())
> > >
> > > Krzysztof also pointed out that we're now having two compatibles for a
> > > single hardware. Admittedly this is unusual, but this is the chance that
> > > the (bad) compatible identifier imx21-fb gets deprecated. The hardware
> > > is called LCDC and only the linux (framebuffer) driver is called imxfb.
> >
> > The problem is you can't have firmware (with the DTB) that supports
> > both. Well, you can if you want to have some firmware setting that
> > selects which one. Otherwise, it's really an OS problem to decide what
> > to use.
>
> I don't understand what you intend to say here. The same applies if the
> compatible is the same for both binding alternatives, isn't it?
Only if you have both nodes in the DT and both enabled. But 2 enabled
nodes at the same address is also a dtc warning, so I was assuming you
didn't do that.
> Do you consider a firmware problem better or an OS problem?
The OS created the problem, so they get to keep it. But a PC BIOS is
full of OS compatibility switches, so...
In the end, it's the platforms' decision really. I just want what the
implications of having 2 compatibles are to be understood.
Rob
More information about the dri-devel
mailing list