* [PATCH] ARM: OMAP2+: Fix selection of clockevent timer when using device-tree
From: Jon Hunter @ 2013-01-30 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433ED03931@DBDE01.ent.ti.com>
On 01/30/2013 01:18 AM, Bedia, Vaibhav wrote:
> On Wed, Jan 30, 2013 at 01:53:11, Hunter, Jon wrote:
>> Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added
>> device-tree support for selecting a clockevent timer by property.
>> However, the code is currently ignoring the property passed and
>> selecting the first available timer found. Hence, for the OMAP3 beagle
>> board timer-12 is not being selected as expected. Fix this problem
>> by ensuring the timer property is passed to omap_get_timer_dt().
>
> I thought that was intentional ;) and had this change in the clkevt-clksrc
> interchange patch for AM33xx.
No definitely was not. Thanks, I had missed that detail in the patch you
sent!
> Anyways, this change works for me so...
>
> Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Thanks!
Jon
^ permalink raw reply
* Commit 384a290283fde63ba8dc671fca5420111cdac19a seems to break 11MPCore boot
From: Will Deacon @ 2013-01-30 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301301223290.6300@xanadu.home>
On Wed, Jan 30, 2013 at 05:30:06PM +0000, Nicolas Pitre wrote:
> On Wed, 30 Jan 2013, Russell King - ARM Linux wrote:
>
> > On Wed, Jan 30, 2013 at 04:45:35PM +0000, Russell King - ARM Linux wrote:
> > > What we could do is scan interrupts 0-31 for a non-zero value. If they're
> > > all zero, we should complain. Otherwise, we use the first non-zero value
> > > we find and validate it for a single bit set.
> >
> > And here's a patch to do this - I've not run this but it's just built
> > successfully here. Anyone want to give it a go?
> >
> > I've decided that if we do hit the mask==0 case, we should just wail
> > loudly - panic'ing will bring the kernel to a halt right there and then,
> > which may be before any console drivers have been initialized (and the
> > kernel message buffer is no longer easy to read). Moreover, panic()ing,
> > along with the possibility of rebooting won't really fix this kind of
> > error - it's rather fatal as far as that goes. So, I think just wailing
> > at CRIT level is fine for this condition that should not occur.
> >
> > arch/arm/common/gic.c | 23 +++++++++++++++++++++--
> > 1 files changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> > index 36ae03a..3bcef49 100644
> > --- a/arch/arm/common/gic.c
> > +++ b/arch/arm/common/gic.c
> > @@ -351,6 +351,23 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
> > irq_set_chained_handler(irq, gic_handle_cascade_irq);
> > }
> >
> > +static u8 gic_get_cpumask(struct gic_chip_data *gic)
> > +{
> > + void __iomem *base = gic_data_dist_base(gic);
> > + u8 mask, i;
> > +
> > + for (i = mask = 0; i < 32; i++) {
> > + mask = readl_relaxed(base + GIC_DIST_TARGET + i);
> > + if (mask)
> > + break;
> > + }
>
> That should probably be:
>
> u32 mask;
>
> for (i = 0; i < 32; i += 4) {
> mask = readl_relaxed(base + GIC_DIST_TARGET + i);
> mask |= (mask >> 16);
> mask |= (mask >> 8);
> if (mask)
> return mask;
> }
>
> I know that the spec says that the GIC should accept byte sized
> accesses, but that too is known not to work on all implementations.
Oh, for a rotation operator!
Tested-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* Commit 384a290283fde63ba8dc671fca5420111cdac19a seems to break 11MPCore boot
From: Russell King - ARM Linux @ 2013-01-30 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301301223290.6300@xanadu.home>
On Wed, Jan 30, 2013 at 12:30:06PM -0500, Nicolas Pitre wrote:
> That should probably be:
>
> u32 mask;
>
> for (i = 0; i < 32; i += 4) {
> mask = readl_relaxed(base + GIC_DIST_TARGET + i);
> mask |= (mask >> 16);
> mask |= (mask >> 8);
> if (mask)
> return mask;
> }
>
> I know that the spec says that the GIC should accept byte sized
> accesses, but that too is known not to work on all implementations.
Well, it really doesn't make that much difference... because from what
I can see the kernel is rather sodded up as it currently stands.
There was a time when the kernel ran on the ARM Realview EB. But it
doesn't today...
Why is it when I walk away from anything kernel related and then come
back to it, it's always sodded up and rather terminally broken?
^ permalink raw reply
* [GIT PULL] vexpress: drivers for v3.9
From: Olof Johansson @ 2013-01-30 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359561551.3094.17.camel@hornet>
On Wed, Jan 30, 2013 at 03:59:11PM +0000, Pawel Moll wrote:
> On Wed, 2013-01-30 at 10:38 +0000, Pawel Moll wrote:
> > In the meantime, could you please take the other patch please? I mean:
> >
> > > > Catalin Marinas (1):
> > > > arm: Move sp810.h to include/linux/amba/
> >
> > I can rework the branch to contain this patch only and send a new pull
> > request if you prefer.
>
> As Samuel will take the LEDs patch through his tree, I've regenerated
> the branch, so:
>
> The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
>
> Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/pawelmoll/linux.git tags/vexpress/drivers-for-3.9
Pulled, thanks.
-Olof
^ permalink raw reply
* [PATCH 1/1] pinctrl: nomadik: Rename Device Tree compatible string
From: Linus Walleij @ 2013-01-30 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130170750.GA5217@gmail.com>
On Wed, Jan 30, 2013 at 6:07 PM, Lee Jones <lee.jones@linaro.org> wrote:
> The preference is to use '-' instead of '_' in compatible strings.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
This does not apply to pinctrl devel. (Same as linux-next)
This is because the two hunks, as compared to the last patch,
were already in-tree, they were changed as part of patch:
commit e32af889458837d11a1ec5ec98934a1e711b049d
Author: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Date: Mon Dec 17 15:53:24 2012 +0100
pinctrl/nomadik: add device tree support
This implements pin multiplexing and pin configuration for
the Nomadik pin controller using the device tree.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@stericsson.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Philippe Langlais <philippe.langlais@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since I don't dare to squash this oneliner into that patch
for fear of Lee's rage, I leave the old patch as it is.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Jason Cooper @ 2013-01-30 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510959D5.1010305@free-electrons.com>
Gregory,
Adding devicetree-discuss.
Guys, how do you prefer to handle plug-in RAM modules? describe the
soldered-in amount, or?
On Wed, Jan 30, 2013 at 06:35:17PM +0100, Gregory CLEMENT wrote:
> On 01/30/2013 06:33 PM, Jason Cooper wrote:
> > On Wed, Jan 30, 2013 at 06:26:14PM +0100, Gregory CLEMENT wrote:
> >> This is the new Armada XP evaluation board from Marvell. It comes with
> >> a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
> >> Gigabit links.
> >>
> >> Support for USB (Host and device), SDIO, PCIe will be added as drivers
> >> when they become available for Armada XP in mainline.
> >>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >> ---
> >> arch/arm/boot/dts/Makefile | 1 +
> >> arch/arm/boot/dts/armada-xp-gp.dts | 94 ++++++++++++++++++++++++++++++++++++
> >> 2 files changed, 95 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/armada-xp-gp.dts
> >>
...
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <0x00000000 0xC0000000>; /* 3 GB */
> >
> > Is this the soldered on the board amount, or the amount with an
> > expandable slot filled?
>
> It is not soldered, so you can change the amount of memory
Well, there's something we don't encounter too much in the embedded
world. ;-) I'm inclined to think the entry here should be the soldered
on amount, and the bootloader would (hypothetically) change the DT to
the probed amount. But I haven't seen a precedent set yet...
thx,
Jason.
^ permalink raw reply
* Commit 384a290283fde63ba8dc671fca5420111cdac19a seems to break 11MPCore boot
From: Russell King - ARM Linux @ 2013-01-30 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130180331.GP23505@n2100.arm.linux.org.uk>
On Wed, Jan 30, 2013 at 06:03:31PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 30, 2013 at 12:30:06PM -0500, Nicolas Pitre wrote:
> > That should probably be:
> >
> > u32 mask;
> >
> > for (i = 0; i < 32; i += 4) {
> > mask = readl_relaxed(base + GIC_DIST_TARGET + i);
> > mask |= (mask >> 16);
> > mask |= (mask >> 8);
> > if (mask)
> > return mask;
> > }
> >
> > I know that the spec says that the GIC should accept byte sized
> > accesses, but that too is known not to work on all implementations.
>
> Well, it really doesn't make that much difference... because from what
> I can see the kernel is rather sodded up as it currently stands.
>
> There was a time when the kernel ran on the ARM Realview EB. But it
> doesn't today...
>
> Why is it when I walk away from anything kernel related and then come
> back to it, it's always sodded up and rather terminally broken?
Finally, it now tries to mount a rootfs, and dies with the following:
BUG: spinlock lockup suspected on CPU#0, init/1
lock: 0xcf8bde10, .magic: dead4ead, .owner: init/1, .owner_cpu: 0
Backtrace:
[<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c)
r6:cf8bde10 r5:cf83d1c0 r4:cf8bde10 r3:cf83d1c0
[<c03294d0>] (dump_stack+0x0/0x1c) from [<c018926c>] (spin_dump+0x84/0x98)
[<c01891e8>] (spin_dump+0x0/0x98) from [<c0189460>] (do_raw_spin_lock+0x100/0x19
8)
r5:00000000 r4:025e4000
[<c0189360>] (do_raw_spin_lock+0x0/0x198) from [<c032cbac>] (_raw_spin_lock+0x3c
/0x44)
[<c032cb70>] (_raw_spin_lock+0x0/0x44) from [<c01c9224>] (pl011_console_write+0x
e8/0x11c)
r5:c0481780 r4:cf8bde10
[<c01c913c>] (pl011_console_write+0x0/0x11c) from [<c002aea8>] (call_console_dri
vers.clone.7+0xdc/0x104)
[<c002adcc>] (call_console_drivers.clone.7+0x0/0x104) from [<c002b320>] (console
_unlock+0x2e8/0x454)
[<c002b038>] (console_unlock+0x0/0x454) from [<c002b8b4>] (vprintk_emit+0x2d8/0x
594)
[<c002b5dc>] (vprintk_emit+0x0/0x594) from [<c0329718>] (printk+0x3c/0x44)
[<c03296dc>] (printk+0x0/0x44) from [<c002929c>] (warn_slowpath_common+0x28/0x6c
)
r3:00000009 r2:c0070ab0 r1:00000ab3 r0:c0334b60
[<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_nu
ll+0x24/0x2c)
r8:c00beb00 r7:000000d0 r6:cf8001c0 r5:60000093 r4:cf83e000
r3:00000009
[<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0070ab0>] (lockdep_trace_allo
c+0xd8/0xf0)
[<c00709d8>] (lockdep_trace_alloc+0x0/0xf0) from [<c00c0850>] (kmem_cache_alloc+
0x24/0x11c)
r5:20000008 r4:000080d0
[<c00c082c>] (kmem_cache_alloc+0x0/0x11c) from [<c00bb044>] (__get_vm_area_node.
clone.24+0x7c/0x16c)
r7:000000d0 r6:00000001 r5:20000008 r4:cf83fbc0
[<c00bafc8>] (__get_vm_area_node.clone.24+0x0/0x16c) from [<c00bb7b8>] (get_vm_a
rea_caller+0x48/0x54)
[<c00bb770>] (get_vm_area_caller+0x0/0x54) from [<c0020064>] (__alloc_remap_buff
er.clone.15+0x38/0xb8)
[<c002002c>] (__alloc_remap_buffer.clone.15+0x0/0xb8) from [<c0020244>] (__dma_a
lloc+0x160/0x2c8)
r8:00000000 r7:00002000 r6:00002000 r5:ffffffff r4:ffffffff
r3:cf83fc54
[<c00200e4>] (__dma_alloc+0x0/0x2c8) from [<c00204d8>] (arm_dma_alloc+0x88/0xa0)
[<c0020450>] (arm_dma_alloc+0x0/0xa0) from [<c00beb00>] (dma_pool_alloc+0xcc/0x1
a8)
[<c00bea34>] (dma_pool_alloc+0x0/0x1a8) from [<c01a9d14>] (pl08x_fill_llis_for_d
esc+0x28/0x568)
[<c01a9cec>] (pl08x_fill_llis_for_desc+0x0/0x568) from [<c01aab8c>] (pl08x_prep_
slave_sg+0x258/0x3b0)
[<c01aa934>] (pl08x_prep_slave_sg+0x0/0x3b0) from [<c01c9f74>] (pl011_dma_tx_ref
ill+0x140/0x288)
[<c01c9e34>] (pl011_dma_tx_refill+0x0/0x288) from [<c01ca748>] (pl011_start_tx+0
xe4/0x120)
[<c01ca664>] (pl011_start_tx+0x0/0x120) from [<c01c54a4>] (__uart_start+0x48/0x4
c)
r5:cfa7c400 r4:cf8bde10
[<c01c545c>] (__uart_start+0x0/0x4c) from [<c01c632c>] (uart_start+0x2c/0x3c)
[<c01c6300>] (uart_start+0x0/0x3c) from [<c01c795c>] (uart_write+0xcc/0xf4)
r6:cfa8b037 r5:cf906000 r4:00000000 r3:cf83d1c0
[<c01c7890>] (uart_write+0x0/0xf4) from [<c01b0384>] (n_tty_write+0x1c0/0x3e4)
[<c01b01c4>] (n_tty_write+0x0/0x3e4) from [<c01acfe8>] (tty_write+0x144/0x240)
[<c01acea4>] (tty_write+0x0/0x240) from [<c01ad17c>] (redirected_tty_write+0x98/
0xac)
[<c01ad0e4>] (redirected_tty_write+0x0/0xac) from [<c00c371c>] (vfs_write+0xbc/0
x150)
r8:00000000 r7:cf83ff70 r6:be83cc04 r5:00000038 r4:cf8b1d80
r3:cf83ff70
[<c00c3660>] (vfs_write+0x0/0x150) from [<c00c39c0>] (sys_write+0x4c/0x78)
r8:00000000 r7:be83cc04 r6:cf83ff70 r5:00000000 r4:cf8b1d80
[<c00c3974>] (sys_write+0x0/0x78) from [<c0014460>] (ret_fast_syscall+0x0/0x3c)
Now, this _used_ to work fine before the DMA code was changed... What
joy running ARM kernels bring. Thankfully I hardly ever do that nowadays.
I wonder why that is...
^ permalink raw reply
* Commit 384a290283fde63ba8dc671fca5420111cdac19a seems to break 11MPCore boot
From: Russell King - ARM Linux @ 2013-01-30 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130181651.GQ23505@n2100.arm.linux.org.uk>
On Wed, Jan 30, 2013 at 06:16:51PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 30, 2013 at 06:03:31PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 30, 2013 at 12:30:06PM -0500, Nicolas Pitre wrote:
> > > That should probably be:
> > >
> > > u32 mask;
> > >
> > > for (i = 0; i < 32; i += 4) {
> > > mask = readl_relaxed(base + GIC_DIST_TARGET + i);
> > > mask |= (mask >> 16);
> > > mask |= (mask >> 8);
> > > if (mask)
> > > return mask;
> > > }
> > >
> > > I know that the spec says that the GIC should accept byte sized
> > > accesses, but that too is known not to work on all implementations.
> >
> > Well, it really doesn't make that much difference... because from what
> > I can see the kernel is rather sodded up as it currently stands.
> >
> > There was a time when the kernel ran on the ARM Realview EB. But it
> > doesn't today...
> >
> > Why is it when I walk away from anything kernel related and then come
> > back to it, it's always sodded up and rather terminally broken?
>
> Finally, it now tries to mount a rootfs, and dies with the following:
>
> BUG: spinlock lockup suspected on CPU#0, init/1
> lock: 0xcf8bde10, .magic: dead4ead, .owner: init/1, .owner_cpu: 0
> Backtrace:
> [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c)
> r6:cf8bde10 r5:cf83d1c0 r4:cf8bde10 r3:cf83d1c0
> [<c03294d0>] (dump_stack+0x0/0x1c) from [<c018926c>] (spin_dump+0x84/0x98)
> [<c01891e8>] (spin_dump+0x0/0x98) from [<c0189460>] (do_raw_spin_lock+0x100/0x19
> 8)
> r5:00000000 r4:025e4000
> [<c0189360>] (do_raw_spin_lock+0x0/0x198) from [<c032cbac>] (_raw_spin_lock+0x3c
> /0x44)
> [<c032cb70>] (_raw_spin_lock+0x0/0x44) from [<c01c9224>] (pl011_console_write+0x
> e8/0x11c)
> r5:c0481780 r4:cf8bde10
> [<c01c913c>] (pl011_console_write+0x0/0x11c) from [<c002aea8>] (call_console_dri
> vers.clone.7+0xdc/0x104)
> [<c002adcc>] (call_console_drivers.clone.7+0x0/0x104) from [<c002b320>] (console
> _unlock+0x2e8/0x454)
> [<c002b038>] (console_unlock+0x0/0x454) from [<c002b8b4>] (vprintk_emit+0x2d8/0x
> 594)
> [<c002b5dc>] (vprintk_emit+0x0/0x594) from [<c0329718>] (printk+0x3c/0x44)
> [<c03296dc>] (printk+0x0/0x44) from [<c002929c>] (warn_slowpath_common+0x28/0x6c
> )
> r3:00000009 r2:c0070ab0 r1:00000ab3 r0:c0334b60
> [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_nu
> ll+0x24/0x2c)
> r8:c00beb00 r7:000000d0 r6:cf8001c0 r5:60000093 r4:cf83e000
> r3:00000009
> [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0070ab0>] (lockdep_trace_allo
> c+0xd8/0xf0)
> [<c00709d8>] (lockdep_trace_alloc+0x0/0xf0) from [<c00c0850>] (kmem_cache_alloc+
> 0x24/0x11c)
> r5:20000008 r4:000080d0
> [<c00c082c>] (kmem_cache_alloc+0x0/0x11c) from [<c00bb044>] (__get_vm_area_node.
> clone.24+0x7c/0x16c)
> r7:000000d0 r6:00000001 r5:20000008 r4:cf83fbc0
> [<c00bafc8>] (__get_vm_area_node.clone.24+0x0/0x16c) from [<c00bb7b8>] (get_vm_a
> rea_caller+0x48/0x54)
> [<c00bb770>] (get_vm_area_caller+0x0/0x54) from [<c0020064>] (__alloc_remap_buff
> er.clone.15+0x38/0xb8)
> [<c002002c>] (__alloc_remap_buffer.clone.15+0x0/0xb8) from [<c0020244>] (__dma_a
> lloc+0x160/0x2c8)
> r8:00000000 r7:00002000 r6:00002000 r5:ffffffff r4:ffffffff
> r3:cf83fc54
> [<c00200e4>] (__dma_alloc+0x0/0x2c8) from [<c00204d8>] (arm_dma_alloc+0x88/0xa0)
> [<c0020450>] (arm_dma_alloc+0x0/0xa0) from [<c00beb00>] (dma_pool_alloc+0xcc/0x1
> a8)
> [<c00bea34>] (dma_pool_alloc+0x0/0x1a8) from [<c01a9d14>] (pl08x_fill_llis_for_d
> esc+0x28/0x568)
> [<c01a9cec>] (pl08x_fill_llis_for_desc+0x0/0x568) from [<c01aab8c>] (pl08x_prep_
> slave_sg+0x258/0x3b0)
> [<c01aa934>] (pl08x_prep_slave_sg+0x0/0x3b0) from [<c01c9f74>] (pl011_dma_tx_ref
> ill+0x140/0x288)
> [<c01c9e34>] (pl011_dma_tx_refill+0x0/0x288) from [<c01ca748>] (pl011_start_tx+0
> xe4/0x120)
> [<c01ca664>] (pl011_start_tx+0x0/0x120) from [<c01c54a4>] (__uart_start+0x48/0x4
> c)
> r5:cfa7c400 r4:cf8bde10
> [<c01c545c>] (__uart_start+0x0/0x4c) from [<c01c632c>] (uart_start+0x2c/0x3c)
> [<c01c6300>] (uart_start+0x0/0x3c) from [<c01c795c>] (uart_write+0xcc/0xf4)
> r6:cfa8b037 r5:cf906000 r4:00000000 r3:cf83d1c0
> [<c01c7890>] (uart_write+0x0/0xf4) from [<c01b0384>] (n_tty_write+0x1c0/0x3e4)
> [<c01b01c4>] (n_tty_write+0x0/0x3e4) from [<c01acfe8>] (tty_write+0x144/0x240)
> [<c01acea4>] (tty_write+0x0/0x240) from [<c01ad17c>] (redirected_tty_write+0x98/
> 0xac)
> [<c01ad0e4>] (redirected_tty_write+0x0/0xac) from [<c00c371c>] (vfs_write+0xbc/0
> x150)
> r8:00000000 r7:cf83ff70 r6:be83cc04 r5:00000038 r4:cf8b1d80
> r3:cf83ff70
> [<c00c3660>] (vfs_write+0x0/0x150) from [<c00c39c0>] (sys_write+0x4c/0x78)
> r8:00000000 r7:be83cc04 r6:cf83ff70 r5:00000000 r4:cf8b1d80
> [<c00c3974>] (sys_write+0x0/0x78) from [<c0014460>] (ret_fast_syscall+0x0/0x3c)
>
> Now, this _used_ to work fine before the DMA code was changed... What
> joy running ARM kernels bring. Thankfully I hardly ever do that nowadays.
> I wonder why that is...
Oh, and there's also this:
WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:757 gic_init_bases+0x1
2c/0x2ec()
Cannot allocate irq_descs @ IRQ96, assuming pre-allocated
Modules linked in:
Backtrace:
[<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c)
r6:000002f5 r5:c042c62c r4:c044ff40 r3:c045f240
[<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/
0x6c)
[<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029384>] (warn_slowpath_fm
t+0x38/0x40)
r8:00000060 r7:00000020 r6:00000060 r5:00000040 r4:00000001
r3:00000009
[<c002934c>] (warn_slowpath_fmt+0x0/0x40) from [<c042c62c>] (gic_init_bases+0x12
c/0x2ec)
r3:00000060 r2:c03340b4
[<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd
8)
[<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24)
r4:ffffffff
[<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300)
[<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
r7:c04605dc r6:c044585c r5:c045c88c r4:00c5387d
---[ end trace 1b75b31a2719ed1c ]---
------------[ cut here ]------------
WARNING: at /home/rmk/git/linux-rmk/kernel/irq/irqdomain.c:234 irq_domain_add_le
gacy+0x80/0x140()
Modules linked in:
Backtrace:
[<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c)
r6:000000ea r5:c0081a38 r4:00000000 r3:c045f240
[<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/
0x6c)
[<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_nu
ll+0x24/0x2c)
r8:00000020 r7:00000020 r6:cf8019c0 r5:00000040 r4:00000060
r3:00000009
[<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0081a38>] (irq_domain_add_leg
acy+0x80/0x140)
[<c00819b8>] (irq_domain_add_legacy+0x0/0x140) from [<c042c64c>] (gic_init_bases
+0x14c/0x2ec)
[<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd
8)
[<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24)
r4:ffffffff
[<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300)
[<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
r7:c04605dc r6:c044585c r5:c045c88c r4:00c5387d
---[ end trace 1b75b31a2719ed1d ]---
------------[ cut here ]------------
WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:762 gic_init_bases+0x1
70/0x2ec()
Modules linked in:
Backtrace:
[<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c)
r6:000002fa r5:c042c670 r4:00000000 r3:c045f240
[<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/
0x6c)
[<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_nu
ll+0x24/0x2c)
r8:00000060 r7:00000020 r6:00000060 r5:00000040 r4:00000001
r3:00000009
[<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c042c670>] (gic_init_bases+0x1
70/0x2ec)
[<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd
8)
[<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24)
r4:ffffffff
[<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300)
[<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
r7:c04605dc r6:c044585c r5:c045c88c r4:00c5387d
---[ end trace 1b75b31a2719ed1e ]---
Way to go, people who DT-ized the GIC stuff, that's really great, three
warnings for one thing. Really excellent.
Giving up trying to test this. Someone else with more patience can do
it, and while they're at it they can fix the sodding kernel too.
^ permalink raw reply
* [PATCH 2/2] ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
From: Jason Cooper @ 2013-01-30 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359509201-11674-2-git-send-email-sebastian.hesselbarth@gmail.com>
Sebastian,
On Wed, Jan 30, 2013 at 02:26:41AM +0100, Sebastian Hesselbarth wrote:
> The ethernet controller used on kirkwood looses its MAC address
> register contents when the corresponding clock is gated. Until there
> is proper DT support for the mv643xx_eth driver, we add a workaround
> to always enable ge0/ge1 clocks on kirkwood. This workaround is also
> already used on non-DT kirkwood kernels.
Could you please make it clear that this is only relevant for scenarios
where mv643xx_eth is built as a module?
thx,
Jason.
>
> Reported-by: Simon Baatz <gmbnomis@gmail.com>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Simon Baatz <gmbnomis@gmail.com>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
> arch/arm/mach-kirkwood/board-dt.c | 24 +++++++++++++++---------
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
> index de4fd2b..e714ead 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -41,16 +41,12 @@ static void __init kirkwood_legacy_clk_init(void)
>
> struct device_node *np = of_find_compatible_node(
> NULL, NULL, "marvell,kirkwood-gating-clock");
> -
> struct of_phandle_args clkspec;
> + struct clk *clk;
>
> clkspec.np = np;
> clkspec.args_count = 1;
>
> - clkspec.args[0] = CGC_BIT_GE0;
> - orion_clkdev_add(NULL, "mv643xx_eth_port.0",
> - of_clk_get_from_provider(&clkspec));
> -
> clkspec.args[0] = CGC_BIT_PEX0;
> orion_clkdev_add("0", "pcie",
> of_clk_get_from_provider(&clkspec));
> @@ -63,14 +59,24 @@ static void __init kirkwood_legacy_clk_init(void)
> orion_clkdev_add("1", "pcie",
> of_clk_get_from_provider(&clkspec));
>
> - clkspec.args[0] = CGC_BIT_GE1;
> - orion_clkdev_add(NULL, "mv643xx_eth_port.1",
> - of_clk_get_from_provider(&clkspec));
> -
> clkspec.args[0] = CGC_BIT_SDIO;
> orion_clkdev_add(NULL, "mvsdio",
> of_clk_get_from_provider(&clkspec));
>
> + /*
> + * The ethernet interfaces forget the MAC address assigned by
> + * u-boot if the clocks are turned off. Until proper DT support
> + * is available we always enable them for now.
> + */
> + clkspec.args[0] = CGC_BIT_GE0;
> + clk = of_clk_get_from_provider(&clkspec);
> + orion_clkdev_add(NULL, "mv643xx_eth_port.0", clk);
> + clk_prepare_enable(clk);
> +
> + clkspec.args[0] = CGC_BIT_GE1;
> + clk = of_clk_get_from_provider(&clkspec);
> + orion_clkdev_add(NULL, "mv643xx_eth_port.1", clk);
> + clk_prepare_enable(clk);
> }
>
> static void __init kirkwood_of_clk_init(void)
> --
> 1.7.10.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
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: Nicolas Pitre @ 2013-01-30 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51089523.3080804@zytor.com>
On Tue, 29 Jan 2013, H. Peter Anvin wrote:
> On 01/29/2013 02:15 AM, Russell King - ARM Linux wrote:
> > On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:
> > > What's this "with enabled unaligned memory access" thing? You mean "if
> > > the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so,
> > > that's only x86, which isn't really in the target market for this
> > > patch, yes?
> > >
> > > It's a lot of code for a 50ms boot-time improvement. Does anyone have
> > > any opinions on whether or not the benefits are worth the cost?
> >
> > Well... when I saw this my immediate reaction was "oh no, yet another
> > decompressor for the kernel". We have five of these things already.
> > Do we really need a sixth?
> >
> > My feeling is that we should have:
> > - one decompressor which is the fastest
> > - one decompressor for the highest compression ratio
> > - one popular decompressor (eg conventional gzip)
> >
> > And if we have a replacement one for one of these, then it should do
> > exactly that: replace it. I realise that various architectures will
> > behave differently, so we should really be looking at numbers across
> > several arches.
> >
> > Otherwise, where do we stop adding new ones? After we have 6 of these
> > (which is after this one). After 12? After the 20th?
> >
>
> The only concern I have with that is if someone paints themselves into a
> corner and absolutely wants, say, LZO.
That would be hard to justify given that the kernel provides its own
decompressor code, making the compression format transparent to
bootloaders, etc. And no one should be poking into the compressed
zImage.
> Otherwise, per your list it pretty much sounds like we should have lz4, gzip,
> and xz.
I do agree with that.
Nicolas
^ permalink raw reply
* [PATCH 1/2] ARM: memory: use SZ_ constants for defining the virtual memory layout
From: Nicolas Pitre @ 2013-01-30 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359554912-26872-1-git-send-email-will.deacon@arm.com>
On Wed, 30 Jan 2013, Will Deacon wrote:
> Parts of the virtual memory layout (mainly the modules area) are
> described using open-coded immediate values.
>
> Use the SZ_ definitions from linux/sizes.h instead to make the code
> clearer.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/include/asm/memory.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 73cf03a..a0fd518 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -36,23 +36,23 @@
> * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area
> */
> #define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
> -#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(0x01000000))
> +#define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
> #define TASK_UNMAPPED_BASE (UL(CONFIG_PAGE_OFFSET) / 3)
>
> /*
> * The maximum size of a 26-bit user space task.
> */
> -#define TASK_SIZE_26 UL(0x04000000)
> +#define TASK_SIZE_26 UL(SZ_64M)
>
> /*
> * The module space lives between the addresses given by TASK_SIZE
> * and PAGE_OFFSET - it must be within 32MB of the kernel text.
> */
> #ifndef CONFIG_THUMB2_KERNEL
> -#define MODULES_VADDR (PAGE_OFFSET - 16*1024*1024)
> +#define MODULES_VADDR (PAGE_OFFSET - SZ_16M)
> #else
> /* smaller range for Thumb-2 symbols relocation (2^24)*/
> -#define MODULES_VADDR (PAGE_OFFSET - 8*1024*1024)
> +#define MODULES_VADDR (PAGE_OFFSET - SZ_8M)
> #endif
>
> #if TASK_SIZE > MODULES_VADDR
> --
> 1.8.0
>
>
> _______________________________________________
> 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] ARM: tlb: perform branch predictor maintenance for whole invalidation
From: Dave Martin @ 2013-01-30 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130155717.GG7484@mudshark.cambridge.arm.com>
On Wed, Jan 30, 2013 at 03:57:17PM +0000, Will Deacon wrote:
> On Wed, Jan 30, 2013 at 02:52:43PM +0000, Dave Martin wrote:
> > On Wed, Jan 30, 2013 at 02:12:05PM +0000, Will Deacon wrote:
> > > The ARM architecture requires explicit branch predictor maintenance
> > > when updating an instruction stream for a given virtual address. In
> > > reality, this isn't so much of a burden because the branch predictor
> > > is flushed during the cache maintenance required to make the new
> > > instructions visible to the I-side of the processor.
> > >
> > > One exception to this rule is when we flush the entire TLB for a CPU in
> > > response to something other than writing new instructions (for example,
> > > ASID rollover or switching to an identity mapping before disabling the
> > > MMU).
> > >
> > > This patch ensures that we flush the branch predictor as part of
> > > invalidating the entire TLB.
> >
> > What about v6 implementations? Is the branch predictor flush implicit?
>
> No, they're also handled by the patch. There's no -UIS versions of iciall
> and bpiall prior to v7, so the operations are broadcast via IPI, hence the
> use of bpiall in the else case below.
Ah, OK
---Dave
>
> Will
>
> > Cheers
> > ---Dave
> >
> > >
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > > arch/arm/include/asm/tlbflush.h | 12 ++++++++++--
> > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
> > > index 6e924d3..713ff32 100644
> > > --- a/arch/arm/include/asm/tlbflush.h
> > > +++ b/arch/arm/include/asm/tlbflush.h
> > > @@ -38,6 +38,7 @@
> > > #define TLB_V7_UIS_PAGE (1 << 19)
> > > #define TLB_V7_UIS_FULL (1 << 20)
> > > #define TLB_V7_UIS_ASID (1 << 21)
> > > +#define TLB_V7_UIS_BP (1 << 22)
> > >
> > > #define TLB_BARRIER (1 << 28)
> > > #define TLB_L2CLEAN_FR (1 << 29) /* Feroceon */
> > > @@ -166,9 +167,11 @@
> > > #endif
> > >
> > > #define v7wbi_tlb_flags_smp (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
> > > - TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID)
> > > + TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | \
> > > + TLB_V7_UIS_ASID | TLB_V7_UIS_BP)
> > > #define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
> > > - TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID)
> > > + TLB_V6_U_FULL | TLB_V6_U_PAGE | \
> > > + TLB_V6_U_ASID)
> > >
> > > #ifdef CONFIG_CPU_TLB_V7
> > >
> > > @@ -330,6 +333,11 @@ static inline void local_flush_tlb_all(void)
> > > tlb_op(TLB_V4_I_FULL | TLB_V6_I_FULL, "c8, c5, 0", zero);
> > > tlb_op(TLB_V7_UIS_FULL, "c8, c3, 0", zero);
> > >
> > > + if (tlb_flag(TLB_V7_UIS_BP))
> > > + asm("mcr p15, 0, %0, c7, c1, 6" : : "r" (zero));
> > > + else
> > > + asm("mcr p15, 0, %0, c7, c5, 6" : : "r" (zero));
> > > +
> > > if (tlb_flag(TLB_BARRIER)) {
> > > dsb();
> > > isb();
> > > --
> > > 1.8.0
> > >
> > >
> > > _______________________________________________
> > > 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 v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Bjorn Helgaas @ 2013-01-30 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130103501.1873d39c@skate>
On Wed, Jan 30, 2013 at 2:35 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Bjorn Helgaas,
>
> On Tue, 29 Jan 2013 15:27:43 -0700, Bjorn Helgaas wrote:
>
>> I'm not sure the existing emulation in these patches is sufficient.
>> For example, pci_sw_pci_bridge_write() updates bridge->membase when we
>> write to the window register, but I don't see anything that updates
>> the actual hardware decoder. That might be done in
>> mvebu_pcie_window_config_port() via armada_370_xp_alloc_pcie_window(),
>> but that looks like it's only done once.
>
> That's correct. I currently let the Linux PCI core enumerate the
> real PCIe devices, allocate the resources, and set the appropriate
> values in the emulated PCI-to-PCI bridge registers. Once this is all
> done, the Marvell PCIe driver looks at each PCI-to-PCI bridge, reads
> the membase and iobase registers, and creates address decoding windows
> so that the physical addresses assigned by the Linux PCI core actually
> resolve to the right PCIe interface. This is done once for all.
>
>> If the PCI core updates a root port window later, I don't see where the hardware
>> decoder will be updated.
>
> It will not be updated.
>
>> Maybe you're counting on the window assignments to be static? The PCI
>> core doesn't guarantee anything like that, though in the absence of
>> hotplug I don't know any reason why it would change things.
>
> Right. Is supporting hotplug a show-stopper to get this included? I
> think it could be added later, if it happens to be needed, no?
>
> I could of course do it, but the patch series is already quite large
> and complicated, so if we could merge a simple, but working, version
> first, and then improve on top of it when needed, it would be nice.
I'm most concerned about the stuff in drivers/pci. I hesitate to
merge drivers/pci/sw-pci-pci-bridge.c as-is because it's a model
that's not connected to hardware and only works in a completely static
situation, and the rest of the PCI core can't really deal with that.
But I don't think supporting hotplug should be a show-stopper at this
point, either. It sounds like we might be heading towards hooking
this up more directly to the Marvell hardware, which will make it more
arch-dependent. Something like that could either go in arch/arm, or
in some not-quite-so-generic spot under drivers/pci.
>> I also forgot about the bus number munging in mvebu_pcie_rd_conf().
>> The PCI core can update the bridge secondary/subordinate registers.
>> It looks like you don't support writing to them, and the read path
>> (pci_sw_pci_bridge_read()) looks like it doesn't do any translation
>> between the hardware and Linux bus numbers. I don't understand the
>> system well enough to know if this is an issue.
>
> Right. Could you explain a little bit for what reasons the PCI core
> could update the secondary/subordinate registers, and to what values it
> sets them?
The secondary/subordinate registers effectively define a bus number
aperture that tells the bridge which transactions to claim and forward
downstream. When enumerating devices, we may update the subordinate
bus number to widen the aperture so we can enumerate an arbitrary tree
behind the bridge. When we're finished, we'll probably narrow it by
updating the subordinate again, so the unused bus number space can be
used for other bridges. I don't know the exact details of the
algorithm, and they're likely to change anyway, but pci_scan_bridge()
is where most of it happens.
It looks like your current system doesn't support trees below the
bridges, but hopefully we can make it so the generic enumeration
algorithms still work.
> For now, I statically assign the secondary bus register value to be
> X+1, where X is the number of the PCIe interface, since X=0 is reserved
> for the root bus (which has the host bridge and the PCI-to-PCI
> bridges).
That makes sense but limits you to a single bus (and really, a single
device since this is PCIe) below the bridge.
> Also, could you detail what kind of translation I should be doing when
> reading the hardware and Linux bus numbers?
I'm hoping that the register Jason mentioned is enough to avoid the
need for translation. If it's not, we can explore this a bit more.
Bjorn
^ permalink raw reply
* [PATCH 2/2] ARM: memory: define TASK_UNMAPPED_BASE in terms of TASK_SIZE
From: Nicolas Pitre @ 2013-01-30 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359554912-26872-2-git-send-email-will.deacon@arm.com>
On Wed, 30 Jan 2013, Will Deacon wrote:
> TASK_UNMAPPED_BASE is defined directly in terms of PAGE_OFFSET, which is
> confusing given that the modules area sits between here and TASK_SIZE
> and is not available for user allocations.
>
> This patch defines TASK_UNMAPPED_BASE in terms of TASK_SIZE instead and
> fixes a bug introduced by 394ef6403abc ("mm: use vm_unmapped_area() on
> arm architecture") whereby TASK_UNMAPPED_BASE is no longer page-aligned
> for bottom-up mmap, causing get_unmapped_area to choke on misaligned
> addresses.
>
> Reported-by: Christoffer Dall <cdall@cs.columbia.edu>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/include/asm/memory.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index a0fd518..255a01b 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -37,7 +37,7 @@
> */
> #define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
> #define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
> -#define TASK_UNMAPPED_BASE (UL(CONFIG_PAGE_OFFSET) / 3)
> +#define TASK_UNMAPPED_BASE ((TASK_SIZE / 3) & ~UL(SZ_16M - 1))
Please round this up not down. In most cases, TASK_SIZE is 0xbf000000
which is not nicely divisible by 3, unlike PAGE_OFFSET was. By rounding
up you get a nice 0x40000000 as before.
Nicolas
^ permalink raw reply
* [PATCH v2 0/2] Add CPSW VLAN Support
From: Mugunthan V N @ 2013-01-30 19:07 UTC (permalink / raw)
To: linux-arm-kernel
CPSW is capable of filtering VLAN packets in hardware. This patch series
implements VLAN support to CPSW driver.
This patch series is tested on net-next with AM335x EVM with ping test.
Changes from initial version
* added vlan support to existing add/delete unicast/multicast apis
* Made driver as default VLAN enabled so that drivers need to be recompiled
when stack is compiled with VLAN
Mugunthan V N (2):
drivers: net: cpsw: Add helper functions for VLAN ALE implementation
drivers: net:ethernet: cpsw: add support for VLAN
Documentation/devicetree/bindings/net/cpsw.txt | 2 +
drivers/net/ethernet/ti/cpsw.c | 100 ++++++++++++++++++++--
drivers/net/ethernet/ti/cpsw_ale.c | 106 +++++++++++++++++++++---
drivers/net/ethernet/ti/cpsw_ale.h | 20 +++--
include/linux/platform_data/cpsw.h | 1 +
5 files changed, 205 insertions(+), 24 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/2] drivers: net: cpsw: Add helper functions for VLAN ALE implementation
From: Mugunthan V N @ 2013-01-30 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359572855-12344-1-git-send-email-mugunthanvnm@ti.com>
Add helper functions for VLAN ALE implementations for Add, Delete
Dump VLAN related ALE entries
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 8 +--
drivers/net/ethernet/ti/cpsw_ale.c | 106 ++++++++++++++++++++++++++++++++----
drivers/net/ethernet/ti/cpsw_ale.h | 20 +++++--
3 files changed, 112 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index b35e6a7..a40750e 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -345,7 +345,7 @@ static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
/* program multicast address list into ALE register */
netdev_for_each_mc_addr(ha, ndev) {
cpsw_ale_add_mcast(priv->ale, (u8 *)ha->addr,
- ALE_ALL_PORTS << priv->host_port, 0, 0);
+ ALE_ALL_PORTS << priv->host_port, 0, 0, 0);
}
}
}
@@ -592,7 +592,7 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
slave_port = cpsw_get_slave_port(priv, slave->slave_num);
cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
- 1 << slave_port, 0, ALE_MCAST_FWD_2);
+ 1 << slave_port, 0, 0, ALE_MCAST_FWD_2);
slave->phy = phy_connect(priv->ndev, slave->data->phy_id,
&cpsw_adjust_link, slave->data->phy_if);
@@ -624,9 +624,9 @@ static void cpsw_init_host_port(struct cpsw_priv *priv)
cpsw_ale_control_set(priv->ale, priv->host_port,
ALE_PORT_STATE, ALE_PORT_STATE_FORWARD);
- cpsw_ale_add_ucast(priv->ale, priv->mac_addr, priv->host_port, 0);
+ cpsw_ale_add_ucast(priv->ale, priv->mac_addr, priv->host_port, 0, 0);
cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
- 1 << priv->host_port, 0, ALE_MCAST_FWD_2);
+ 1 << priv->host_port, 0, 0, ALE_MCAST_FWD_2);
}
static int cpsw_ndo_open(struct net_device *ndev)
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
index 0e9ccc2..18b88ce 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -148,7 +148,7 @@ static int cpsw_ale_write(struct cpsw_ale *ale, int idx, u32 *ale_entry)
return idx;
}
-static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr)
+int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS];
int type, idx;
@@ -160,6 +160,8 @@ static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr)
type = cpsw_ale_get_entry_type(ale_entry);
if (type != ALE_TYPE_ADDR && type != ALE_TYPE_VLAN_ADDR)
continue;
+ if (cpsw_ale_get_vlan_id(ale_entry) != vid)
+ continue;
cpsw_ale_get_addr(ale_entry, entry_addr);
if (memcmp(entry_addr, addr, 6) == 0)
return idx;
@@ -167,6 +169,22 @@ static int cpsw_ale_match_addr(struct cpsw_ale *ale, u8 *addr)
return -ENOENT;
}
+int cpsw_ale_match_vlan(struct cpsw_ale *ale, u16 vid)
+{
+ u32 ale_entry[ALE_ENTRY_WORDS];
+ int type, idx;
+
+ for (idx = 0; idx < ale->params.ale_entries; idx++) {
+ cpsw_ale_read(ale, idx, ale_entry);
+ type = cpsw_ale_get_entry_type(ale_entry);
+ if (type != ALE_TYPE_VLAN)
+ continue;
+ if (cpsw_ale_get_vlan_id(ale_entry) == vid)
+ return idx;
+ }
+ return -ENOENT;
+}
+
static int cpsw_ale_match_free(struct cpsw_ale *ale)
{
u32 ale_entry[ALE_ENTRY_WORDS];
@@ -274,19 +292,26 @@ int cpsw_ale_flush(struct cpsw_ale *ale, int port_mask)
return 0;
}
-int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port, int flags)
+int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port,
+ int flags, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx;
- cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ if (flags & ALE_VLAN) {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN_ADDR);
+ cpsw_ale_set_vlan_id(ale_entry, vid);
+ } else {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ }
+
cpsw_ale_set_addr(ale_entry, addr);
cpsw_ale_set_ucast_type(ale_entry, ALE_UCAST_PERSISTANT);
cpsw_ale_set_secure(ale_entry, (flags & ALE_SECURE) ? 1 : 0);
cpsw_ale_set_blocked(ale_entry, (flags & ALE_BLOCKED) ? 1 : 0);
cpsw_ale_set_port_num(ale_entry, port);
- idx = cpsw_ale_match_addr(ale, addr);
+ idx = cpsw_ale_match_addr(ale, addr, (flags & ALE_VLAN) ? vid : 0);
if (idx < 0)
idx = cpsw_ale_match_free(ale);
if (idx < 0)
@@ -298,12 +323,13 @@ int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port, int flags)
return 0;
}
-int cpsw_ale_del_ucast(struct cpsw_ale *ale, u8 *addr, int port)
+int cpsw_ale_del_ucast(struct cpsw_ale *ale, u8 *addr, int port,
+ int flags, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx;
- idx = cpsw_ale_match_addr(ale, addr);
+ idx = cpsw_ale_match_addr(ale, addr, (flags & ALE_VLAN) ? vid : 0);
if (idx < 0)
return -ENOENT;
@@ -313,18 +339,24 @@ int cpsw_ale_del_ucast(struct cpsw_ale *ale, u8 *addr, int port)
}
int cpsw_ale_add_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
- int super, int mcast_state)
+ int flags, u16 vid, int mcast_state)
{
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx, mask;
- idx = cpsw_ale_match_addr(ale, addr);
+ idx = cpsw_ale_match_addr(ale, addr, (flags & ALE_VLAN) ? vid : 0);
if (idx >= 0)
cpsw_ale_read(ale, idx, ale_entry);
- cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ if (flags & ALE_VLAN) {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN_ADDR);
+ cpsw_ale_set_vlan_id(ale_entry, vid);
+ } else {
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_ADDR);
+ }
+
cpsw_ale_set_addr(ale_entry, addr);
- cpsw_ale_set_super(ale_entry, super);
+ cpsw_ale_set_super(ale_entry, (flags & ALE_BLOCKED) ? 1 : 0);
cpsw_ale_set_mcast_state(ale_entry, mcast_state);
mask = cpsw_ale_get_port_mask(ale_entry);
@@ -342,12 +374,13 @@ int cpsw_ale_add_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
return 0;
}
-int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask)
+int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
+ int flags, u16 vid)
{
u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
int idx;
- idx = cpsw_ale_match_addr(ale, addr);
+ idx = cpsw_ale_match_addr(ale, addr, (flags & ALE_VLAN) ? vid : 0);
if (idx < 0)
return -EINVAL;
@@ -362,6 +395,55 @@ int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask)
return 0;
}
+int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
+ int reg_mcast, int unreg_mcast)
+{
+ u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
+ int idx;
+
+ idx = cpsw_ale_match_vlan(ale, vid);
+ if (idx >= 0)
+ cpsw_ale_read(ale, idx, ale_entry);
+
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_VLAN);
+ cpsw_ale_set_vlan_id(ale_entry, vid);
+
+ cpsw_ale_set_vlan_untag_force(ale_entry, untag);
+ cpsw_ale_set_vlan_reg_mcast(ale_entry, reg_mcast);
+ cpsw_ale_set_vlan_unreg_mcast(ale_entry, unreg_mcast);
+ cpsw_ale_set_vlan_member_list(ale_entry, port);
+
+ if (idx < 0)
+ idx = cpsw_ale_match_free(ale);
+ if (idx < 0)
+ idx = cpsw_ale_find_ageable(ale);
+ if (idx < 0)
+ return -ENOMEM;
+
+ cpsw_ale_write(ale, idx, ale_entry);
+ return 0;
+}
+
+int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port_mask)
+{
+ u32 ale_entry[ALE_ENTRY_WORDS] = {0, 0, 0};
+ int idx;
+
+ idx = cpsw_ale_match_vlan(ale, vid);
+ if (idx < 0)
+ return -ENOENT;
+
+ cpsw_ale_read(ale, idx, ale_entry);
+
+ if (port_mask)
+ cpsw_ale_set_vlan_member_list(ale_entry, port_mask);
+ else
+ cpsw_ale_set_entry_type(ale_entry, ALE_TYPE_FREE);
+
+ cpsw_ale_write(ale, idx, ale_entry);
+ return 0;
+}
+
struct ale_control_info {
const char *name;
int offset, port_offset;
diff --git a/drivers/net/ethernet/ti/cpsw_ale.h b/drivers/net/ethernet/ti/cpsw_ale.h
index 2bd09cb..a002417 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.h
+++ b/drivers/net/ethernet/ti/cpsw_ale.h
@@ -64,8 +64,10 @@ enum cpsw_ale_port_state {
};
/* ALE unicast entry flags - passed into cpsw_ale_add_ucast() */
-#define ALE_SECURE 1
-#define ALE_BLOCKED 2
+#define ALE_SECURE BIT(0)
+#define ALE_BLOCKED BIT(1)
+#define ALE_SUPER BIT(2)
+#define ALE_VLAN BIT(3)
#define ALE_MCAST_FWD 0
#define ALE_MCAST_BLOCK_LEARN_FWD 1
@@ -81,11 +83,17 @@ void cpsw_ale_stop(struct cpsw_ale *ale);
int cpsw_ale_set_ageout(struct cpsw_ale *ale, int ageout);
int cpsw_ale_flush(struct cpsw_ale *ale, int port_mask);
int cpsw_ale_flush_multicast(struct cpsw_ale *ale, int port_mask);
-int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port, int flags);
-int cpsw_ale_del_ucast(struct cpsw_ale *ale, u8 *addr, int port);
+int cpsw_ale_add_ucast(struct cpsw_ale *ale, u8 *addr, int port,
+ int flags, u16 vid);
+int cpsw_ale_del_ucast(struct cpsw_ale *ale, u8 *addr, int port,
+ int flags, u16 vid);
int cpsw_ale_add_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
- int super, int mcast_state);
-int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask);
+ int flags, u16 vid, int mcast_state);
+int cpsw_ale_del_mcast(struct cpsw_ale *ale, u8 *addr, int port_mask,
+ int flags, u16 vid);
+int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port, int untag,
+ int reg_mcast, int unreg_mcast);
+int cpsw_ale_del_vlan(struct cpsw_ale *ale, u16 vid, int port);
int cpsw_ale_control_get(struct cpsw_ale *ale, int port, int control);
int cpsw_ale_control_set(struct cpsw_ale *ale, int port,
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/2] drivers: net:ethernet: cpsw: add support for VLAN
From: Mugunthan V N @ 2013-01-30 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359572855-12344-1-git-send-email-mugunthanvnm@ti.com>
adding support for VLAN interface for cpsw.
CPSW VLAN Capability
* Can filter VLAN packets in Hardware
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Documentation/devicetree/bindings/net/cpsw.txt | 2 +
drivers/net/ethernet/ti/cpsw.c | 92 +++++++++++++++++++++++-
include/linux/platform_data/cpsw.h | 1 +
3 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
index 6ddd028..99696bf 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -24,6 +24,8 @@ Required properties:
Optional properties:
- ti,hwmods : Must be "cpgmac0"
- no_bd_ram : Must be 0 or 1
+- default_vlan : Specifies Default VLAN for non tagged packets
+ ALE processing
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index a40750e..6c66f01 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -32,6 +32,7 @@
#include <linux/of.h>
#include <linux/of_net.h>
#include <linux/of_device.h>
+#include <linux/if_vlan.h>
#include <linux/platform_data/cpsw.h>
@@ -118,6 +119,9 @@ do { \
#define TX_PRIORITY_MAPPING 0x33221100
#define CPDMA_TX_PRIORITY_MAP 0x76543210
+#define CPSW_VLAN_AWARE BIT(1)
+#define CPSW_ALE_VLAN_AWARE 1
+
#define cpsw_enable_irq(priv) \
do { \
u32 i; \
@@ -607,14 +611,41 @@ static void cpsw_slave_open(struct cpsw_slave *slave, struct cpsw_priv *priv)
}
}
+static inline void cpsw_add_default_vlan(struct cpsw_priv *priv)
+{
+ writel(priv->data.default_vlan, &priv->host_port_regs->port_vlan);
+ if (priv->version == CPSW_VERSION_1) {
+ slave_write(&priv->slaves[0], priv->data.default_vlan,
+ CPSW1_PORT_VLAN);
+ slave_write(&priv->slaves[1], priv->data.default_vlan,
+ CPSW1_PORT_VLAN);
+ } else {
+ slave_write(&priv->slaves[0], priv->data.default_vlan,
+ CPSW2_PORT_VLAN);
+ slave_write(&priv->slaves[1], priv->data.default_vlan,
+ CPSW2_PORT_VLAN);
+ }
+ cpsw_ale_add_vlan(priv->ale, priv->data.default_vlan,
+ ALE_ALL_PORTS << priv->host_port,
+ ALE_ALL_PORTS << priv->host_port,
+ ALE_ALL_PORTS << priv->host_port,
+ (BIT(1) | BIT(2)) << priv->host_port);
+}
+
static void cpsw_init_host_port(struct cpsw_priv *priv)
{
+ u32 control_reg;
+
/* soft reset the controller and initialize ale */
soft_reset("cpsw", &priv->regs->soft_reset);
cpsw_ale_start(priv->ale);
/* switch to vlan unaware mode */
- cpsw_ale_control_set(priv->ale, 0, ALE_VLAN_AWARE, 0);
+ cpsw_ale_control_set(priv->ale, priv->host_port, ALE_VLAN_AWARE,
+ CPSW_ALE_VLAN_AWARE);
+ control_reg = readl(&priv->regs->control);
+ control_reg |= CPSW_VLAN_AWARE;
+ writel(control_reg, &priv->regs->control);
/* setup host port priority mapping */
__raw_writel(CPDMA_TX_PRIORITY_MAP,
@@ -650,6 +681,9 @@ static int cpsw_ndo_open(struct net_device *ndev)
cpsw_init_host_port(priv);
for_each_slave(priv, cpsw_slave_open, priv);
+ /* Add default VLAN */
+ cpsw_add_default_vlan(priv);
+
/* setup tx dma to fixed prio and zero offset */
cpdma_control_set(priv->dma, CPDMA_TX_PRIO_FIXED, 1);
cpdma_control_set(priv->dma, CPDMA_RX_BUFFER_OFFSET, 0);
@@ -933,6 +967,55 @@ static void cpsw_ndo_poll_controller(struct net_device *ndev)
}
#endif
+static inline void cpsw_add_vlan_ale_entry(struct cpsw_priv *priv,
+ unsigned short vid)
+{
+ cpsw_ale_add_vlan(priv->ale, vid, ALE_ALL_PORTS << priv->host_port,
+ 0, ALE_ALL_PORTS << priv->host_port,
+ (BIT(1) | BIT(2)) << priv->host_port);
+ cpsw_ale_add_ucast(priv->ale, priv->mac_addr,
+ priv->host_port, ALE_VLAN, vid);
+ cpsw_ale_add_mcast(priv->ale, priv->ndev->broadcast,
+ ALE_ALL_PORTS << priv->host_port, ALE_VLAN, vid, 0);
+}
+
+static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
+ unsigned short vid)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+
+ if (vid == priv->data.default_vlan)
+ return 0;
+
+ spin_lock(&priv->lock);
+
+ dev_info(priv->dev, "Adding vlanid %d to vlan filter\n", vid);
+ cpsw_add_vlan_ale_entry(priv, vid);
+
+ spin_unlock(&priv->lock);
+ return 0;
+}
+
+static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
+ unsigned short vid)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+
+ if (vid == priv->data.default_vlan)
+ return 0;
+
+ spin_lock(&priv->lock);
+
+ dev_info(priv->dev, "removing vlanid %d from vlan filter\n", vid);
+ cpsw_ale_del_vlan(priv->ale, vid, 0);
+ cpsw_ale_del_ucast(priv->ale, priv->mac_addr,
+ priv->host_port, ALE_VLAN, vid);
+ cpsw_ale_del_mcast(priv->ale, priv->ndev->broadcast, 0, ALE_VLAN, vid);
+
+ spin_unlock(&priv->lock);
+ return 0;
+}
+
static const struct net_device_ops cpsw_netdev_ops = {
.ndo_open = cpsw_ndo_open,
.ndo_stop = cpsw_ndo_stop,
@@ -947,6 +1030,8 @@ static const struct net_device_ops cpsw_netdev_ops = {
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = cpsw_ndo_poll_controller,
#endif
+ .ndo_vlan_rx_add_vid = cpsw_ndo_vlan_rx_add_vid,
+ .ndo_vlan_rx_kill_vid = cpsw_ndo_vlan_rx_kill_vid,
};
static void cpsw_get_drvinfo(struct net_device *ndev,
@@ -1103,6 +1188,9 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data->mac_control = prop;
+ if (!of_property_read_u32(node, "default_vlan", &prop))
+ data->default_vlan = prop;
+
/*
* Populate all the child nodes here...
*/
@@ -1356,7 +1444,7 @@ static int cpsw_probe(struct platform_device *pdev)
k++;
}
- ndev->flags |= IFF_ALLMULTI; /* see cpsw_ndo_change_rx_flags() */
+ ndev->features |= NETIF_F_HW_VLAN_FILTER;
ndev->netdev_ops = &cpsw_netdev_ops;
SET_ETHTOOL_OPS(ndev, &cpsw_ethtool_ops);
diff --git a/include/linux/platform_data/cpsw.h b/include/linux/platform_data/cpsw.h
index 24368a2..e962cfd 100644
--- a/include/linux/platform_data/cpsw.h
+++ b/include/linux/platform_data/cpsw.h
@@ -35,6 +35,7 @@ struct cpsw_platform_data {
u32 bd_ram_size; /*buffer descriptor ram size */
u32 rx_descs; /* Number of Rx Descriptios */
u32 mac_control; /* Mac control register */
+ u16 default_vlan; /* Def VLAN for ALE lookup in VLAN aware mode*/
};
#endif /* __CPSW_H__ */
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name
From: Nicolas Pitre @ 2013-01-30 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359558091-29251-2-git-send-email-ruslan.bilovol@ti.com>
On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
> Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> the CPU carrying out the read from the file.
> Userspace using this information may decide what module
> to load or how to configure some specific (and processor-depended)
> settings or so.
> However, since really different SoCs can share same ARM core,
> this information currently is not so useful.
> For example, TI OMAP4460 and OMAP4470 SoCs show the same
> information in the /proc/cpuinfo whereas they are different.
> Since in most cases ARM CPU is a part of some system on a chip (SoC),
> the "cpuinfo" file looks like exactly that place, where this
> information have to be displayed.
>
> So added new line "SoC name" in the "cpuinfo" output for system
> on a chip name. It is placed between CPU information and machine
> information, so the file structure looks gracefully (CPU-SoC-Hardware)
>
> Example:
>
> / # cat proc/cpuinfo
> [...]
> CPU variant : 0x2
> CPU part : 0xc09
> CPU revision : 10
>
> SoC name : OMAP4470
>
> Hardware : OMAP4 Blaze Tablet
Please remove that extra blank line between "SoC name" and "Hardware".
The blank line after "CPU revision" is fine.
Also, please rename this to "System name". Not all systems are "on
chip". By using "System name" this is more universally useful.
Nicolas
^ permalink raw reply
* [PATCH 2/2] ARM: memory: define TASK_UNMAPPED_BASE in terms of TASK_SIZE
From: Will Deacon @ 2013-01-30 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301301352180.6300@xanadu.home>
On Wed, Jan 30, 2013 at 06:57:24PM +0000, Nicolas Pitre wrote:
> On Wed, 30 Jan 2013, Will Deacon wrote:
>
> > TASK_UNMAPPED_BASE is defined directly in terms of PAGE_OFFSET, which is
> > confusing given that the modules area sits between here and TASK_SIZE
> > and is not available for user allocations.
> >
> > This patch defines TASK_UNMAPPED_BASE in terms of TASK_SIZE instead and
> > fixes a bug introduced by 394ef6403abc ("mm: use vm_unmapped_area() on
> > arm architecture") whereby TASK_UNMAPPED_BASE is no longer page-aligned
> > for bottom-up mmap, causing get_unmapped_area to choke on misaligned
> > addresses.
> >
> > Reported-by: Christoffer Dall <cdall@cs.columbia.edu>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm/include/asm/memory.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> > index a0fd518..255a01b 100644
> > --- a/arch/arm/include/asm/memory.h
> > +++ b/arch/arm/include/asm/memory.h
> > @@ -37,7 +37,7 @@
> > */
> > #define PAGE_OFFSET UL(CONFIG_PAGE_OFFSET)
> > #define TASK_SIZE (UL(CONFIG_PAGE_OFFSET) - UL(SZ_16M))
> > -#define TASK_UNMAPPED_BASE (UL(CONFIG_PAGE_OFFSET) / 3)
> > +#define TASK_UNMAPPED_BASE ((TASK_SIZE / 3) & ~UL(SZ_16M - 1))
>
> Please round this up not down. In most cases, TASK_SIZE is 0xbf000000
> which is not nicely divisible by 3, unlike PAGE_OFFSET was. By rounding
> up you get a nice 0x40000000 as before.
Sure, I think ALIGN does that for us, so I can use that instead.
Cheers,
Will
^ permalink raw reply
* [PATCH] arm: mvebu: support for the new Armada XP evaluation board(DB-MV784MP-GP)
From: Florian Fainelli @ 2013-01-30 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359566774-27669-2-git-send-email-gregory.clement@free-electrons.com>
On Wednesday 30 January 2013 18:26:14 Gregory CLEMENT wrote:
> This is the new Armada XP evaluation board from Marvell. It comes with
> a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
> Gigabit links.
>
> Support for USB (Host and device), SDIO, PCIe will be added as drivers
> when they become available for Armada XP in mainline.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Florian Fainelli <florian@openwrt.org>
The PHY mapping you have is the right one, besides the minor naming in model
and header comment, this is good, thanks a lot!
--
Florian
^ permalink raw reply
* [PATCH 4/6] usb: chipidea: add PTW and PTS handling
From: Sascha Hauer @ 2013-01-30 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5109505E.7040204@parrot.com>
On Wed, Jan 30, 2013 at 05:54:54PM +0100, Matthieu CASTET wrote:
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 57cae1f..dcb650f 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -67,6 +67,8 @@
> > #include <linux/usb/gadget.h>
> > #include <linux/usb/otg.h>
> > #include <linux/usb/chipidea.h>
> > +#include <linux/usb/of.h>
> > +#include <linux/phy.h>
> >
> > #include "ci.h"
> > #include "udc.h"
> > @@ -211,6 +213,42 @@ static int hw_device_init(struct ci13xxx *ci, void __iomem *base)
> > return 0;
> > }
> >
> > +static void hw_phymode_configure(struct ci13xxx *ci)
> > +{
> > + u32 portsc;
> > +
> > + /*
> > + * The lpm version has the corresponding bits in the devlc register.
> > + * Currently not implemented.
> > + */
> > + if (ci->hw_bank.lpm)
> > + return;
> Why you don't implement it ?
>
> If you don't implement it, I believe you should add a warning in order to catch
> it when used with lpm devices.
I'm against adding a warning because current users seem to go well
without this setting. Adding a warning would lead to more confusion than
it would help.
I could try and implement it, though I'm unsure about the register
layout.
What I know from an earlier post from you is this:
#define LPM_PTS(d) (((d)>>29)&7)
#define LPM_STS BIT(28) /* serial transceiver select */
#define LPM_PTW BIT(27) /* parallel transceiver width */
Do you also know how LPM_PTS is decoded?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Matt Sealey @ 2013-01-30 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129143302.GF2046@arwen.pp.htv.fi>
On Tue, Jan 29, 2013 at 8:33 AM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Tue, Jan 29, 2013 at 07:40:23PM +0530, kishon wrote:
>> On Tuesday 29 January 2013 07:23 PM, Wolfram Sang wrote:
>> >>>+ err = of_property_read_string(np, "phy_type", &phy_type);
>> >>>+ if (err < 0)
>> >>>+ return USBPHY_INTERFACE_MODE_NA;
>> >>
>> >>Why don't we use a u32 property type for the *phy-type*? IMHO we
>> >>should use string property only when the property should be
>> >>absolutely unambiguous (e.g., compatible property should be string).
>> >
>> >If we would use u32-numbers in the compatible entry, this would also be
>> >unambiguous, no? 0xd00dfeed would be the at24-driver. Pretty specific.
>>
>> hehe... But we don't have a corresponding *enum* representing the
>> drivers :-)
>> >
>> >I don't mind having readable devicetrees. And we have it for ethernet
>> >phys already with strings, so it would be consistent.
>>
>> Ok. Fine with it then :-)
>
> I prefer u32 here, because we have the matching enum. Otherwise we end
> up with:
>
> of_property_read_string(...,&type);
>
> if (!strcmp(type, "ulpi"))
> foo();
> else if (!strcmp(type, "utmi"))
> bar();
> else if (!strcmp(type, "pipe3"))
> baz();
> else
> BUG();
>
> and I don't like that, it's ugly and error prone. Also looks awful when
> someone needs to change that, the diff looks messy. A u32 followed by a
> switch statement looks nicer.
I wholeheartedly and vehemently disagree.
Device trees don't exist to make Linux look prettier, *OR* clean up
your source code of string comparisons when you think comparing an
integer looks or feels cleaner. They exist to provide a hardware
description. phy-type 0x3 does not describe anything except that you
have to go look up what 0x3 means, and means device trees cannot be
internally consistent within themselves or publically existing
documentation (it is certain that there is no USB PHY specification
that defines 0x3 as anything, which means the value is entirely Linux
specific).
Matching an enum or magic number encoded into a u32 in some external
source code to define a type that wasn't just an index is not
something that anyone has ever reasonably done in any traditional
IEEE1275 device tree or OpenFirmware-committee binding, and we
shouldn't just be subverting the existing standard to make Linux code
"look prettier".
Please consider other operating systems, which would need to copy the
definition of the enum which may not be possible when thinking of
Linux vs. FreeBSD or so, and in general the readability of the device
tree - phy-type 0x3 is going to require a comment in the device tree
source to remind people what that means, or a cross-reference to a
binding which is more work than most developers want to do to make
sure they specified the correct PHY type. A string is completely and
unavoidably correct - a typo in the phy-type means a match against
valid bindings is impossible and an instant bug. A mistaken u32 value
means the wrong phy-type is defined which has increased potential to
provide misconfigured phy with the wrong type and less warning than a
string literal not being absolutely identical. I think that means more
buggy device trees will get past where it doesn't actually work
properly, and more time will be spent working out WHY it doesn't
actually work properly.
It is much better to be totally unambiguous in the device tree as per
the type and a string is the best way. If you really want effective,
less error-prone code, define all the existing or useful types as
preprocessor defines (#define PHY_TYPE_UTMI_WIDE "utmiw") and use
those to match the binding. I wouldn't hand-code a property string
inline even if you offered me a million dollars to do so. Matching the
dr_mode property is already done in a drivers/of or of_phy.h include
so just move the potential match code to there and return the correct
enum (which is arguably Linux-specific) from the string and give a big
fat error from the match function if none of the valid bindings
matches up.
BTW I disagree with the use of underscores in device trees as well, I
wouldn't use an underscore for a new property. But in the case of
dr_mode it is well used already especially for Freescale controllers
on PPC where there are a significant handful of DTS (or real OF) that
implement it. It might not be a bad idea, though, to update the
binding deprecating dr_mode in favor of something that is much less
ambiguous and descriptive itself - "dr-mode" is an acceptable fix but
a "role" property or "dual-role-mode" is much more descriptive. Moving
the matching to some common code since more than one controller uses
it and then adding a new, better property name with dr_mode as an
acceptable but unrecommended fallback means this can be left to
history.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Matt Sealey @ 2013-01-30 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKGA1bmQCSHxy=hLh9XYkt9vSzdO=vO9XGhJX1cZFBSL=jZHvw@mail.gmail.com>
s/is already done/should already be done.
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
On Wed, Jan 30, 2013 at 1:33 PM, Matt Sealey <matt@genesi-usa.com> wrote:
> On Tue, Jan 29, 2013 at 8:33 AM, Felipe Balbi <balbi@ti.com> wrote:
>> Hi,
>>
>> On Tue, Jan 29, 2013 at 07:40:23PM +0530, kishon wrote:
>>> On Tuesday 29 January 2013 07:23 PM, Wolfram Sang wrote:
>>> >>>+ err = of_property_read_string(np, "phy_type", &phy_type);
>>> >>>+ if (err < 0)
>>> >>>+ return USBPHY_INTERFACE_MODE_NA;
>>> >>
>>> >>Why don't we use a u32 property type for the *phy-type*? IMHO we
>>> >>should use string property only when the property should be
>>> >>absolutely unambiguous (e.g., compatible property should be string).
>>> >
>>> >If we would use u32-numbers in the compatible entry, this would also be
>>> >unambiguous, no? 0xd00dfeed would be the at24-driver. Pretty specific.
>>>
>>> hehe... But we don't have a corresponding *enum* representing the
>>> drivers :-)
>>> >
>>> >I don't mind having readable devicetrees. And we have it for ethernet
>>> >phys already with strings, so it would be consistent.
>>>
>>> Ok. Fine with it then :-)
>>
>> I prefer u32 here, because we have the matching enum. Otherwise we end
>> up with:
>>
>> of_property_read_string(...,&type);
>>
>> if (!strcmp(type, "ulpi"))
>> foo();
>> else if (!strcmp(type, "utmi"))
>> bar();
>> else if (!strcmp(type, "pipe3"))
>> baz();
>> else
>> BUG();
>>
>> and I don't like that, it's ugly and error prone. Also looks awful when
>> someone needs to change that, the diff looks messy. A u32 followed by a
>> switch statement looks nicer.
>
> I wholeheartedly and vehemently disagree.
>
> Device trees don't exist to make Linux look prettier, *OR* clean up
> your source code of string comparisons when you think comparing an
> integer looks or feels cleaner. They exist to provide a hardware
> description. phy-type 0x3 does not describe anything except that you
> have to go look up what 0x3 means, and means device trees cannot be
> internally consistent within themselves or publically existing
> documentation (it is certain that there is no USB PHY specification
> that defines 0x3 as anything, which means the value is entirely Linux
> specific).
>
> Matching an enum or magic number encoded into a u32 in some external
> source code to define a type that wasn't just an index is not
> something that anyone has ever reasonably done in any traditional
> IEEE1275 device tree or OpenFirmware-committee binding, and we
> shouldn't just be subverting the existing standard to make Linux code
> "look prettier".
>
> Please consider other operating systems, which would need to copy the
> definition of the enum which may not be possible when thinking of
> Linux vs. FreeBSD or so, and in general the readability of the device
> tree - phy-type 0x3 is going to require a comment in the device tree
> source to remind people what that means, or a cross-reference to a
> binding which is more work than most developers want to do to make
> sure they specified the correct PHY type. A string is completely and
> unavoidably correct - a typo in the phy-type means a match against
> valid bindings is impossible and an instant bug. A mistaken u32 value
> means the wrong phy-type is defined which has increased potential to
> provide misconfigured phy with the wrong type and less warning than a
> string literal not being absolutely identical. I think that means more
> buggy device trees will get past where it doesn't actually work
> properly, and more time will be spent working out WHY it doesn't
> actually work properly.
>
> It is much better to be totally unambiguous in the device tree as per
> the type and a string is the best way. If you really want effective,
> less error-prone code, define all the existing or useful types as
> preprocessor defines (#define PHY_TYPE_UTMI_WIDE "utmiw") and use
> those to match the binding. I wouldn't hand-code a property string
> inline even if you offered me a million dollars to do so. Matching the
> dr_mode property is already done in a drivers/of or of_phy.h include
> so just move the potential match code to there and return the correct
> enum (which is arguably Linux-specific) from the string and give a big
> fat error from the match function if none of the valid bindings
> matches up.
>
> BTW I disagree with the use of underscores in device trees as well, I
> wouldn't use an underscore for a new property. But in the case of
> dr_mode it is well used already especially for Freescale controllers
> on PPC where there are a significant handful of DTS (or real OF) that
> implement it. It might not be a bad idea, though, to update the
> binding deprecating dr_mode in favor of something that is much less
> ambiguous and descriptive itself - "dr-mode" is an acceptable fix but
> a "role" property or "dual-role-mode" is much more descriptive. Moving
> the matching to some common code since more than one controller uses
> it and then adding a new, better property name with dr_mode as an
> acceptable but unrecommended fallback means this can be left to
> history.
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply
* [PATCH 1/4] pinctrl/abx500: use the BIT() macro where appropriate
From: Linus Walleij @ 2013-01-30 19:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Lee Jones <lee.jones@linaro.org>
The BIT() macro provides a simple and easy to read way of
obtaining bit offsets into things like masks and hardware
registers. In this patch we're simply replacing all
instances of '1 << x' with 'bit(x)'.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-abx500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-abx500.c b/drivers/pinctrl/pinctrl-abx500.c
index 7046aef..539c9bb 100644
--- a/drivers/pinctrl/pinctrl-abx500.c
+++ b/drivers/pinctrl/pinctrl-abx500.c
@@ -157,7 +157,7 @@ static int abx500_gpio_set_bits(struct gpio_chip *chip, u8 reg,
reg += offset / 8;
ret = abx500_mask_and_set_register_interruptible(pct->dev,
- AB8500_MISC, reg, 1 << pos, val << pos);
+ AB8500_MISC, reg, BIT(pos), val << pos);
if (ret < 0)
dev_err(pct->dev, "%s write failed\n", __func__);
return ret;
--
1.7.11.3
^ permalink raw reply related
* [PATCH 2/4] pinctrl/abx500: replace incorrect return value
From: Linus Walleij @ 2013-01-30 19:40 UTC (permalink / raw)
To: linux-arm-kernel
From: Lee Jones <lee.jones@linaro.org>
Currently in the empty abx500_pin_config_get() function, we're
returning -EINVAL, with a comment stating that the reason for the
failure is that the function isn't implemented yet. Well there's
a proper return code for that. If we use it, we can do away with
the comment too, as it would be implied.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-abx500.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-abx500.c b/drivers/pinctrl/pinctrl-abx500.c
index 539c9bb..305a9cb 100644
--- a/drivers/pinctrl/pinctrl-abx500.c
+++ b/drivers/pinctrl/pinctrl-abx500.c
@@ -971,8 +971,7 @@ int abx500_pin_config_get(struct pinctrl_dev *pctldev,
unsigned pin,
unsigned long *config)
{
- /* Not implemented */
- return -EINVAL;
+ return -ENOSYS;
}
int abx500_pin_config_set(struct pinctrl_dev *pctldev,
--
1.7.11.3
^ permalink raw reply related
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