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

Hello Tomi,

On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen [off-list ref] wrote:

On 12/05/14 12:34, Javier Martinez Canillas wrote:

quoted

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