* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
