summaryrefslogtreecommitdiff
path: root/recipes/linux/linux-omap-pm
diff options
context:
space:
mode:
authorKoen Kooi <koen@openembedded.org>2009-03-19 11:32:06 +0100
committerKoen Kooi <koen@openembedded.org>2009-03-19 11:32:06 +0100
commitebd561bc14a9a0883ad7c0ef2a6560ec9ae6824a (patch)
tree20eb796ad4af13c056223c9da31ecbf01e7dac79 /recipes/linux/linux-omap-pm
parent2612236bf6abf8ebd98fac5359f3b1b830404ed5 (diff)
linux-omap-pm: add 2.6.28 recipe so git can move to .29rc
Diffstat (limited to 'recipes/linux/linux-omap-pm')
-rw-r--r--recipes/linux/linux-omap-pm/0124-leds-gpio-broken-with-current-git.patch79
-rw-r--r--recipes/linux/linux-omap-pm/fixup-evm-cpufreq.diff44
-rw-r--r--recipes/linux/linux-omap-pm/ioremap-fix.patch75
3 files changed, 198 insertions, 0 deletions
diff --git a/recipes/linux/linux-omap-pm/0124-leds-gpio-broken-with-current-git.patch b/recipes/linux/linux-omap-pm/0124-leds-gpio-broken-with-current-git.patch
new file mode 100644
index 0000000000..dc6e190e89
--- /dev/null
+++ b/recipes/linux/linux-omap-pm/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-pm/fixup-evm-cpufreq.diff b/recipes/linux/linux-omap-pm/fixup-evm-cpufreq.diff
new file mode 100644
index 0000000000..fda1b6ddd9
--- /dev/null
+++ b/recipes/linux/linux-omap-pm/fixup-evm-cpufreq.diff
@@ -0,0 +1,44 @@
+From: Kevin Hilman <khilman@deeprootsystems.com>
+Date: Mon, 2 Mar 2009 21:57:31 +0000 (-0800)
+Subject: OMAP3: PM: CPUfreq support for OMAP3EVM board
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fkhilman%2Flinux-omap-pm.git;a=commitdiff_plain;h=e10fda5f6106c6e0a559c3a4720ebff7a8bb1a43
+
+OMAP3: PM: CPUfreq support for OMAP3EVM board
+
+From: Koen Kooi <koen@beagleboard.org>
+
+Uses the common OMAP3 OPP settings on OMAP3 EVM board.
+
+Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
+---
+
+diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
+index 6fbbe95..072930a 100644
+--- a/arch/arm/mach-omap2/board-omap3evm.c
++++ b/arch/arm/mach-omap2/board-omap3evm.c
+@@ -36,14 +36,11 @@
+ #include <mach/usb-ehci.h>
+ #include <mach/common.h>
+ #include <mach/mcspi.h>
+-#include <mach/omap-pm.h>
+-#include <mach/clock.h>
+
+ #include "sdram-micron-mt46h32m32lf-6.h"
+ #include "twl4030-generic-scripts.h"
+ #include "mmc-twl4030.h"
+-#include "pm.h"
+-#include "omap3-opp.h"
++
+
+ static struct resource omap3evm_smc911x_resources[] = {
+ [0] = {
+@@ -220,8 +217,7 @@ struct spi_board_info omap3evm_spi_board_info[] = {
+
+ static void __init omap3_evm_init_irq(void)
+ {
+- omap2_init_common_hw(mt46h32m32lf6_sdrc_params, omap3_mpu_rate_table,
+- omap3_dsp_rate_table, omap3_l3_rate_table);
++ omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL, NULL, NULL);
+ omap_init_irq();
+ omap_gpio_init();
+ omap3evm_init_smc911x();
diff --git a/recipes/linux/linux-omap-pm/ioremap-fix.patch b/recipes/linux/linux-omap-pm/ioremap-fix.patch
new file mode 100644
index 0000000000..406138b04d
--- /dev/null
+++ b/recipes/linux/linux-omap-pm/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);