* [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: Russell King - ARM Linux @ 2012-10-27 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027163224.67d57aef@endymion.delvare>
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > > The original idea of using the hole in the i2c_msg structure is from
> > > David Brownell, who was apparently familiar with such practice, so I
> > > assumed it was OK. Actually I still assume it is, until someone comes
> > > with an supported architecture where it is not.
> >
> > According to Al Viro, that would be m68k.
>
> OK... So to make things clear, let me ask Al directly about it. Al, can
> you please tell us if:
>
> --- a/include/uapi/linux/i2c.h
> +++ b/include/uapi/linux/i2c.h
> struct i2c_msg {
> __u16 addr; /* slave address */
> __u16 flags;
> __u16 len; /* msg length */
> + __u16 transferred; /* actual bytes transferred */
> __u8 *buf; /* pointer to msg data */
> };
>
> would break binary compatibility on m68k or any other architecture you
> are familiar with? Note that struct i2c_msg isn't declared with
> attribute packed, so my assumption was that pointer "buf" was align on
> at least 4 bytes, leaving a hole between len and buf. Am I wrong?
So, you're attitude here is "I don't believe you, you are lying". Well,
if you have that level of distrust of your fellow developers, then you
don't deserve to be a Linux developer at all - and given that why should
I take any notice of you in the future over I2C stuff.
Especially as you've just proven that you don't know how to deal properly
with APIs...
Quite frankly I find your attitude towards me here totally disgusting and
insulting.
Not surprisingly, I didn't lie (I don't lie) and so I didn't "make up"
that M68k is one such architecture, and you've now had the confirmation
from Al.
So, I look forward to your apology for _implying_ that I'm a liar over
this issue, or if not, your resignation as I2C maintainer.
Thanks.
^ permalink raw reply
* [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board
From: Thomas Petazzoni @ 2012-10-27 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351354965-23875-1-git-send-email-gregory.clement@free-electrons.com>
On Sat, 27 Oct 2012 18:22:45 +0200, Gregory CLEMENT wrote:
> This platform, available from Globalscale has an Armada 370. For now,
> only the serial port is supported. Support for network, USB and other
> peripherals will be added as drivers for them become available for
> Armada 370 in mainline.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/boot/dts/Makefile | 3 ++-
> arch/arm/boot/dts/mbx001.dts | 37 +++++++++++++++++++++++++++++++++++
> arch/arm/mach-mvebu/armada-370-xp.c | 1 +
> 3 files changed, 40 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/mbx001.dts
With the rename mbx001.dts -> mbx0001.dts, this works fine for me on
the hardware platform, so:
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: Al Viro @ 2012-10-27 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027170235.GA24388@ZenIV.linux.org.uk>
On Sat, Oct 27, 2012 at 06:02:35PM +0100, Al Viro wrote:
> On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
>
> > You are wrong. Assumption that pointers are aligned to 32bit boundary
> > is simply not true. In particular, on m68k alignment is 16bit, i.e. there
> > struct foo {
> > char x;
> > void *p;
> > }; will have 1 byte occupied by x, followed by 1-byte gap, followed by 4 bytes
> > occupied by p.
> >
> > Note, BTW, that m68k includes things like coldfire, etc. and I wouldn't be
> > surprised by e.g. coldfire-based SoC with i2c on it.
>
> BTW, that's easily verified - take a cross-compiler and do this:
> ; cat >a.c <<'EOF'
> struct { char x; void *y; } v;
> int z = (char *)&v.y - (char *)&v;
> EOF
> ; m68k-linux-gnu-gcc -S a.c
> ; grep -A1 'z:' a.s
> z:
> .long 2
> ;
> and watch what it puts into z. gcc is very liberal about what it considers
> a constant expression, so it allows that sort of expressions as initializers
> for global variables. Not a portable C, but convenient for experiments like
> that; just grab a cross-toolchain and feed it testcases of that kind...
... and google for i2c coldfire immediately turns up this:
http://mailman.uclinux.org/pipermail/uclinux-dev/2012-May/051874.html
with
+config I2C_COLDFIRE
+ tristate "Freescale Coldfire I2C driver"
+ depends on !M5272
+ help
+ This driver supports the I2C interface availible on most Freescale
+ Coldfire processors.
+
+ This driver can be built as a module. If so, the module
+ will be called i2c-coldfire.
in it, along with addition of drivers/i2c/busses/i2c-coldfire.c... IOW,
i2c on m68k is quite real. Sorry, no go - you don't even have an excuse
of i2c never existing on the architecture in question.
^ permalink raw reply
* [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: Al Viro @ 2012-10-27 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027164013.GV2616@ZenIV.linux.org.uk>
On Sat, Oct 27, 2012 at 05:40:13PM +0100, Al Viro wrote:
> You are wrong. Assumption that pointers are aligned to 32bit boundary
> is simply not true. In particular, on m68k alignment is 16bit, i.e. there
> struct foo {
> char x;
> void *p;
> }; will have 1 byte occupied by x, followed by 1-byte gap, followed by 4 bytes
> occupied by p.
>
> Note, BTW, that m68k includes things like coldfire, etc. and I wouldn't be
> surprised by e.g. coldfire-based SoC with i2c on it.
BTW, that's easily verified - take a cross-compiler and do this:
; cat >a.c <<'EOF'
struct { char x; void *y; } v;
int z = (char *)&v.y - (char *)&v;
EOF
; m68k-linux-gnu-gcc -S a.c
; grep -A1 'z:' a.s
z:
.long 2
;
and watch what it puts into z. gcc is very liberal about what it considers
a constant expression, so it allows that sort of expressions as initializers
for global variables. Not a portable C, but convenient for experiments like
that; just grab a cross-toolchain and feed it testcases of that kind...
^ permalink raw reply
* [PATCH] arm: bcm2835: enable proc and sysfs in defconfig
From: Thomas Petazzoni @ 2012-10-27 17:00 UTC (permalink / raw)
To: linux-arm-kernel
For some reason, support for proc and sysfs is currently disabled in
the bcm2835_defconfig, even though those filesystems are quite
essential even for very basic Linux userspace. As most defconfig have
them enabled by default, enable them as well in bcm2835_defconfig.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/configs/bcm2835_defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 7aea702..74e27f0 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -66,8 +66,6 @@ CONFIG_TTY_PRINTK=y
# CONFIG_FILE_LOCKING is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY_USER is not set
-# CONFIG_PROC_FS is not set
-# CONFIG_SYSFS is not set
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
--
1.7.9.5
^ permalink raw reply related
* [PATCH] GPIO: mvebu-gpio: Don't initialize the mask_cache
From: Andrew Lunn @ 2012-10-27 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027185305.71d88c07@skate>
On Sat, Oct 27, 2012 at 06:53:05PM +0200, Thomas Petazzoni wrote:
>
> On Sat, 27 Oct 2012 18:31:41 +0200, Linus Walleij wrote:
> > On Sat, Oct 27, 2012 at 3:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > Due to the SMP nature of some of the chips, which have per CPU
> > > registers, the driver does not use the generic irq_gc_mask_set_bit() &
> > > irq_gc_mask_clr_bit() functions, which only support a single register.
> > > The driver has its own implementation of these functions, which can
> > > pick the correct register depending on the CPU being used. The
> > > functions do however use the gc->mask_cache value.
> > >
> > > The call to irq_setup_generic_chip() was passing
> > > IRQ_GC_INIT_MASK_CACHE, which caused the gc->mask_cache to be
> > > initialized to the contents of some random register. This resulted in
> > > unexpected interrupts been delivered from random GPIO lines.
> > >
> > > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> >
> > Thanks, patch applied to fixes. Unless Thomas screams...
>
> Acked-by-the-not-screaming: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> Sounds good? :-)
https://lwn.net/Articles/503829
Its at least new...
Andrew
^ permalink raw reply
* [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board
From: Thomas Petazzoni @ 2012-10-27 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027164448.GB15824@lunn.ch>
On Sat, 27 Oct 2012 18:44:48 +0200, Andrew Lunn wrote:
> > diff --git a/arch/arm/boot/dts/mbx001.dts b/arch/arm/boot/dts/mbx001.dts
> > new file mode 100644
> > index 0000000..88a5a11
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/mbx001.dts
>
> Hi Gregory
>
> Maybe it would be good to prefix this with armada-370. It then fits
> with armada-370-db.dts, and all the kirkwood files are kirkwood-*.dts.
So for OpenBlocks, I should rename armada-xp-openblocks-ax3-4.dts as
well, I guess. I agree with your comment: I think that a name such as
mbx001.dts is way too generic.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] GPIO: mvebu-gpio: Don't initialize the mask_cache
From: Thomas Petazzoni @ 2012-10-27 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYE_P_MQch4dLuCBeUXEfr2RG3TwdUMdT75cN3MELG3pQ@mail.gmail.com>
On Sat, 27 Oct 2012 18:31:41 +0200, Linus Walleij wrote:
> On Sat, Oct 27, 2012 at 3:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>
> > Due to the SMP nature of some of the chips, which have per CPU
> > registers, the driver does not use the generic irq_gc_mask_set_bit() &
> > irq_gc_mask_clr_bit() functions, which only support a single register.
> > The driver has its own implementation of these functions, which can
> > pick the correct register depending on the CPU being used. The
> > functions do however use the gc->mask_cache value.
> >
> > The call to irq_setup_generic_chip() was passing
> > IRQ_GC_INIT_MASK_CACHE, which caused the gc->mask_cache to be
> > initialized to the contents of some random register. This resulted in
> > unexpected interrupts been delivered from random GPIO lines.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>
> Thanks, patch applied to fixes. Unless Thomas screams...
Acked-by-the-not-screaming: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Sounds good? :-)
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 5/5] zynq: move static peripheral mappings
From: Michal Simek @ 2012-10-27 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026010303.GA13669@beefymiracle.amer.corp.natinst.com>
HI Josh and Nick,
look below.
> -----Original Message-----
> From: Josh Cartwright [mailto:josh.cartwright at ni.com]
> Sent: Friday, October 26, 2012 3:03 AM
> To: Nick Bowler
> Cc: arm at kernel.org; Arnd Bergmann; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; John Linn; Michal Simek
> Subject: Re: [PATCH v4 5/5] zynq: move static peripheral mappings
>
> On Thu, Oct 25, 2012 at 06:41:08PM -0400, Nick Bowler wrote:
> > On 2012-10-25 16:29 -0500, Josh Cartwright wrote:
> > > On Thu, Oct 25, 2012 at 04:17:01PM -0400, Nick Bowler wrote:
> > > > Did you test this on any real hardware? I can't get the ZC702 to
> > > > work with the UART mapped at this address (this ends up being
> > > > mapped at 0xFEFFF000), although I can't for the life of me figure
> > > > out why the virtual address even matters. Note that for the
> > > > ZC702, the physical address of the "main" UART is 0xE0001000.
>
> Good news is you're not crazy; I was able to duplicate the problem here.
>
> > If I were to guess, I would guess that, except for when it "Works",
> > the really really early printk stuff isn't actually hitting the uart
> > at all. The "Fails" case would then be due to the stray writes
> > crashing the board, and the "Truncated" case due to the stray writes
> > being (ostensibly) benign.
>
> If I'm not mistaken, this hypothesis is predicated on the early bootup code
> establishing a (linear?) mapping for addresses > VMALLOC_START; before the
> mdesc->map_io() is even handled. That seems odd to me.
>
> > But I really have no way right now to test this hypothesis, since I
> > can't print anything in the failing case.
>
> Not sure if I'll be able to get anything meaningful out of it yet (I've not
> historically had good luck with Xilinx's debugging tools), but I did finally get a
> JTAG debugger hooked up to the zc702. I'll see if I can get any useful
> information tomorrow.
I have seen the same problem on zc702. I will debug it.
Josh: the best will be if you can send v5 for patches 1-3 (1 with small changes in dts - uart) which I will apply
to arm-next.
4/5 should go out of zynq subtree, it means directly to arm-soc or via Russel's tree.
5/5 + Nick patch should be tested.
Thanks,
Michal
^ permalink raw reply
* [PATCH v4 3/5] zynq: remove use of CLKDEV_LOOKUP
From: Michal Simek @ 2012-10-27 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024200407.GD6713@beefymiracle.amer.corp.natinst.com>
> -----Original Message-----
> From: Josh Cartwright [mailto:josh.cartwright at ni.com]
> Sent: Wednesday, October 24, 2012 10:04 PM
> To: arm at kernel.org; Arnd Bergmann
> Cc: linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; John
> Linn; Nick Bowler; Michal Simek
> Subject: [PATCH v4 3/5] zynq: remove use of CLKDEV_LOOKUP
>
> The Zynq support in mainline does not (yet) make use of any of the generic clk
> or clk lookup functionality. Remove what is upstream for now, until the out-of-
> tree implementation is in suitable form for merging.
>
> An important side effect of this patch is that it allows the building of a Zynq
> kernel without running into unresolved symbol problems:
>
> drivers/built-in.o: In function `amba_get_enable_pclk':
> clkdev.c:(.text+0x444): undefined reference to `clk_enable'
> drivers/built-in.o: In function `amba_remove':
> clkdev.c:(.text+0x488): undefined reference to `clk_disable'
> drivers/built-in.o: In function `amba_probe':
> clkdev.c:(.text+0x540): undefined reference to `clk_disable'
> drivers/built-in.o: In function `amba_device_add':
> clkdev.c:(.text+0x77c): undefined reference to `clk_disable'
> drivers/built-in.o: In function `enable_clock':
> clkdev.c:(.text+0x29738): undefined reference to `clk_enable'
> drivers/built-in.o: In function `disable_clock':
> clkdev.c:(.text+0x29778): undefined reference to `clk_disable'
> drivers/built-in.o: In function `__pm_clk_remove':
> clkdev.c:(.text+0x297f8): undefined reference to `clk_disable'
> drivers/built-in.o: In function `pm_clk_suspend':
> clkdev.c:(.text+0x29bc8): undefined reference to `clk_disable'
> drivers/built-in.o: In function `pm_clk_resume':
> clkdev.c:(.text+0x29c28): undefined reference to `clk_enable'
> make[2]: *** [vmlinux] Error 1
> make[1]: *** [sub-make] Error 2
> make: *** [all] Error 2
>
> In addition, eliminate Zynq's "use" of the versatile platform, as it is no longer
> needed. As Nick Bowler points out:
>
> For the record, I think this was introduced by commit 56a34b03ff427
> ("ARM: versatile: Make plat-versatile clock optional") which forgot to
> select PLAT_VERSATILE_CLOCK on Zynq. This is not all that surprising,
> because the fact that Zynq "uses" PLAT_VERSATILE is secretly hidden in
> the Makefile.
>
> Nevertheless, the only feature from versatile that Zynq needed was the
> clock support, so this patch should *also* delete the secret use of
> plat-versatile by removing this line from arch/arm/Makefile:
>
> plat-$(CONFIG_ARCH_ZYNQ) += versatile
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> Cc: John Linn <john.linn@xilinx.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/Kconfig | 1 -
> arch/arm/Makefile | 1 -
> arch/arm/mach-zynq/common.c | 1 -
> arch/arm/mach-zynq/include/mach/clkdev.h | 32 --------------------------------
> 4 files changed, 35 deletions(-)
> delete mode 100644 arch/arm/mach-zynq/include/mach/clkdev.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index cce4f8d..de70d99 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -946,7 +946,6 @@ config ARCH_ZYNQ
> bool "Xilinx Zynq ARM Cortex A9 Platform"
> select ARM_AMBA
> select ARM_GIC
> - select CLKDEV_LOOKUP
> select CPU_V7
> select GENERIC_CLOCKEVENTS
> select ICST
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 451757d..8dbab2d
> 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -197,7 +197,6 @@ machine-$(CONFIG_ARCH_ZYNQ) += zynq
> # by CONFIG_* macro name.
> plat-$(CONFIG_ARCH_OMAP) += omap
> plat-$(CONFIG_ARCH_S3C64XX) += samsung
> -plat-$(CONFIG_ARCH_ZYNQ) += versatile
> plat-$(CONFIG_PLAT_IOP) += iop
> plat-$(CONFIG_PLAT_NOMADIK) += nomadik
> plat-$(CONFIG_PLAT_ORION) += orion
> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
> index 056091a..ba48f06 100644
> --- a/arch/arm/mach-zynq/common.c
> +++ b/arch/arm/mach-zynq/common.c
> @@ -31,7 +31,6 @@
> #include <asm/hardware/cache-l2x0.h>
>
> #include <mach/zynq_soc.h>
> -#include <mach/clkdev.h>
> #include "common.h"
>
> static struct of_device_id zynq_of_bus_ids[] __initdata = { diff --git
> a/arch/arm/mach-zynq/include/mach/clkdev.h b/arch/arm/mach-
> zynq/include/mach/clkdev.h
> deleted file mode 100644
> index c6e73d8..0000000
> --- a/arch/arm/mach-zynq/include/mach/clkdev.h
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -/*
> - * arch/arm/mach-zynq/include/mach/clkdev.h
> - *
> - * Copyright (C) 2011 Xilinx, Inc.
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - */
> -
> -#ifndef __MACH_CLKDEV_H__
> -#define __MACH_CLKDEV_H__
> -
> -#include <plat/clock.h>
> -
> -struct clk {
> - unsigned long rate;
> - const struct clk_ops *ops;
> - const struct icst_params *params;
> - void __iomem *vcoreg;
> -};
> -
> -#define __clk_get(clk) ({ 1; })
> -#define __clk_put(clk) do { } while (0)
> -
> -#endif
Tested-by: Michal Simek <michal.simek@xilinx.com>
Thanks
Michal
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [PATCH 3/3] arm: mvebu: move irq controller driver to drivers/irqchip
From: Thomas Petazzoni @ 2012-10-27 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351356317-16758-1-git-send-email-thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
---
arch/arm/mach-mvebu/Kconfig | 1 +
arch/arm/mach-mvebu/Makefile | 2 +-
arch/arm/mach-mvebu/armada-370-xp.c | 4 +-
arch/arm/mach-mvebu/common.h | 3 -
drivers/irqchip/Makefile | 1 +
.../irqchip}/irq-armada-370-xp.c | 58 +++++++++-----------
drivers/irqchip/irqchip.c | 3 +
drivers/irqchip/irqchip.h | 2 +
8 files changed, 36 insertions(+), 38 deletions(-)
rename {arch/arm/mach-mvebu => drivers/irqchip}/irq-armada-370-xp.c (87%)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 416d46e..415ed0f 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -9,6 +9,7 @@ config ARCH_MVEBU
select PINCTRL
select PLAT_ORION
select SPARSE_IRQ
+ select USE_IRQCHIP
if ARCH_MVEBU
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 57f996b..7f4e9f4 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -2,4 +2,4 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
-I$(srctree)/arch/arm/plat-orion/include
obj-y += system-controller.o
-obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o irq-armada-370-xp.o addr-map.o
+obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o addr-map.o
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 68f1483..9b28991 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -16,6 +16,7 @@
#include <linux/init.h>
#include <linux/of_platform.h>
#include <linux/io.h>
+#include <linux/irqchip.h>
#include <linux/time-armada-370-xp.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -56,8 +57,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] = {
DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
.init_machine = armada_370_xp_dt_init,
.map_io = armada_370_xp_map_io,
- .init_irq = armada_370_xp_init_irq,
- .handle_irq = armada_370_xp_handle_irq,
+ .init_irq = irqchip_init,
.timer = &armada_370_xp_timer,
.restart = mvebu_restart,
.dt_compat = armada_370_xp_dt_board_dt_compat,
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 02f89ea..f0eaa21 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -17,7 +17,4 @@
void mvebu_restart(char mode, const char *cmd);
-void armada_370_xp_init_irq(void);
-void armada_370_xp_handle_irq(struct pt_regs *regs);
-
#endif
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 77adcb1..d1a163c 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_USE_IRQCHIP) += irqchip.o
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
+obj-$(CONFIG_ARCH_MVEBU) += irq-armada-370-xp.o
diff --git a/arch/arm/mach-mvebu/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
similarity index 87%
rename from arch/arm/mach-mvebu/irq-armada-370-xp.c
rename to drivers/irqchip/irq-armada-370-xp.c
index 5f5f939..148a67c 100644
--- a/arch/arm/mach-mvebu/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -23,6 +23,7 @@
#include <linux/of_irq.h>
#include <linux/irqdomain.h>
#include <asm/mach/arch.h>
+#include <asm/mach/irq.h>
#include <asm/exception.h>
/* Interrupt Controller Registers Map */
@@ -39,6 +40,27 @@ static void __iomem *per_cpu_int_base;
static void __iomem *main_int_base;
static struct irq_domain *armada_370_xp_mpic_domain;
+static asmlinkage void __exception_irq_entry
+armada_370_xp_handle_irq(struct pt_regs *regs)
+{
+ u32 irqstat, irqnr;
+
+ do {
+ irqstat = readl_relaxed(per_cpu_int_base +
+ ARMADA_370_XP_CPU_INTACK_OFFS);
+ irqnr = irqstat & 0x3FF;
+
+ if (irqnr < 1023) {
+ irqnr =
+ irq_find_mapping(armada_370_xp_mpic_domain, irqnr);
+ handle_IRQ(irqnr, regs);
+ continue;
+ }
+
+ break;
+ } while (1);
+}
+
static void armada_370_xp_irq_mask(struct irq_data *d)
{
writel(irqd_to_hwirq(d),
@@ -77,8 +99,8 @@ static struct irq_domain_ops armada_370_xp_mpic_irq_ops = {
.xlate = irq_domain_xlate_onecell,
};
-static int __init armada_370_xp_mpic_of_init(struct device_node *node,
- struct device_node *parent)
+int __init armada_370_xp_mpic_of_init(struct device_node *node,
+ struct device_node *parent)
{
u32 control;
@@ -98,36 +120,8 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
panic("Unable to add Armada_370_Xp MPIC irq domain (DT)\n");
irq_set_default_host(armada_370_xp_mpic_domain);
- return 0;
-}
-asmlinkage void __exception_irq_entry armada_370_xp_handle_irq(struct pt_regs
- *regs)
-{
- u32 irqstat, irqnr;
-
- do {
- irqstat = readl_relaxed(per_cpu_int_base +
- ARMADA_370_XP_CPU_INTACK_OFFS);
- irqnr = irqstat & 0x3FF;
+ handle_arch_irq = armada_370_xp_handle_irq;
- if (irqnr < 1023) {
- irqnr =
- irq_find_mapping(armada_370_xp_mpic_domain, irqnr);
- handle_IRQ(irqnr, regs);
- continue;
- }
-
- break;
- } while (1);
-}
-
-static const struct of_device_id mpic_of_match[] __initconst = {
- {.compatible = "marvell,mpic", .data = armada_370_xp_mpic_of_init},
- {},
-};
-
-void __init armada_370_xp_init_irq(void)
-{
- of_irq_init(mpic_of_match);
+ return 0;
}
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index f01cf6e..f8fbf00 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -17,6 +17,9 @@ static const struct of_device_id irqchip_of_match[] __initconst = {
#ifdef CONFIG_ARCH_BCM2835
{ .compatible = "brcm,bcm2835-armctrl-ic", .data = armctrl_of_init },
#endif
+#ifdef CONFIG_ARCH_MVEBU
+ {.compatible = "marvell,mpic", .data = armada_370_xp_mpic_of_init },
+#endif
{},
};
diff --git a/drivers/irqchip/irqchip.h b/drivers/irqchip/irqchip.h
index 0e68965..a961ca9 100644
--- a/drivers/irqchip/irqchip.h
+++ b/drivers/irqchip/irqchip.h
@@ -12,5 +12,7 @@
#define _IRQCHIP_H
int armctrl_of_init(struct device_node *node, struct device_node *parent);
+int armada_370_xp_mpic_of_init(struct device_node *node,
+ struct device_node *parent);
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] arm: bcm2835: convert to the irqchip infrastructure
From: Thomas Petazzoni @ 2012-10-27 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351356317-16758-1-git-send-email-thomas.petazzoni@free-electrons.com>
Register the irq controller driver in the main
drivers/irqchip/irqchip.c file, and make sure that the initialization
function of the driver sets handle_arch_irq() appropriately. This
requires a bit of movement in the driver since the
bcm2835_handle_irq() must move before the armctrl_of_init() function
to avoid a forward declaration.
On the arch/arm side, use irqchip_init() as the ->init_irq() callback,
and remove the definition of ->handle_irq() since this is now done by
the irq controller driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
---
arch/arm/Kconfig | 1 +
arch/arm/mach-bcm2835/bcm2835.c | 5 +-
drivers/irqchip/irq-bcm2835.c | 110 +++++++++++++++++++--------------------
drivers/irqchip/irqchip.c | 3 ++
drivers/irqchip/irqchip.h | 2 +
include/linux/irqchip/bcm2835.h | 29 -----------
6 files changed, 61 insertions(+), 89 deletions(-)
delete mode 100644 include/linux/irqchip/bcm2835.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 73067ef..7030500 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -347,6 +347,7 @@ config ARCH_BCM2835
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
select USE_OF
+ select USE_IRQCHIP
help
This enables support for the Broadcom BCM2835 SoC. This SoC is
use in the Raspberry Pi, and Roku 2 devices.
diff --git a/arch/arm/mach-bcm2835/bcm2835.c b/arch/arm/mach-bcm2835/bcm2835.c
index f6fea49..ab1bccd 100644
--- a/arch/arm/mach-bcm2835/bcm2835.c
+++ b/arch/arm/mach-bcm2835/bcm2835.c
@@ -13,10 +13,10 @@
*/
#include <linux/init.h>
-#include <linux/irqchip/bcm2835.h>
#include <linux/of_platform.h>
#include <linux/bcm2835_timer.h>
#include <linux/clk/bcm2835.h>
+#include <linux/irqchip.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
@@ -56,8 +56,7 @@ static const char * const bcm2835_compat[] = {
DT_MACHINE_START(BCM2835, "BCM2835")
.map_io = bcm2835_map_io,
- .init_irq = bcm2835_init_irq,
- .handle_irq = bcm2835_handle_irq,
+ .init_irq = irqchip_init,
.init_machine = bcm2835_init,
.timer = &bcm2835_timer,
.dt_compat = bcm2835_compat
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index dc670cc..6f845c7 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -49,9 +49,11 @@
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/irqdomain.h>
-#include <linux/irqchip/bcm2835.h>
#include <asm/exception.h>
+#include <asm/mach/irq.h>
+
+#include "irqchip.h"
/* Put the bank and irq (32 bits) into the hwirq */
#define MAKE_HWIRQ(b, n) ((b << 5) | (n))
@@ -94,6 +96,52 @@ struct armctrl_ic {
static struct armctrl_ic intc __read_mostly;
+/*
+ * Handle each interrupt across the entire interrupt controller. This reads the
+ * status register before handling each interrupt, which is necessary given that
+ * handle_IRQ may briefly re-enable interrupts for soft IRQ handling.
+ */
+
+static void armctrl_handle_bank(int bank, struct pt_regs *regs)
+{
+ u32 stat, irq;
+
+ while ((stat = readl_relaxed(intc.pending[bank]))) {
+ irq = MAKE_HWIRQ(bank, ffs(stat) - 1);
+ handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
+ }
+}
+
+static void armctrl_handle_shortcut(int bank, struct pt_regs *regs,
+ u32 stat)
+{
+ u32 irq = MAKE_HWIRQ(bank, shortcuts[ffs(stat >> SHORTCUT_SHIFT) - 1]);
+ handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
+}
+
+static asmlinkage void __exception_irq_entry
+bcm2835_handle_irq(struct pt_regs *regs)
+{
+ u32 stat, irq;
+
+ while ((stat = readl_relaxed(intc.pending[0]) & BANK0_VALID_MASK)) {
+ if (stat & BANK0_HWIRQ_MASK) {
+ irq = MAKE_HWIRQ(0, ffs(stat & BANK0_HWIRQ_MASK) - 1);
+ handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
+ } else if (stat & SHORTCUT1_MASK) {
+ armctrl_handle_shortcut(1, regs, stat & SHORTCUT1_MASK);
+ } else if (stat & SHORTCUT2_MASK) {
+ armctrl_handle_shortcut(2, regs, stat & SHORTCUT2_MASK);
+ } else if (stat & BANK1_HWIRQ) {
+ armctrl_handle_bank(1, regs);
+ } else if (stat & BANK2_HWIRQ) {
+ armctrl_handle_bank(2, regs);
+ } else {
+ BUG();
+ }
+ }
+}
+
static void armctrl_mask_irq(struct irq_data *d)
{
writel_relaxed(HWIRQ_BIT(d->hwirq), intc.disable[HWIRQ_BANK(d->hwirq)]);
@@ -135,8 +183,8 @@ static struct irq_domain_ops armctrl_ops = {
.xlate = armctrl_xlate
};
-static int __init armctrl_of_init(struct device_node *node,
- struct device_node *parent)
+int __init armctrl_of_init(struct device_node *node,
+ struct device_node *parent)
{
void __iomem *base;
int irq, b, i;
@@ -164,60 +212,8 @@ static int __init armctrl_of_init(struct device_node *node,
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
}
}
- return 0;
-}
-
-static struct of_device_id irq_of_match[] __initconst = {
- { .compatible = "brcm,bcm2835-armctrl-ic", .data = armctrl_of_init }
-};
-
-void __init bcm2835_init_irq(void)
-{
- of_irq_init(irq_of_match);
-}
-
-/*
- * Handle each interrupt across the entire interrupt controller. This reads the
- * status register before handling each interrupt, which is necessary given that
- * handle_IRQ may briefly re-enable interrupts for soft IRQ handling.
- */
-
-static void armctrl_handle_bank(int bank, struct pt_regs *regs)
-{
- u32 stat, irq;
-
- while ((stat = readl_relaxed(intc.pending[bank]))) {
- irq = MAKE_HWIRQ(bank, ffs(stat) - 1);
- handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
- }
-}
-static void armctrl_handle_shortcut(int bank, struct pt_regs *regs,
- u32 stat)
-{
- u32 irq = MAKE_HWIRQ(bank, shortcuts[ffs(stat >> SHORTCUT_SHIFT) - 1]);
- handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
-}
-
-asmlinkage void __exception_irq_entry bcm2835_handle_irq(
- struct pt_regs *regs)
-{
- u32 stat, irq;
+ handle_arch_irq = bcm2835_handle_irq;
- while ((stat = readl_relaxed(intc.pending[0]) & BANK0_VALID_MASK)) {
- if (stat & BANK0_HWIRQ_MASK) {
- irq = MAKE_HWIRQ(0, ffs(stat & BANK0_HWIRQ_MASK) - 1);
- handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
- } else if (stat & SHORTCUT1_MASK) {
- armctrl_handle_shortcut(1, regs, stat & SHORTCUT1_MASK);
- } else if (stat & SHORTCUT2_MASK) {
- armctrl_handle_shortcut(2, regs, stat & SHORTCUT2_MASK);
- } else if (stat & BANK1_HWIRQ) {
- armctrl_handle_bank(1, regs);
- } else if (stat & BANK2_HWIRQ) {
- armctrl_handle_bank(2, regs);
- } else {
- BUG();
- }
- }
+ return 0;
}
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index 410f99f..f01cf6e 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -14,6 +14,9 @@
#include "irqchip.h"
static const struct of_device_id irqchip_of_match[] __initconst = {
+#ifdef CONFIG_ARCH_BCM2835
+ { .compatible = "brcm,bcm2835-armctrl-ic", .data = armctrl_of_init },
+#endif
{},
};
diff --git a/drivers/irqchip/irqchip.h b/drivers/irqchip/irqchip.h
index 1e7a5c2..0e68965 100644
--- a/drivers/irqchip/irqchip.h
+++ b/drivers/irqchip/irqchip.h
@@ -11,4 +11,6 @@
#ifndef _IRQCHIP_H
#define _IRQCHIP_H
+int armctrl_of_init(struct device_node *node, struct device_node *parent);
+
#endif
diff --git a/include/linux/irqchip/bcm2835.h b/include/linux/irqchip/bcm2835.h
deleted file mode 100644
index 48a859b..0000000
--- a/include/linux/irqchip/bcm2835.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * Copyright (C) 2010 Broadcom
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#ifndef __LINUX_IRQCHIP_BCM2835_H_
-#define __LINUX_IRQCHIP_BCM2835_H_
-
-#include <asm/exception.h>
-
-extern void bcm2835_init_irq(void);
-
-extern asmlinkage void __exception_irq_entry bcm2835_handle_irq(
- struct pt_regs *regs);
-
-#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] irqchip: add basic infrastructure
From: Thomas Petazzoni @ 2012-10-27 16:45 UTC (permalink / raw)
To: linux-arm-kernel
With the recent creation of the drivers/irqchip/ directory, it is
desirable to move irq controller drivers here. At the moment, the only
driver here is irq-bcm2835, the driver for the irq controller found in
the ARM BCM2835 SoC, present in Rasberry Pi systems. This irq
controller driver was exporting its initialization function and its
irq handling function through a header file in
<linux/irqchip/bcm2835.h>.
When proposing to also move another irq controller driver in
drivers/irqchip, Rob Herring raised the very valid point that moving
things to drivers/irqchip was good in order to remove more stuff from
arch/arm, but if it means adding gazillions of headers files in
include/linux/irqchip/, it would not be very nice.
So, upon the suggestion of Rob Herring and Arnd Bergmann, this commit
introduces a small infrastructure that defines a central
irqchip_init() function in drivers/irqchip/irqchip.c, which is meant
to be called as the ->init_irq() callback of ARM platforms. This
function calls of_irq_init() with an array that will progressively
contain the compatible strings of each irq controller driver, and also
a reference to the initialization functions of such drivers. The
drivers/irqchip/irqchip.h header file, currently empty, is added to
allow irq controller drivers to expose their initialization function
to the main irqchip.c file. Note that the irq controller driver
initialization function is responsible for setting the global
handle_arch_irq() variable, so that ARM platforms no longer have to
define the ->handle_irq field in their DT_MACHINE structure.
A global header, <linux/irqchip.h> is also added to expose the single
irqchip_init() function to the reset of the kernel.
A further commit moves the BCM2835 irq controller driver to this new
small infrastructure, therefore removing the include/linux/irqchip/
directory.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/irqchip/Kconfig | 3 ++-
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irqchip.c | 23 +++++++++++++++++++++++
drivers/irqchip/irqchip.h | 14 ++++++++++++++
include/linux/irqchip.h | 16 ++++++++++++++++
5 files changed, 56 insertions(+), 1 deletion(-)
create mode 100644 drivers/irqchip/irqchip.c
create mode 100644 drivers/irqchip/irqchip.h
create mode 100644 include/linux/irqchip.h
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 1bb8bf6..e0ff166 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -1 +1,2 @@
-# empty
+config USE_IRQCHIP
+ bool
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 054321d..77adcb1 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1 +1,2 @@
+obj-$(CONFIG_USE_IRQCHIP) += irqchip.o
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
new file mode 100644
index 0000000..410f99f
--- /dev/null
+++ b/drivers/irqchip/irqchip.c
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2012 Thomas Petazzoni
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/init.h>
+#include <linux/of_irq.h>
+
+#include "irqchip.h"
+
+static const struct of_device_id irqchip_of_match[] __initconst = {
+ {},
+};
+
+void __init irqchip_init(void)
+{
+ of_irq_init(irqchip_of_match);
+}
diff --git a/drivers/irqchip/irqchip.h b/drivers/irqchip/irqchip.h
new file mode 100644
index 0000000..1e7a5c2
--- /dev/null
+++ b/drivers/irqchip/irqchip.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) 2012 Thomas Petazzoni
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _IRQCHIP_H
+#define _IRQCHIP_H
+
+#endif
diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
new file mode 100644
index 0000000..e0006f1
--- /dev/null
+++ b/include/linux/irqchip.h
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2012 Thomas Petazzoni
+ *
+ * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _LINUX_IRQCHIP_H
+#define _LINUX_IRQCHIP_H
+
+void irqchip_init(void);
+
+#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board
From: Andrew Lunn @ 2012-10-27 16:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351354965-23875-1-git-send-email-gregory.clement@free-electrons.com>
> diff --git a/arch/arm/boot/dts/mbx001.dts b/arch/arm/boot/dts/mbx001.dts
> new file mode 100644
> index 0000000..88a5a11
> --- /dev/null
> +++ b/arch/arm/boot/dts/mbx001.dts
Hi Gregory
Maybe it would be good to prefix this with armada-370. It then fits
with armada-370-db.dts, and all the kirkwood files are kirkwood-*.dts.
Andrew
^ permalink raw reply
* [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg
From: Al Viro @ 2012-10-27 16:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027163224.67d57aef@endymion.delvare>
On Sat, Oct 27, 2012 at 04:32:24PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 15:18:00 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> > > The original idea of using the hole in the i2c_msg structure is from
> > > David Brownell, who was apparently familiar with such practice, so I
> > > assumed it was OK. Actually I still assume it is, until someone comes
> > > with an supported architecture where it is not.
> >
> > According to Al Viro, that would be m68k.
>
> OK... So to make things clear, let me ask Al directly about it. Al, can
> you please tell us if:
[snip]
> would break binary compatibility on m68k or any other architecture you
> are familiar with? Note that struct i2c_msg isn't declared with
> attribute packed, so my assumption was that pointer "buf" was align on
> at least 4 bytes, leaving a hole between len and buf. Am I wrong?
You are wrong. Assumption that pointers are aligned to 32bit boundary
is simply not true. In particular, on m68k alignment is 16bit, i.e. there
struct foo {
char x;
void *p;
}; will have 1 byte occupied by x, followed by 1-byte gap, followed by 4 bytes
occupied by p.
Note, BTW, that m68k includes things like coldfire, etc. and I wouldn't be
surprised by e.g. coldfire-based SoC with i2c on it.
^ permalink raw reply
* [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board
From: Sebastian Hesselbarth @ 2012-10-27 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027183326.62ab505a@skate>
On 10/27/2012 06:33 PM, Thomas Petazzoni wrote:
> On Sat, 27 Oct 2012 18:22:45 +0200, Gregory CLEMENT wrote:
>> This platform, available from Globalscale has an Armada 370. For now,
>> only the serial port is supported. Support for network, USB and other
>> peripherals will be added as drivers for them become available for
>> Armada 370 in mainline.
>
> Great!
ACK!
>> +++ b/arch/arm/boot/dts/mbx001.dts
>
> If you decided to name your platform with four zeros (00001), then the
> file should be mbx0001.dts here.
What is wrong with "globalscale,mirabox" ?
Sebastian
^ permalink raw reply
* [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board
From: Thomas Petazzoni @ 2012-10-27 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351354965-23875-1-git-send-email-gregory.clement@free-electrons.com>
Hello,
On Sat, 27 Oct 2012 18:22:45 +0200, Gregory CLEMENT wrote:
> This platform, available from Globalscale has an Armada 370. For now,
> only the serial port is supported. Support for network, USB and other
> peripherals will be added as drivers for them become available for
> Armada 370 in mainline.
Great!
> +++ b/arch/arm/boot/dts/mbx001.dts
If you decided to name your platform with four zeros (00001), then the
file should be mbx0001.dts here.
> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> index 49d7915..e5269b4 100644
> --- a/arch/arm/mach-mvebu/armada-370-xp.c
> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> @@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
> static const char * const armada_370_xp_dt_board_dt_compat[] = {
> "marvell,a370-db",
> "marvell,axp-db",
> + "globalscale,mbx0001",
> NULL,
> };
As Andrew said, sorted entries would be nicer.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] omap plat header removal for v3.8 merge window, part1
From: Tony Lindgren @ 2012-10-27 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121027090210.GJ28061@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [121027 02:03]:
>
> Rather than moving all the files from plat-omap/include/plat into plat-omap
> and then having all these totally disgusting relative includes, why don't
> you add to these makefiles:
>
> ccflags += -I$(srctree)/arch/arm/plat-omap/include
>
> and avoid all that include moving and all the include name fixup?
I'll take a look. Most of these headers should be local,
so it should not be too many files to move for plat-omap
to fix this.
Regards,
Tony
^ permalink raw reply
* [PATCH] GPIO: mvebu-gpio: Don't initialize the mask_cache
From: Linus Walleij @ 2012-10-27 16:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351344538-5238-1-git-send-email-andrew@lunn.ch>
On Sat, Oct 27, 2012 at 3:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> Due to the SMP nature of some of the chips, which have per CPU
> registers, the driver does not use the generic irq_gc_mask_set_bit() &
> irq_gc_mask_clr_bit() functions, which only support a single register.
> The driver has its own implementation of these functions, which can
> pick the correct register depending on the CPU being used. The
> functions do however use the gc->mask_cache value.
>
> The call to irq_setup_generic_chip() was passing
> IRQ_GC_INIT_MASK_CACHE, which caused the gc->mask_cache to be
> initialized to the contents of some random register. This resulted in
> unexpected interrupts been delivered from random GPIO lines.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Thanks, patch applied to fixes. Unless Thomas screams...
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] omap plat header removal for v3.8 merge window, part1
From: Tony Lindgren @ 2012-10-27 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210270809.02140.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [121027 01:11]:
> On Friday 26 October 2012, Tony Lindgren wrote:
> > Here's a patch for that. It's against what I have queued up in
> > omap-for-v3.8/cleanup-headers. Does that look OK to you?
>
> Hi Tony,
>
> thanks for the quick follow-up. Using the absolute #include statements
> again looks good, but now there is another problem:
>
> > diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
> > index cd169c3..03b1e80 100644
> > --- a/arch/arm/mach-omap1/Makefile
> > +++ b/arch/arm/mach-omap1/Makefile
> > @@ -2,6 +2,8 @@
> > # Makefile for the linux kernel.
> > #
> >
> > +ccflags-$(CONFIG_ARCH_OMAP) := -I$(srctree)/arch/arm
> > +
>
> This is not what I meant, I don't think we want to have the entire
> arch/arm/ hierarchy visible in platform directories. Instead, I thought
> we'd keep using the existing arch/arm/mach-$foo/include/mach directories
> that are currently visible to all files and make them available only
> to platforms that explicitly add -I$(srctree)/arch/arm/include/mach-$foo/include
> to their local include path.
>
> This of course requires moving all those headers back to where they just came
> from.
OK I'll take a look. Most of them should be local to mach-omap2,
so it may not be that bad with the file moves.
Regards,
Tony
^ permalink raw reply
* [PATCH v5] gpio/omap: fix off-mode bug: clear debounce settings on free/reset
From: Linus Walleij @ 2012-10-27 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351279564-4591-1-git-send-email-jon-hunter@ti.com>
On Fri, Oct 26, 2012 at 9:26 PM, Jon Hunter <jon-hunter@ti.com> wrote:
> This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
> clock enable mask on free/reset". The title has been updated slightly to
> reflect (what should be) the final fix.
>
> When a GPIO is freed or shutdown, we need to ensure that any debounce settings
> are cleared and if the GPIO is the only GPIO in the bank that is currently
> using debounce, then disable the debounce clock as well to save power.
>
> Currently, the debounce settings are not cleared on a GPIO free or shutdown and
> so during a context restore on subsequent off-mode transition, the previous
> debounce values are restored from the shadow copies (bank->context.debounce*)
> leading to mismatch state between driver state and hardware state.
>
> This was discovered when board code was doing
>
> gpio_request_one()
> gpio_set_debounce()
> gpio_free()
>
> which was leaving the GPIO debounce settings in a confused state. If that GPIO
> bank is subsequently used with off-mode enabled, bogus state would be restored,
> leaving GPIO debounce enabled which then prevented the CORE powerdomain from
> transitioning.
>
> To fix this, introduce a new function called _clear_gpio_debounce() to clear
> any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
> last debounce-enabled GPIO in the bank, the debounce will also be cut.
>
> Please note that we cannot use _gpio_dbck_disable() to disable the debounce
> clock because this has been specifically created for the gpio suspend path
> and is intended to shutdown the debounce clock while debounce is enabled.
>
> Special thanks to Kevin Hilman for root causing the bug. This fix is a
> collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
> Santosh Shilimkar.
>
> Testing:
> - This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
> enabling debounce and then freeing the gpio and checking the register
> contents, the saved register context and the debounce clock state.
> - Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
> ads7846 touchscreen in its board file using the above sequence, and so was
> failing off-mode tests in dynamic idle. Verified that off-mode tests are
> passing with this patch.
>
> V5 changes:
> - Corrected author
>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Cc: Grazvydas Ignotas <notasas@gmail.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> Tested-by: Kevin Hilman <khilman@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Hey there is a version I requested, with ACKs and all.
You must be reading my mind :-D
OK patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
From: Linus Walleij @ 2012-10-27 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5089C2B6.5020606@ti.com>
On Fri, Oct 26, 2012 at 12:52 AM, Jon Hunter <jon-hunter@ti.com> wrote:
> Subject: [PATCH] gpio/omap: fix clearing of debounce settings on gpio
> free/reset
>
> When a GPIO is freed or shutdown, we need to ensure that any debounce settings
> are cleared and if the GPIO is the only GPIO in the bank that is currently
> using debounce, then disable the debounce clock as well to save power.
>
> Therefore, introduce a new function called _clear_gpio_debounce() to clear
> any debounce settings when the GPIO is freed or shutdown.
>
> Please note that we cannot use _gpio_dbck_disable() to disable the debounce
> clock because this has been specifically created for the gpio suspend path
> and is intended to shutdown the debounce clock while debounce is enabled.
>
> This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
> enabling debounce and then freeing the gpio and checking the register contents,
> the saved register context and the debounce clock state.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
I have come to the conclusion that there is consensus to merge this
patch.
However it does *not* apply to my GPIO tree, which for the OMAP
driver is just a clean v3.7-rc1 and nothing else.
I previously reverted Kevin's patch, is this meant to be applied
on top of that one or what?
Jon, can you please submit a patch made against my GPIO
tree or linux-next or v3.7-rc2 or whatever and include the ACKs
you've recieved?
Thanks!
Linus Walleij
^ permalink raw reply
* [PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board
From: Gregory CLEMENT @ 2012-10-27 16:22 UTC (permalink / raw)
To: linux-arm-kernel
This platform, available from Globalscale has an Armada 370. For now,
only the serial port is supported. Support for network, USB and other
peripherals will be added as drivers for them become available for
Armada 370 in mainline.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/mbx001.dts | 37 +++++++++++++++++++++++++++++++++++
arch/arm/mach-mvebu/armada-370-xp.c | 1 +
3 files changed, 40 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/mbx001.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..ee09963 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -44,7 +44,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
msm8960-cdp.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
- armada-xp-db.dtb
+ armada-xp-db.dtb \
+ mbx0001.dtb
dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
imx53-evk.dtb \
diff --git a/arch/arm/boot/dts/mbx001.dts b/arch/arm/boot/dts/mbx001.dts
new file mode 100644
index 0000000..88a5a11
--- /dev/null
+++ b/arch/arm/boot/dts/mbx001.dts
@@ -0,0 +1,37 @@
+/*
+ * Device Tree file for Globalscale Mirabox MBX0001
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "armada-370.dtsi"
+
+/ {
+ model = "Mirabox MBX0001";
+ compatible = "globalscale,mbx0001", "marvell,armada370", "marvell,armada-370-xp";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x20000000>; /* 512 MB */
+ };
+
+ soc {
+ serial at d0012000 {
+ clock-frequency = <200000000>;
+ status = "okay";
+ };
+ timer at d0020300 {
+ clock-frequency = <600000000>;
+ status = "okay";
+ };
+ };
+};
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 49d7915..e5269b4 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
static const char * const armada_370_xp_dt_board_dt_compat[] = {
"marvell,a370-db",
"marvell,axp-db",
+ "globalscale,mbx0001",
NULL,
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge
From: Francesco Lavra @ 2012-10-27 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAB4BAkuPE6eSr2+LWTaV9trOnFk-_yt-+x8f6zpum=Ws1UvmmA@mail.gmail.com>
On 10/27/2012 06:00 PM, Rajanikanth HV wrote:
> On 27 October 2012 20:37, Francesco Lavra <francescolavra.fl@gmail.com> wrote:
>> On 10/25/2012 08:30 AM, Rajanikanth H.V wrote:
>>> From: "Rajanikanth H.V" <rajanikanth.hv@stericsson.com>
>>> + bat_tech = of_get_property(np_bat_supply,
>>> + "stericsson,battery-type", NULL);
>>> + if (!bat_tech)
>>> + dev_warn(dev, "missing property battery-name/type\n");
>>> +
>>> + if (strncmp(bat_tech, "LION", 4) == 0) {
>>
>> What if bat_tech is NULL?
> It will be UNKNOWN
I wanted to draw your attention to the fact that if bat_tech is NULL you
are passing a NULL pointer to strncmp(), which is not good.
So you should assign a default value to bat_tech in case the battery
type property is not found in the DT, as below:
if (!bat_tech) {
dev_warn(dev, "missing property battery-name/type\n");
bat_tech = "UNKNOWN";
}
--
Francesco
^ permalink raw reply
* [GIT PULL] arm-soc fixes for 3.7-rc3
From: Arnd Bergmann @ 2012-10-27 16:01 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-3.7
for you to fetch changes up to 943bb48755a7f70ee36e029904ed8b679bb1da58:
Revert "ARM i.MX25: Fix PWM per clock lookups" (2012-10-27 17:46:56 +0200)
----------------------------------------------------------------
arm-soc: fixes for v3.7-rc3
Bug fixes for a number of ARM platforms, mostly OMAP, imx and at91.
These come a little later than I had hoped but unfortunately we
had a few of these patches cause regressions themselves and had to
work out how to deal with those in the meantime.
----------------------------------------------------------------
Arnd Bergmann (9):
Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into fixes
Merge branch 'for-rcs-3.7' of git://git.linaro.org/people/ljones/linux-3.0-ux500 into fixes
Merge tag 'imx-fixes' of git://git.pengutronix.de/git/imx/linux-2.6 into fixes
Merge tag 'omap-for-v3.7-rc2/fixes-signed' of git://git.kernel.org/.../tmlind/linux-omap into fixes
Merge branch 'v3.7-samsung-fixes-2' of git://git.kernel.org/.../kgene/linux-samsung into fixes
Merge branch 'fixes' of git://git.kernel.org/.../horms/renesas into fixes
ARM: at91: fix at91x40 build
ARM: versatile: fix versatile_defconfig
Revert "ARM i.MX25: Fix PWM per clock lookups"
Bo Shen (2):
ARM: at91/i2c: change id to let i2c-gpio work
ARM: at91/i2c: change id to let i2c-at91 work
Fabio Estevam (3):
ARM: imx_v6_v7_defconfig: Enable CONFIG_GPIO_MC9S08DZ60
ARM: imx: clk-imx27: Fix divider width field
ARM: mxc: platform-mxc-mmc: Fix register region size
Heiko Stuebner (1):
ARM: SAMSUNG: Add naming of s3c64xx-spi devices
Huang Shijie (1):
ARM: dts: mxs: add the "clock-names" for gpmi-nand
Ivan Shugov (1):
ARM: at91: at91sam9g10: fix SOC type detection
Jean-Christophe PLAGNIOL-VILLARD (1):
ARM: at91: drop duplicated config SOC_AT91SAM9 entry
Josh Wu (1):
ARM: at91/tc: fix typo in the DT document
Kevin Hilman (2):
ARM: OMAP2: UART: fix console UART mismatched runtime PM status
ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
Kuninori Morimoto (1):
ARM: shmobile: r8a7779: I/O address abuse cleanup
Lee Jones (3):
ARM: ux500: Fix build error relating to IRQCHIP_SKIP_SET_WAKE
ARM: ux500: Specify AMBA Primecell IDs for Nomadik I2C in DT
ARM: ux500: Correct SDI5 address and add some format changes
Marek Belisko (1):
ARM: at91/dts: at91sam9g20ek_common: Fix typos in buttons labels.
Nicolas Ferre (2):
ARM: at91: fix external interrupts in non-DT case
ARM: at91: fix external interrupt specification in board code
Paul Walmsley (1):
ARM: OMAP3: PM: apply part of the erratum i582 workaround
Pavel Machek (1):
ARM: socfpga: Fix socfpga compilation with early_printk() enabled
Peter Ujfalusi (1):
ARM/dts: omap3: Fix mcbsp2/3 hwmods to be able to probe the drivers for audio
Sascha Hauer (3):
ARM i.MX25: Fix lcdc_ipg_per parent clock
ARM i.MX25 clk: Fix nfc_ipg_per parent
ARM i.MX25: Fix PWM per clock lookups
Stephen Boyd (1):
MAINTAINERS: Add arm-soc tree entry
Thomas Petazzoni (1):
ARM: mvebu: update defconfig with 3.7 changes
Tomasz Figa (2):
ARM: dts: Split memory into 4 sections for exynos4210-trats
ARM: EXYNOS: Set .smp field of machine descriptor for exynos4-dt
Tony Lindgren (3):
ARM: OMAP2+: Fix location of select PINCTRL
ARM: OMAP3: Fix 3430 legacy mux names for ssi1 signals.
Merge tag 'for_3.7-rc3-fixes-pm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.7-rc2/fixes
Vaibhav Hiremath (1):
ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driverDate:Wed, 17 Oct 2012 13:55:55 -0500
Viresh Kumar (1):
ARM: SPEAr: Remove unused empty files
Wei Yongjun (2):
ARM: imx: fix return value check in imx3_init_l2x0()
ARM: imx: fix the return value check in imx_clk_busy_divider()
.../devicetree/bindings/arm/atmel-at91.txt | 2 +-
MAINTAINERS | 7 +++++
arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 4 +--
arch/arm/boot/dts/dbx5x0.dtsi | 17 ++++++++++-
arch/arm/boot/dts/exynos4210-trats.dts | 6 ++--
arch/arm/boot/dts/imx23.dtsi | 1 +
arch/arm/boot/dts/imx28.dtsi | 1 +
arch/arm/boot/dts/omap3.dtsi | 4 +--
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
arch/arm/configs/mvebu_defconfig | 10 +++++--
arch/arm/configs/versatile_defconfig | 1 +
arch/arm/include/debug/8250_32.S | 27 ++++++++++++++++++
arch/arm/include/debug/picoxcell.S | 18 +-----------
arch/arm/include/debug/socfpga.S | 5 ++++
arch/arm/mach-at91/Kconfig | 10 ++-----
arch/arm/mach-at91/at91rm9200.c | 2 +-
arch/arm/mach-at91/at91rm9200_devices.c | 4 +--
arch/arm/mach-at91/at91sam9260.c | 4 +--
arch/arm/mach-at91/at91sam9260_devices.c | 4 +--
arch/arm/mach-at91/at91sam9261.c | 4 +--
arch/arm/mach-at91/at91sam9261_devices.c | 4 +--
arch/arm/mach-at91/at91sam9263.c | 2 +-
arch/arm/mach-at91/at91sam9263_devices.c | 4 +--
arch/arm/mach-at91/at91sam9rl_devices.c | 4 +--
arch/arm/mach-at91/at91x40.c | 2 +-
arch/arm/mach-at91/board-neocore926.c | 2 +-
arch/arm/mach-at91/board-sam9261ek.c | 2 +-
arch/arm/mach-at91/board-sam9263ek.c | 2 +-
arch/arm/mach-at91/generic.h | 3 +-
arch/arm/mach-at91/irq.c | 9 ++++--
arch/arm/mach-at91/setup.c | 4 +--
arch/arm/mach-exynos/common.c | 5 ++++
arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
arch/arm/mach-imx/clk-busy.c | 2 +-
arch/arm/mach-imx/clk-imx25.c | 4 +--
arch/arm/mach-imx/clk-imx27.c | 4 +--
arch/arm/mach-imx/mm-imx3.c | 5 ++--
arch/arm/mach-omap2/Kconfig | 1 -
arch/arm/mach-omap2/board-omap3beagle.c | 22 ++++++++------
arch/arm/mach-omap2/clock33xx_data.c | 2 ++
arch/arm/mach-omap2/mux34xx.c | 8 +++---
arch/arm/mach-omap2/pm.h | 1 +
arch/arm/mach-omap2/pm34xx.c | 30 ++++++++++++++++++--
arch/arm/mach-omap2/serial.c | 5 ++++
arch/arm/mach-s3c24xx/s3c2416.c | 2 ++
arch/arm/mach-s3c24xx/s3c2443.c | 4 +++
arch/arm/mach-s5p64x0/common.c | 3 ++
arch/arm/mach-s5pc100/common.c | 3 ++
arch/arm/mach-s5pv210/common.c | 3 ++
arch/arm/mach-shmobile/setup-r8a7779.c | 2 +-
arch/arm/mach-ux500/cpu.c | 1 +
arch/arm/plat-mxc/devices/platform-mxc-mmc.c | 2 +-
arch/arm/plat-omap/Kconfig | 1 +
arch/arm/plat-samsung/include/plat/spi-core.h | 30 ++++++++++++++++++++
54 files changed, 225 insertions(+), 87 deletions(-)
create mode 100644 arch/arm/include/debug/8250_32.S
delete mode 100644 arch/arm/mach-spear13xx/include/mach/spear1310_misc_regs.h
delete mode 100644 arch/arm/mach-spear13xx/include/mach/spear1340_misc_regs.h
create mode 100644 arch/arm/plat-samsung/include/plat/spi-core.h
^ 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