[PATCH 0/6] Misc omap board patches for v2.6.38 merge window

[PATCH 0/6] Misc omap board patches for v2.6.38 merge window

[Tony Lindgren]

Hi,

The following set contains some patches for the v2.6.38 merge window.

Regards,

Tony

---

Hemanth V (2):
      omap4: Add platform changes for Ambient Light sensor
      omap4: Add platform changes for PWM LED

Laurent Pinchart (2):
      omap3: igepv2: Don't call gpio_set_value right aftergpio_direction_output
      omap3: igepv2: LED gpio-led:green:d1 is active low

Raghuveer Murthy (1):
      OMAP4: Pandaboard: Add omap_reserve functionality

Tony Lindgren (1):
      omap1: Fix innovator FPGA init for multi-omap


 arch/arm/mach-omap1/board-innovator.c  |    7 ++-----
 arch/arm/mach-omap1/fpga.c             |   10 ++++++----
 arch/arm/mach-omap2/board-4430sdp.c    |   27 +++++++++++++++++++++++++++
 arch/arm/mach-omap2/board-igep0020.c   |   21 +++++++++------------
 arch/arm/mach-omap2/board-omap4panda.c |    1 +
 arch/arm/plat-omap/include/plat/fpga.h |    4 ----
 6 files changed, 45 insertions(+), 25 deletions(-)

-- 
Signature

[PATCH 1/6] omap1: Fix innovator FPGA init for multi-omap

[Tony Lindgren]

No need to call this early from init_irq. Also recent changes
initialize GPIO now later, so calling gpio_request from init_irq
will make it fail.

While at it, also remove the unnecessary EXPORT_SYMBOL.

Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap1/board-innovator.c  |    7 ++-----
 arch/arm/mach-omap1/fpga.c             |   10 ++++++----
 arch/arm/plat-omap/include/plat/fpga.h |    4 ----
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap1/board-innovator.c b/arch/arm/mach-omap1/board-innovator.c
index a051acd..8d59b07 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -290,11 +290,6 @@ static void __init innovator_init_irq(void)
 {
 	omap1_init_common_hw();
 	omap_init_irq();
-#ifdef CONFIG_ARCH_OMAP15XX
-	if (cpu_is_omap1510()) {
-		omap1510_fpga_init_irq();
-	}
-#endif
 }
 
 #ifdef CONFIG_ARCH_OMAP15XX
@@ -385,6 +380,8 @@ static struct omap_board_config_kernel innovator_config[] = {
 
 static void __init innovator_init(void)
 {
+	if (cpu_is_omap1510())
+		omap1510_fpga_init_irq();
 	innovator_init_smc91x();
 
 #ifdef CONFIG_ARCH_OMAP15XX
diff --git a/arch/arm/mach-omap1/fpga.c b/arch/arm/mach-omap1/fpga.c
index 5cfce16..8780e75 100644
--- a/arch/arm/mach-omap1/fpga.c
+++ b/arch/arm/mach-omap1/fpga.c
@@ -143,7 +143,7 @@ static struct irq_chip omap_fpga_irq = {
  */
 void omap1510_fpga_init_irq(void)
 {
-	int i;
+	int i, res;
 
 	__raw_writeb(0, OMAP1510_FPGA_IMR_LO);
 	__raw_writeb(0, OMAP1510_FPGA_IMR_HI);
@@ -177,10 +177,12 @@ void omap1510_fpga_init_irq(void)
 	 * NOTE: For general GPIO/MPUIO access and interrupts, please see
 	 * gpio.[ch]
 	 */
-	gpio_request(13, "FPGA irq");
+	res = gpio_request(13, "FPGA irq");
+	if (res) {
+		pr_err("%s failed to get gpio\n", __func__);
+		return;
+	}
 	gpio_direction_input(13);
 	set_irq_type(gpio_to_irq(13), IRQ_TYPE_EDGE_RISING);
 	set_irq_chained_handler(OMAP1510_INT_FPGA, innovator_fpga_IRQ_demux);
 }
-
-EXPORT_SYMBOL(omap1510_fpga_init_irq);
diff --git a/arch/arm/plat-omap/include/plat/fpga.h b/arch/arm/plat-omap/include/plat/fpga.h
index f1864a6..ae39bcb 100644
--- a/arch/arm/plat-omap/include/plat/fpga.h
+++ b/arch/arm/plat-omap/include/plat/fpga.h
@@ -19,11 +19,7 @@
 #ifndef __ASM_ARCH_OMAP_FPGA_H
 #define __ASM_ARCH_OMAP_FPGA_H
 
-#if defined(CONFIG_MACH_OMAP_INNOVATOR) && defined(CONFIG_ARCH_OMAP15XX)
 extern void omap1510_fpga_init_irq(void);
-#else
-#define omap1510_fpga_init_irq()	(0)
-#endif
 
 #define fpga_read(reg)			__raw_readb(reg)
 #define fpga_write(val, reg)		__raw_writeb(val, reg)

[PATCH 2/6] OMAP4: Pandaboard: Add omap_reserve functionality

[Tony Lindgren]

From: Raghuveer Murthy <raghuveer.murthy@ti.com>

This patch adds omap_reserve functionality to board-omap4panda.c.
Helps in the reserving boot time memory in SDRAM, used here for
framebuffer allocation.

This patch is in similar lines to commit id 71ee7dad9b6991, from
Russell king

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Raghuveer Murthy <raghuveer.murthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/board-omap4panda.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 38f942b..9f49e23 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -407,6 +407,7 @@ MACHINE_START(OMAP4_PANDA, "OMAP4 Panda board")
 	/* Maintainer: David Anders - Texas Instruments Inc */
 	.boot_params	= 0x80000100,
 	.map_io		= omap4_panda_map_io,
+	.reserve	= omap_reserve,
 	.init_irq	= omap4_panda_init_irq,
 	.init_machine	= omap4_panda_init,
 	.timer		= &omap_timer,

[PATCH 3/6] omap3: igepv2: Don't call gpio_set_value right aftergpio_direction_output

[Tony Lindgren]

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

gpio_direction_output() has a value argument, there's no need to call
gpio_set_value() explicitly right after.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/board-igep0020.c |   20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 3bee9a1..77e2db7 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -377,24 +377,21 @@ static void __init igep2_leds_init(void)
 static inline void igep2_leds_init(void)
 {
 	if ((gpio_request(IGEP2_GPIO_LED0_RED, "gpio-led:red:d0") == 0) &&
-	    (gpio_direction_output(IGEP2_GPIO_LED0_RED, 1) == 0)) {
+	    (gpio_direction_output(IGEP2_GPIO_LED0_RED, 0) == 0))
 		gpio_export(IGEP2_GPIO_LED0_RED, 0);
-		gpio_set_value(IGEP2_GPIO_LED0_RED, 0);
-	} else
+	else
 		pr_warning("IGEP v2: Could not obtain gpio GPIO_LED0_RED\n");
 
 	if ((gpio_request(IGEP2_GPIO_LED0_GREEN, "gpio-led:green:d0") == 0) &&
-	    (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 1) == 0)) {
+	    (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 0) == 0))
 		gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
-		gpio_set_value(IGEP2_GPIO_LED0_GREEN, 0);
-	} else
+	else
 		pr_warning("IGEP v2: Could not obtain gpio GPIO_LED0_GREEN\n");
 
 	if ((gpio_request(IGEP2_GPIO_LED1_RED, "gpio-led:red:d1") == 0) &&
-	    (gpio_direction_output(IGEP2_GPIO_LED1_RED, 1) == 0)) {
+	    (gpio_direction_output(IGEP2_GPIO_LED1_RED, 0) == 0))
 		gpio_export(IGEP2_GPIO_LED1_RED, 0);
-		gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
-	} else
+	else
 		pr_warning("IGEP v2: Could not obtain gpio GPIO_LED1_RED\n");
 
 }
@@ -426,10 +423,9 @@ static int igep2_twl_gpio_setup(struct device *dev,
 	/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
 #if !defined(CONFIG_LEDS_GPIO) && !defined(CONFIG_LEDS_GPIO_MODULE)
 	if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, "gpio-led:green:d1") == 0)
-	    && (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0)) {
+	    && (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
 		gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
-		gpio_set_value(gpio + TWL4030_GPIO_MAX + 1, 0);
-	} else
+	else
 		pr_warning("IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n");
 #else
 	igep2_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;

[PATCH 4/6] omap3: igepv2: LED gpio-led:green:d1 is active low

[Tony Lindgren]

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Make sure the LED is turned off at boot time, and configure the GPIO LED
device as active low.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/board-igep0020.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 77e2db7..c5bd537 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -352,6 +352,7 @@ static struct gpio_led igep2_gpio_leds[] = {
 		.name			= "gpio-led:green:d1",
 		.default_trigger	= "heartbeat",
 		.gpio			= -EINVAL, /* gets replaced */
+		.active_low		= 1,
 	},
 };
 
@@ -423,7 +424,7 @@ static int igep2_twl_gpio_setup(struct device *dev,
 	/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
 #if !defined(CONFIG_LEDS_GPIO) && !defined(CONFIG_LEDS_GPIO_MODULE)
 	if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, "gpio-led:green:d1") == 0)
-	    && (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
+	    && (gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0))
 		gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
 	else
 		pr_warning("IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n");

[PATCH 5/6] omap4: Add platform changes for Ambient Light sensor

[Tony Lindgren]

From: Hemanth V <hemanthv@ti.com>

Register BH1780GLI Ambient light sensor, which is an I2C device
for 4430SDP board.

Signed-off-by: Hemanth V <hemanthv@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/board-4430sdp.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 8842ec5..66f8943 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -464,6 +464,9 @@ static struct i2c_board_info __initdata sdp4430_i2c_3_boardinfo[] = {
 	{
 		I2C_BOARD_INFO("tmp105", 0x48),
 	},
+	{
+		I2C_BOARD_INFO("bh1780", 0x29),
+	},
 };
 static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
 	{

[PATCH 6/6] omap4: Add platform changes for PWM LED

[Tony Lindgren]

From: Hemanth V <hemanthv@ti.com>

Register TWL6030 PWM, which is used as charging LED

Signed-off-by: Hemanth V <hemanthv@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/board-4430sdp.c |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 66f8943..33b1f73 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -23,6 +23,7 @@
 #include <linux/gpio_keys.h>
 #include <linux/regulator/machine.h>
 #include <linux/leds.h>
+#include <linux/leds_pwm.h>
 
 #include <mach/hardware.h>
 #include <mach/omap4-common.h>
@@ -97,6 +98,28 @@ static struct gpio_led_platform_data sdp4430_led_data = {
 	.num_leds	= ARRAY_SIZE(sdp4430_gpio_leds),
 };
 
+static struct led_pwm sdp4430_pwm_leds[] = {
+	{
+		.name		= "omap4:green:chrg",
+		.pwm_id		= 1,
+		.max_brightness	= 255,
+		.pwm_period_ns	= 7812500,
+	},
+};
+
+static struct led_pwm_platform_data sdp4430_pwm_data = {
+	.num_leds	= ARRAY_SIZE(sdp4430_pwm_leds),
+	.leds		= sdp4430_pwm_leds,
+};
+
+static struct platform_device sdp4430_leds_pwm = {
+	.name	= "leds_pwm",
+	.id	= -1,
+	.dev	= {
+		.platform_data = &sdp4430_pwm_data,
+	},
+};
+
 static int omap_prox_activate(struct device *dev)
 {
 	gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
@@ -204,6 +227,7 @@ static struct platform_device *sdp4430_devices[] __initdata = {
 	&sdp4430_lcd_device,
 	&sdp4430_gpio_keys_device,
 	&sdp4430_leds_gpio,
+	&sdp4430_leds_pwm,
 };
 
 static struct omap_lcd_config sdp4430_lcd_config __initdata = {

[PATCH 2/6] OMAP4: Pandaboard: Add omap_reserve functionality

[Russell King - ARM Linux]

On Fri, Dec 17, 2010 at 07:05:21PM -0800, Tony Lindgren wrote:
>  	/* Maintainer: David Anders - Texas Instruments Inc */
>  	.boot_params	= 0x80000100,
>  	.map_io		= omap4_panda_map_io,
> +	.reserve	= omap_reserve,

Please put .reserve before .map_io.

[PATCH 2/6] OMAP4: Pandaboard: Add omap_reserve functionality

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 00:26]:
> On Fri, Dec 17, 2010 at 07:05:21PM -0800, Tony Lindgren wrote:
> >  	/* Maintainer: David Anders - Texas Instruments Inc */
> >  	.boot_params	= 0x80000100,
> >  	.map_io		= omap4_panda_map_io,
> > +	.reserve	= omap_reserve,
> 
> Please put .reserve before .map_io.

Hmm, that's the way it should be.. But we should also correct the
earlier changes too?

See 98c672cf1fa2a56f6f43e3f48b1208b83845582c (ARM: Move platform memory
reservations out of generic code) and 71ee7dad9b69917079f24d42aff796bad7932914
(ARM: OMAP: Convert to use ->reserve method to reserve boot time memory).

In these patches .reserve is also after .map_io which is
probably not intentional?

Regards,

Tony

[PATCH 2/6] OMAP4: Pandaboard: Add omap_reserve functionality

[Russell King - ARM Linux]

On Sat, Dec 18, 2010 at 09:20:56AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 00:26]:
> > On Fri, Dec 17, 2010 at 07:05:21PM -0800, Tony Lindgren wrote:
> > >  	/* Maintainer: David Anders - Texas Instruments Inc */
> > >  	.boot_params	= 0x80000100,
> > >  	.map_io		= omap4_panda_map_io,
> > > +	.reserve	= omap_reserve,
> > 
> > Please put .reserve before .map_io.
> 
> Hmm, that's the way it should be.. But we should also correct the
> earlier changes too?

Strangely that's what I've been doing in my init_early patches.  My
comment was aimed to ensure that no new instances are introduced.

[PATCH 2/6] OMAP4: Pandaboard: Add omap_reserve functionality

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 09:36]:
> On Sat, Dec 18, 2010 at 09:20:56AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 00:26]:
> > > On Fri, Dec 17, 2010 at 07:05:21PM -0800, Tony Lindgren wrote:
> > > >  	/* Maintainer: David Anders - Texas Instruments Inc */
> > > >  	.boot_params	= 0x80000100,
> > > >  	.map_io		= omap4_panda_map_io,
> > > > +	.reserve	= omap_reserve,
> > > 
> > > Please put .reserve before .map_io.
> > 
> > Hmm, that's the way it should be.. But we should also correct the
> > earlier changes too?
> 
> Strangely that's what I've been doing in my init_early patches.  My
> comment was aimed to ensure that no new instances are introduced.

OK, do you want to merge this one into your patches too?

Tony

[PATCH 2/6] OMAP4: Pandaboard: Add omap_reserve functionality

[Russell King - ARM Linux]

On Sat, Dec 18, 2010 at 09:41:36AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 09:36]:
> > On Sat, Dec 18, 2010 at 09:20:56AM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 00:26]:
> > > > On Fri, Dec 17, 2010 at 07:05:21PM -0800, Tony Lindgren wrote:
> > > > >  	/* Maintainer: David Anders - Texas Instruments Inc */
> > > > >  	.boot_params	= 0x80000100,
> > > > >  	.map_io		= omap4_panda_map_io,
> > > > > +	.reserve	= omap_reserve,
> > > > 
> > > > Please put .reserve before .map_io.
> > > 
> > > Hmm, that's the way it should be.. But we should also correct the
> > > earlier changes too?
> > 
> > Strangely that's what I've been doing in my init_early patches.  My
> > comment was aimed to ensure that no new instances are introduced.
> 
> OK, do you want to merge this one into your patches too?

Well, the main purpose of init_early is to provide a hook to allow
platforms to initialize their sched_clock() implementation before the
scheduler comes up.

init_early is already in my misc branch, and should appear in linux-next
during the next update, if it isn't there already.  The patch for using
this new hook is still work in progress (SMP issues has overtaken it
again today.)

However, the problem I currently have is that the sched_clock() patchset
depends on the ftrace changes from Rabin (in devel-stable) and the
init_early stuff is in the misc branch, and I'm trying to avoid merging
those two branches until the patches for using the new hook have been
finalized and reviewed.

Once that's happened there's another pile of work to sort out the
initialization of sched_clock(), especially as almost every machine
class is completely different in this regard (due to dependencies with
things like clk API.)

I think this is going to be rather hit and miss, so I'm probably going
to do this relatively slowly - let's do the init_early support and
moving stuff there for this merge window, and leave resolving the
sched_clock() initialization issue until the following merge window.
(The rest of the sched_clock() stuff can go in as-is because it's no
worse than what we do today.)

[PATCH 2/6] OMAP4: Pandaboard: Add omap_reserve functionality

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 09:50]:
> On Sat, Dec 18, 2010 at 09:41:36AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 09:36]:
> > > On Sat, Dec 18, 2010 at 09:20:56AM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [101218 00:26]:
> > > > > On Fri, Dec 17, 2010 at 07:05:21PM -0800, Tony Lindgren wrote:
> > > > > >  	/* Maintainer: David Anders - Texas Instruments Inc */
> > > > > >  	.boot_params	= 0x80000100,
> > > > > >  	.map_io		= omap4_panda_map_io,
> > > > > > +	.reserve	= omap_reserve,
> > > > > 
> > > > > Please put .reserve before .map_io.
> > > > 
> > > > Hmm, that's the way it should be.. But we should also correct the
> > > > earlier changes too?
> > > 
> > > Strangely that's what I've been doing in my init_early patches.  My
> > > comment was aimed to ensure that no new instances are introduced.
> > 
> > OK, do you want to merge this one into your patches too?
> 
> Well, the main purpose of init_early is to provide a hook to allow
> platforms to initialize their sched_clock() implementation before the
> scheduler comes up.
> 
> init_early is already in my misc branch, and should appear in linux-next
> during the next update, if it isn't there already.  The patch for using
> this new hook is still work in progress (SMP issues has overtaken it
> again today.)
> 
> However, the problem I currently have is that the sched_clock() patchset
> depends on the ftrace changes from Rabin (in devel-stable) and the
> init_early stuff is in the misc branch, and I'm trying to avoid merging
> those two branches until the patches for using the new hook have been
> finalized and reviewed.
> 
> Once that's happened there's another pile of work to sort out the
> initialization of sched_clock(), especially as almost every machine
> class is completely different in this regard (due to dependencies with
> things like clk API.)
> 
> I think this is going to be rather hit and miss, so I'm probably going
> to do this relatively slowly - let's do the init_early support and
> moving stuff there for this merge window, and leave resolving the
> sched_clock() initialization issue until the following merge window.
> (The rest of the sched_clock() stuff can go in as-is because it's no
> worse than what we do today.)

OK, sounds good. I'll give those a try next week too.

Will update this patch based on your original comment and keep
it in my series.

Regards,

Tony