[PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
tony at atomide.com
Mon May 12 07:26:46 PDT 2014
* Javier Martinez Canillas <javier at dowhile0.org> [140512 03:01]:
> Hello Tomi,
> On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> 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 ;-)
This remapping of compatible flags sounds smelly to me, please discuss
it first with the device tree people.
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.
More information about the linux-arm-kernel