* [PATCH 2/2] [ARM] MX1:apf9328: Add i2c support
From: Gwenhael Goavec-Merou @ 2011-10-08 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318087189-22977-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
---
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/mach-apf9328.c | 10 ++++++++++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 4792fd5..0e89395 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -99,6 +99,7 @@ config MACH_SCB9328
config MACH_APF9328
bool "APF9328"
select SOC_IMX1
+ select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_UART
help
Say Yes here if you are using the Armadeus APF9328 development board
diff --git a/arch/arm/mach-imx/mach-apf9328.c b/arch/arm/mach-imx/mach-apf9328.c
index a404c89..f60e2b4 100644
--- a/arch/arm/mach-imx/mach-apf9328.c
+++ b/arch/arm/mach-imx/mach-apf9328.c
@@ -18,6 +18,7 @@
#include <linux/platform_device.h>
#include <linux/mtd/physmap.h>
#include <linux/dm9000.h>
+#include <linux/i2c.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -41,6 +42,9 @@ static const int apf9328_pins[] __initconst = {
PB29_PF_UART2_RTS,
PB30_PF_UART2_TXD,
PB31_PF_UART2_RXD,
+ /* I2C */
+ PA15_PF_I2C_SDA,
+ PA16_PF_I2C_SCL,
};
/*
@@ -103,6 +107,10 @@ static const struct imxuart_platform_data uart1_pdata __initconst = {
.flags = IMXUART_HAVE_RTSCTS,
};
+static const struct imxi2c_platform_data apf9328_i2c_data __initconst = {
+ .bitrate = 100000,
+};
+
static struct platform_device *devices[] __initdata = {
&apf9328_flash_device,
&dm9000x_device,
@@ -119,6 +127,8 @@ static void __init apf9328_init(void)
imx1_add_imx_uart0(NULL);
imx1_add_imx_uart1(&uart1_pdata);
+ imx1_add_imx_i2c(&apf9328_i2c_data);
+
platform_add_devices(devices, ARRAY_SIZE(devices));
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH] ARM: omap2+: stub out omap*_volt_data
From: Arnd Bergmann @ 2011-10-08 15:23 UTC (permalink / raw)
To: linux-arm-kernel
When CONFIG_PM_OPP is not set, the definitions for these variables
are not available, so we should conditionally define them to
NULL.
arch/arm/mach-omap2/built-in.o: In function `omap3xxx_voltagedomains_init':
voltagedomains3xxx_data.c:100: undefined reference to `omap36xx_vddmpu_volt_data'
voltagedomains3xxx_data.c:100: undefined reference to `omap34xx_vddmpu_volt_data'
voltagedomains3xxx_data.c:100: undefined reference to `omap36xx_vddcore_volt_data'
voltagedomains3xxx_data.c:100: undefined reference to `omap34xx_vddcore_volt_data'
arch/arm/mach-omap2/built-in.o: In function `omap44xx_voltagedomains_init':
voltagedomains44xx_data.c:111: undefined reference to `omap44xx_vdd_mpu_volt_data'
voltagedomains44xx_data.c:111: undefined reference to `omap44xx_vdd_iva_volt_data'
voltagedomains44xx_data.c:111: undefined reference to `omap44xx_vdd_core_volt_data'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I got this build error only now after pulling in the latest omap series, but
I cannot tell what caused it. It's also not clear to me if this is the correct
solution. Please ack or provide a better fix.
arch/arm/mach-omap2/omap_opp_data.h | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_opp_data.h b/arch/arm/mach-omap2/omap_opp_data.h
index c784c12..fdbf96b 100644
--- a/arch/arm/mach-omap2/omap_opp_data.h
+++ b/arch/arm/mach-omap2/omap_opp_data.h
@@ -83,7 +83,7 @@ struct omap_opp_def {
extern int __init omap_init_opp_table(struct omap_opp_def *opp_def,
u32 opp_def_size);
-
+#ifdef CONFIG_PM_OPP
extern struct omap_volt_data omap34xx_vddmpu_volt_data[];
extern struct omap_volt_data omap34xx_vddcore_volt_data[];
extern struct omap_volt_data omap36xx_vddmpu_volt_data[];
@@ -93,4 +93,15 @@ extern struct omap_volt_data omap44xx_vdd_mpu_volt_data[];
extern struct omap_volt_data omap44xx_vdd_iva_volt_data[];
extern struct omap_volt_data omap44xx_vdd_core_volt_data[];
+#else
+#define omap34xx_vddmpu_volt_data NULL
+#define omap34xx_vddcore_volt_data NULL
+#define omap36xx_vddmpu_volt_data NULL
+#define omap36xx_vddcore_volt_data NULL
+
+#define omap44xx_vdd_mpu_volt_data NULL
+#define omap44xx_vdd_iva_volt_data NULL
+#define omap44xx_vdd_core_volt_data NULL
+#endif
+
#endif /* __ARCH_ARM_MACH_OMAP2_OMAP_OPP_DATA_H */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/3] ARM: imx: add missing include of linux/ftrace.h
From: Jamie Iles @ 2011-10-08 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1928841.IC5oQhqc6l@wuerfel>
Hi Arnd, Sascha,
On Sat, Oct 08, 2011 at 05:16:26PM +0200, Arnd Bergmann wrote:
> Using the __exception_irq_entry symbol requires including
> this header file:
>
> arch/arm/plat-mxc/avic.c:154:39: error: expected '=', ',', ';', 'asm'
> or '__attribute__' before 'avic_handle_irq'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/plat-mxc/avic.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-mxc/avic.c b/arch/arm/plat-mxc/avic.c
> index 8875fb4..9bab263 100644
> --- a/arch/arm/plat-mxc/avic.c
> +++ b/arch/arm/plat-mxc/avic.c
> @@ -20,6 +20,7 @@
> #include <linux/module.h>
> #include <linux/irq.h>
> #include <linux/io.h>
> +#include <linux/ftrace.h>
Russell has applied a patch to move __exception_irq_entry into
asm/exception.h (with the include of ftrace.h) into his for-next branch.
So I think avic.c should be using this (as it's not explicitly using
ftrace).
Jamie
^ permalink raw reply
* [PATCH] ARM: kprobes: work around build errors
From: Dr. David Alan Gilbert @ 2011-10-08 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2056947.a9vGLIKRYk@wuerfel>
* Arnd Bergmann (arnd at arndb.de) wrote:
> I got a few build errors for kprobes playing with randconfig on the
> latest kernel. While this patch manages to avoid these errors, I'm
> pretty sure that it is not the ideal solution.
>
> The errors I got in arm are while building for ARMv6 with
> the arm-linux-gnueabihf-gcc-4.6 provided by Linaro, which
> results in these messages:
>
> /tmp/ccGpftnj.s: Assembler messages:
> /tmp/ccGpftnj.s:22066: Error: selected processor does not support ARM mode `mls r0,r1,r2,r3'
> /tmp/ccGpftnj.s:22099: Error: selected processor does not support ARM mode `mlshi r7,r8,r9,r10'
> /tmp/ccGpftnj.s:22128: Error: selected processor does not support ARM mode `mls lr,r1,r2,r13'
> /tmp/ccGpftnj.s:23781: Error: selected processor does not support ARM mode `strexd r0,r2,r3,[sp]'
> /tmp/ccGpftnj.s:23802: Error: selected processor does not support ARM mode `ldrexd r2,r3,[sp]'
> /tmp/ccGpftnj.s:23823: Error: selected processor does not support ARM mode `strexb r0,r2,[sp]'
> /tmp/ccGpftnj.s:23844: Error: selected processor does not support ARM mode `ldrexb r2,[sp]'
> /tmp/ccGpftnj.s:23865: Error: selected processor does not support ARM mode `strexh r0,r2,[sp]'
> /tmp/ccGpftnj.s:23886: Error: selected processor does not support ARM mode `ldrexh r2,[sp]'
> /tmp/ccGpftnj.s:25836: Warning: base register written back, and overlaps second transfer register
>
> The errors for the thumb variant are using the same tool
> chain, but obviously in v7 thumb2 mode. The error I got
> is
>
> /tmp/cczp95OW.s:18721: Error: offset out of range
>
> Reducing the amount of padding in the "TEST_BF_X("bpl.w 2f",0x1000)"
> test case resolves this, and I experimentally found 0xe20 to be the
> maximum value in this location, but that is different if I change the
> surrounding code. This one is much harder to reproduce and I can
> provide the configuration file I used if that helps.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
> index fc82de8..ba9c600 100644
> --- a/arch/arm/kernel/kprobes-test-arm.c
> +++ b/arch/arm/kernel/kprobes-test-arm.c
<snip>
> -#if __LINUX_ARM_ARCH__ >= 6
> +#if __LINUX_ARM_ARCH__ >= 7
> TEST_UNSUPPORTED("ldrex r2, [sp]")
> TEST_UNSUPPORTED("strexd r0, r2, r3, [sp]")
> TEST_UNSUPPORTED("ldrexd r2, r3, [sp]")
The ldrexd and strexd are supported on one of the ARMv6 varients
(6k I think from memory) which makes stuff a bit more complicated.
(and I think the plain ldrex that's the first one in that set
works on older CPUs).
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ gro.gilbert @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Greg KH @ 2011-10-08 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111008040351.GA7694@leaf>
On Fri, Oct 07, 2011 at 09:03:51PM -0700, Josh Triplett wrote:
> On Fri, Oct 07, 2011 at 02:23:26PM -0700, Greg KH wrote:
> > On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
> > > On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
> > > > On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
> > > > > +config PROBE_DEFER
> > > > > + bool "Deferred Driver Probe"
> > > > > + default y
> > > > > + help
> > > > > + This option provides deferring driver probe if it has dependency on
> > > > > + other driver. Without this feature, initcall ordering should be done
> > > > > + manually to resolve driver dependencies. This feature completely side
> > > > > + steps the issues by allowing driver registration to occur in any
> > > > > + order, and any driver can request to be retried after a few more other
> > > > > + drivers get probed.
> > > >
> > > > Why is this even an option? Why would you ever want it disabled? Why
> > > > does it need to be selected?
> > > >
> > > > If you are going to default something to 'y' then just make it so it
> > > > can't be turned off any other way by just not making it an option at
> > > > all.
> > >
> > > Given that the drivers which use this mechanism will not necessarily get
> > > built into the kernel, I'd suggest that it should remain optional and
> > > default to n. Those drivers can then add a dependency on PROBE_DEFER.
> > > Let's try to avoid adding more infrastructure to the kernel that takes
> > > up space even when unused; certainly embedded will appreciate not having
> > > this feature unless a driver needs it.
> >
> > How much extra space is this "feature" really?
>
> Just checked: 776 bytes, 640 of text and 136 of data. We have kconfig
> options for comparable amounts.
>
> > I don't see it being
> > anything larger than the amount of memory increase that just happened as
> > I typed this email as part of the ongoing memory density changes.
>
> I don't know about the changes you mean
Moore's law.
Really, 776 bytes, just always enable it, it's not worth it.
greg k-h
^ permalink raw reply
* [PATCH 18/26] ARM: pxa: MTD_XIP is not actually working any more
From: Nicolas Pitre @ 2011-10-08 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO88OdwjfERo=Ri_-_xR75S53d-HKW1Ah0WGnu_0P1gRXQ@mail.gmail.com>
On Sat, 8 Oct 2011, Eric Miao wrote:
> On Sun, Oct 2, 2011 at 4:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The headers files required for XIP support have moved around
> > over the last few years, and the code no longer builds.
> > Until someone fixes this, let's just disable support, leaving
> > sa1100 as the only platform still supporting xip.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> It is actually fixable, the problem is really mtd-xip.h is referencing
> the interrupt registers directly which I moved them to mach-pxa/irq.c
> for better modularization.
>
> I'm fine to drop XIP. I'm afraid Nico's gonna be a bit disappointed
> as I broke his favorite XIP code :-)
Well, I don't care much myself. I have no use for that capability, even
though this was interesting to implement. So it only depends if someone
relies on this or not.
A few months ago I asked on the list if XIP was still useful, and Tim
Bird replied that Sony was indeed using it. So if this is not too hard
to keep this feature alive then I'd go with that option.
Nicolas
^ permalink raw reply
* Serieal console on Samsung S3C6410 ARM11 CPU (Was [ANNOUNCE] 3.0.6-rt17)
From: Juergen Beisert @ 2011-10-08 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwSEvA+EHwyhgeZkBX+bB_e1cmFnC6YdEx-CdHzk8peyEw@mail.gmail.com>
Hi Thomas,
Thomas Abraham wrote:
> On 8 October 2011 16:56, Juergen Beisert <jbe@pengutronix.de> wrote:
> > Thomas Gleixner wrote:
> >> I'm pleased to announce the 3.0.6-rt17 release.
> >
> > I have no idea where to search, but when I'm using the 3.0.6-rt17 on my
> > Samsung S3C6410 ARM based system, the UART (serial console) does not work
> > as expected. Typing only one char at a time is okay. Typing two chars
> > immediately makes the system using 100 % CPU load and takes about 2
> > seconds to respond. It seems the interrupt handling is broken in the UART
> > driver, but I don't know how to fix it.
> >
> > This with a simple cursor up (one char to get the last command) and a
> > small pause to the next "ENTER" char:
> >
> > root at mini6410:~ cat /proc/interrupts | grep 18:
> > ?18: ? ?5739107 ?s3c-uart ?s3c6400-uart
> >
> > Same again:
> >
> > root at mini6410:~ cat /proc/interrupts | grep 18:
> > ?18: ? ?5739113 ?s3c-uart ?s3c6400-uart
> >
> > 6 interrupts seems reasonable.
> >
> > Now with cursor up and SPACE immediately, then a pause for ENTER:
> >
> > root at mini6410:~ cat /proc/interrupts | grep 18:
> > ?18: ? ?5923815 ?s3c-uart ?s3c6400-uart
> >
> > 184702 interrupts looks strange.
>
> Just curious, do you have the following two commits?
>
> serial: samsung: Add unified interrupt handler for s3c64xx and later SoC's
> ARM: SAMSUNG: Remove uart irq handling from platform code
Are they part of the current 3.0.6 vanilla kernel? I'm only using the vanilla
3.0.6 with rt17 on my target.
jbe
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Josh Triplett @ 2011-10-08 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111008155502.GB616@kroah.com>
On Sat, Oct 08, 2011 at 08:55:02AM -0700, Greg KH wrote:
> On Fri, Oct 07, 2011 at 09:03:51PM -0700, Josh Triplett wrote:
> > On Fri, Oct 07, 2011 at 02:23:26PM -0700, Greg KH wrote:
> > > On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
> > > > On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
> > > > > On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
> > > > > > +config PROBE_DEFER
> > > > > > + bool "Deferred Driver Probe"
> > > > > > + default y
> > > > > > + help
> > > > > > + This option provides deferring driver probe if it has dependency on
> > > > > > + other driver. Without this feature, initcall ordering should be done
> > > > > > + manually to resolve driver dependencies. This feature completely side
> > > > > > + steps the issues by allowing driver registration to occur in any
> > > > > > + order, and any driver can request to be retried after a few more other
> > > > > > + drivers get probed.
> > > > >
> > > > > Why is this even an option? Why would you ever want it disabled? Why
> > > > > does it need to be selected?
> > > > >
> > > > > If you are going to default something to 'y' then just make it so it
> > > > > can't be turned off any other way by just not making it an option at
> > > > > all.
> > > >
> > > > Given that the drivers which use this mechanism will not necessarily get
> > > > built into the kernel, I'd suggest that it should remain optional and
> > > > default to n. Those drivers can then add a dependency on PROBE_DEFER.
> > > > Let's try to avoid adding more infrastructure to the kernel that takes
> > > > up space even when unused; certainly embedded will appreciate not having
> > > > this feature unless a driver needs it.
> > >
> > > How much extra space is this "feature" really?
> >
> > Just checked: 776 bytes, 640 of text and 136 of data. We have kconfig
> > options for comparable amounts.
> >
> > > I don't see it being
> > > anything larger than the amount of memory increase that just happened as
> > > I typed this email as part of the ongoing memory density changes.
> >
> > I don't know about the changes you mean
>
> Moore's law.
Ah, I see. For new systems, sure; for systems or mechanisms with a
pre-existing size constraint, that doesn't help.
> Really, 776 bytes, just always enable it, it's not worth it.
776 bytes alone, no; 776 bytes times the next (or previous) thousand
features, yes.
- Josh Triplett
^ permalink raw reply
* Serieal console on Samsung S3C6410 ARM11 CPU (Was [ANNOUNCE] 3.0.6-rt17)
From: Thomas Abraham @ 2011-10-08 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110082015.17128.jbe@pengutronix.de>
On 8 October 2011 23:45, Juergen Beisert <jbe@pengutronix.de> wrote:
> Hi Thomas,
>
> Thomas Abraham wrote:
>> On 8 October 2011 16:56, Juergen Beisert <jbe@pengutronix.de> wrote:
>> > Thomas Gleixner wrote:
>> >> I'm pleased to announce the 3.0.6-rt17 release.
>> >
>> > I have no idea where to search, but when I'm using the 3.0.6-rt17 on my
>> > Samsung S3C6410 ARM based system, the UART (serial console) does not work
>> > as expected. Typing only one char at a time is okay. Typing two chars
>> > immediately makes the system using 100 % CPU load and takes about 2
>> > seconds to respond. It seems the interrupt handling is broken in the UART
>> > driver, but I don't know how to fix it.
>> >
>> > This with a simple cursor up (one char to get the last command) and a
>> > small pause to the next "ENTER" char:
>> >
>> > root at mini6410:~ cat /proc/interrupts | grep 18:
>> > ?18: ? ?5739107 ?s3c-uart ?s3c6400-uart
>> >
>> > Same again:
>> >
>> > root at mini6410:~ cat /proc/interrupts | grep 18:
>> > ?18: ? ?5739113 ?s3c-uart ?s3c6400-uart
>> >
>> > 6 interrupts seems reasonable.
>> >
>> > Now with cursor up and SPACE immediately, then a pause for ENTER:
>> >
>> > root at mini6410:~ cat /proc/interrupts | grep 18:
>> > ?18: ? ?5923815 ?s3c-uart ?s3c6400-uart
>> >
>> > 184702 interrupts looks strange.
>>
>> Just curious, do you have the following two commits?
>>
>> serial: samsung: Add unified interrupt handler for s3c64xx and later SoC's
>> ARM: SAMSUNG: Remove uart irq handling from platform code
>
> Are they part of the current 3.0.6 vanilla kernel? I'm only using the vanilla
> 3.0.6 with rt17 on my target.
No. I don't think they are part of 3.0.6 kernel. I am not sure of the
issue you have with serial console, but if you do not have these
patches already applied, you could try with them.
Thanks,
Thomas.
^ permalink raw reply
* [PATCH 1/2] [ARM] mach-types: Re-add apf9328
From: Wolfram Sang @ 2011-10-08 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318087189-22977-1-git-send-email-gwenhael.goavec-merou@armadeus.com>
On Sat, Oct 08, 2011 at 05:19:48PM +0200, Gwenhael Goavec-Merou wrote:
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
I think this file is maintained by Russell, yet I want to ack that the entry
below is missing for building mx1_defconfig. Found that, too.
Regards,
Wolfram
> ---
> arch/arm/tools/mach-types | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
> index fff68d0..07811a7 100644
> --- a/arch/arm/tools/mach-types
> +++ b/arch/arm/tools/mach-types
> @@ -188,6 +188,7 @@ omap_2430sdp MACH_OMAP_2430SDP OMAP_2430SDP 900
> davinci_evm MACH_DAVINCI_EVM DAVINCI_EVM 901
> palmz72 MACH_PALMZ72 PALMZ72 904
> nxdb500 MACH_NXDB500 NXDB500 905
> +apf9328 MACH_APF9328 APF9328 906
> palmt5 MACH_PALMT5 PALMT5 917
> palmtc MACH_PALMTC PALMTC 918
> omap_apollon MACH_OMAP_APOLLON OMAP_APOLLON 919
> --
> 1.7.3.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111008/616e92ce/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] [ARM] MX1:apf9328: Add i2c support
From: Wolfram Sang @ 2011-10-08 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318087189-22977-2-git-send-email-gwenhael.goavec-merou@armadeus.com>
On Sat, Oct 08, 2011 at 05:19:49PM +0200, Gwenhael Goavec-Merou wrote:
>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
Out of curiosity, no devices on the bus?
Other than that, looks OK to me:
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> arch/arm/mach-imx/Kconfig | 1 +
> arch/arm/mach-imx/mach-apf9328.c | 10 ++++++++++
> 2 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 4792fd5..0e89395 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -99,6 +99,7 @@ config MACH_SCB9328
> config MACH_APF9328
> bool "APF9328"
> select SOC_IMX1
> + select IMX_HAVE_PLATFORM_IMX_I2C
> select IMX_HAVE_PLATFORM_IMX_UART
> help
> Say Yes here if you are using the Armadeus APF9328 development board
> diff --git a/arch/arm/mach-imx/mach-apf9328.c b/arch/arm/mach-imx/mach-apf9328.c
> index a404c89..f60e2b4 100644
> --- a/arch/arm/mach-imx/mach-apf9328.c
> +++ b/arch/arm/mach-imx/mach-apf9328.c
> @@ -18,6 +18,7 @@
> #include <linux/platform_device.h>
> #include <linux/mtd/physmap.h>
> #include <linux/dm9000.h>
> +#include <linux/i2c.h>
>
> #include <asm/mach-types.h>
> #include <asm/mach/arch.h>
> @@ -41,6 +42,9 @@ static const int apf9328_pins[] __initconst = {
> PB29_PF_UART2_RTS,
> PB30_PF_UART2_TXD,
> PB31_PF_UART2_RXD,
> + /* I2C */
> + PA15_PF_I2C_SDA,
> + PA16_PF_I2C_SCL,
> };
>
> /*
> @@ -103,6 +107,10 @@ static const struct imxuart_platform_data uart1_pdata __initconst = {
> .flags = IMXUART_HAVE_RTSCTS,
> };
>
> +static const struct imxi2c_platform_data apf9328_i2c_data __initconst = {
> + .bitrate = 100000,
> +};
> +
> static struct platform_device *devices[] __initdata = {
> &apf9328_flash_device,
> &dm9000x_device,
> @@ -119,6 +127,8 @@ static void __init apf9328_init(void)
> imx1_add_imx_uart0(NULL);
> imx1_add_imx_uart1(&uart1_pdata);
>
> + imx1_add_imx_i2c(&apf9328_i2c_data);
> +
> platform_add_devices(devices, ARRAY_SIZE(devices));
> }
>
> --
> 1.7.3.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111008/4d5fd193/attachment.sig>
^ permalink raw reply
* [PATCH] arm: mx3: update defconfig
From: Wolfram Sang @ 2011-10-08 20:20 UTC (permalink / raw)
To: linux-arm-kernel
Activate watchdog, rtc, usb, usb-gadget, keypad, audio for broader test
coverage. Disable remote controls. Activate ARM errata as mentioned in [1].
Rest of changes is caused by version bump to 3.1-rc9.
[1] http://www.spinics.net/lists/arm-kernel/msg88710.html
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
arch/arm/configs/mx3_defconfig | 46 ++++++++++++++++++++++++++++-----------
1 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/arch/arm/configs/mx3_defconfig b/arch/arm/configs/mx3_defconfig
index 7c4b30b..cb0717f 100644
--- a/arch/arm/configs/mx3_defconfig
+++ b/arch/arm/configs/mx3_defconfig
@@ -3,7 +3,6 @@ CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
-CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_EXPERT=y
CONFIG_SLAB=y
CONFIG_MODULES=y
@@ -13,20 +12,21 @@ CONFIG_MODVERSIONS=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_ARCH_MXC=y
CONFIG_MACH_MX31ADS_WM1133_EV1=y
+CONFIG_MACH_MX31LILLY=y
+CONFIG_MACH_MX31LITE=y
CONFIG_MACH_PCM037=y
CONFIG_MACH_PCM037_EET=y
-CONFIG_MACH_MX31LITE=y
CONFIG_MACH_MX31_3DS=y
CONFIG_MACH_MX31MOBOARD=y
-CONFIG_MACH_MX31LILLY=y
CONFIG_MACH_QONG=y
-CONFIG_MACH_PCM043=y
CONFIG_MACH_ARMADILLO5X0=y
-CONFIG_MACH_MX35_3DS=y
CONFIG_MACH_KZM_ARM11_01=y
+CONFIG_MACH_PCM043=y
+CONFIG_MACH_MX35_3DS=y
CONFIG_MACH_EUKREA_CPUIMX35=y
CONFIG_MXC_IRQ_PRIOR=y
CONFIG_MXC_PWM=y
+CONFIG_ARM_ERRATA_411920=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
@@ -35,7 +35,6 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw ip=off"
CONFIG_VFP=y
-CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_NET=y
CONFIG_PACKET=y
@@ -52,7 +51,6 @@ CONFIG_IP_PNP_DHCP=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_FW_LOADER=m
CONFIG_MTD=y
-CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
@@ -62,24 +60,27 @@ CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_MXC=y
CONFIG_MTD_UBI=y
# CONFIG_BLK_DEV is not set
+CONFIG_MISC_DEVICES=y
CONFIG_EEPROM_AT24=y
CONFIG_NETDEVICES=y
CONFIG_SMSC_PHY=y
CONFIG_NET_ETHERNET=y
CONFIG_SMSC911X=y
CONFIG_DNET=y
-CONFIG_FEC=y
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
-# CONFIG_INPUT is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_IMX=y
+# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_IMX=y
CONFIG_SERIAL_IMX_CONSOLE=y
-# CONFIG_LEGACY_PTYS is not set
# CONFIG_HW_RANDOM is not set
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
@@ -89,12 +90,15 @@ CONFIG_W1=y
CONFIG_W1_MASTER_MXC=y
CONFIG_W1_SLAVE_THERM=y
# CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
+CONFIG_IMX2_WDT=y
CONFIG_MFD_WM8350_I2C=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_WM8350=y
CONFIG_MEDIA_SUPPORT=y
CONFIG_VIDEO_DEV=y
-# CONFIG_VIDEO_ALLOW_V4L1 is not set
+# CONFIG_RC_CORE is not set
+# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
CONFIG_SOC_CAMERA=y
CONFIG_SOC_CAMERA_MT9M001=y
CONFIG_SOC_CAMERA_MT9M111=y
@@ -105,9 +109,26 @@ CONFIG_SOC_CAMERA_OV772X=y
CONFIG_VIDEO_MX3=y
# CONFIG_RADIO_ADAPTERS is not set
CONFIG_FB=y
-# CONFIG_USB_SUPPORT is not set
+CONFIG_SOUND=y
+CONFIG_SND=y
+# CONFIG_SND_ARM is not set
+# CONFIG_SND_SPI is not set
+CONFIG_SND_SOC=y
+CONFIG_SND_IMX_SOC=y
+CONFIG_SND_MXC_SOC_WM1133_EV1=y
+CONFIG_SND_SOC_PHYCORE_AC97=y
+CONFIG_SND_SOC_EUKREA_TLV320=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_MXC=y
+CONFIG_USB_GADGET=m
+CONFIG_USB_FSL_USB2=m
+CONFIG_USB_G_SERIAL=m
+CONFIG_USB_ULPI=y
CONFIG_MMC=y
CONFIG_MMC_MXC=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_MXC=y
CONFIG_DMADEVICES=y
# CONFIG_DNOTIFY is not set
CONFIG_TMPFS=y
@@ -119,6 +140,5 @@ CONFIG_NFS_V4=y
CONFIG_ROOT_NFS=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
--
1.7.6.3
^ permalink raw reply related
* [GIT PULL] final arm-soc fixes for 3.1
From: Arnd Bergmann @ 2011-10-08 20:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Here are some last fixes from my side, please consider merging them into 3.1.
The majority of fixes that I received is now queued up in my next branch
for 3.2, but these are the ones that we agreed should still be merged before
the release.
Arnd
The following changes since commit a102a9ece5489e1718cd7543aa079082450ac3a2:
Linux 3.1-rc8 (2011-09-27 15:48:34 -0700)
are available in the git repository at:
git://git.linaro.org/people/arnd/arm-soc.git fixes
Arnd Bergmann (1):
Merge branch 'omap/fixes-for-3.1' into fixes
Axel Lin (1):
ARM: OMAP: musb: Remove a redundant omap4430_phy_init call in usb_musb_init
Bryan Buckley (1):
ARM: OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1
Tony Lindgren (1):
ARM: OMAP: Fix i2c init for twl4030
srinidhi kasagar (1):
ARM: mach-ux500: enable fix for ARM errata 754322
arch/arm/mach-omap2/board-2430sdp.c | 3 ++-
arch/arm/mach-omap2/hsmmc.c | 12 ++++--------
arch/arm/mach-omap2/usb-musb.c | 3 ---
arch/arm/mach-ux500/Kconfig | 1 +
4 files changed, 7 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH 1/2] [ARM] mach-types: Re-add apf9328
From: Russell King - ARM Linux @ 2011-10-08 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111008192621.GA28049@pengutronix.de>
On Sat, Oct 08, 2011 at 09:26:21PM +0200, Wolfram Sang wrote:
> On Sat, Oct 08, 2011 at 05:19:48PM +0200, Gwenhael Goavec-Merou wrote:
> >
> > Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
>
> I think this file is maintained by Russell, yet I want to ack that the entry
> below is missing for building mx1_defconfig. Found that, too.
The thing is - read the comments at the top of the file. There's hints
there as to what will happen if you patch the file. The hint is
'automatically generated'. So when I next update the file, any patches
done to the file will be wiped out.
^ permalink raw reply
* [PATCH v2] pinmux: add a driver for the CSR SiRFprimaII pinmux
From: Barry Song @ 2011-10-09 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3712698.4MAZQPafzW@wuerfel>
2011/10/8 Arnd Bergmann <arnd@arndb.de>:
> On Saturday 08 October 2011 19:58:23 Barry Song wrote:
>> > You can probably simplify this and other things with
>> > preprocessor macros if you want to, like:
>> >
>> > #define SIRF_FUNC_ENTRY(a) \
>> > { .name = "##a##", .pins = ##a##_pins, .num_pins =
>> > ARRAY_SIZE(##a##_pins), .padmux = &##a##_padmux }
>> >
>> > Then just:
>> >
>> > static const struct sirfsoc_pinmux_func sirfsoc_pinmux_funcs[] = {
>> > ? ? SIRF_FUNC_ENTRY(lcd_16bits),
>> >
>> >
>> > The macro syntax is probably wrong, the preprocessor always
>> > craze me out, but you get the idea.
>>
>> ?:-) ?.name = "##a##" ?should be changed to .name = #a
>>
>> #name will convert name into a string "name"
>>
>
> Better don't use string concatenation at all if you can avoid it.
>
> A generic macro like
>
> #define SIRF_PINMUX(_name, _pins, _padmux) \
> ? ? ? ?{ .name = (_name), .pins = (_pins), \
> ? ? ? ? ?.num_pins = ARRAY_SIZE(_pins), padmux = (_padmux), }
>
> is both very easy to understand for someone reading it casually and
> lets you actually grep for where the identifiers are being used.
>
>> static const struct sirfsoc_pinmux_func sirfsoc_pinmux_funcs[] = {
>> ? ? SIRF_FUNC_ENTRY(lcd_16bits),
>
> for the first time, you have no clue what that does, but
>
> static const struct sirfsoc_pinmux_func sirfsoc_pinmux_funcs[] = {
> ? ? ? ?SIRF_PINMUX("lcd_16bits", lcd_16bits_pins, &lcd_16bits_padmux),
> ? ? ? ?...
> };
>
> Makes it very clear what you are referencing here and needs no extra lines.
well. thanks! i'll send prima2 pinmux v3 rebased on Linus W's v9 and
with this change too.
>
> ? ? ? ?Arnd
>
-barry
^ permalink raw reply
* [PATCH 1/3] ARM: imx: always select CACHE_L2X0 on i.MX3
From: Shawn Guo @ 2011-10-09 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <101401532.609jSdenqo@wuerfel>
On Sat, Oct 08, 2011 at 05:15:50PM +0200, Arnd Bergmann wrote:
> The i.MX3 and i.MX35 files unconditionally call the l2x0_init
> function, so we should make sure that this is built into the
> kernel.
>
> arch/arm/mach-imx/built-in.o: In function `imx3_init_l2x0':
> mm-imx3.c:(.text+0x154): undefined reference to `l2x0_init'
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Shawn Guo <shawn.guo@linaro.org>
However, this should also be fixed by the Rob Herring's patch below
which I suppose it will be merged in the coming window.
ARM: l2x0: add empty l2x0_of_init
Anyway, your change makes sense to me, as the SoCs have L2 integrated
and I see no reason that L2 can not be selected by default. I will
do the same for my imx6q series to remove the dependency on Rob's
patch.
Regards,
Shawn
> arch/arm/mach-imx/Kconfig | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 6c12836..3de9ac9 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -64,6 +64,7 @@ config SOC_IMX31
> select ARCH_MXC_AUDMUX_V2
> select ARCH_MX31
> select MXC_AVIC
> + select CACHE_L2X0
>
> config SOC_IMX35
> bool
> @@ -73,7 +74,7 @@ config SOC_IMX35
> select HAVE_EPIT
> select ARCH_MX35
> select MXC_AVIC
> -
> + select CACHE_L2X0
>
> if ARCH_IMX_V4_V5
>
> --
> 1.7.5.4
>
>
>
> _______________________________________________
> 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 1/3] ARM: imx: always select CACHE_L2X0 on i.MX3
From: Barry Song @ 2011-10-09 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111009053905.GA24198@S2100-06.ap.freescale.net>
2011/10/9 Shawn Guo <shawn.guo@freescale.com>:
> On Sat, Oct 08, 2011 at 05:15:50PM +0200, Arnd Bergmann wrote:
>> The i.MX3 and i.MX35 files unconditionally call the l2x0_init
>> function, so we should make sure that this is built into the
>> kernel.
>>
>> arch/arm/mach-imx/built-in.o: In function `imx3_init_l2x0':
>> mm-imx3.c:(.text+0x154): undefined reference to `l2x0_init'
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
>
> However, this should also be fixed by the Rob Herring's patch below
> which I suppose it will be merged in the coming window.
>
> ?ARM: l2x0: add empty l2x0_of_init
>
> Anyway, your change makes sense to me, as the SoCs have L2 integrated
> and I see no reason that L2 can not be selected by default. ?I will
> do the same for my imx6q series to remove the dependency on Rob's
> patch.
the only loss is that users have to change Kconfig if they don't want
to open L2 for debugging purpose.
>
> Regards,
> Shawn
>
>> ?arch/arm/mach-imx/Kconfig | ? ?3 ++-
>> ?1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
>> index 6c12836..3de9ac9 100644
>> --- a/arch/arm/mach-imx/Kconfig
>> +++ b/arch/arm/mach-imx/Kconfig
>> @@ -64,6 +64,7 @@ config SOC_IMX31
>> ? ? ? select ARCH_MXC_AUDMUX_V2
>> ? ? ? select ARCH_MX31
>> ? ? ? select MXC_AVIC
>> + ? ? select CACHE_L2X0
>>
>> ?config SOC_IMX35
>> ? ? ? bool
>> @@ -73,7 +74,7 @@ config SOC_IMX35
>> ? ? ? select HAVE_EPIT
>> ? ? ? select ARCH_MX35
>> ? ? ? select MXC_AVIC
>> -
>> + ? ? select CACHE_L2X0
>>
>> ?if ARCH_IMX_V4_V5
>>
>> --
>> 1.7.5.4
-barry
^ permalink raw reply
* [PATCH 0/1] arm: omap: remove obsolete IRQF_DISABLED
From: Michael Opdenacker @ 2011-10-09 5:46 UTC (permalink / raw)
To: linux-arm-kernel
Remove all occurrences of IRQF_DISABLED in the OMAP tree.
This flag is deprecated and obsolete and as IRQ handlers now run
with all interrupts disabled since 2.6.36
^ permalink raw reply
* [PATCH 1/1] arm: omap: removed obsolete IRQF_DISABLED
From: Michael Opdenacker @ 2011-10-09 5:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318139198-6865-1-git-send-email-michael.opdenacker@linaro.org>
This flag is a NOOP since 2.6.36
Signed-off-by: Michael Opdenacker <michael.opdenacker@linaro.org>
---
arch/arm/mach-omap1/fpga.c | 5 ++---
arch/arm/mach-omap1/pm.c | 1 -
arch/arm/mach-omap1/time.c | 2 +-
arch/arm/mach-omap1/timer32k.c | 2 +-
arch/arm/mach-omap2/omap_l3_noc.c | 4 ++--
arch/arm/mach-omap2/omap_l3_smx.c | 4 ++--
arch/arm/mach-omap2/pm34xx.c | 2 +-
arch/arm/mach-omap2/timer.c | 2 +-
arch/arm/plat-omap/dma.c | 1 -
9 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap1/fpga.c b/arch/arm/mach-omap1/fpga.c
index cddbf8b..3786b35 100644
--- a/arch/arm/mach-omap1/fpga.c
+++ b/arch/arm/mach-omap1/fpga.c
@@ -131,9 +131,8 @@ static struct irq_chip omap_fpga_irq = {
* In an attempt to workaround the problem with missed interrupts, the
* mask_ack routine for all of the FPGA interrupts has been changed from
* fpga_mask_ack_irq() to fpga_ack_irq() so that the specific FPGA interrupt
- * being serviced is left unmasked. We can do this because the FPGA cascade
- * interrupt is installed with the IRQF_DISABLED flag, which leaves all
- * interrupts masked at the CPU while an FPGA interrupt handler executes.
+ * being serviced is left unmasked. We can do this because all the interrupts
+ * are masked at the CPU while an FPGA interrupt handler executes.
*
* Limited testing indicates that this workaround appears to be effective
* for the smc9194 Ethernet driver used on the Innovator. It should work
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 6badc29..f842ff2 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -641,7 +641,6 @@ static irqreturn_t omap_wakeup_interrupt(int irq, void *dev)
static struct irqaction omap_wakeup_irq = {
.name = "peripheral wakeup",
- .flags = IRQF_DISABLED,
.handler = omap_wakeup_interrupt
};
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index a183777..a35b4d2 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -163,7 +163,7 @@ static irqreturn_t omap_mpu_timer1_interrupt(int irq, void *dev_id)
static struct irqaction omap_mpu_timer1_irq = {
.name = "mpu_timer1",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler = omap_mpu_timer1_interrupt,
};
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index 96604a5..db08fd4 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -155,7 +155,7 @@ static irqreturn_t omap_32k_timer_interrupt(int irq, void *dev_id)
static struct irqaction omap_32k_timer_irq = {
.name = "32KHz timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler = omap_32k_timer_interrupt,
};
diff --git a/arch/arm/mach-omap2/omap_l3_noc.c b/arch/arm/mach-omap2/omap_l3_noc.c
index c8b1bef..a679437 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -186,7 +186,7 @@ static int __devinit omap4_l3_probe(struct platform_device *pdev)
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq,
l3_interrupt_handler,
- IRQF_DISABLED, "l3-dbg-irq", l3);
+ 0, "l3-dbg-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
OMAP44XX_IRQ_L3_DBG);
@@ -196,7 +196,7 @@ static int __devinit omap4_l3_probe(struct platform_device *pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = request_irq(l3->app_irq,
l3_interrupt_handler,
- IRQF_DISABLED, "l3-app-irq", l3);
+ 0, "l3-app-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
OMAP44XX_IRQ_L3_APP);
diff --git a/arch/arm/mach-omap2/omap_l3_smx.c b/arch/arm/mach-omap2/omap_l3_smx.c
index a05a62f..c1c33bf 100644
--- a/arch/arm/mach-omap2/omap_l3_smx.c
+++ b/arch/arm/mach-omap2/omap_l3_smx.c
@@ -237,7 +237,7 @@ static int __init omap3_l3_probe(struct platform_device *pdev)
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq, omap3_l3_app_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_RISING,
"l3-debug-irq", l3);
if (ret) {
dev_err(&pdev->dev, "couldn't request debug irq\n");
@@ -246,7 +246,7 @@ static int __init omap3_l3_probe(struct platform_device *pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = request_irq(l3->app_irq, omap3_l3_app_irq,
- IRQF_DISABLED | IRQF_TRIGGER_RISING,
+ IRQF_TRIGGER_RISING,
"l3-app-irq", l3);
if (ret) {
dev_err(&pdev->dev, "couldn't request app irq\n");
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c8cbd00..ea5b37a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -878,7 +878,7 @@ static int __init omap3_pm_init(void)
ret = request_irq(INT_34XX_PRCM_MPU_IRQ,
(irq_handler_t)prcm_interrupt_handler,
- IRQF_DISABLED, "prcm", NULL);
+ 0, "prcm", NULL);
if (ret) {
printk(KERN_ERR "request_irq failed to register for 0x%x\n",
INT_34XX_PRCM_MPU_IRQ);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 037b0d7..2bc303c 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -91,7 +91,7 @@ static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
static struct irqaction omap2_gp_timer_irq = {
.name = "gp timer",
- .flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
.handler = omap2_gp_timer_interrupt,
};
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c22217c..f51e18e 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1928,7 +1928,6 @@ static irqreturn_t omap2_dma_irq_handler(int irq, void *dev_id)
static struct irqaction omap24xx_dma_irq = {
.name = "DMA",
.handler = omap2_dma_irq_handler,
- .flags = IRQF_DISABLED
};
#else
--
1.7.4.1
^ permalink raw reply related
* [PATCH 3/7] ARM: imx: export imx_ioremap
From: Shawn Guo @ 2011-10-09 5:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2199742.hioYdt4QXg@wuerfel>
On Sat, Oct 08, 2011 at 05:16:49PM +0200, Arnd Bergmann wrote:
> The arch_ioremap function on i.MX is now an indirect function pointer.
> In order to use it from any loadable module, the pointer itself
> has to be exported.
>
> ERROR: "imx_ioremap" [drivers/video/tmiofb.ko] undefined!
> ERROR: "imx_ioremap" [drivers/usb/host/sl811-hcd.ko] undefined!
> ERROR: "imx_ioremap" [drivers/usb/host/r8a66597-hcd.ko] undefined!
> ERROR: "imx_ioremap" [drivers/usb/host/oxu210hp-hcd.ko] undefined!
> ERROR: "imx_ioremap" [drivers/usb/gadget/r8a66597-udc.ko] undefined!
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Regards,
Shawn
> arch/arm/plat-mxc/system.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/plat-mxc/system.c b/arch/arm/plat-mxc/system.c
> index 9dad8dc..45e1b5f 100644
> --- a/arch/arm/plat-mxc/system.c
> +++ b/arch/arm/plat-mxc/system.c
> @@ -21,6 +21,7 @@
> #include <linux/io.h>
> #include <linux/err.h>
> #include <linux/delay.h>
> +#include <linux/module.h>
>
> #include <mach/hardware.h>
> #include <mach/common.h>
> @@ -30,6 +31,7 @@
>
> void (*imx_idle)(void) = NULL;
> void __iomem *(*imx_ioremap)(unsigned long, size_t, unsigned int) = NULL;
> +EXPORT_SYMBOL_GPL(imx_ioremap);
>
> static void __iomem *wdog_base;
>
> --
> 1.7.5.4
^ permalink raw reply
* [PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa
From: Haojian Zhuang @ 2011-10-09 6:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1499585.ED4ktnBDpX@wuerfel>
On Sat, Oct 8, 2011 at 9:24 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday 08 October 2011 11:32:14 Haojian Zhuang wrote:
>>
>> Eric,
>>
>> At first, a new macro (ARCH_PXA_V7) is defined in
>> arch/arm/mach-pxa/Kconfig in this patch.
>> I prefer to move this macro to arch/arm/Kconfig.
>
> If we move it to arch/arm/Kconfig, I would prefer making it a global option,
> not a pxa specific one. If we introduce a top-level CONFIG_CPU_V6PLUS
> option, we can make a number of decisions inside of Kconfig depend on that,
> especially as we move to allow building multiple v6/v7 platforms together,
> or multiple v5 platforms for that matter. I believe we don't need to
> worry about v5+v7 at this point and can instead assume that won't ever
> happen.
>
Nobody is using PJ4 as v6 architecture now. CPUv6 is used in old stepping
of Dove and MMP2. CPU_PJ4 only enables CPU_v7 in the mainline code.
If we used ARCH_PXA_V7 in arch/arm/Kconfig, we would have two ARCH for
pxa. One is ARCH_PXA, and the other is ARCH_PXA_V7. Those v5 machine
should be based on ARCH_PXA. And the saarb, tavorevb3 should be based
on ARCH_PXA_V7. So we can avoid to define PXA_V7_MACH_AUTO. I think
the logic of Kconfig could be easier.
>> Secondly, pxa95x is both used in saarb and tavorevb3.
>
> The patch makes that very explicit, doesn't it?
>
+config PXA_V7_MACH_AUTO
+ def_bool y
+ depends on ARCH_PXA_V7
+ depends on !MACH_SAARB
+ select MACH_TAVOREVB3
+
Please check this. In your patch, SAARB and TAVOREVB3 is a mutex.
>> Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
>> machines in defconfig or define a new DT machine type to select all
>> machines.
>
> Enabling them in defconfig will not help here, it still allows creating
> an invalid configuration by disabling both saarb and tavorevb3.
> I agree that it would be best to have a single DT machine type that can
> handle both saarb and tavorevb3 as well as any future pxa95x based machines,
> but nobody has implemented that yet. In the meantime, I think we should
> have the PXA_V7_MACH_AUTO or an equivalent mechanism to enforce that at
> least one of the two board files gets built into any kernel. This is mostly
> important to help the 'make randconfig' builds succeed, not for actual
> users getting it wrong accidentally.
>
> ? ? ? ?Arnd
>
Exactly we need to define a single DT machine type in both arch-pxa
and arch-mmp.
I'll register it first.
Thanks
Haojian
^ permalink raw reply
* [PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa
From: Eric Miao @ 2011-10-09 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN1soZyDu43EN3W5YBttdzx7qx=MLKAR1OsJC3hUdqWWxhQaew@mail.gmail.com>
On Sun, Oct 9, 2011 at 2:21 PM, Haojian Zhuang <haojian.zhuang@gmail.com> wrote:
> On Sat, Oct 8, 2011 at 9:24 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Saturday 08 October 2011 11:32:14 Haojian Zhuang wrote:
>>>
>>> Eric,
>>>
>>> At first, a new macro (ARCH_PXA_V7) is defined in
>>> arch/arm/mach-pxa/Kconfig in this patch.
>>> I prefer to move this macro to arch/arm/Kconfig.
>>
>> If we move it to arch/arm/Kconfig, I would prefer making it a global option,
>> not a pxa specific one. If we introduce a top-level CONFIG_CPU_V6PLUS
>> option, we can make a number of decisions inside of Kconfig depend on that,
>> especially as we move to allow building multiple v6/v7 platforms together,
>> or multiple v5 platforms for that matter. I believe we don't need to
>> worry about v5+v7 at this point and can instead assume that won't ever
>> happen.
>>
> Nobody is using PJ4 as v6 architecture now. CPUv6 is used in old stepping
> of Dove and MMP2. CPU_PJ4 only enables CPU_v7 in the mainline code.
>
> If we used ARCH_PXA_V7 in arch/arm/Kconfig, we would have two ARCH for
> pxa. One is ARCH_PXA, and the other is ARCH_PXA_V7. Those v5 machine
> should be based on ARCH_PXA. And the saarb, tavorevb3 should be based
> on ARCH_PXA_V7. So we can avoid to define PXA_V7_MACH_AUTO. I think
> the logic of Kconfig could be easier.
Haojian,
PXA_V7_MACH_AUTO is to by default auto enable tavorevb3 when
ARCH_PXA_V7 is selected.
>
>>> Secondly, pxa95x is both used in saarb and tavorevb3.
>>
>> The patch makes that very explicit, doesn't it?
>>
> +config PXA_V7_MACH_AUTO
> + ? ? ? def_bool y
> + ? ? ? depends on ARCH_PXA_V7
> + ? ? ? depends on !MACH_SAARB
> + ? ? ? select MACH_TAVOREVB3
> +
>
> Please check this. In your patch, SAARB and TAVOREVB3 is a mutex.
They are actually not mutually exclusive - it's a trick we use to select
MACH_TAVOREVB3 by default but this option also disappears once SAARB
is selected.
Arnd,
The 'depends on ARCH_PXA_V7' could actually be removed here, as the
option is already encapsulated in if ARCH_PXA_V7 ... endif. And this
trick won't work very well when there are more than 2 boards.
>
>>> Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
>>> machines in defconfig or define a new DT machine type to select all
>>> machines.
>>
>> Enabling them in defconfig will not help here, it still allows creating
>> an invalid configuration by disabling both saarb and tavorevb3.
>> I agree that it would be best to have a single DT machine type that can
>> handle both saarb and tavorevb3 as well as any future pxa95x based machines,
>> but nobody has implemented that yet. In the meantime, I think we should
>> have the PXA_V7_MACH_AUTO or an equivalent mechanism to enforce that at
>> least one of the two board files gets built into any kernel. This is mostly
>> important to help the 'make randconfig' builds succeed, not for actual
>> users getting it wrong accidentally.
>>
>> ? ? ? ?Arnd
>>
>
> Exactly we need to define a single DT machine type in both arch-pxa
> and arch-mmp.
> I'll register it first.
Please go ahead.
^ permalink raw reply
* [PATCH 17/26] ARM: pxa: pxa95x is incompatible with earlier pxa
From: Haojian Zhuang @ 2011-10-09 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMPhdO8_cZU8FEGsK0m_XrhbR33TiZFFaNrXddKT1YrHREt-TQ@mail.gmail.com>
On Sun, Oct 9, 2011 at 2:36 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Sun, Oct 9, 2011 at 2:21 PM, Haojian Zhuang <haojian.zhuang@gmail.com> wrote:
>> On Sat, Oct 8, 2011 at 9:24 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Saturday 08 October 2011 11:32:14 Haojian Zhuang wrote:
>>>>
>>>> Eric,
>>>>
>>>> At first, a new macro (ARCH_PXA_V7) is defined in
>>>> arch/arm/mach-pxa/Kconfig in this patch.
>>>> I prefer to move this macro to arch/arm/Kconfig.
>>>
>>> If we move it to arch/arm/Kconfig, I would prefer making it a global option,
>>> not a pxa specific one. If we introduce a top-level CONFIG_CPU_V6PLUS
>>> option, we can make a number of decisions inside of Kconfig depend on that,
>>> especially as we move to allow building multiple v6/v7 platforms together,
>>> or multiple v5 platforms for that matter. I believe we don't need to
>>> worry about v5+v7 at this point and can instead assume that won't ever
>>> happen.
>>>
>> Nobody is using PJ4 as v6 architecture now. CPUv6 is used in old stepping
>> of Dove and MMP2. CPU_PJ4 only enables CPU_v7 in the mainline code.
>>
>> If we used ARCH_PXA_V7 in arch/arm/Kconfig, we would have two ARCH for
>> pxa. One is ARCH_PXA, and the other is ARCH_PXA_V7. Those v5 machine
>> should be based on ARCH_PXA. And the saarb, tavorevb3 should be based
>> on ARCH_PXA_V7. So we can avoid to define PXA_V7_MACH_AUTO. I think
>> the logic of Kconfig could be easier.
>ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7iMTlInbItkRaH3yJidg18Bg1SyIYZhbgu4jKpRkG4vavWebU6FwjovIuXoJqWzQimP4dvF4LWVq1xW84jtds8hRIc0a9nI1o2DUyqFzYvHHbqjXq+AJCqmUCaf9mlGn5/Ocd4LDbZKff3rHApCZrP4J/5beIiBDX25sFyRPNFjakJp5FbqwT17L91900rj7O60UeTe/vI9Gaf/oIvxMYriDmF02vsQgNqVNUzFllB8VTVb5HprZFZFX0ulBWhgTfMNqrhcZAxKwAW8tAY2zqa7NZZQhw0Ea8IkZrwA4qAwjQHwY56mNL7JRFLKlLVt3dEfkgx/HHWS8v1D80VGXUw== zhouhong at zhouhong-desktop
> Haojian,
>
> PXA_V7_MACH_AUTO is to by default auto enable tavorevb3 when
> ARCH_PXA_V7 is selected.
>
>>
>>>> Secondly, pxa95x is both used in saarb and tavorevb3.
>>>
>>> The patch makes that very explicit, doesn't it?
>>>
>> +config PXA_V7_MACH_AUTO
>> + ? ? ? def_bool y
>> + ? ? ? depends on ARCH_PXA_V7
>> + ? ? ? depends on !MACH_SAARB
>> + ? ? ? select MACH_TAVOREVB3
>> +
>>
>> Please check this. In your patch, SAARB and TAVOREVB3 is a mutex.
>
> They are actually not mutually exclusive - it's a trick we use to select
> MACH_TAVOREVB3 by default but this option also disappears once SAARB
> is selected.
>
OK. Could I know why saarb should be deselected while tavorevb3 is selected?
> Arnd,
>
> The 'depends on ARCH_PXA_V7' could actually be removed here, as the
> option is already encapsulated in if ARCH_PXA_V7 ... endif. And this
> trick won't work very well when there are more than 2 boards.
>
>>
>>>> Thirdly, PXA_V7_MACH_AUTO is unnecessary. We just need to select those
>>>> machines in defconfig or define a new DT machine type to select all
>>>> machines.
>>>
>>> Enabling them in defconfig will not help here, it still allows creating
>>> an invalid configuration by disabling both saarb and tavorevb3.
>>> I agree that it would be best to have a single DT machine type that can
>>> handle both saarb and tavorevb3 as well as any future pxa95x based machines,
>>> but nobody has implemented that yet. In the meantime, I think we should
>>> have the PXA_V7_MACH_AUTO or an equivalent mechanism to enforce that at
>>> least one of the two board files gets built into any kernel. This is mostly
>>> important to help the 'make randconfig' builds succeed, not for actual
>>> users getting it wrong accidentally.
>>>
>>> ? ? ? ?Arnd
>>>
>>
>> Exactly we need to define a single DT machine type in both arch-pxa
>> and arch-mmp.
>> I'll register it first.
>
> Please go ahead.
>
^ permalink raw reply
* [PATCH 2/3] mmc: Add OF bindings support for mmc host controller capabilities
From: Thomas Abraham @ 2011-10-09 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173A2C7245@HQMAIL01.nvidia.com>
On 5 October 2011 21:25, Stephen Warren <swarren@nvidia.com> wrote:
> Thomas Abraham wrote at Wednesday, October 05, 2011 8:28 AM:
>> On 5 October 2011 18:59, Rob Herring <robherring2@gmail.com> wrote:
>> > On 10/05/2011 05:13 AM, Thomas Abraham wrote:
>> >> Device nodes representing sd/mmc controllers in a device tree would include
>> >> mmc host controller capabilities. Add support for parsing of mmc host
>> >> controller capabilities included in device nodes.
> ...
>> >> +- linux,mmc_cap_4_bit_data - host can do 4 bit transfers
>> >> +- linux,mmc_cap_mmc_highspeed - host can do MMC high-speed timing
>> >> +- linux,mmc_cap_sd_highspeed - host can do SD high-speed timing
>> >> +- linux,mmc_cap_needs_poll - host needs polling for card detection
>> >> +- linux,mmc_cap_8_bit_data - host can do 8 bit transfer
>> >
>> > "sdhci,1-bit-only" already exists as a binding. Perhaps add
>> > "sdhci,4-bit-only". No property then means can do 8-bit.
>>
>> Ok. But that would remain just as sdhci host controller capability and
>> will not be applicable to other types of host controllers.
>
> Just as an FYI, NVIDIA's SDHCI controller bindings use property
> "support-8bit" to indicate 8-bit support. A similar property could be
> used for 4-bit support too.
In this case, the binding would be applicable only to nVidia's SDHCI
controller. And this binding would select MMC_CAP_8_BIT_DATA in the
sdhci-tegra driver. There are sdhci drivers that can accept host
capabilities via platform data.
The MMC_CAP_XXX macros in linux/mmc/host.h file are usuable across
host controllers and some of them are supplied as platform data for
non-device tree platforms.
So, bindings for MMC_CAP_XXX macros can be defined which any host
controller supporting device tree could use. Host controllers could
use the mmc_of_parse_host_caps() helper function (listed in this
patch) to parse all the bindings for MMC_CAP_XXX available in the
device node.
I would like to retain this patch in this series but if there is a
definite no, then I will drop it. Please let me know your opinion.
Thanks,
Thomas.
>
> --
> nvpublic
>
>
^ permalink raw reply
* [PATCH 1/4] mmc: mmci: Bugfix in pio read for small packets
From: Linus Walleij @ 2011-10-09 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111008091036.GF25689@n2100.arm.linux.org.uk>
On Sat, Oct 8, 2011 at 11:10 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Oct 07, 2011 at 03:45:48PM +0200, Ulf Hansson wrote:
>
> Well, the patch system says that each one depends on the previous one,
> and the first one in the series contains the PIO read thing.
>
> Do 7108/1 onwards depend on 7106/1 and 7107/1 ?
Probably my fault, since I was helping Ulf out with the patch tracker
introduction.
The patches should be pretty much semantically orthogonal as
far as I can tell, the only reason dependency was stated that way
was that I couldn't tell from head-parsing whether there were
syntactical dependencies. (And wanted to avoid the annoyance
of non-applying patches...)
So if they apply, they are independent AFAICT.
Yours,
Linus Walleij
^ 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