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

* Tomi Valkeinen [off-list ref] [140512 07:55]:

On 12/05/14 17:26, Tony Lindgren wrote:

quoted

quoted

quoted

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.

quoted

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