[PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen at ti.com> [140512 07:55]:
> On 12/05/14 17:26, Tony Lindgren wrote:
> 
> >>> The omapdss case is different, there the "omapdss" points to a sw thing,
> >>> it does not describe the hardware. It's only needed as we don't have
> >>> proper sw drivers for the devices.
> >>>
> >>> That said, I think what you describe would work. But I would rather keep
> >>> the .dts files clean and correct, and keep that hacks hidden inside the
> >>> kernel.
> >>>
> >>
> >> Thanks for the explanation. Since DT are meant to describe hardware
> >> and not software I agree with you that we shouldn't leak an
> >> implementation detail to the DeviceTrees.
> >>
> >> And after all fortunately we don't have a stable API in the kernel
> >> like the one that is enforced in the DT so we can fix it later ;-)
> > 
> > This remapping of compatible flags sounds smelly to me, please discuss
> > it first with the device tree people.
> 
> It's already in v3.15.

Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
even acked it :( Looks like there's also the custom mux hacks. And
custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add
_any_ new crap into arch/arm/mach-omap2/display.c.

So please consider this a huge eternal NAK to add any more crap to
arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
the soc_is_am43xx() you have in linux next. No more adding 
of_find_compatible_node() beyond ti,omap5-dss you have in linux next.

And no more new panel remapping in this file as soon as you have found
a better solution. Preferrably by v3.17 merge window. This file just
needs to disappear. Yuk.

> I agree it's smelly, but it smelly only inside the kernel, not visible
> anywhere, and we can remove it when we have common panel drivers,
> without any modifications to .dts files.
> 
> > I think we're better off just using the compatible properties limited
> > to the simple-panel.txt for now and actually describe the real
> > hardware. The fact that the panel is connected to DSS should be possible
> > to find out based on the phandles.
> 
> I'm not sure what you mean. We do describe only the real hardware. The
> compatible string in the .dts file is "sharp,ls037v7dw01".
> 
> Prepending the "omapdss" to the compatible string is required for the
> device/driver matching to work, because we can't use the
> "sharp,ls037v7dw01" compatible string in our omap specific panel driver.
> 
> I'm not sure what it would give us to try to be compatible with
> simple-panel.txt. The simple-panel bindings won't probably be compatible
> with the future common display drivers in any case, as the simple-panel
> binding is just too limited and doesn't describe the hardware fully.

Hmm what else does a panel need where the existing binding cannot be
extended? 

Regards,

Tony