RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
> 
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Valkeinen, Tomi
> > Sent: Monday, May 09, 2011 1:06 PM
> > To: tony@atomide.com
> > Cc: linux-omap@vger.kernel.org; Valkeinen, Tomi; Stanley Miao
> > Subject: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
> > 
> > Port the old omapfb panel driver to DSS2i. This patch changes the board
> > file only, the driver is ported in separate patch.
> > 
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Stanley Miao <stanley.miao@windriver.com>
> > ---
> >  arch/arm/mach-omap2/board-ldp.c |   73 +++++++++++++++++++++++++++++++++-
> > ----

<snip>

> > +static struct panel_generic_dpi_data ldp_panel_data = {
> > +	.name			= "2430sdp",
> 
> LDP is a 3430 board.

That is just the name of the panel, used to find the right timings from
the panel database. I first ported 2430sdp board, and called the panel
that. The timings looked the same on LDP board, so I deduced it's the
same panel, and used the same name.

However, if you do have the board, can you find the name and type of the
panel? It's usually printed in the backside of the panel, which of
course may not be accessible easily.

Or, if you or anyone else knows where to find information about the LDP
board, schematics or datasheets, that could help also.

> > +static void __init ldp_display_init(void)
> > +{
> > +	int r;
> > +
> > +	struct gpio gpios[] = {
> > +		{LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, "LCD RESET"},
> > +		{LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "LCD QVGA"},
> > +		{LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, "LCD ENABLE"},
> > +		{LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, "LCD
> > BACKLIGHT"},
> > +	};
> > +
> > +	r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
> > +	if (r) {
> > +		pr_err("Cannot request LCD GPIOs, error %d\n", r);
> > +		return;
> > +	}
> 
> If I test with this patch, this request is returning error.

Hmm. Well, the GPIOs are the same as in the old driver. However, the old
driver doesn't even seem to check if it manages to request the GPIOs, so
it may well be that it was failing also.

Can you check from /sys/class/gpio/ if some of the GPIOs are already
allocated: 207, 199, 55, 56?

The definition of two of those GPIOs look kinda funny to me: (15 +
OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
it sure doesn't sound ok to have a GPIO number that is 15 over the
maximum =).

 Tomi