Re: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c
On Wed, 2010-06-30 at 14:07 +0200, ext Tony Lindgren wrote: Use the new mux function for that. Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Tomi Valkeinen tomi.valkei...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/board-apollon.c |3 +++ drivers/video/omap/lcd_apollon.c|3 --- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach-omap2/board-apollon.c index b86a879..bc67026 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -332,6 +332,9 @@ static void __init omap_apollon_init(void) /* REVISIT: where's the correct place */ omap_cfg_reg(W19_24XX_SYS_NIRQ); + /* LCD PWR_EN */ + omap_mux_init_signal(mcbsp2_dr.gpio_11, OMAP_PULL_ENA | OMAP_PULL_UP); LCD_PWR_EN sounds like output pin. However, I don't see lcd_apollon.c nor board-apollon.c set the gpio. I don't know what omap_cfg_reg(M21_242X_GPIO11) does, but if it does the same thing as the line above, then does the apollon LCD work by luck? OMAP pulling the line up, and by chance the pull is stronger than the LCDs (possible) pull down, and thus the LCD is powered up... Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c
Hi, This value is set from bootloader, and kernel side only change the mode. Right it runs by luck. Thank you, Kyungmin Park -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Thursday, July 01, 2010 4:06 PM To: ext Tony Lindgren Cc: linux-arm-ker...@lists.infradead.org; Kyungmin Park; linux- o...@vger.kernel.org Subject: Re: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board- apollon.c On Wed, 2010-06-30 at 14:07 +0200, ext Tony Lindgren wrote: Use the new mux function for that. Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Tomi Valkeinen tomi.valkei...@nokia.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/board-apollon.c |3 +++ drivers/video/omap/lcd_apollon.c|3 --- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/board-apollon.c b/arch/arm/mach- omap2/board-apollon.c index b86a879..bc67026 100644 --- a/arch/arm/mach-omap2/board-apollon.c +++ b/arch/arm/mach-omap2/board-apollon.c @@ -332,6 +332,9 @@ static void __init omap_apollon_init(void) /* REVISIT: where's the correct place */ omap_cfg_reg(W19_24XX_SYS_NIRQ); + /* LCD PWR_EN */ + omap_mux_init_signal(mcbsp2_dr.gpio_11, OMAP_PULL_ENA | OMAP_PULL_UP); LCD_PWR_EN sounds like output pin. However, I don't see lcd_apollon.c nor board-apollon.c set the gpio. I don't know what omap_cfg_reg(M21_242X_GPIO11) does, but if it does the same thing as the line above, then does the apollon LCD work by luck? OMAP pulling the line up, and by chance the pull is stronger than the LCDs (possible) pull down, and thus the LCD is powered up... Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c
* Kyungmin Park kyungmin.p...@samsung.com [100701 11:12]: Hi, This value is set from bootloader, and kernel side only change the mode. Right it runs by luck. So should we just drop the omap_cfg_reg for now, then add it back later with proper gpio_request etc? Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c
On Thu, Jul 1, 2010 at 7:33 PM, Tony Lindgren t...@atomide.com wrote: * Kyungmin Park kyungmin.p...@samsung.com [100701 11:12]: Hi, This value is set from bootloader, and kernel side only change the mode. Right it runs by luck. So should we just drop the omap_cfg_reg for now, then add it back later with proper gpio_request etc? I mean the original patch is okay. Now that's find. I'll send a patch if require. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
