Hello Tomi, On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On 12/05/14 12:34, Javier Martinez Canillas wrote: > >> Maybe we can remove this hackery by relying on the fact that a >> compatible string can have a set of values that goes from more >> specific to more general. So you can have something like: >> >> compatible = "sony,panel-foobar", "omapdss,panel-foobar" >> >> So right now only "omapdss,panel-foobar" will be matched and later >> when we have common panel drivers then that driver could handle the >> "sony,panel-foobar" compatible string. >> >> Other platforms could do something similar and have >> >> compatible = "sony,panel-foobar", "baz,panel-foobar" >> >> That way you won't break DT backward compatible but still not require >> hacks on arch/arm/mach-omap2/display.c. >> >> We do the same for OMAP boards, we now have the following compatible string: >> >> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3"; >> >> There isn't a struct machine_desc that matches "isee,omap3-igep0020" >> but later if we find that we need some board specific initialization >> we could add one without breaking existing DTS. In fact it used to be >> a single machine_desc that matched "ti,omap3" for both omap36xx and >> omap34xx but later when some DT clocks changes were introduced we >> needed to split both SoC families. > > I think that's a different thing. "isee,omap3-igep0020" is a proper > compatible string, if the board is "isee,...". No matter what software > you run, that's correct and fine. > > 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 ;-) > Tomi > > Bets regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
