Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V4 3/4] ARM: Xilinx: base header files and assembly macros
From: John Linn @ 2011-02-28 14:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110228111839.GA9206@pulham.picochip.com>

> -----Original Message-----
> From: Jamie Iles [mailto:jamie at jamieiles.com]
> Sent: Monday, February 28, 2011 4:19 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org;
linux-kernel at vger.kernel.org; linux at arm.linux.org.uk;
> catalin.marinas at arm.com; glikely at secretlab.ca; jamie at jamieiles.com;
arnd at arndb.de
> Subject: Re: [PATCH V4 3/4] ARM: Xilinx: base header files and
assembly macros
> 
> Hi John,
> 
> One more pedantic nitpick, but nothing major!
> 
> Jamie
> 
> On Fri, Feb 18, 2011 at 11:14:40AM -0700, John Linn wrote:
> > These are the minimum needed to build the kernel for the new
platform.
> >
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
> >
> > V4 Changes
> >
> > Cleanup based on input from Jamie Iles.
> > 	Moved to PLAT_PHYS_OFFSET.
> > 	Remove headers file inclusions that weren't needed.
> > 	Added use of raw_readl/raw_writel in uncompressor uart code.
> > 	Added cpu_relax() in the uncompressor uart code.
> >
> > V3 Changes
> >
> > Updates based on Russell Kings' comments
> > 	Changed headers to update the license info and remove
> > 	the address
> >
> > 	Updated the constant to use UL in vmalloc.h
> >
> > V2 Changes
> >
> > Updates based on Russell King's comments
> > 	moved to using entry-macro-gic.S
> > 	moved stuff from hardware.h to xilinx_soc.h
> > 	added IOMEM() in io.h to help with typing
> > 	Minor updates to IO_SPACE_LIMIT and __io()
> > 	Updated addresses to be clear with seperate virtual
> > 		and physical addresses
> >
> >  arch/arm/mach-xilinx/include/mach/clkdev.h      |   33 ++++++++++++
> >  arch/arm/mach-xilinx/include/mach/debug-macro.S |   36
+++++++++++++
> >  arch/arm/mach-xilinx/include/mach/entry-macro.S |   30 +++++++++++
> >  arch/arm/mach-xilinx/include/mach/hardware.h    |   18 +++++++
> >  arch/arm/mach-xilinx/include/mach/io.h          |   33 ++++++++++++
> >  arch/arm/mach-xilinx/include/mach/irqs.h        |   29 +++++++++++
> >  arch/arm/mach-xilinx/include/mach/memory.h      |   23 +++++++++
> >  arch/arm/mach-xilinx/include/mach/system.h      |   28 ++++++++++
> >  arch/arm/mach-xilinx/include/mach/timex.h       |   22 ++++++++
> >  arch/arm/mach-xilinx/include/mach/uart.h        |   25 +++++++++
> >  arch/arm/mach-xilinx/include/mach/uncompress.h  |   61
+++++++++++++++++++++++
> >  arch/arm/mach-xilinx/include/mach/vmalloc.h     |   20 +++++++
> >  arch/arm/mach-xilinx/include/mach/xilinx_soc.h  |   46
+++++++++++++++++
> >  13 files changed, 404 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/clkdev.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/debug-macro.S
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/entry-macro.S
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/hardware.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/io.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/irqs.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/memory.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/system.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/timex.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/uart.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/uncompress.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/vmalloc.h
> >  create mode 100644 arch/arm/mach-xilinx/include/mach/xilinx_soc.h
> >
> > diff --git a/arch/arm/mach-xilinx/include/mach/clkdev.h
b/arch/arm/mach-xilinx/include/mach/clkdev.h
> > new file mode 100644
> > index 0000000..5dd1453
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/clkdev.h
> > @@ -0,0 +1,33 @@
> > +/*
> > + * arch/arm/mach-xilinx/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__
> > +
> > +struct clk {
> > +	unsigned long rate;
> > +};
> > +
> > +static inline int __clk_get(struct clk *clk)
> > +{
> > +	return 1;
> > +}
> > +
> > +static inline void __clk_put(struct clk *clk)
> > +{
> > +}
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/debug-macro.S
b/arch/arm/mach-
> xilinx/include/mach/debug-macro.S
> > new file mode 100644
> > index 0000000..30d3d3d
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/debug-macro.S
> > @@ -0,0 +1,36 @@
> > +/* arch/arm/mach-xilinx/include/mach/debug-macro.S
> > + *
> > + * Debugging macro include header
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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.
> > + */
> > +
> > +#include <mach/xilinx_soc.h>
> > +#include <mach/uart.h>
> > +
> > +		.macro	addruart, rp, rv
> > +		ldr	\rp, =LL_UART_PADDR	@ physical
> > +		ldr	\rv, =LL_UART_VADDR	@ virtual
> > +		.endm
> > +
> > +		.macro	senduart,rd,rx
> > +		str	\rd, [\rx, #UART_FIFO_OFFSET]	@ TXDATA
> > +		.endm
> > +
> > +		.macro	waituart,rd,rx
> > +		.endm
> > +
> > +		.macro	busyuart,rd,rx
> > +1002:		ldr	\rd, [\rx, #UART_SR_OFFSET]	@ get
status register
> > +		tst	\rd, #UART_SR_TXFULL		@
> > +		bne	1002b			@ wait if FIFO is full
> > +		.endm
> > diff --git a/arch/arm/mach-xilinx/include/mach/entry-macro.S
b/arch/arm/mach-
> xilinx/include/mach/entry-macro.S
> > new file mode 100644
> > index 0000000..11a2866
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/entry-macro.S
> > @@ -0,0 +1,30 @@
> > +/*
> > + * arch/arm/mach-xilinx/include/mach/entry-macro.S
> > + *
> > + * Low-level IRQ helper macros
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * based on arch/plat-mxc/include/mach/entry-macro.S
> > + *
> > + *  Copyright (C) 2007 Lennert Buytenhek <buytenh@wantstofly.org>
> > + *  Copyright 2004-2007 Freescale Semiconductor, Inc. All Rights
Reserved.
> > + *
> > + * 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.
> > + */
> > +
> > +#include <mach/hardware.h>
> > +#include <asm/hardware/entry-macro-gic.S>
> > +
> > +                .macro  disable_fiq
> > +                .endm
> > +
> > +                .macro  arch_ret_to_user, tmp1, tmp2
> > +                .endm
> > diff --git a/arch/arm/mach-xilinx/include/mach/hardware.h
b/arch/arm/mach-
> xilinx/include/mach/hardware.h
> > new file mode 100644
> > index 0000000..f9685c4
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/hardware.h
> > @@ -0,0 +1,18 @@
> > +/* arch/arm/mach-xilinx/include/mach/hardware.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_HARDWARE_H__
> > +#define __MACH_HARDWARE_H__
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/io.h
b/arch/arm/mach-xilinx/include/mach/io.h
> > new file mode 100644
> > index 0000000..ef69e65
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/io.h
> > @@ -0,0 +1,33 @@
> > +/* arch/arm/mach-xilinx/include/mach/io.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_IO_H__
> > +#define __MACH_IO_H__
> > +
> > +/* Allow IO space to be anywhere in the memory */
> > +
> > +#define IO_SPACE_LIMIT 0xffff
> > +
> > +/* IO address mapping macros, nothing special at this time but
required */
> > +
> > +#ifdef __ASSEMBLER__
> > +#define IOMEM(x)		(x)
> > +#else
> > +#define IOMEM(x)		((void __force __iomem *)(x))
> > +#endif
> > +
> > +#define __io(a)			__typesafe_io(a)
> > +#define __mem_pci(a)		(a)
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/irqs.h
b/arch/arm/mach-xilinx/include/mach/irqs.h
> > new file mode 100644
> > index 0000000..47a8162
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/irqs.h
> > @@ -0,0 +1,29 @@
> > +/* arch/arm/mach-xilinx/include/mach/irqs.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_IRQS_H
> > +#define __MACH_IRQS_H
> > +
> > +#define ARCH_NR_GPIOS	118
> > +#define NR_IRQS		(128 + ARCH_NR_GPIOS)
> > +
> > +/*
> > + * GIC Interrupts
> > + */
> > +
> > +#define IRQ_GIC_SPI_START	32
> > +#define IRQ_TIMERCOUNTER0	42
> > +#define IRQ_UART0		59
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/memory.h
b/arch/arm/mach-xilinx/include/mach/memory.h
> > new file mode 100644
> > index 0000000..3efde15
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/memory.h
> > @@ -0,0 +1,23 @@
> > +/* arch/arm/mach-xilinx/include/mach/memory.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_MEMORY_H__
> > +#define __MACH_MEMORY_H__
> > +
> > +#include <asm/sizes.h>
> > +
> > +#define PHYS_OFFSET             UL(0x0)
> > +#define MEM_SIZE		SZ_256M
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/system.h
b/arch/arm/mach-xilinx/include/mach/system.h
> > new file mode 100644
> > index 0000000..e8514a0
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/system.h
> > @@ -0,0 +1,28 @@
> > +/* arch/arm/mach-xilinx/include/mach/system.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_SYSTEM_H__
> > +#define __MACH_SYSTEM_H__
> > +
> > +static inline void arch_idle(void)
> > +{
> > +	cpu_do_idle();
> > +}
> > +
> > +static inline void arch_reset(char mode, const char *cmd)
> > +{
> > +	/* Add architecture specific reset processing here */
> > +}
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/timex.h
b/arch/arm/mach-xilinx/include/mach/timex.h
> > new file mode 100644
> > index 0000000..4ebc0a6
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/timex.h
> > @@ -0,0 +1,22 @@
> > +/* arch/arm/mach-xilinx/include/mach/timex.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_TIMEX_H__
> > +#define __MACH_TIMEX_H__
> > +
> > +#define PERIPHERAL_CLOCK_RATE	2500000
> > +
> > +#define CLOCK_TICK_RATE	(PERIPHERAL_CLOCK_RATE / 32)
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/uart.h
b/arch/arm/mach-xilinx/include/mach/uart.h
> > new file mode 100644
> > index 0000000..7fca361
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/uart.h
> > @@ -0,0 +1,25 @@
> > +/* arch/arm/mach-xilinx/include/mach/uart.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_UART_H__
> > +#define __MACH_UART_H__
> > +
> > +#define UART_CR_OFFSET          0x00  /* Control Register [8:0] */
> > +#define UART_SR_OFFSET          0x2C  /* Channel Status [11:0] */
> > +#define UART_FIFO_OFFSET        0x30  /* FIFO [15:0] or [7:0] */
> > +
> > +#define UART_SR_TXFULL		0x00000010	/* TX FIFO full
*/
> > +#define UART_SR_TXEMPTY		0x00000008	/* TX FIFO empty
*/
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/uncompress.h
b/arch/arm/mach-
> xilinx/include/mach/uncompress.h
> > new file mode 100644
> > index 0000000..ff3754c
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/uncompress.h
> > @@ -0,0 +1,61 @@
> > +/* arch/arm/mach-xilinx/include/mach/uncompress.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_UNCOMPRESS_H__
> > +#define __MACH_UNCOMPRESS_H__
> > +
> > +#include <mach/xilinx_soc.h>
> > +#include <mach/uart.h>
> > +#include <asm/processor.h>
> > +#include <asm/io.h>
> > +#include <mach/io.h>
> > +
> > +void arch_decomp_setup(void)
> > +{
> > +}
> > +
> > +static inline void flush(void)
> > +{
> > +	u32 status;
> > +	/*
> > +	 * Wait while the FIFO is not empty
> > +	 */
> > +	while (1) {
> > +		status = __raw_readl(IOMEM(LL_UART_PADDR +
UART_SR_OFFSET));
> > +		if (status & UART_SR_TXEMPTY)
> > +			break;
> > +		cpu_relax();
> > +	}
> 
> This could be written as:
> 
> static inline void flush(void)
> {
> 	while (!(__raw_readl(IOMEM(LL_UART_PADDR + UART_SR_OFFSET)) &
> 		 UART_SR_TXEMPTY))
> 		 cpu_relax();
> }

Honestly I had it that way as I know most in the community do that and
terse-ness
is somewhat preferred.

I thought my way is a bit clearer as it was a bit harder to read the
other way.

Do you think everyone else would say to change it?  No big deal to
change it.

Thanks,
John

> 
> > +}
> > +
> > +#define arch_decomp_wdog()
> > +
> > +static void putc(char ch)
> > +{
> > +	u32 status;
> > +
> > +	/*
> > +	 * Wait for room in the FIFO, then write the char into the FIFO
> > +	 */
> > +	while (1) {
> > +		status = __raw_readl(IOMEM(LL_UART_PADDR +
UART_SR_OFFSET));
> > +		if (!(status & UART_SR_TXFULL))
> > +			break;
> > +		cpu_relax();
> > +	}
> > +
> > +	__raw_writel(ch, IOMEM(LL_UART_PADDR + UART_FIFO_OFFSET));
> > +}
> 
> static void putch(char ch)
> {
> 	while (__raw_readl(IOMEM(LL_UART_PADDR + UART_SR_OFFSET)) &
> 	       UART_SR_TXFULL)
> 	       cpu_relax();
> 	__raw_writel(ch, IOMEM(LL_UART_PADDR + UART_FIFO_OFFSET));
> }
> 

Same thing.

> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/vmalloc.h
b/arch/arm/mach-
> xilinx/include/mach/vmalloc.h
> > new file mode 100644
> > index 0000000..aba20a3
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/vmalloc.h
> > @@ -0,0 +1,20 @@
> > +/* arch/arm/mach-xilinx/include/mach/vmalloc.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_VMALLOC_H__
> > +#define __MACH_VMALLOC_H__
> > +
> > +#define VMALLOC_END       0xE0000000UL
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/xilinx_soc.h
b/arch/arm/mach-
> xilinx/include/mach/xilinx_soc.h
> > new file mode 100644
> > index 0000000..d01cde1
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/xilinx_soc.h
> > @@ -0,0 +1,46 @@
> > +/* arch/arm/mach-xilinx/include/mach/xilinx_soc.h
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * 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_XILINX_SOC_H__
> > +#define __MACH_XILINX_SOC_H__
> > +
> > +/* For now, all mappings are flat (physical = virtual)
> > + */
> > +#define UART0_PHYS			0xE0000000
> > +#define UART0_VIRT			UART0_PHYS
> > +
> > +#define TTC0_PHYS			0xF8001000
> > +#define TTC0_VIRT			TTC0_PHYS
> > +
> > +#define PL310_L2CC_PHYS			0xF8F02000
> > +#define PL310_L2CC_VIRT			PL310_L2CC_PHYS
> > +
> > +#define SCU_PERIPH_PHYS			0xF8F00000
> > +#define SCU_PERIPH_VIRT			SCU_PERIPH_PHYS
> > +
> > +/* The following are intended for the devices that are mapped early
*/
> > +
> > +#define TTC0_BASE			IOMEM(TTC0_VIRT)
> > +#define SCU_PERIPH_BASE			IOMEM(SCU_PERIPH_VIRT)
> > +#define SCU_GIC_CPU_BASE		(SCU_PERIPH_BASE + 0x100)
> > +#define SCU_GIC_DIST_BASE		(SCU_PERIPH_BASE + 0x1000)
> > +#define PL310_L2CC_BASE			IOMEM(PL310_L2CC_VIRT)
> > +
> > +/*
> > + * Mandatory for CONFIG_LL_DEBUG, UART is mapped virtual = physical
> > + */
> > +#define LL_UART_PADDR	UART0_PHYS
> > +#define LL_UART_VADDR	UART0_VIRT
> > +
> > +#endif
> > --
> > 1.6.2.1
> >
> >
> >
> > 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.
> >
> >


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 V3 1/4] ARM: imx53_loco: add esdhc device support
From: Wolfram Sang @ 2011-02-28 14:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <AANLkTimTsv1jsvX8Eq9EttU32O0sJ-8yj-SGadx9gwLD@mail.gmail.com>


> >> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
> >> ---
> >> ?arch/arm/mach-mx5/Kconfig ? ? ? ? ? | ? ?1 +
> >> ?arch/arm/mach-mx5/board-mx53_loco.c | ? ?2 ++
> >> ?2 files changed, 3 insertions(+), 0 deletions(-)
> >
> > I think this patch should be the last one of the series.
> Yes, but I don't think it matter much.

It will if you bisect and end up here without the clock patch, no?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/caf7af73/attachment.sig>

^ permalink raw reply

* [PATCH V4 2/4] ARM: Xilinx: Adding timer support to the platform
From: John Linn @ 2011-02-28 14:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110228111156.GB8751@pulham.picochip.com>

> -----Original Message-----
> From: Jamie Iles [mailto:jamie at jamieiles.com]
> Sent: Monday, February 28, 2011 4:12 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org;
linux-kernel at vger.kernel.org; linux at arm.linux.org.uk;
> catalin.marinas at arm.com; glikely at secretlab.ca; jamie at jamieiles.com;
arnd at arndb.de; Kiran Sutariya
> Subject: Re: [PATCH V4 2/4] ARM: Xilinx: Adding timer support to the
platform
> 
> On Fri, Feb 18, 2011 at 11:14:39AM -0700, John Linn wrote:
> > The timer driver supports the Xilinx PS Timer Counter IP.
> >
> > Signed-off-by: Kiran Sutariya <kiran.sutariya@einfochips.com>
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
> 
> Looks nice to me.  It may be worth adding sched_clock() support to get
> better scheduler resolution in the future but that could come as a
> separate patch.

Yes will do that as an update patch later, good suggestion.

Thanks,
John

> 
> Jamie


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 V4 1/4] ARM: Xilinx: Adding Xilinx board support
From: John Linn @ 2011-02-28 14:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110228110618.GA8751@pulham.picochip.com>

> -----Original Message-----
> From: Jamie Iles [mailto:jamie at jamieiles.com]
> Sent: Monday, February 28, 2011 4:06 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org;
linux-kernel at vger.kernel.org; linux at arm.linux.org.uk;
> catalin.marinas at arm.com; glikely at secretlab.ca; jamie at jamieiles.com;
arnd at arndb.de
> Subject: Re: [PATCH V4 1/4] ARM: Xilinx: Adding Xilinx board support
> 
> Hi John,
> 
> A couple of very pedantic nitpicks below, sorry I didn't spot them
> before!
> 
> On Fri, Feb 18, 2011 at 11:14:38AM -0700, John Linn wrote:
> > The 1st board support is minimal to get a system up and running
> > on the Xilinx platform.
> >
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
> >
> > V4 Changes
> > 	Minor cleanup based on input from Jamie Iles.
> >
> > V3 Changes
> >
> > Updates based on Russell Kings' comments
> > 	Changed headers to update the license info and remove
> > 	the address
> >
> > 	Changed the name of functions to include "xilinx" in
> > 	common.c and common.h
> >
> > Changed the Kconfig and Makefile to use MACH_XILINX which
> > matches the machine registered.
> >
> > V2 Changes
> >
> > Updates based on Russell King's comments
> > 	minor cleanups
> > 	cleaned up physical/virtual addresses in early i/o table
> >
> >  arch/arm/mach-xilinx/Kconfig       |   14 +++++
> >  arch/arm/mach-xilinx/Makefile      |    7 ++
> >  arch/arm/mach-xilinx/Makefile.boot |    3 +
> >  arch/arm/mach-xilinx/board_ep107.c |   82
++++++++++++++++++++++++++
> >  arch/arm/mach-xilinx/common.c      |  113
++++++++++++++++++++++++++++++++++++
> >  arch/arm/mach-xilinx/common.h      |   30 ++++++++++
> >  6 files changed, 249 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/arm/mach-xilinx/Kconfig
> >  create mode 100644 arch/arm/mach-xilinx/Makefile
> >  create mode 100644 arch/arm/mach-xilinx/Makefile.boot
> >  create mode 100644 arch/arm/mach-xilinx/board_ep107.c
> >  create mode 100644 arch/arm/mach-xilinx/common.c
> >  create mode 100644 arch/arm/mach-xilinx/common.h
> >
> > diff --git a/arch/arm/mach-xilinx/Kconfig
b/arch/arm/mach-xilinx/Kconfig
> > new file mode 100644
> > index 0000000..61532af
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/Kconfig
> > @@ -0,0 +1,14 @@
> > +if ARCH_XILINX
> > +
> > +choice
> > +        prompt "Board Selection"
> > +	default MACH_XILINX
> > +
> > +config MACH_XILINX
> > +	bool "Xilinx EP107 Board"
> > +	help
> > +	  Select if you are using a Xilinx EP107 board.
> > +
> > +endchoice
> > +
> > +endif
> > diff --git a/arch/arm/mach-xilinx/Makefile
b/arch/arm/mach-xilinx/Makefile
> > new file mode 100644
> > index 0000000..76e9e55
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/Makefile
> > @@ -0,0 +1,7 @@
> > +#
> > +# Makefile for the linux kernel.
> > +#
> > +
> > +# Common support
> > +obj-y 				:= common.o
> > +obj-$(CONFIG_MACH_XILINX)	+= board_ep107.o
> > diff --git a/arch/arm/mach-xilinx/Makefile.boot
b/arch/arm/mach-xilinx/Makefile.boot
> > new file mode 100644
> > index 0000000..67039c3
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/Makefile.boot
> > @@ -0,0 +1,3 @@
> > +   zreladdr-y	:= 0x00008000
> > +params_phys-y	:= 0x00000100
> > +initrd_phys-y	:= 0x00800000
> > diff --git a/arch/arm/mach-xilinx/board_ep107.c
b/arch/arm/mach-xilinx/board_ep107.c
> > new file mode 100644
> > index 0000000..a1635b5
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/board_ep107.c
> > @@ -0,0 +1,82 @@
> > +/* arch/arm/mach-xilinx/board_ep107.c
> > + *
> > + * This file contains code specific to the Xilinx EP107 board.
> > + *
> > + *  Copyright (C) 2011 Xilinx
> > + *
> > + * based on /arch/arm/mach-realview/core.c
> > + *
> > + *  Copyright (C) 1999 - 2003 ARM Limited
> > + *  Copyright (C) 2000 Deep Blue Solutions Ltd
> > + *
> > + * 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.
> > + */
> > +
> > +#include <linux/platform_device.h>
> > +#include <asm/mach-types.h>
> > +#include <asm/mach/arch.h>
> > +#include <mach/xilinx_soc.h>
> > +#include <mach/irqs.h>
> > +#include <linux/clkdev.h>
> > +#include "common.h"
> 
> Usual convention is to order these as the linux, then the asm, then
the
> mach includes.

Easy to fix :), thanks for pointing it out.

> 
> > +
> > +/*
> > + * Fixed clocks for now
> > + */
> > +
> > +static struct clk ref50_clk = {
> > +	.rate	= 50000000,
> > +};
> > +
> > +/* Create all the platform devices for the board */
> > +
> > +static struct resource uart0[] = {
> > +	{
> > +		.start = UART0_PHYS,
> > +		.end = UART0_PHYS + 0xFFF,
> > +		.flags = IORESOURCE_MEM,
> > +	}, {
> > +		.start = IRQ_UART0,
> > +		.end = IRQ_UART0,
> > +		.flags = IORESOURCE_IRQ,
> > +	},
> > +};
> > +
> > +static struct platform_device uart_device0 = {
> > +	.name = "xuartpss",
> > +	.id = 0,
> > +	.dev = {
> > +		.platform_data = &ref50_clk.rate,
> > +	},
> > +	.resource = uart0,
> > +	.num_resources = ARRAY_SIZE(uart0),
> > +};
> > +
> > +static struct platform_device *xilinx_pdevices[] __initdata = {
> > +	&uart_device0,
> > +};
> > +
> > +/**
> > + * board_ep107_init - Board specific initialization for the Xilinx
EP107 board.
> > + *
> > + **/
> > +static void __init board_ep107_init(void)
> > +{
> > +	xilinx_system_init();
> > +	platform_add_devices(&xilinx_pdevices[0],
ARRAY_SIZE(xilinx_pdevices));
> > +}
> > +
> > +MACHINE_START(XILINX_EP107, "Xilinx EP107")
> > +	.boot_params    = PHYS_OFFSET + 0x00000100,
> 
> Should this use PLAT_PHYS_OFFSET?
> 

Yes, not sure why I didn't catch that.

Thanks,
John

> Jamie


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 v10 05/18] OMAP2,3 DSS2 Change driver name to omap_display
From: Russell King - ARM Linux @ 2011-02-28 14:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4D6BA558.5050700@ti.com>

On Mon, Feb 28, 2011 at 02:38:32PM +0100, Cousson, Benoit wrote:
> On 2/28/2011 1:13 PM, Russell King - ARM Linux wrote:
>> On Mon, Feb 28, 2011 at 02:10:26PM +0200, Tomi Valkeinen wrote:
>>> On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
>>>> Cannot you use a device hierarchy then to do that?
>>>>    omap_dss/core
>>>>    omap_dss/dsi
>>>>    omap_dss/venc
>>>>
>>>> This is moreover the way the HW is done.
>>>
>>> Hmm, how would that work? The devices are platform devices, and they
>>> have a unique global name, which is used to match the driver for the
>>> device.
>>
>> And not forgetting that '/' is not permitted in device or driver names.
>
> I was not really considering naming the device with a '/'. The idea is  
> that the devices will not longer be flat platform devices but something  
> like dss devices that will have have a omap_dss parent.
>
> I do not know if that makes sense to store some kind of hierarchy in the  
> device model, but encoding the hierarchy in the name like it is proposed  
> looks like a hack to me.

Try:

tree -d /sys/devices/pci0000\:00

on your PC, taking special note of how pci-to-pci bridges are handled.

^ permalink raw reply

* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Russell King - ARM Linux @ 2011-02-28 14:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298900022-21516-7-git-send-email-will.deacon@arm.com>

On Mon, Feb 28, 2011 at 01:33:42PM +0000, Will Deacon wrote:
> The chained GPIO IRQ handler for the nomadik platform can be called
> with the GIC as its host chip on the mach-ux500 machines.
> 
> This patch updates the code to use ->irq_eoi when it is available.
> 
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  arch/arm/plat-nomadik/gpio.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-nomadik/gpio.c b/arch/arm/plat-nomadik/gpio.c
> index 1e88ecb..51cc71b 100644
> --- a/arch/arm/plat-nomadik/gpio.c
> +++ b/arch/arm/plat-nomadik/gpio.c
> @@ -538,6 +538,8 @@ static void nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
>  	}
>  
>  	host_chip->irq_unmask(&desc->irq_data);
> +	if (host_chip->irq_eoi)
> +		host_chip->irq_eoi(&desc->irq_data);

I notice in some you delete the irq_unmask, others you leave it.  Shouldn't
they all be similar?

Maybe we do something like:

static inline void chained_irq_exit(struct irq_chip *chip, struct irq_desc *desc)
{
	if (chip->irq_eoi)
		chip->irq_eoi(&desc->irq_data);
	else
		chip->irq_unmask(&desc->irq_data);
}

to cover these exit paths in a common way?

^ permalink raw reply

* [PATCH v10 05/18] OMAP2, 3 DSS2 Change driver name to omap_display
From: Cousson, Benoit @ 2011-02-28 14:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298895026.9809.27.camel@deskari>

On 2/28/2011 1:10 PM, Valkeinen, Tomi wrote:
> On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
>> Hi Tomi,
>>
>> On 2/28/2011 8:19 AM, Valkeinen, Tomi wrote:
>>> On Mon, 2011-02-28 at 01:09 -0600, Taneja, Archit wrote:
>>>> Hi,
>>>>
>>>> On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote:
>>>>> On Thu, 2011-02-24 at 03:27 -0600, Tomi Valkeinen wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, 2011-01-24 at 11:51 +0530, ext Sumit Semwal wrote:
>>>>>>> From: Senthilvadivu Guruswamy<svadivu@ti.com>
>>>>>>>
>>>>>>> Change the driver name from omapdss to omap_display as the driver takes care of
>>>>>>> the display devices ie number of panels, type of panels available in the
>>>>>>> platform.  Change the device name in the board files and 2420,2430,3xxx clock
>>>>>>> files from omapdss to omap_display to match the driver name.
>>>>>>
>>>>>> I just realized that changing the driver name will break all scripts and
>>>>>> applications using omapdss sysfs files.
>>>>>>
>>>>>> How does this sound:
>>>>>>
>>>>>> Let's leave the omapdss device name as it is. It represents a "super"
>>>>>> device, containing the dss sysfs files and upper level dss management.
>>
>> This is the case for all the drivers migrated to omap_device anyway due
>> to the change in the top level hierarchy. Everything is below
>> platform/omap now.
>
> The HW module drivers are under platform/omap/, but omapdss is in
> platform/. Do you mean that omapdss should also be under platform/omap/?

This is because you are probably not using omap_device yet. is should 
happen when you will change your platform_device to be omap_device.

> The reason I'm unwilling to change omapdss name, or location, is that
> omapdss directory contains lots of DSS configuration files, used by
> scripts and programs.

Is that used for debug only?

>> That's why we are using that opportunity to clean and provide a
>> consistent naming for all devices.
>>
>>>>>> Name the HW module platform drivers as: omapdss_dss, omapdss_venc,
>>>>>> omapdss_dispc, etc. This would indicate them to be clearly parts of DSS,
>>>>>> and would also prevent any possible name conflict if there would happen
>>>>>> to be a, say, "dsi" block in some other HW component.
>>
>> Cannot you use a device hierarchy then to do that?
>>    omap_dss/core
>>    omap_dss/dsi
>>    omap_dss/venc
>>
>> This is moreover the way the HW is done.
>
> Hmm, how would that work? The devices are platform devices, and they
> have a unique global name, which is used to match the driver for the
> device.

Practically, I don't really know :-) Please see the reply to Russell.

>>>>> Any comments on this?
>>>>
>>>> I also think we need to stick to the older name, "omapdss_dss" sounds a
>>>> bit confusing, and I think one of the previous versions had something
>>>> like "dss_dss" in it and it wasn't approved. Does something like
>>>> "omapdss_core" or "omapdss_dss_core" make sense, or is it more misleading?
>>>
>>> It is confusing, but so is the hardware naming =). There is a DSS module
>>> inside the omap display subsystem. That's why I would like to name it
>>> "dss", not "core", so it's clear it refers to this DSS module.
>>>
>>> "dss_dss" looks a bit silly, but I think "omapdss_dss" is slightly
>>> better in the sense that it doesn't repeat the same "dss", and there is
>>> an "omapdss" device, which acts like "manager" for these module devices.
>>> But yes, I wouldn't call it perfect either.
>>>
>>> "omapdss_dss_core" is one option. But then again, TRM doesn't speak of
>>> "core".
>>
>> We should not maintain silly names just because they are in the TRM, we
>> should just fix the TRM. This is exactly what we are going to do for
>> most HW names we introduced in OMAP4.
>>
>> So if we all agree that this name will avoid confusion and is much
>> better than the current one, we can change it right now with a comment
>> to explain the change and give the pointer to the current TRM naming.
>
> True. But I don't think there's a huge difference with omapdss_dss or
> omapdss_core.

You're right, at the end it is just a name. We are just trying to clean 
a little bit the current devices name mess. So the convention we are 
trying to enforce is to name omap devices omap_XXX.

> The name is used in only a few places inside the kernel, and never from
> userspace, so we can change that also later.
>
> The main issue I had was changing the omapdss device name, which would
> break the userspace.

That's why we'd better break it properly today once and for all :-)
At least when you will migrate to omap_device.

Benoit

^ permalink raw reply

* [PATCH V3 1/4] ARM: imx53_loco: add esdhc device support
From: Wolfram Sang @ 2011-02-28 13:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298892725-23672-1-git-send-email-Hong-Xing.Zhu@freescale.com>

On Mon, Feb 28, 2011 at 07:32:02PM +0800, Richard Zhu wrote:
> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>

Acked-by: Wolfram Sang <w.sang@pengutronix.de>

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/deaf223d/attachment.sig>

^ permalink raw reply

* [PATCH V5 6/6] pxa3xx_nand: clean the keep configure code
From: Artem Bityutskiy @ 2011-02-28 13:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298860335-18638-7-git-send-email-leiwen@marvell.com>

On Mon, 2011-02-28 at 10:32 +0800, Lei Wen wrote:
> Signed-off-by: Lei Wen <leiwen@marvell.com>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> ---
>  arch/arm/plat-pxa/include/plat/pxa3xx_nand.h |    2 +-
>  drivers/mtd/nand/pxa3xx_nand.c               |  103 +++++++++-----------------
>  2 files changed, 36 insertions(+), 69 deletions(-)

Similarly, could you please improve the commit message a bit?

-- 
Best Regards,
Artem Bityutskiy (????? ????????)

^ permalink raw reply

* [PATCH V5 1/6] pxa3xx_nand: make scan procedure more clear
From: Artem Bityutskiy @ 2011-02-28 13:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298860335-18638-2-git-send-email-leiwen@marvell.com>

On Mon, 2011-02-28 at 10:32 +0800, Lei Wen wrote:
> Signed-off-by: Lei Wen <leiwen@marvell.com>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>

Could you please improve the commit message and make it explain why your
code makes "scan" more clear, what exactly you do to improve it?

-- 
Best Regards,
Artem Bityutskiy (????? ????????)

^ permalink raw reply

* [PATCH V3 1/4] ARM: imx53_loco: add esdhc device support
From: Richard Zhao @ 2011-02-28 13:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <AANLkTin1U=B3xnp0UGK_2iHK2k=o4Tda=6NzyoLFgUAv@mail.gmail.com>

On Mon, Feb 28, 2011 at 8:43 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Richard,
>
> On Mon, Feb 28, 2011 at 8:25 AM, Richard Zhu
> <Hong-Xing.Zhu@freescale.com> wrote:
>> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
>> ---
>> ?arch/arm/mach-mx5/Kconfig ? ? ? ? ? | ? ?1 +
>> ?arch/arm/mach-mx5/board-mx53_loco.c | ? ?2 ++
>> ?2 files changed, 3 insertions(+), 0 deletions(-)
>
> I think this patch should be the last one of the series.
Yes, but I don't think it matter much.

Thanks
Richard
>
> Regards,
>
> Fabio Estevam
>

^ permalink raw reply

* [PATCH v10 05/18] OMAP2, 3 DSS2 Change driver name to omap_display
From: Cousson, Benoit @ 2011-02-28 13:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110228121321.GB30781@n2100.arm.linux.org.uk>

On 2/28/2011 1:13 PM, Russell King - ARM Linux wrote:
> On Mon, Feb 28, 2011 at 02:10:26PM +0200, Tomi Valkeinen wrote:
>> On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
>>> Cannot you use a device hierarchy then to do that?
>>>    omap_dss/core
>>>    omap_dss/dsi
>>>    omap_dss/venc
>>>
>>> This is moreover the way the HW is done.
>>
>> Hmm, how would that work? The devices are platform devices, and they
>> have a unique global name, which is used to match the driver for the
>> device.
>
> And not forgetting that '/' is not permitted in device or driver names.

I was not really considering naming the device with a '/'. The idea is 
that the devices will not longer be flat platform devices but something 
like dss devices that will have have a omap_dss parent.

I do not know if that makes sense to store some kind of hierarchy in the 
device model, but encoding the hierarchy in the name like it is proposed 
looks like a hack to me. The point is that the dsi instances might 
potentially be in another part of the SoC. Having the device name based 
on the hierarchy will not allow the driver to bind the device properly.

Please note, that I'm not really sure it is doable with the current 
device model, hence the original question.

Benoit

^ permalink raw reply

* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>

The chained GPIO IRQ handler for the nomadik platform can be called
with the GIC as its host chip on the mach-ux500 machines.

This patch updates the code to use ->irq_eoi when it is available.

Cc: Rabin Vincent <rabin@rab.in>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/plat-nomadik/gpio.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-nomadik/gpio.c b/arch/arm/plat-nomadik/gpio.c
index 1e88ecb..51cc71b 100644
--- a/arch/arm/plat-nomadik/gpio.c
+++ b/arch/arm/plat-nomadik/gpio.c
@@ -538,6 +538,8 @@ static void nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 	}
 
 	host_chip->irq_unmask(&desc->irq_data);
+	if (host_chip->irq_eoi)
+		host_chip->irq_eoi(&desc->irq_data);
 }
 
 static int nmk_gpio_init_irq(struct nmk_gpio_chip *nmk_chip)
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH 5/6] ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>

The chained GPIO IRQ handler on MSM8x60 calls ->ack on the parent chip
after handling the interrupt.

This patch updates the code to use ->irq_eoi now that the GIC has moved
to using the fasteoi flow model.

Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/mach-msm/gpio-v2.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
index 0de19ec..90a968f 100644
--- a/arch/arm/mach-msm/gpio-v2.c
+++ b/arch/arm/mach-msm/gpio-v2.c
@@ -310,6 +310,7 @@ static int msm_gpio_irq_set_type(unsigned int irq, unsigned int flow_type)
 static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)
 {
 	unsigned long i;
+	struct irq_chip *chip = get_irq_desc_chip(desc);
 
 	for (i = find_first_bit(msm_gpio.enabled_irqs, NR_GPIO_IRQS);
 	     i < NR_GPIO_IRQS;
@@ -318,7 +319,7 @@ static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)
 			generic_handle_irq(msm_gpio_to_irq(&msm_gpio.gpio_chip,
 							   i));
 	}
-	desc->chip->ack(irq);
+	chip->irq_eoi(&desc->irq_data);
 }
 
 static int msm_gpio_irq_set_wake(unsigned int irq, unsigned int on)
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH 4/6] ARM: s5pv310: update IRQ combiner to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>

The IRQ combiner code invokes the ->irq_{un}mask routines of the parent
chip.

This patch updates the cascaded handler to use EOI now that the GIC has
moved to using the fasteoi flow model.

Tested-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/mach-s5pv310/irq-combiner.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-s5pv310/irq-combiner.c b/arch/arm/mach-s5pv310/irq-combiner.c
index 1ea4a9e..24d5604 100644
--- a/arch/arm/mach-s5pv310/irq-combiner.c
+++ b/arch/arm/mach-s5pv310/irq-combiner.c
@@ -59,9 +59,6 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
 	unsigned int cascade_irq, combiner_irq;
 	unsigned long status;
 
-	/* primary controller ack'ing */
-	chip->irq_ack(&desc->irq_data);
-
 	spin_lock(&irq_controller_lock);
 	status = __raw_readl(chip_data->base + COMBINER_INT_STATUS);
 	spin_unlock(&irq_controller_lock);
@@ -79,8 +76,8 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
 		generic_handle_irq(cascade_irq);
 
  out:
-	/* primary controller unmasking */
-	chip->irq_unmask(&desc->irq_data);
+	/* primary controller EOI */
+	chip->irq_eoi(&desc->irq_data);
 }
 
 static struct irq_chip combiner_chip = {
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH 3/6] ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>

The chained GPIO IRQ handler on Tegra calls ->irq_ack on the parent
chip prior to handling the interrupt.

This patch updates the code to use ->irq_eoi now that the GIC has moved
to using the fasteoi flow model.

Acked-by: Colin Cross <ccross@android.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/mach-tegra/gpio.c |   17 +----------------
 1 files changed, 1 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c
index ad80488..5019b01 100644
--- a/arch/arm/mach-tegra/gpio.c
+++ b/arch/arm/mach-tegra/gpio.c
@@ -219,9 +219,6 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 	struct tegra_gpio_bank *bank;
 	int port;
 	int pin;
-	int unmasked = 0;
-
-	desc->irq_data.chip->irq_ack(&desc->irq_data);
 
 	bank = get_irq_data(irq);
 
@@ -233,23 +230,11 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 
 		for_each_set_bit(pin, &sta, 8) {
 			__raw_writel(1 << pin, GPIO_INT_CLR(gpio));
-
-			/* if gpio is edge triggered, clear condition
-			 * before executing the hander so that we don't
-			 * miss edges
-			 */
-			if (lvl & (0x100 << pin)) {
-				unmasked = 1;
-				desc->irq_data.chip->irq_unmask(&desc->irq_data);
-			}
-
 			generic_handle_irq(gpio_to_irq(gpio + pin));
 		}
 	}
 
-	if (!unmasked)
-		desc->irq_data.chip->irq_unmask(&desc->irq_data);
-
+	desc->irq_data.chip->irq_eoi(&desc->irq_data);
 }
 
 #ifdef CONFIG_PM
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH 2/6] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>

On OMAP4, gpio_irq_handler can be chained to a physical interrupt using
the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow
model, the chained handler must invoke ->irq_eoi once handling is
complete.

This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler
for OMAP platforms. For OMAP implementations using other primary
interrupt controllers, the ->irq_ack call remains and is also made
conditional on the support offered by the controller.

Cc: Colin Cross <ccross@google.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-and-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/plat-omap/gpio.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 971d186..1d2d1c7 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1144,7 +1144,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 	u32 retrigger = 0;
 	int unmasked = 0;
 
-	desc->irq_data.chip->irq_ack(&desc->irq_data);
+	if (desc->irq_data.chip->irq_ack)
+		desc->irq_data.chip->irq_ack(&desc->irq_data);
 
 	bank = get_irq_data(irq);
 #ifdef CONFIG_ARCH_OMAP1
@@ -1238,6 +1239,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
 exit:
 	if (!unmasked)
 		desc->irq_data.chip->irq_unmask(&desc->irq_data);
+	if (desc->irq_data.chip->irq_eoi)
+		desc->irq_data.chip->irq_eoi(&desc->irq_data);
 }
 
 static void gpio_irq_shutdown(struct irq_data *d)
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH 1/6] ARM: gic: use handle_fasteoi_irq for SPIs
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1298900022-21516-1-git-send-email-will.deacon@arm.com>

Currently, the gic uses handle_level_irq for handling SPIs (Shared
Peripheral Interrupts), requiring active interrupts to be masked at
the distributor level during IRQ handling.

On a virtualised system, only the CPU interfaces are virtualised in
hardware. Accesses to the distributor must be trapped by the
hypervisor, adding latency to the critical interrupt path in Linux.

This patch modifies the GIC code to use handle_fasteoi_irq for handling
interrupts, which only requires us to signal EOI to the CPU interface
when handling is complete. Cascaded IRQ handling is also updated so
that EOI is signalled after handling.

Note that commit 846afbd1 ("GIC: Dont disable INT in ack callback")
broke cascading interrupts by forgetting to add IRQ masking. This is
no longer an issue because the unmask call is now unnecessary.

Tested on Versatile Express and Realview EB (1176 w/ cascaded GICs).

Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/common/gic.c |   23 +++++++++--------------
 1 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 2243772..9def30b 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -71,13 +71,6 @@ static inline unsigned int gic_irq(struct irq_data *d)
 /*
  * Routines to acknowledge, disable and enable interrupts
  */
-static void gic_ack_irq(struct irq_data *d)
-{
-	spin_lock(&irq_controller_lock);
-	writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
-	spin_unlock(&irq_controller_lock);
-}
-
 static void gic_mask_irq(struct irq_data *d)
 {
 	u32 mask = 1 << (d->irq % 32);
@@ -96,6 +89,11 @@ static void gic_unmask_irq(struct irq_data *d)
 	spin_unlock(&irq_controller_lock);
 }
 
+static void gic_eoi_irq(struct irq_data *d)
+{
+	writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
+}
+
 static int gic_set_type(struct irq_data *d, unsigned int type)
 {
 	void __iomem *base = gic_dist_base(d);
@@ -174,9 +172,6 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
 	unsigned int cascade_irq, gic_irq;
 	unsigned long status;
 
-	/* primary controller ack'ing */
-	chip->irq_ack(&desc->irq_data);
-
 	spin_lock(&irq_controller_lock);
 	status = readl(chip_data->cpu_base + GIC_CPU_INTACK);
 	spin_unlock(&irq_controller_lock);
@@ -192,15 +187,15 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
 		generic_handle_irq(cascade_irq);
 
  out:
-	/* primary controller unmasking */
-	chip->irq_unmask(&desc->irq_data);
+	/* primary controller EOI */
+	chip->irq_eoi(&desc->irq_data);
 }
 
 static struct irq_chip gic_chip = {
 	.name			= "GIC",
-	.irq_ack		= gic_ack_irq,
 	.irq_mask		= gic_mask_irq,
 	.irq_unmask		= gic_unmask_irq,
+	.irq_eoi		= gic_eoi_irq,
 	.irq_set_type		= gic_set_type,
 #ifdef CONFIG_SMP
 	.irq_set_affinity	= gic_set_cpu,
@@ -275,7 +270,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
 	for (i = irq_start; i < irq_limit; i++) {
 		set_irq_chip(i, &gic_chip);
 		set_irq_chip_data(i, gic);
-		set_irq_handler(i, handle_level_irq);
+		set_irq_handler(i, handle_fasteoi_irq);
 		set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
 	}
 
-- 
1.7.0.4

^ permalink raw reply related

* [PATCH v2 0/6] Migrate GIC to fasteoi flow control
From: Will Deacon @ 2011-02-28 13:33 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,

This is version 2 of the patch series originally posted here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/043083.html

Changes since v1:

	* Added plat-nomadik changes after related patch from Rabin
	* Fixed msm changes to call irq_eoi correctly
	* No longer in quoted-printable encoding (thanks Colin)

This is going to be a PITA to merge so any thoughts relating to that
are welcome.

Thanks,

Will


Will Deacon (6):
  ARM: gic: use handle_fasteoi_irq for SPIs
  ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
  ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
  ARM: s5pv310: update IRQ combiner to use EOI in parent chip
  ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
  ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip

 arch/arm/common/gic.c                |   23 +++++++++--------------
 arch/arm/mach-msm/gpio-v2.c          |    3 ++-
 arch/arm/mach-s5pv310/irq-combiner.c |    7 ++-----
 arch/arm/mach-tegra/gpio.c           |   17 +----------------
 arch/arm/plat-nomadik/gpio.c         |    2 ++
 arch/arm/plat-omap/gpio.c            |    5 ++++-
 6 files changed, 20 insertions(+), 37 deletions(-)

^ permalink raw reply

* Linux support for Samsung S3C2510A Processor
From: Ben Dooks @ 2011-02-28 13:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <AANLkTinBZCQ7Q+BaSxhm62pKiZHhmVWAgNzxnm5jBhZy@mail.gmail.com>

On Mon, Feb 28, 2011 at 06:52:15PM +0530, Madhavi Manchala wrote:
> Dear All,
> 
> Does Linux kernel supports the Samsung S3C2510A processor? Why am I
> asking this question is, when I looked into  the arch/arm/ directory I
> did not find anything which is related to Samsung S3C2510A processor.
> There are other directories like mach-s3c24xx and mach-s3c64xx
> directories, but not mach-s3c25xx.
> 
> Any ideas / hints will be appreciated.

I think this is a no-mmu version, and there is not a lot of ARM no-mmu
support at the moment.

-- 
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

^ permalink raw reply

* Linux support for Samsung S3C2510A Processor
From: Madhavi Manchala @ 2011-02-28 13:22 UTC (permalink / raw)
  To: linux-arm-kernel

Dear All,

Does Linux kernel supports the Samsung S3C2510A processor? Why am I
asking this question is, when I looked into  the arch/arm/ directory I
did not find anything which is related to Samsung S3C2510A processor.
There are other directories like mach-s3c24xx and mach-s3c64xx
directories, but not mach-s3c25xx.

Any ideas / hints will be appreciated.

Thanks and Regards,
Madhavi M.

^ permalink raw reply

* [patch 2/2] efika mx/sb: enable watchdog
From: Arnaud Patard (Rtp) @ 2011-02-28 13:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110228132132.654689676@rtp-net.org>

An embedded and charset-unspecified text was scrubbed...
Name: wdt.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/0e4de70b/attachment.ksh>

^ permalink raw reply

* [patch 1/2] mc13892: reboot on wdi event
From: Arnaud Patard (Rtp) @ 2011-02-28 13:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20110228132132.654689676@rtp-net.org>

An embedded and charset-unspecified text was scrubbed...
Name: mc13892_wdog_reboot.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/562257ca/attachment.ksh>

^ permalink raw reply

* [patch 0/2] Get watchdog reboot working on efika smartbook
From: Arnaud Patard (Rtp) @ 2011-02-28 13:21 UTC (permalink / raw)
  To: linux-arm-kernel


Hi,

With current patches in Sascha Hauer's tree, the efika smartbook is powering
off when rebooting. The cause of this bug is the default behaviour of the
mc13892 pmic. This patchset is configuring the pmic to reboot the system 
as expected by imx system.c (the reboot is done throught watchdog) and enables
the watchdog on the efika mx/sb systems.

Arnaud

^ permalink raw reply

* One quick question about SMP on ARM
From: rocky @ 2011-02-28 13:20 UTC (permalink / raw)
  To: linux-arm-kernel

Hi, all

I am puzzled these day on three issues for SMP ARM in terms of hardware:
1: Is MMU global or per cpu ?
2: Is MicroTLB/MainTLB global or per cpu ?

I read the code, each cpu has to set its own pgd base addr into TBBR0,so I draw the conclusion MMU is per cpu;
ASID is shared between each cpu, while when ASID rollover from 0xff back to 0x0, each cpu has to call local_flush_tlb_all to invalidate I/D tlb; Does that mean MicroTLB/MainTLB is also per cpu; then why all cpu shared ASID from 0x0~0xff ?


I am really confused about this ? any tips
Thanks

rocky









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110228/1bab0b01/attachment-0001.html>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox