linux-omap-pm: add 2.6.28 recipe so git can move to .29rc

2 files changed, 154 insertions, 0 deletions

diff --git a/recipes/linux/linux-omap-2.6.28/0124-leds-gpio-broken-with-current-git.patch b/recipes/linux/linux-omap-2.6.28/0124-leds-gpio-broken-with-current-git.patch
new file mode 100644
index 0000000000..dc6e190e89
--- /dev/null
+++ b/recipes/linux/linux-omap-2.6.28/0124-leds-gpio-broken-with-current-git.patch
@@ -0,0 +1,79 @@
+From c810e850d830330cf04225a4cff8e981e153f269 Mon Sep 17 00:00:00 2001
+From: David Brownell <david-b@pacbell.net>
+Date: Mon, 23 Feb 2009 14:08:14 -0800
+Subject: [PATCH 124/133] leds-gpio broken with current git?
+MIME-Version: 1.0
+Content-Type: text/plain; charset=utf-8
+Content-Transfer-Encoding: 8bit
+
+On Monday 23 February 2009, David Brownell wrote:
+>
+> > Perhaps something broke with Tony's RC1 merge?
+> > The LEDs are broken for me as well.
+>
+> Still works for me.  Did you maybe not enable the twl4030
+> GPIO support in Kconfig?
+
+Oh, and if you did *not*, please give this patch a try.
+I've been meaning to test it.
+
+- Dave
+
+==============
+Sometimes it's awkward to make sure that the array in the
+platform_data handed to the leds-gpio driver has only valid
+data ... some leds may not be always available, and coping
+with that currently requires patching or rebuilding the array.
+
+This patch fixes that by making it be OK to pass an invalid
+GPIO (such as "-EINVAL") ... such table entries are skipped.
+---
+ drivers/leds/leds-gpio.c |   12 +++++++++++-
+ 1 files changed, 11 insertions(+), 1 deletions(-)
+
+diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
+index b13bd29..83737e6 100644
+--- a/drivers/leds/leds-gpio.c
++++ b/drivers/leds/leds-gpio.c
+@@ -90,13 +90,19 @@ static int gpio_led_probe(struct platform_device *pdev)
+ 		cur_led = &pdata->leds[i];
+ 		led_dat = &leds_data[i];
+ 
++		/* skip leds that aren't available */
++		led_dat->gpio = cur_led->gpio;
++		if (!gpio_is_valid(led_dat->gpio)) {
++			dev_dbg(&pdev->dev, "skipping %s\n", cur_led->name);
++			continue;
++		}
++
+ 		ret = gpio_request(cur_led->gpio, cur_led->name);
+ 		if (ret < 0)
+ 			goto err;
+ 
+ 		led_dat->cdev.name = cur_led->name;
+ 		led_dat->cdev.default_trigger = cur_led->default_trigger;
+-		led_dat->gpio = cur_led->gpio;
+ 		led_dat->can_sleep = gpio_cansleep(cur_led->gpio);
+ 		led_dat->active_low = cur_led->active_low;
+ 		if (pdata->gpio_blink_set) {
+@@ -124,6 +130,8 @@ static int gpio_led_probe(struct platform_device *pdev)
+ err:
+ 	if (i > 0) {
+ 		for (i = i - 1; i >= 0; i--) {
++			if (!gpio_is_valid(leds_data[i].gpio))
++				continue;
+ 			led_classdev_unregister(&leds_data[i].cdev);
+ 			cancel_work_sync(&leds_data[i].work);
+ 			gpio_free(leds_data[i].gpio);
+@@ -144,6 +152,8 @@ static int __devexit gpio_led_remove(struct platform_device *pdev)
+ 	leds_data = platform_get_drvdata(pdev);
+ 
+ 	for (i = 0; i < pdata->num_leds; i++) {
++		if (!gpio_is_valid(leds_data[i].gpio))
++			continue;
+ 		led_classdev_unregister(&leds_data[i].cdev);
+ 		cancel_work_sync(&leds_data[i].work);
+ 		gpio_free(leds_data[i].gpio);
+-- 
+1.6.0.4.790.gaa14a
+
diff --git a/recipes/linux/linux-omap-2.6.28/ioremap-fix.patch b/recipes/linux/linux-omap-2.6.28/ioremap-fix.patch
new file mode 100644
index 0000000000..406138b04d
--- /dev/null
+++ b/recipes/linux/linux-omap-2.6.28/ioremap-fix.patch
@@ -0,0 +1,75 @@
+From: Russell King <rmk@dyn-67.arm.linux.org.uk>
+Date: Sun, 25 Jan 2009 17:36:34 +0000 (+0000)
+Subject: [ARM] fix section-based ioremap
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fkhilman%2Flinux-omap-pm.git;a=commitdiff_plain;h=9ae635f00a568cf95dbd15fa2c50eaee0aa27d2a
+
+[ARM] fix section-based ioremap
+
+Tomi Valkeinen reports:
+  Running with latest linux-omap kernel on OMAP3 SDP board, I have
+  problem with iounmap(). It looks like iounmap() does not properly
+  free large areas. Below is a test which fails for me in 6-7 loops.
+
+	for (i = 0; i < 200; ++i) {
+		vaddr = ioremap(paddr, size);
+		if (!vaddr) {
+			printk("couldn't ioremap\n");
+			break;
+		}
+		iounmap(vaddr);
+	}
+
+The changes to vmalloc.c weren't reflected in the ARM ioremap
+implementation.  Turns out the fix is rather simple.
+
+Tested-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
+Tested-by: Matt Gerassimoff <mgeras@gmail.com>
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+(cherry picked from commit 24f11ec001920f1cfaeeed8e8b55725d900bbb56)
+---
+
+diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
+index 18373f7..9f88dd3 100644
+--- a/arch/arm/mm/ioremap.c
++++ b/arch/arm/mm/ioremap.c
+@@ -138,7 +138,7 @@ void __check_kvm_seq(struct mm_struct *mm)
+  */
+ static void unmap_area_sections(unsigned long virt, unsigned long size)
+ {
+-	unsigned long addr = virt, end = virt + (size & ~SZ_1M);
++	unsigned long addr = virt, end = virt + (size & ~(SZ_1M - 1));
+ 	pgd_t *pgd;
+ 
+ 	flush_cache_vunmap(addr, end);
+@@ -337,10 +337,7 @@ void __iounmap(volatile void __iomem *io_addr)
+ 	void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr);
+ #ifndef CONFIG_SMP
+ 	struct vm_struct **p, *tmp;
+-#endif
+-	unsigned int section_mapping = 0;
+ 
+-#ifndef CONFIG_SMP
+ 	/*
+ 	 * If this is a section based mapping we need to handle it
+ 	 * specially as the VM subsystem does not know how to handle
+@@ -352,11 +349,8 @@ void __iounmap(volatile void __iomem *io_addr)
+ 	for (p = &vmlist ; (tmp = *p) ; p = &tmp->next) {
+ 		if ((tmp->flags & VM_IOREMAP) && (tmp->addr == addr)) {
+ 			if (tmp->flags & VM_ARM_SECTION_MAPPING) {
+-				*p = tmp->next;
+ 				unmap_area_sections((unsigned long)tmp->addr,
+ 						    tmp->size);
+-				kfree(tmp);
+-				section_mapping = 1;
+ 			}
+ 			break;
+ 		}
+@@ -364,7 +358,6 @@ void __iounmap(volatile void __iomem *io_addr)
+ 	write_unlock(&vmlist_lock);
+ #endif
+ 
+-	if (!section_mapping)
+-		vunmap(addr);
++	vunmap(addr);
+ }
+ EXPORT_SYMBOL(__iounmap);