Re: [PATCH 05/33] arm: omap: board-cm-t35: use generic dpi panel's gpio handling

On 2013-02-14 14:37, Igor Grinberg wrote:

On 02/14/13 12:59, Tomi Valkeinen wrote:

quoted

On 2013-02-14 11:43, Igor Grinberg wrote:

quoted

quoted

quoted

True, it's generic, but does it work reliably? The panel hardware is now
partly handled in the backlight driver, and partly in the omap's panel
driver (and wherever on other platforms).

It works reliably on other platforms, but not on OMAP - because
we need to cope with the OMAP specific framework...

quoted

How do you handle the gpios on other platform? Those are the ones
causing the issues here, right?

Well, I'm also talking about something that is a history already.
Remember, we had multiple panel drivers inside the
video/omap2/displays and then they were consolidated into the
"generic dpi/dsi/whatever".

Sorry, I miss the point. Was that a bad thing? Didn't it simplify the
task for you with simple panels? It could've been taken even further,
though (see below).

And yes you are right, on the platforms I'm aware of, the GPIO is not
handled. Apparently its hardware default (pull resistor) is always on...

Ok, so the simple fix of setting the GPIOs only in the board file is
acceptable for now.

Can the LCD_BL_GPIO be handled by the omap panel driver? Otherwise the
backlight will supposedly be always on. Is it just a simple switch for
the BL power, which does not affect the SPI in any way?

quoted

Or is there something else with OMAP DSS that you need to specifically
cope with?

The fact there is a need to create a OMAP specific driver.
I'm not talking about the generic driver which only needs to have the
controller specific data (e.g. porches, pixel clock, bus width).
The generic driver was one of the good ways to go.

Well, we could also have an even more generic driver that takes the
video timings from the board file as platform data. Then all you would
need to do is to define the timings in the board file, as I think is
done for other platforms also.

I'm not very fond of that idea, as I think hardcoded device specific
data should not be given as parameters, but they should be handled by
the device driver internally, as it should know that device specific
data already.

But, in practice, making this kind of even more generic panel driver
will probably make life easier for everyone, so I think we'll have one
with CDF.

 Tomi