From mboxrd@z Thu Jan 1 00:00:00 1970 From: tomi.valkeinen@ti.com (Tomi Valkeinen) Date: Mon, 12 May 2014 12:40:22 +0300 Subject: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support In-Reply-To: References: <1398815562-24113-1-git-send-email-tony@atomide.com> <1398815562-24113-4-git-send-email-tony@atomide.com> <5369EAE7.3030705@ti.com> <20140507150343.GA9502@atomide.com> <536A5920.1020908@ti.com> <20140507175919.GH9502@atomide.com> <20140508233300.GI2198@atomide.com> <536C8293.4070506@ti.com> <20140509155504.GE17814@atomide.com> <53707A64.2060203@ti.com> Message-ID: <53709706.10501@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: