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

[Javier Martinez Canillas]

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 ;-)

>  Tomi
>
>

Bets regards,
Javier