On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote: > > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Valkeinen, Tomi > > Sent: Monday, May 09, 2011 1:06 PM > > To: tony@xxxxxxxxxxx > > Cc: linux-omap@xxxxxxxxxxxxxxx; 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@xxxxxx> > > Cc: Stanley Miao <stanley.miao@xxxxxxxxxxxxx> > > --- > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
