Hello Tomi,

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

On 09/05/14 18:55, Tony Lindgren wrote:

quoted

quoted

Although if the MO gpio is not controlled by the driver, we should tell
the driver whether that gpio is high or low.

What do you have in mind for telling that? We should also tell the
orientation of the panel:

EVM   VGA     omapfb.rotate=3
LDP   QVGA    omapfb.rotate=0

Do you have something in mind for that?

Hmm, right. I guess all we can do is have boolean flags in the .dts for
MO, LR and UD, which tells if the respective pins are hard-wires high or
low. And say in the documentation that you must either have a proper
GPIO, or use the flag, but not both.

The panel mounting orientation is a different matter. But I think it is
also something we should specify in the .dts. However, we don't have any
SW support to handle it, and it's a bit unclear to me how it should be
handled, so I think that has to be left for later.

quoted

quoted

At the moment our display drivers are OMAP specific, and for that reason
we should prefix the compatible strings with "omapdss,". For example,
drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:

     { .compatible = "omapdss,panel-dsi-cm", },

But we should still have the right compatible string in the .dts, so we
convert the compatible name in arch/arm/mach-omap2/display.c, with
'dss_compat_conv_list' array, to which this panel's name should be added.

Oh so what do you want to have in the .dts file then?

The .dts should have the proper names. The idea of this hackery is that
in the .dts we can have the proper compatible string. So in the .dts, we
have, say:

"sony,panel-foobar"

Then, at boot time, omap's platform code changes that to:

"omapdss,sony,panel-foobar".

And our (omap specific) panel-foobar driver use that
"omapdss,sony,panel-foobar" string.

This way some other platform could do the same, and have their platform
specific drivers handle the panel.

At some point in the future we hopefully will have common panel drivers,
and at that point we can remove that hackery. The .dts files will
already be correct.

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.

 Tomi

Best regards,
Javier