* [PATCH 6/6] Fix eseries compilation if w100fb is not compiled in kernel
From: Dmitry Eremin-Solenikov @ 2011-01-05 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294193110-23958-1-git-send-email-dbaryshkov@gmail.com>
e800_tg_change depends on w100fb_gpio_read/write API which is only present
if w100fb is compiled in kernel.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Ian Molton <ian@mnementh.co.uk>
---
arch/arm/mach-pxa/eseries.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-pxa/eseries.c b/arch/arm/mach-pxa/eseries.c
index b25690c..ed2c157 100644
--- a/arch/arm/mach-pxa/eseries.c
+++ b/arch/arm/mach-pxa/eseries.c
@@ -829,6 +829,7 @@ static struct w100_mem_info e800_w100_mem_info = {
static void e800_tg_change(struct w100fb_par *par)
{
+#ifdef FB_W100
unsigned long tmp;
tmp = w100fb_gpio_read(W100_GPIO_PORT_A);
@@ -837,6 +838,7 @@ static void e800_tg_change(struct w100fb_par *par)
else
tmp &= ~0x100;
w100fb_gpio_write(W100_GPIO_PORT_A, tmp);
+#endif
}
static struct w100_tg_info e800_tg_info = {
--
1.7.2.3
^ permalink raw reply related
* [PATCH 5/6] pcmcia: limit pxa2xx_trizeps4 subdriver to trizeps4 platform
From: Dmitry Eremin-Solenikov @ 2011-01-05 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294193110-23958-1-git-send-email-dbaryshkov@gmail.com>
pxa2xx_trizeps4 tries to register pxa2xx-pcmcia device not checking whether
machine is really trizeps4, thus messing multi-machine kernels. Fix it up.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/pcmcia/pxa2xx_trizeps4.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/pcmcia/pxa2xx_trizeps4.c b/drivers/pcmcia/pxa2xx_trizeps4.c
index b7e5966..5bb4e1a 100644
--- a/drivers/pcmcia/pxa2xx_trizeps4.c
+++ b/drivers/pcmcia/pxa2xx_trizeps4.c
@@ -226,6 +226,9 @@ static int __init trizeps_pcmcia_init(void)
{
int ret;
+ if (!machine_is_trizeps4() && !machine_is_trizeps4wl())
+ return -ENODEV;
+
trizeps_pcmcia_device = platform_device_alloc("pxa2xx-pcmcia", -1);
if (!trizeps_pcmcia_device)
return -ENOMEM;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/6] pcmcia: limit pxa2xx_balloon3 subdriver to balloon3 platform
From: Dmitry Eremin-Solenikov @ 2011-01-05 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294193110-23958-1-git-send-email-dbaryshkov@gmail.com>
pxa2xx_balloon3 tries to register pxa2xx-pcmcia device not checking whether
machine is really balloon3, thus messing multi-machine kernels. Fix it up.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/pcmcia/pxa2xx_balloon3.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/pcmcia/pxa2xx_balloon3.c b/drivers/pcmcia/pxa2xx_balloon3.c
index dbbdd00..0b1caca 100644
--- a/drivers/pcmcia/pxa2xx_balloon3.c
+++ b/drivers/pcmcia/pxa2xx_balloon3.c
@@ -25,6 +25,8 @@
#include <mach/balloon3.h>
+#include <asm/mach-types.h>
+
#include "soc_common.h"
/*
@@ -128,6 +130,9 @@ static int __init balloon3_pcmcia_init(void)
{
int ret;
+ if (!machine_is_balloon3())
+ return -ENODEV;
+
balloon3_pcmcia_device = platform_device_alloc("pxa2xx-pcmcia", -1);
if (!balloon3_pcmcia_device)
return -ENOMEM;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/6] pxa2xx: update stored gpio settings in pxa2xx_mfp_set_lpm()
From: Dmitry Eremin-Solenikov @ 2011-01-05 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294193110-23958-1-git-send-email-dbaryshkov@gmail.com>
pxa2xx_mfp_set_lpm() reconfigures MFP, but doesn't update gpio_desc cache. Fix that.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/arm/mach-pxa/mfp-pxa2xx.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-pxa/mfp-pxa2xx.c b/arch/arm/mach-pxa/mfp-pxa2xx.c
index 1d1419b..7a6e122 100644
--- a/arch/arm/mach-pxa/mfp-pxa2xx.c
+++ b/arch/arm/mach-pxa/mfp-pxa2xx.c
@@ -160,6 +160,7 @@ void pxa2xx_mfp_set_lpm(int mfp, unsigned long lpm)
c = gpio_desc[gpio].config;
c = (c & ~MFP_LPM_STATE_MASK) | lpm;
+ gpio_desc[gpio].config = c;
__mfp_config_gpio(gpio, c);
local_irq_restore(flags);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/6] mfp-pxa27x: correct naming of GPIO13_KP_DKIN_7
From: Dmitry Eremin-Solenikov @ 2011-01-05 2:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294193110-23958-1-git-send-email-dbaryshkov@gmail.com>
Correct naming of one of pin functions: it's GPIO13_KP_DKIN_7, not
GPIO13_KP_KDIN_7.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/arm/mach-pxa/include/mach/mfp-pxa27x.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h b/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
index ec0f0b0..6553d62 100644
--- a/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
+++ b/arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
@@ -300,7 +300,7 @@
#define GPIO97_KP_DKIN_4 MFP_CFG_IN(GPIO97, AF1)
#define GPIO98_KP_DKIN_5 MFP_CFG_IN(GPIO98, AF1)
#define GPIO99_KP_DKIN_6 MFP_CFG_IN(GPIO99, AF1)
-#define GPIO13_KP_KDIN_7 MFP_CFG_IN(GPIO13, AF2)
+#define GPIO13_KP_DKIN_7 MFP_CFG_IN(GPIO13, AF2)
#define GPIO100_KP_MKIN_0 MFP_CFG_IN(GPIO100, AF1)
#define GPIO101_KP_MKIN_1 MFP_CFG_IN(GPIO101, AF1)
#define GPIO102_KP_MKIN_2 MFP_CFG_IN(GPIO102, AF1)
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/6] i2c-pxa: move i2c_pxa_remove to __devexit instead of just __exit
From: Dmitry Eremin-Solenikov @ 2011-01-05 2:05 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: linux-i2c at vger.kernel.org
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/i2c/busses/i2c-pxa.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index f4c19a9..0f10955 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1115,7 +1115,7 @@ emalloc:
return ret;
}
-static int __exit i2c_pxa_remove(struct platform_device *dev)
+static int __devexit i2c_pxa_remove(struct platform_device *dev)
{
struct pxa_i2c *i2c = platform_get_drvdata(dev);
@@ -1169,7 +1169,7 @@ static const struct dev_pm_ops i2c_pxa_dev_pm_ops = {
static struct platform_driver i2c_pxa_driver = {
.probe = i2c_pxa_probe,
- .remove = __exit_p(i2c_pxa_remove),
+ .remove = __devexit_p(i2c_pxa_remove),
.driver = {
.name = "pxa2xx-i2c",
.owner = THIS_MODULE,
--
1.7.2.3
^ permalink raw reply related
* [PATCH 5/5] omap2+: pm_bus: make functions used as pointers as static
From: Kevin Hilman @ 2011-01-05 0:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294171634-13943-6-git-send-email-nm@ti.com>
Nishanth Menon <nm@ti.com> writes:
> omap_pm_runtime_suspend and omap_pm_runtime_resume are used
> as function pointers and does not really need to be exposed
> to the world.
>
> Fixes sparse warnings:
> arch/arm/mach-omap2/pm_bus.c:23:5: warning: symbol 'omap_pm_runtime_suspend' was not declared. Should it be static?
> arch/arm/mach-omap2/pm_bus.c:40:5: warning: symbol 'omap_pm_runtime_resume' was not declared. Should it be static?
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Thanks, will queue this one in my pm-fixes branch for 2.6.38-rc.
Kevin
> ---
> arch/arm/mach-omap2/pm_bus.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm_bus.c b/arch/arm/mach-omap2/pm_bus.c
> index 784989f..5acd2ab 100644
> --- a/arch/arm/mach-omap2/pm_bus.c
> +++ b/arch/arm/mach-omap2/pm_bus.c
> @@ -20,7 +20,7 @@
> #include <plat/omap-pm.h>
>
> #ifdef CONFIG_PM_RUNTIME
> -int omap_pm_runtime_suspend(struct device *dev)
> +static int omap_pm_runtime_suspend(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> int r, ret = 0;
> @@ -37,7 +37,7 @@ int omap_pm_runtime_suspend(struct device *dev)
> return ret;
> };
>
> -int omap_pm_runtime_resume(struct device *dev)
> +static int omap_pm_runtime_resume(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> int r;
^ permalink raw reply
* [PATCH 0/5] omap2plus: Trivial build break fixes
From: Kevin Hilman @ 2011-01-05 0:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294165576-15628-1-git-send-email-santosh.shilimkar@ti.com>
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> These are trivial build fixes which I found while doing some
> testing 'omap-for-linus' branch.
>
> The series is generated against the linux-omap 'omap-for-linus' branch
> and boot tested on OMAP4430 SDP and OMAP3630 ZOOM.
Minor nit in your git-send-email config.
Can you add the following to your ~/.gitconfig, or update to newer git
where this is now the default:
[sendemail]
chainreplyto = false
This will make all patches a reply to PATCH 0 instead of to the previous
patch.
Thanks,
Kevin
>
>
> The following changes since commit dc69d1af9e8d9cbbabff88bb35a6782187a22229:
> Ben Gamari (1):
> omap2: Make OMAP2PLUS select OMAP_DM_TIMER
>
>
> Santosh Shilimkar (5):
> omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
> omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
> omap2plus: voltage: Trivial warning fix 'no return statement'
> omap2plus: voltage: Trivial linking fix 'undefined reference'
> omap2plus: voltage: Trivial linking fix for 'EINVAL' undeclared
>
> arch/arm/mach-omap2/Makefile | 2 +-
> arch/arm/mach-omap2/clockdomain.h | 2 +-
> arch/arm/mach-omap2/prm2xxx_3xxx.h | 45 ++++++++++++++++++++++++++++-
> arch/arm/plat-omap/include/plat/voltage.h | 17 ++++++++--
> 4 files changed, 59 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH] [ARM] orion5x: accelerate NAND on the TS-78xx
From: Russell King - ARM Linux @ 2011-01-05 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104235158.GQ12386@chipmunk>
On Tue, Jan 04, 2011 at 11:51:59PM +0000, Alexander Clouter wrote:
> The NAND supports 32bit reads and writes so lets stop shunting 8bit
> chunks across the bus.
>
> Doing a dumb 'dd' benchmark, this increases performance roughly like so:
> * read: 1.3MB/s to 3.4MB/s
> * write: 614kB/s to 882kB/s
Try something like the below. It's slightly more typing, but the
underlying string IO functions should improve your transfer speed.
Note that they won't do endian conversions.
>
> Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
> ---
> arch/arm/mach-orion5x/ts78xx-setup.c | 42 ++++++++++++++++++++++++++++++++++
> 1 files changed, 42 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-orion5x/ts78xx-setup.c
> index 9a5d1ef..bcc21fe 100644
> --- a/arch/arm/mach-orion5x/ts78xx-setup.c
> +++ b/arch/arm/mach-orion5x/ts78xx-setup.c
> @@ -191,6 +191,46 @@ static int ts78xx_ts_nand_dev_ready(struct mtd_info *mtd)
> return readb(TS_NAND_CTRL) & 0x20;
> }
>
> +static void ts78xx_ts_nand_write_buf(struct mtd_info *mtd,
> + const uint8_t *buf, int len)
> +{
> + struct nand_chip *chip = mtd->priv;
> + void __iomem *io_base = chip->IO_ADDR_W;
> + uint32_t *buf32;
> + int i = 0;
> +
> + while (len && (unsigned int)buf & 3) {
> + writeb(*buf++, io_base);
> + len--;
> + }
> + buf32 = (uint32_t *)buf;
> + while (i < len/4)
> + writel(buf32[i++], io_base);
> + i *= 4;
> + while (i < len)
> + writeb(buf[i++], io_base);
unsigned long off = ((unsigned long)buf & 3);
int sz;
if (off) {
sz = min(4 - off, len);
writesb(io_base, buf, sz);
buf += sz;
len -= sz;
}
sz = len >> 2;
if (sz) {
u32 *buf32 = (u32 *)buf;
writesl(io_base, buf32, sz);
buf += sz << 2;
len -= sz << 2;
}
if (len)
writesb(io_base, buf, len);
> +}
> +
> +static void ts78xx_ts_nand_read_buf(struct mtd_info *mtd,
> + uint8_t *buf, int len)
> +{
> + struct nand_chip *chip = mtd->priv;
> + void __iomem *io_base = chip->IO_ADDR_R;
> + uint32_t *buf32;
> + int i = 0;
> +
> + while (len && (unsigned int)buf & 3) {
> + *buf++ = readb(io_base);
> + len--;
> + }
> + buf32 = (uint32_t *)buf;
> + while (i < len/4)
> + buf32[i++] = readl(io_base);
> + i *= 4;
> + while (i < len)
> + buf[i++] = readb(io_base);
unsigned long off = ((unsigned long)buf & 3);
int sz;
if (off) {
sz = min(4 - off, len);
readsb(io_base, buf, sz);
buf += sz;
len -= sz;
}
sz = len >> 2;
if (sz) {
u32 *buf32 = (u32 *)buf;
readsl(io_base, buf32, sz);
buf += sz << 2;
len -= sz << 2;
}
if (len)
readsb(io_base, buf, len);
> +}
> +
> const char *ts_nand_part_probes[] = { "cmdlinepart", NULL };
>
> static struct mtd_partition ts78xx_ts_nand_parts[] = {
> @@ -233,6 +273,8 @@ static struct platform_nand_data ts78xx_ts_nand_data = {
> */
> .cmd_ctrl = ts78xx_ts_nand_cmd_ctrl,
> .dev_ready = ts78xx_ts_nand_dev_ready,
> + .write_buf = ts78xx_ts_nand_write_buf,
> + .read_buf = ts78xx_ts_nand_read_buf,
> },
> };
>
> --
> 1.7.2.3
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
From: Kevin Hilman @ 2011-01-05 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cc76ecb39b950683cd12d254968e851c@mail.gmail.com>
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>> -----Original Message-----
>> From: Paul Walmsley [mailto:paul at pwsan.com]
>> Sent: Wednesday, January 05, 2011 12:11 AM
>> To: Santosh Shilimkar
>> Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com;
>> linux-arm-kernel at lists.infradead.org
>> Subject: Re: [PATCH 2/5] omap2plus: prm: Trvial build break fix for
>> undefined reference to 'omap2_prm_read_mod_reg'
>>
>> Hi Santosh,
>>
>> On Tue, 4 Jan 2011, Santosh Shilimkar wrote:
>>
>> > omap2plus_defocnfig build breaks when customised with only
>> ARCH_OMAP4
>> > selected. This is because common files make references to the
>> functions
>> > which are defined only for omap2xxx and omap3xxx.
>> >
>> > LD .tmp_vmlinux1
>> > arch/arm/mach-omap2/built-in.o: In function `pm_dbg_regset_store':
>> > arch/arm/mach-omap2/pm-debug.c:335: undefined reference to
>> `omap2_prm_read_mod_reg'
>> > arch/arm/mach-omap2/built-in.o: In function `omap2_pm_dump':
>> > arch/arm/mach-omap2/pm-debug.c:121: undefined reference to
>> `omap2_prm_read_mod_reg'
>> > arch/arm/mach-omap2/pm-debug.c:123: undefined reference to
>> `omap2_prm_read_mod_reg'
>> > arch/arm/mach-omap2/pm-debug.c:124: undefined reference to
>> `omap2_prm_read_mod_reg'
>> > arch/arm/mach-omap2/pm-debug.c:125: undefined reference to
>> `omap2_prm_read_mod_reg'
>> > arch/arm/mach-omap2/built-in.o: In function
>> `omap_prcm_arch_reset':
>> > arch/arm/mach-omap2/prcm.c:106: undefined reference to
>> `omap2_prm_set_mod_reg_bits'
>> > arch/arm/mach-omap2/prcm.c:108: undefined reference to
>> `omap2_prm_read_mod_reg'
>> > arch/arm/mach-omap2/built-in.o: In function
>> `omap_prcm_get_reset_sources':
>> > arch/arm/mach-omap2/prcm.c:53: undefined reference to
>> `omap2_prm_read_mod_reg'
>> > arch/arm/mach-omap2/built-in.o: In function
>> `clkdm_clear_all_wkdeps':
>> > arch/arm/mach-omap2/clockdomain.c:545: undefined reference to
>> `omap2_prm_clear_mod_reg_bits'
>> > arch/arm/mach-omap2/built-in.o: In function `clkdm_del_wkdep':
>> > arch/arm/mach-omap2/clockdomain.c:475: undefined reference to
>> `omap2_prm_clear_mod_reg_bits'
>> > arch/arm/mach-omap2/built-in.o: In function `clkdm_read_wkdep':
>> > arch/arm/mach-omap2/clockdomain.c:511: undefined reference to
>> `omap2_prm_read_mod_bits_shift'
>> > arch/arm/mach-omap2/built-in.o: In function `clkdm_add_wkdep':
>> > arch/arm/mach-omap2/clockdomain.c:440: undefined reference to
>> `omap2_prm_set_mod_reg_bits'
>> > make: *** [.tmp_vmlinux1] Error 1
>> >
>> > This patch adds stubs for these functions so that build continues
>> to work.
>> >
>> > Probably alternately the build can be fixed as below but that not
>> seems to
>> > be the right way.
>>
>> Since these functions now return 0, maybe it would be better to call
>> WARN() or BUG() in these functions for OMAP4. Otherwise, they are
>> going
>> to silently do the wrong thing, and someone needs to fix any usage
>> of
>> these functions where they shouldn't be used. e.g., in mach-
>> omap2/prcm.c
>> or mach-omap2/pm-debug.c ...
>>
> Good point. Will update the patch accordingly and repost.
Please use WARN() instead of BUG() as this is not worthy of causing a
panic() for the whole kernel.
Kevin
^ permalink raw reply
* [PATCH 0/2] OMAP: TWL: sparse fixes
From: Russell King - ARM Linux @ 2011-01-05 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D238503.6070103@ti.com>
On Tue, Jan 04, 2011 at 02:37:23PM -0600, Nishanth Menon wrote:
> hmm.. minor nit (with codesourcery 2010.09-50 - 4.5.1):
> rm arch/arm/mach-omap2/*.o;make C=1 arch/arm/mach-omap2/ 2>Kerr;make C=2
> arch/arm/mach-omap2/ 2>Kerr1;diff Kerr Kerr1
> [..]
> 1,4d0
> < arch/arm/mach-omap2/mux.c: In function 'omap_mux_get_by_name':
> < arch/arm/mach-omap2/mux.c:163:17: warning: 'found_mode' may be used
> uninitialized in this function
> < arch/arm/mach-omap2/clkt_clksel.c: In function 'omap2_clksel_set_parent':
> < arch/arm/mach-omap2/clkt_clksel.c:100:35: warning: 'max_clkr' may be
> used uninitialized in this function
>
> Kinda interesting to note that C=2 does'nt list all potential gcc
> warnings :( if one wanted a collated list of all warnings, rm .../*.o
> helps I guess.
C=2 only runs sparse - so if you're committing patches to fix sparse
warnings, that's what you should be interested in.
I'd suggest that fixing sparse warnings and GCC warnings in a single
patch is probably not the best thing to do - GCC warnings are less
subjective than sparse warnings.
^ permalink raw reply
* [PATCH 1/4] arm: omap: gpio: don't access irq_desc array directly
From: Kevin Hilman @ 2011-01-05 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294142577-28772-2-git-send-email-balbi@ti.com>
Felipe Balbi <balbi@ti.com> writes:
> Instead of accessing the irq_desc array directly
> we can use irq_to_desc(irq). That will allow us to,
> if wanted, select SPARSE_IRQ and irq_descs will be
> added to a radix tree, instead of a array.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Can you refresh this one against Tony's omap-for-linus branch. The GPIO
omap_device/hwmod conversion changed things around a bit and this patch
doesn't apply.
After that, you can send separately, and I'll queue this one along with
some other GPIO core fixes for the 2.6.38-rc series after -rc1 comes
out.
Kevin
> ---
> arch/arm/plat-omap/gpio.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index c05c653..c351758 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -905,8 +905,10 @@ static int gpio_irq_type(unsigned irq, unsigned type)
> spin_lock_irqsave(&bank->lock, flags);
> retval = _set_gpio_triggering(bank, get_gpio_index(gpio), type);
> if (retval == 0) {
> - irq_desc[irq].status &= ~IRQ_TYPE_SENSE_MASK;
> - irq_desc[irq].status |= type;
> + struct irq_desc *d = irq_to_desc(irq);
> +
> + d->status &= ~IRQ_TYPE_SENSE_MASK;
> + d->status |= type;
> }
> spin_unlock_irqrestore(&bank->lock, flags);
>
> @@ -1925,7 +1927,9 @@ static int __init _omap_gpio_init(void)
>
> for (j = bank->virtual_irq_start;
> j < bank->virtual_irq_start + gpio_count; j++) {
> - lockdep_set_class(&irq_desc[j].lock, &gpio_lock_class);
> + struct irq_desc *d = irq_to_desc(j);
> +
> + lockdep_set_class(&d->lock, &gpio_lock_class);
> set_irq_chip_data(j, bank);
> if (bank_is_mpuio(bank))
> set_irq_chip(j, &mpuio_irq_chip);
^ permalink raw reply
* [RFC 5/5] ARM: P2V: extend to 16-bit translation offsets
From: Russell King - ARM Linux @ 2011-01-05 0:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101041628060.22191@xanadu.home>
On Tue, Jan 04, 2011 at 04:41:34PM -0500, Nicolas Pitre wrote:
> I'd suggest making the type argument into a mask instead, something
> like:
>
> __pv_stub(x, t, "add", 0xff000000);
> #ifdef CONFIG_ARM_PATCH_PHYS_VIRT_16BIT
> __pv_stub(t, t, "add", 0x00ff0000);
> #endif
>
> Reasons for this are multiple:
>
> - This would simplifies the patching code as the rotation bitfield in
> the instruction would already be set appropriately for the desired
> value by the assembler. Would only suffice to test one bit in that
> field to determine the required constant to patch in.
>
> - For the Thumb2 build, we want the assembler to select the appropriate
> encoding flavor for the add instruction from all the possibilities.
> Giving it a constant with all bits set nicely solves this issue.
>
> If further distinctions are needed in the future then we can use the 6
> middle bits to encode alternatives.
Lets go with 0x81000000 and 0x0081000000 for the first then. We can
count up with the 6-bit value from there.
^ permalink raw reply
* [RFC 5/5] ARM: P2V: extend to 16-bit translation offsets
From: Russell King - ARM Linux @ 2011-01-05 0:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8yabp3wfeax.fsf@huya.qualcomm.com>
On Tue, Jan 04, 2011 at 03:18:46PM -0800, David Brown wrote:
> On Tue, Jan 04 2011, Russell King - ARM Linux wrote:
>
> > MSM's memory is aligned to 2MB, which is more than we can do with our
> > existing method as we're limited to the upper 8 bits. Extend this by
> > using two instructions to 16 bits, automatically selected when MSM is
> > enabled.
>
> I should also add that this series adds a warning to my build when
> CONFIG_ARM_PATCH_PHYS_VIRT is not defined:
>
> arch/arm/kernel/module.c:279: error: 'find_mod_section' defined but not used
Hmm, probably best to mark this with __maybe_unused.
Also note that I messed up the 16-23 bit shift value in this patch - it
needs:
- orr r0, r0, #0x400 @ mask in rotate right 8 bits
+ orr r0, r0, #0x800 @ mask in rotate right 16 bits
^ permalink raw reply
* [RFC 4/5] ARM: P2V: introduce phys_to_virt/virt_to_phys runtime patching
From: Russell King - ARM Linux @ 2011-01-05 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101041614090.22191@xanadu.home>
On Tue, Jan 04, 2011 at 04:27:37PM -0500, Nicolas Pitre wrote:
> On Tue, 4 Jan 2011, Russell King - ARM Linux wrote:
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index f67e682..7c5499d 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -804,7 +804,7 @@ void __init setup_arch(char **cmdline_p)
> > struct machine_desc *mdesc;
> > char *from = default_command_line;
> >
> > - tags->mem.start = PHYS_OFFSET;
> > + init_tags.mem.start = PHYS_OFFSET;
>
> Doesn't this belong in 2/5 instead?
It's actually the result of using interdiff with the original patch...
It'll get killed shortly.
^ permalink raw reply
* [RFC 1/5] ARM: P2V: separate PHYS_OFFSET from platform definitions
From: Russell King - ARM Linux @ 2011-01-05 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104212359.GH25121@pengutronix.de>
On Tue, Jan 04, 2011 at 10:23:59PM +0100, Uwe Kleine-K?nig wrote:
> Hello Russell,
>
> On Tue, Jan 04, 2011 at 08:22:17PM +0000, Russell King - ARM Linux wrote:
> > This uncouple PHYS_OFFSET from the platform definitions, thereby
> > facilitating run-time computation of the physical memory offset.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> > arch/arm/include/asm/memory.h | 2 ++
> > arch/arm/kernel/tcm.c | 2 +-
> > arch/arm/mach-aaec2000/include/mach/memory.h | 2 +-
> > arch/arm/mach-at91/include/mach/memory.h | 2 +-
> > arch/arm/mach-bcmring/include/mach/hardware.h | 2 +-
> > arch/arm/mach-bcmring/include/mach/memory.h | 2 +-
> > arch/arm/mach-clps711x/include/mach/memory.h | 2 +-
> > arch/arm/mach-cns3xxx/include/mach/memory.h | 2 +-
> > arch/arm/mach-davinci/include/mach/memory.h | 4 ++--
> > arch/arm/mach-dove/include/mach/memory.h | 2 +-
> > arch/arm/mach-ebsa110/include/mach/memory.h | 2 +-
> > arch/arm/mach-ep93xx/include/mach/memory.h | 10 +++++-----
> > arch/arm/mach-footbridge/include/mach/memory.h | 2 +-
> > arch/arm/mach-h720x/include/mach/memory.h | 2 +-
> > arch/arm/mach-integrator/include/mach/memory.h | 2 +-
> > arch/arm/mach-iop13xx/include/mach/memory.h | 2 +-
> > arch/arm/mach-iop32x/include/mach/memory.h | 2 +-
> > arch/arm/mach-iop33x/include/mach/memory.h | 2 +-
> > arch/arm/mach-ixp2000/include/mach/memory.h | 2 +-
> > arch/arm/mach-ixp23xx/include/mach/memory.h | 2 +-
> > arch/arm/mach-ixp4xx/include/mach/memory.h | 2 +-
> > arch/arm/mach-kirkwood/include/mach/memory.h | 2 +-
> > arch/arm/mach-ks8695/include/mach/memory.h | 2 +-
> > arch/arm/mach-lh7a40x/include/mach/memory.h | 2 +-
> > arch/arm/mach-loki/include/mach/memory.h | 2 +-
> > arch/arm/mach-lpc32xx/include/mach/memory.h | 2 +-
> > arch/arm/mach-mmp/include/mach/memory.h | 2 +-
> > arch/arm/mach-msm/board-msm7x30.c | 2 +-
> > arch/arm/mach-msm/include/mach/memory.h | 10 +++++-----
> > arch/arm/mach-mv78xx0/include/mach/memory.h | 2 +-
> > arch/arm/mach-mx3/mach-kzm_arm11_01.c | 2 +-
> > arch/arm/mach-netx/include/mach/memory.h | 2 +-
> > arch/arm/mach-nomadik/include/mach/memory.h | 2 +-
> > arch/arm/mach-ns9xxx/include/mach/memory.h | 2 +-
> > arch/arm/mach-nuc93x/include/mach/memory.h | 2 +-
> > arch/arm/mach-orion5x/include/mach/memory.h | 2 +-
> > arch/arm/mach-pnx4008/include/mach/memory.h | 2 +-
> > arch/arm/mach-pxa/include/mach/memory.h | 2 +-
> > arch/arm/mach-realview/include/mach/memory.h | 4 ++--
> > arch/arm/mach-rpc/include/mach/memory.h | 2 +-
> > arch/arm/mach-s3c2400/include/mach/memory.h | 2 +-
> > arch/arm/mach-s3c2410/include/mach/memory.h | 2 +-
> > arch/arm/mach-s3c24a0/include/mach/memory.h | 2 +-
> > arch/arm/mach-s3c64xx/include/mach/memory.h | 2 +-
> > arch/arm/mach-s5p6442/include/mach/memory.h | 2 +-
> > arch/arm/mach-s5p64x0/include/mach/memory.h | 2 +-
> > arch/arm/mach-s5pc100/include/mach/memory.h | 2 +-
> > arch/arm/mach-s5pv210/include/mach/memory.h | 2 +-
> > arch/arm/mach-s5pv310/include/mach/memory.h | 2 +-
> > arch/arm/mach-sa1100/include/mach/memory.h | 2 +-
> > arch/arm/mach-shark/include/mach/memory.h | 2 +-
> > arch/arm/mach-shmobile/include/mach/memory.h | 2 +-
> > arch/arm/mach-tegra/include/mach/memory.h | 2 +-
> > arch/arm/mach-u300/include/mach/memory.h | 6 +++---
> > arch/arm/mach-u300/u300.c | 2 +-
> > arch/arm/mach-ux500/include/mach/memory.h | 2 +-
> > arch/arm/mach-versatile/include/mach/memory.h | 2 +-
> > arch/arm/mach-vexpress/include/mach/memory.h | 2 +-
> > arch/arm/mach-w90x900/include/mach/memory.h | 2 +-
> > arch/arm/plat-omap/include/plat/memory.h | 4 ++--
> > arch/arm/plat-spear/include/plat/memory.h | 2 +-
> > arch/arm/plat-stmp3xxx/include/mach/memory.h | 2 +-
> > arch/arm/plat-tcc/include/mach/memory.h | 2 +-
> > 63 files changed, 77 insertions(+), 75 deletions(-)
> You didn't touch arch/arm/plat-mxc/include/mach/memory.h which defines
> PHYS_OFFSET, too. I assume you just missed these?
Grr.
That's because it didn't match the '#define *PHYS_OFFSET' regexp I used
to find all the definitions. This is exactly why being different from
everyone else is a bad idea - you get missed.
^ permalink raw reply
* [PATCH] [ARM] orion5x: accelerate NAND on the TS-78xx
From: Alexander Clouter @ 2011-01-04 23:51 UTC (permalink / raw)
To: linux-arm-kernel
The NAND supports 32bit reads and writes so lets stop shunting 8bit
chunks across the bus.
Doing a dumb 'dd' benchmark, this increases performance roughly like so:
* read: 1.3MB/s to 3.4MB/s
* write: 614kB/s to 882kB/s
Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
---
arch/arm/mach-orion5x/ts78xx-setup.c | 42 ++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c b/arch/arm/mach-orion5x/ts78xx-setup.c
index 9a5d1ef..bcc21fe 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -191,6 +191,46 @@ static int ts78xx_ts_nand_dev_ready(struct mtd_info *mtd)
return readb(TS_NAND_CTRL) & 0x20;
}
+static void ts78xx_ts_nand_write_buf(struct mtd_info *mtd,
+ const uint8_t *buf, int len)
+{
+ struct nand_chip *chip = mtd->priv;
+ void __iomem *io_base = chip->IO_ADDR_W;
+ uint32_t *buf32;
+ int i = 0;
+
+ while (len && (unsigned int)buf & 3) {
+ writeb(*buf++, io_base);
+ len--;
+ }
+ buf32 = (uint32_t *)buf;
+ while (i < len/4)
+ writel(buf32[i++], io_base);
+ i *= 4;
+ while (i < len)
+ writeb(buf[i++], io_base);
+}
+
+static void ts78xx_ts_nand_read_buf(struct mtd_info *mtd,
+ uint8_t *buf, int len)
+{
+ struct nand_chip *chip = mtd->priv;
+ void __iomem *io_base = chip->IO_ADDR_R;
+ uint32_t *buf32;
+ int i = 0;
+
+ while (len && (unsigned int)buf & 3) {
+ *buf++ = readb(io_base);
+ len--;
+ }
+ buf32 = (uint32_t *)buf;
+ while (i < len/4)
+ buf32[i++] = readl(io_base);
+ i *= 4;
+ while (i < len)
+ buf[i++] = readb(io_base);
+}
+
const char *ts_nand_part_probes[] = { "cmdlinepart", NULL };
static struct mtd_partition ts78xx_ts_nand_parts[] = {
@@ -233,6 +273,8 @@ static struct platform_nand_data ts78xx_ts_nand_data = {
*/
.cmd_ctrl = ts78xx_ts_nand_cmd_ctrl,
.dev_ready = ts78xx_ts_nand_dev_ready,
+ .write_buf = ts78xx_ts_nand_write_buf,
+ .read_buf = ts78xx_ts_nand_read_buf,
},
};
--
1.7.2.3
^ permalink raw reply related
* [PATCH] leds/h1940: Use gpiolib for latch access / fix build failure
From: Andrew Morton @ 2011-01-04 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201012100016.58130.anarsoul@gmail.com>
On Fri, 10 Dec 2010 00:16:57 +0200
Vasily Khoruzhick <anarsoul@gmail.com> wrote:
> On Friday 10 December 2010 00:04:52 Peter Huewe wrote:
> > This patch fixes a build failure by converting leds-h1940.c to use
> > gpiolib for latch access introduced by 14477095abc6
> > (ARM: h1940: Use gpiolib for latch access)
> >
> > Unfortunately this driver was not converted back then.
>
> I sent similar patch (however, my patch does gpio_request/gpio_free) ~month
> ago.
>
> Here's link:
> http://www.spinics.net/lists/arm-kernel/msg103429.html
>
So which patch to use?
I queued Peter's patch because it's simpler. I queued it for
2.6.38-rc1, taged for backporting into 2.6.37.x, so we have a bit of
time to think about it.
^ permalink raw reply
* [PATCH v3 1/2] ARM i.MX53: Some bug fix about MX53 MSL code
From: Fabio Estevam @ 2011-01-04 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimhxmJNgC7=0kdr022VX605rsweiJ8_Nb-1zVNo@mail.gmail.com>
Yong,
On Tue, Jan 4, 2011 at 12:41 PM, Yong Shen <yong.shen@linaro.org> wrote:
> Hi there,
>
> Are there any more comments?
> Because of the time difference, the review process is longer than it
> should be. If no more comments, I am going to ask for merge, so more
> works can be carry on based on this.
Looks like you haven?t checked Sascha?s tree:
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=shortlog;h=refs/heads/imx-for-2.6.38
The patch is there ;-)
Regards,
Fabio Estevam
^ permalink raw reply
* [RFC 5/5] ARM: P2V: extend to 16-bit translation offsets
From: David Brown @ 2011-01-04 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1PaDPu-00023p-QG@rmk-PC.arm.linux.org.uk>
On Tue, Jan 04 2011, Russell King - ARM Linux wrote:
> MSM's memory is aligned to 2MB, which is more than we can do with our
> existing method as we're limited to the upper 8 bits. Extend this by
> using two instructions to 16 bits, automatically selected when MSM is
> enabled.
I should also add that this series adds a warning to my build when
CONFIG_ARM_PATCH_PHYS_VIRT is not defined:
arch/arm/kernel/module.c:279: error: 'find_mod_section' defined but not used
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
From: Tony Lindgren @ 2011-01-04 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294181154.18162.39.camel@localhost>
* Kevin Hilman <khilman@ti.com> [110104 14:45]:
> On Tue, 2011-01-04 at 09:52 -0800, Kevin Hilman wrote:
> > Mika Westerberg <ext-mika.1.westerberg@nokia.com> writes:
> >
> > > In case on OMAP2+ we call set_24xx_gpio_triggering() instead of
> > > updating reg and l values. However, at the end of the function we
> > > perform a write:
> > >
> > > __raw_writel(l, reg);
> > >
> > > So on OMAP2+ we end up writing 0 to the bank->base which is not
> > > correct (typically this points to GPIO_REVISION register).
> > >
> > > Fix this by returning immediately after call to
> > > set_24xx_gpio_triggering().
> > >
> > > Signed-off-by: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
> >
> > Acked-by: Kevin Hilman <khilman@ti.com>
> >
> > Tony, this should be added to omap-for-linus as it fixes a problem in
> > the recently merged GPIO omap_device/hwmod conversion.
>
> On second thought, it's a bit late for the main 2.6.38 window, so will
> queue this in my pm-fixes branch for the .38-rc cycle.
Yeah let's not mess with omap-for-linus right now, but instead start
queueing up fixes for -rc1.
Tony
^ permalink raw reply
* [RFC 5/5] ARM: P2V: extend to 16-bit translation offsets
From: David Brown @ 2011-01-04 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1PaDPu-00023p-QG@rmk-PC.arm.linux.org.uk>
On Tue, Jan 04 2011, Russell King - ARM Linux wrote:
> MSM's memory is aligned to 2MB, which is more than we can do with our
> existing method as we're limited to the upper 8 bits. Extend this by
> using two instructions to 16 bits, automatically selected when MSM is
> enabled.
I've verified that the these 5 patches boot on an MSM QSD 8x50, both
with and without ARM_PATCH_PHYS_VIRT enabled. I haven't tried building
with a different offset than it is running at, yet.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCHv8 00/12] Contiguous Memory Allocator
From: Jamie Lokier @ 2011-01-04 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101223142053.GN3636@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> I'll give you another solution to the problem - lobby ARM Ltd to have
> this restriction lifted from the architecture specification, which
> will probably result in the speculative prefetching also having to be
> removed.
I don't know if there was lobbying involved, but the way some barriers
on x86 turned out to be unnecessary, on both Intel and AMD, after
years of specs which abstractly implied they might be necessary.... I
guess someone realised the relaxed specs weren't providing a benefit
at the hardware level.
Perhaps it is possible to draw this to ARM's attention as a rather
serious performance-damaging thing, so they might tighten the rules in
favour of common sense, at least for the majority of devices?
Off the top of my head (and I really don't know much about the
internals of an ARM), hardware that avoided speculation where there
was no entry already in the TLB for the address... that would be
workable, as page/range TLB flushes would be enough to protect
pages from access.
With regard to specific chips (i.e. current ones, while lobbying to
tighten the rules for future ones). Is there a control register on
the chips which are known to have this annoying issue, to turn off the
problematic cache behaviour (permanently while Linux runs), or some
set of memory attributes that produces that effect? (Obviously there
is: Turn off all caching, but is there a weaker and equally effective
one on current hardware with the problem?)
It might be there simply _isn't_ any solution that satisfies the
generality of ARM spec, while satisfying the engineering requirements
of particular media player chips on which the CMA+DMA may be perfectly
safe. That would be unpleasant but hardly the first time some feature
was not usable on some chips and essential on some others.
Take, for example, those (now old) ARMs that mishandle SWP so it can't
be used. We still use SWP in kernels, and indeed userspace, which
will break if run on those particular chips, but that's ok - it's an
understood limitation.
Russell, I think the repeated attempts to propose the same thing,
which you keep rejecting (rightly), isn't because they're not
listening, but because you haven't got a better solution - other than
scrap the hardware :-) Their code might actually be 100% reliable with
the chips they use in those products, and it might be the _only_
solution which works on those, thus solving a real problem.
What's the right thing to do in that case? Maintain a fork out of
tree, or some Kconfig animal that says you can't select this ARM
subarch and that memory facility in the same kernel because they are
technically incompatible - but at least everyone can see the code, and
know which chip families to avoid for certain applications?
Here is a hint of an idea for a way forward:
- An API that everyone can use (in drivers etc.), that behaves the
same for everyone, except that:
- On some chips (ARMv7...) some functions requires a large
up-front memory reservation at boot time, (but that's ok because
you probably have gobs of RAM with it anyway).
- On other chips (<= ARMv6?) it is safe to reduce the up-front
reservation to less, maybe zero. (Better for smaller memories).
- Maybe it even makes sense for drivers using the API to request,
@boot time, "_if_ you need early reservation, then _this_ is
how much I will need maximum". The values can potentially
dynamic anti-fragmantation allocators too. (I've done a bit of
research on this - a sort of "semi-reservation" where you don't
keep it free up front, but you limit how its used and grouped in
a precise way, to make sure other uses are sufficiently
reclaimable to satisfy the call when it comes.)
- Didn't reserve enough in advance for the architectural
constraints - get NULL back. That's what allocators always do.
That's what /proc/cmdline's options have a long history helping
with - finding the setting which works on your kit. People are
already used to a bit of fiddly tuning (and random crashes ;-)
with these media application sorts of things.
Presumably the problem will ease off with IOMMUs and/or sensible SG
(and/or sensible architectural constraints) becoming ubiquitous eventually.
-- Jamie
^ permalink raw reply
* [PATCH] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
From: Kevin Hilman @ 2011-01-04 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87aajg7dzu.fsf@ti.com>
On Tue, 2011-01-04 at 09:52 -0800, Kevin Hilman wrote:
> Mika Westerberg <ext-mika.1.westerberg@nokia.com> writes:
>
> > In case on OMAP2+ we call set_24xx_gpio_triggering() instead of
> > updating reg and l values. However, at the end of the function we
> > perform a write:
> >
> > __raw_writel(l, reg);
> >
> > So on OMAP2+ we end up writing 0 to the bank->base which is not
> > correct (typically this points to GPIO_REVISION register).
> >
> > Fix this by returning immediately after call to
> > set_24xx_gpio_triggering().
> >
> > Signed-off-by: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
>
> Acked-by: Kevin Hilman <khilman@ti.com>
>
> Tony, this should be added to omap-for-linus as it fixes a problem in
> the recently merged GPIO omap_device/hwmod conversion.
On second thought, it's a bit late for the main 2.6.38 window, so will
queue this in my pm-fixes branch for the .38-rc cycle.
Kevin
^ permalink raw reply
* [PATCH 0/2] OMAP: TWL: sparse fixes
From: Kevin Hilman @ 2011-01-04 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8762u47dmk.fsf@ti.com>
On Tue, 2011-01-04 at 10:00 -0800, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
>
> > Source:
> > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> > branch: omap-for-linus
> >
> > Doing a rm arch/arm/mach-omap2/*.o;make C=1 arch/arm/mach-omap2/
> > resulted in the following sparse warnings:
> > http://pastebin.mozilla.org/907954
> >
> > This series fixes the twl warnings
> > Nishanth Menon (2):
> > OMAP2+: TWL: make conversion routines static
> > OMAP2+: TWL: include pm header for init protos
> >
> > arch/arm/mach-omap2/omap_twl.c | 10 ++++++----
> > 1 files changed, 6 insertions(+), 4 deletions(-)
>
> Acked-by: Kevin Hilman <khilman@ti.com>
>
> Tony, these should probably queue for .38 if it's not too late.
On second thought, it's too late for the main 2.6.38 merge window for
these. I'll queue these in my pm-fixes branch for the 2.6.38-rc cycle.
Kevin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox