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

[Tony Lindgren]

* 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.

Regards,

Tony