[RFC][PATCH v1.0] Update and enhance TS-7XXX support

[RFC][PATCH v1.0] Update and enhance TS-7XXX support

[Christian Gagneraud]

This is the very first patch needed to uptdate and enhance support for the 
TS-72XX boards (See http://www.embeddedarm.com).

These few patches are the ones that affect all EP93XX platforms. As I'm sure 
they are not yet quite right for now, any comments are very welcome.

These patch have been collected and maintained mainly by Matthieu Crapet 
(http://mcrapet.free.fr/). Tests and contributions are made by the community 
on yahoo groups (http://tech.groups.yahoo.com/group/ts-7000).

Thanks to Russel King for spoting the bug that made the sparsemem patch useless.
Now we can enjoy a recent kernel with 64MB of RAM! :)

Patch set statistics:
 arch/arm/Kconfig                                |    1 +
 arch/arm/include/asm/memory.h                   |    2 ++
 arch/arm/kernel/head.S                          |    3 ++
 arch/arm/mach-ep93xx/Kconfig                    |   16 ++++++++++++
 arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h |   15 ++++++++++++
 arch/arm/mach-ep93xx/include/mach/memory.h      |   30 +++++++++++++++++++++++
 arch/arm/mm/proc-arm920.S                       |    3 ++
 7 files changed, 70 insertions(+), 0 deletions(-)

[PATCH v1.0 1/4] EP93XX: Allow to force nF bit in control reg

[Christian Gagneraud]

Usually this is set by the bootrom.  If it is not set, then the CPU
core will run from HCLK instead of FCLK, and performance will suffer.

Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
---

 arch/arm/mach-ep93xx/Kconfig |    9 +++++++++
 arch/arm/mm/proc-arm920.S    |    3 +++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index 9167c3d..303c4f8 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -7,6 +7,15 @@ config CRUNCH
 	help
 	  Enable kernel support for MaverickCrunch.
 
+config CR1_NFBIT
+       bool "Turn on nF bit in ControlRegister 1"
+       help
+         Say 'Y' here to force the nF bit on.  Usually this is set
+         by the bootrom.  If it is not set, then the CPU core will
+         run from HCLK instead of FCLK, and performance will suffer.
+         If you see BogoMIPS of about 1/4 of your CPU clock, try
+         turning this on; your performance should double.
+
 comment "EP93xx Platforms"
 
 choice
diff --git a/arch/arm/mm/proc-arm920.S b/arch/arm/mm/proc-arm920.S
index 914d688..9f030ee 100644
--- a/arch/arm/mm/proc-arm920.S
+++ b/arch/arm/mm/proc-arm920.S
@@ -373,6 +373,9 @@ __arm920_setup:
 	mrc	p15, 0, r0, c1, c0		@ get control register v4
 	bic	r0, r0, r5
 	orr	r0, r0, r6
+#ifdef CONFIG_CR1_NFBIT
+	orr     r0, r0, #0x40000000             @ set nF
+#endif
 	mov	pc, lr
 	.size	__arm920_setup, . - __arm920_setup
 

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Christian Gagneraud]

From: Matthieu Crapet <mcrapet@gmail.com>

In early days Technologic Systems fixed the 0x163 value in redboot
instead of 0x2a1, this patch allow to overwrite it.

Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
---

 arch/arm/kernel/head.S       |    3 +++
 arch/arm/mach-ep93xx/Kconfig |    7 +++++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 38ccbe1..c2e4514 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -82,6 +82,9 @@ ENTRY(stext)
 	bl	__lookup_processor_type		@ r5=procinfo r9=cpuid
 	movs	r10, r5				@ invalid processor (r5=0)?
 	beq	__error_p			@ yes, error 'p'
+#ifdef CONFIG_MACH_TS72XX_FORCE_MACHINEID
+	ldr r1, =0x2a1
+#endif
 	bl	__lookup_machine_type		@ r5=machinfo
 	movs	r8, r5				@ invalid machine (r5=0)?
 	beq	__error_a			@ yes, error 'a'
diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index 303c4f8..a909303 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -191,6 +191,13 @@ config EP93XX_EARLY_UART3
 
 endchoice
 
+config MACH_TS72XX_FORCE_MACHINEID
+	bool "Force Machine ID"
+	depends on MACH_TS72XX
+	help
+	  Say 'Y' here to force Machine ID to 0x2A1 (MACH_TYPE_TS72XX legacy value)
+	  In early days Technologic Systems fixed the 0x163 value in redboot.
+
 endmenu
 
 endif

[PATCH v1.0 3/4] EP93XX: Add more register definition

[Christian Gagneraud]

Add register definition for GPIO A,B,C and D data and data direction,
Security, Chip ID, ...

Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
---

 arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
index c5216fc..a5f721e 100644
--- a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
+++ b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
@@ -111,28 +111,42 @@
 #define EP93XX_I2S_BASE			EP93XX_APB_IOMEM(0x00020000)
 
 #define EP93XX_SECURITY_BASE		EP93XX_APB_IOMEM(0x00030000)
+#define EP93XX_SECURITY_REG(x)		(EP93XX_SECURITY_BASE + (x))
+#define EP93XX_SECURITY_UNIQID		EP93XX_SECURITY_REG(0x2440)
 
 #define EP93XX_GPIO_BASE		EP93XX_APB_IOMEM(0x00040000)
 #define EP93XX_GPIO_REG(x)		(EP93XX_GPIO_BASE + (x))
+#define EP93XX_GPIO_A_DATA		EP93XX_GPIO_REG(0x00)
+#define EP93XX_GPIO_B_DATA		EP93XX_GPIO_REG(0x04)
+#define EP93XX_GPIO_C_DATA		EP93XX_GPIO_REG(0x08)
+#define EP93XX_GPIO_D_DATA		EP93XX_GPIO_REG(0x0C)
+#define EP93XX_GPIO_A_DIR		EP93XX_GPIO_REG(0x10)
+#define EP93XX_GPIO_B_DIR		EP93XX_GPIO_REG(0x14)
+#define EP93XX_GPIO_C_DIR		EP93XX_GPIO_REG(0x18)
+#define EP93XX_GPIO_D_DIR		EP93XX_GPIO_REG(0x1C)
 #define EP93XX_GPIO_F_INT_TYPE1		EP93XX_GPIO_REG(0x4c)
 #define EP93XX_GPIO_F_INT_TYPE2		EP93XX_GPIO_REG(0x50)
 #define EP93XX_GPIO_F_INT_ACK		EP93XX_GPIO_REG(0x54)
 #define EP93XX_GPIO_F_INT_ENABLE	EP93XX_GPIO_REG(0x58)
 #define EP93XX_GPIO_F_INT_STATUS	EP93XX_GPIO_REG(0x5c)
+#define EP93XX_GPIO_F_INT_DEBOUNCE	EP93XX_GPIO_REG(0x64)
 #define EP93XX_GPIO_A_INT_TYPE1		EP93XX_GPIO_REG(0x90)
 #define EP93XX_GPIO_A_INT_TYPE2		EP93XX_GPIO_REG(0x94)
 #define EP93XX_GPIO_A_INT_ACK		EP93XX_GPIO_REG(0x98)
 #define EP93XX_GPIO_A_INT_ENABLE	EP93XX_GPIO_REG(0x9c)
+#define EP93XX_GPIO_A_INT_DEBOUNCE	EP93XX_GPIO_REG(0xa8)
 #define EP93XX_GPIO_A_INT_STATUS	EP93XX_GPIO_REG(0xa0)
 #define EP93XX_GPIO_B_INT_TYPE1		EP93XX_GPIO_REG(0xac)
 #define EP93XX_GPIO_B_INT_TYPE2		EP93XX_GPIO_REG(0xb0)
 #define EP93XX_GPIO_B_INT_ACK		EP93XX_GPIO_REG(0xb4)
 #define EP93XX_GPIO_B_INT_ENABLE	EP93XX_GPIO_REG(0xb8)
 #define EP93XX_GPIO_B_INT_STATUS	EP93XX_GPIO_REG(0xbc)
+#define EP93XX_GPIO_B_INT_DEBOUNCE	EP93XX_GPIO_REG(0xc4)
 #define EP93XX_GPIO_EEDRIVE		EP93XX_GPIO_REG(0xc8)
 
 #define EP93XX_AAC_BASE			EP93XX_APB_IOMEM(0x00080000)
 
+#define EP93XX_SPI_PHYS_BASE		EP93XX_APB_PHYS(0x000a0000)
 #define EP93XX_SPI_BASE			EP93XX_APB_IOMEM(0x000a0000)
 
 #define EP93XX_IRDA_BASE		EP93XX_APB_IOMEM(0x000b0000)
@@ -221,6 +235,7 @@
 #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV	(1<<16)
 #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN	(1<<15)
 #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV	(1<<0)
+#define EP93XX_SYSCON_CHIPID		EP93XX_SYSCON_REG(0x94)
 #define EP93XX_SYSCON_SWLOCK		EP93XX_SYSCON_REG(0xc0)
 
 #define EP93XX_WATCHDOG_BASE		EP93XX_APB_IOMEM(0x00140000)

[PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem

[Christian Gagneraud]

Tested on TS7260 with 64MB SDRAM (8*8MB). (Other boards will be tested
soon-ish). Special thanks to Matthieu Crappet, Charlie M.

I'm not sure what's the impact for other machine based on EP93XX, it's likely
that SECTION_SIZE_BITS and MAX_PHYSMEM_BITS needs to be define with default
values that suits everyone

PS: Has to be apply on top of this patch:
http://lists.infradead.org/pipermail/linux-arm-kernel/2009-October/001706.html

Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
---

 arch/arm/Kconfig                           |    1 +
 arch/arm/include/asm/memory.h              |    2 ++
 arch/arm/mach-ep93xx/include/mach/memory.h |   30 ++++++++++++++++++++++++++++
 3 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1c4119c..0f1d52f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -288,6 +288,7 @@ config ARCH_EP93XX
 	select CPU_ARM920T
 	select ARM_AMBA
 	select ARM_VIC
+	select ARCH_SPARSEMEM_ENABLE
 	select GENERIC_GPIO
 	select HAVE_CLK
 	select COMMON_CLKDEV
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index cefedf0..6be9d9b 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -125,8 +125,10 @@
  * private definitions which should NOT be used outside memory.h
  * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
  */
+#ifndef __phys_to_virt
 #define __virt_to_phys(x)	((x) - PAGE_OFFSET + PHYS_OFFSET)
 #define __phys_to_virt(x)	((x) - PHYS_OFFSET + PAGE_OFFSET)
+#endif
 
 /*
  * Convert a physical address to a Page Frame Number and back
diff --git a/arch/arm/mach-ep93xx/include/mach/memory.h b/arch/arm/mach-ep93xx/include/mach/memory.h
index 554064e..4cb3329 100644
--- a/arch/arm/mach-ep93xx/include/mach/memory.h
+++ b/arch/arm/mach-ep93xx/include/mach/memory.h
@@ -19,4 +19,34 @@
 #error "Kconfig bug: No EP93xx PHYS_OFFSET set"
 #endif
 
+#ifdef CONFIG_MACH_TS72XX
+/*
+ * Non-linear mapping like so:
+ * phys       => virt
+ * 0x00000000 => 0xc0000000
+ * 0x01000000 => 0xc1000000
+ * 0x04000000 => 0xc4000000
+ * 0x05000000 => 0xc5000000
+ * 0xe0000000 => 0xc8000000
+ * 0xe1000000 => 0xc9000000
+ * 0xe4000000 => 0xcc000000
+ * 0xe5000000 => 0xcd000000
+ *
+ * As suggested here: http://marc.info/?l=linux-arm&m=122754446724900&w=2
+ *
+ * Note that static inline functions won't work here because
+ * arch/arm/include/asm/memory.h uses "#ifndef __virt_to_phys" to check whether to
+ * use generic functions or not.
+ */
+#define __phys_to_virt(p)   \
+            (((p) & 0x07ffffff) | (((p) & 0xe0000000) ? 0x08000000 : 0) | PAGE_OFFSET)
+
+#define __virt_to_phys(v)   \
+            (((v) & 0x07ffffff) | (((v) & 0x08000000) ? 0xe0000000 : 0 ))
+
+#define SECTION_SIZE_BITS 24
+#define MAX_PHYSMEM_BITS 32
+
+#endif /* CONFIG_ARCH_TS72XX */
+
 #endif

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Matthieu Crapet]

Christian,

This can't be acked, it's pure hack!


Christian Gagneraud wrote:
> From: Matthieu Crapet <mcrapet@gmail.com>
>
> In early days Technologic Systems fixed the 0x163 value in redboot
> instead of 0x2a1, this patch allow to overwrite it.
>
> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
> ---
>
>  arch/arm/kernel/head.S       |    3 +++
>  arch/arm/mach-ep93xx/Kconfig |    7 +++++++
>  2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 38ccbe1..c2e4514 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -82,6 +82,9 @@ ENTRY(stext)
>  	bl	__lookup_processor_type		@ r5=procinfo r9=cpuid
>  	movs	r10, r5				@ invalid processor (r5=0)?
>  	beq	__error_p			@ yes, error 'p'
> +#ifdef CONFIG_MACH_TS72XX_FORCE_MACHINEID
> +	ldr r1, =0x2a1
> +#endif
>  	bl	__lookup_machine_type		@ r5=machinfo
>  	movs	r8, r5				@ invalid machine (r5=0)?
>  	beq	__error_a			@ yes, error 'a'
> diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
> index 303c4f8..a909303 100644
> --- a/arch/arm/mach-ep93xx/Kconfig
> +++ b/arch/arm/mach-ep93xx/Kconfig
> @@ -191,6 +191,13 @@ config EP93XX_EARLY_UART3
>  
>  endchoice
>  
> +config MACH_TS72XX_FORCE_MACHINEID
> +	bool "Force Machine ID"
> +	depends on MACH_TS72XX
> +	help
> +	  Say 'Y' here to force Machine ID to 0x2A1 (MACH_TYPE_TS72XX legacy value)
> +	  In early days Technologic Systems fixed the 0x163 value in redboot.
> +
>  endmenu
>  
>  endif
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>   

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Alexander Clouter]

Christian Gagneraud <cgagneraud@techworks.ie> wrote:
<
> From: Matthieu Crapet <mcrapet@gmail.com>
> 
> In early days Technologic Systems fixed the 0x163 value in redboot
> instead of 0x2a1, this patch allow to overwrite it.
> 
> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
> ---
> 
> arch/arm/kernel/head.S       |    3 +++
> arch/arm/mach-ep93xx/Kconfig |    7 +++++++
> 2 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 38ccbe1..c2e4514 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -82,6 +82,9 @@ ENTRY(stext)
>        bl      __lookup_processor_type         @ r5=procinfo r9=cpuid
>        movs    r10, r5                         @ invalid processor (r5=0)?
>        beq     __error_p                       @ yes, error 'p'
> +#ifdef CONFIG_MACH_TS72XX_FORCE_MACHINEID
> +       ldr r1, =0x2a1
> +#endif
>        bl      __lookup_machine_type           @ r5=machinfo
>        movs    r8, r5                          @ invalid machine (r5=0)?
>        beq     __error_a                       @ yes, error 'a'
>
Brace yourself for Russell giving you a FPSesque "DENIED" here.  I 
suggested a similar patch over a year ago for my TS78XX board and got 
(rightly) gunned down. :)

If you are compiling your own kernels the best solution I have seen[1] 
is to simply patch the kernel image with:

http://ts78xx.digriz.org.uk/booting-woes

You will need to use the following devio line instead:

devio 'wl 0xe3a01c02,4' 'wl 0xe38110a1,4'

Cheers

[1] something I first saw on the NAS Buffolo site but then heavily 
	prompted by the orion5x Debian installer maintainers

-- 
Alexander Clouter
.sigmonster says: Acceptance testing:
                  	An unsuccessful attempt to find bugs.

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Russell King - ARM Linux]

On Sun, Oct 04, 2009 at 02:14:24AM +0100, Christian Gagneraud wrote:
> In early days Technologic Systems fixed the 0x163 value in redboot
> instead of 0x2a1, this patch allow to overwrite it.

This is where ensuring that the machine number is not hard coded into
the boot loader, having it as a script-settable variable or a run-time
configuration option is a win-win situation.

Patch is not suitable for the mainline kernel.

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Christian Gagneraud]

Russell King - ARM Linux wrote:
> On Sun, Oct 04, 2009 at 02:14:24AM +0100, Christian Gagneraud wrote:
>> In early days Technologic Systems fixed the 0x163 value in redboot
>> instead of 0x2a1, this patch allow to overwrite it.
> 
> This is where ensuring that the machine number is not hard coded into
> the boot loader, having it as a script-settable variable or a run-time
> configuration option is a win-win situation.
> 
> Patch is not suitable for the mainline kernel.

OK, fair enough. At least I tried! ;)

Chris.


> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Bill Gatliff]

Alexander Clouter wrote:
>
> [1] something I first saw on the NAS Buffolo site but then heavily 
> 	prompted by the orion5x Debian installer maintainers
>
>   

Yea, a lot of the IOP machines that use RedBoot have to do this junk 
too...  Like the N4100.  :(

I mean, I could "lie" and say that I'm an N2100.  In fact, that plus a 
big comment in the machine descriptor that says "the crappy bootloader 
for this board passes the wrong machine identifier, so we lie to it in 
order to bring the system up" might be a better way to deal with it than 
an out-of-mainline asm hack that keeps coming back to you with each 
kernel release.

Could you tolerate that, rmk?  Just one commented line in the machine 
descriptor that looks kind of strange?


b.g.

-- 
Bill Gatliff
bgat at billgatliff.com

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Bill Gatliff]

Alexander Clouter wrote:
> Brace yourself for Russell giving you a FPSesque "DENIED" here.


Does that stand for "First Person Shooter"?  Yes, that would be a NAK 
that would leave a mark.  :)


b.g.

-- 
Bill Gatliff
bgat at billgatliff.com

[PATCH v1.0 3/4] EP93XX: Add more register definition

[Ryan Mallon]

Christian Gagneraud wrote:
> Add register definition for GPIO A,B,C and D data and data direction,
> Security, Chip ID, ...
> 
> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
> ---
> 
>  arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h |   15 +++++++++++++++
>  1 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
> index c5216fc..a5f721e 100644
> --- a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
> +++ b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
> @@ -111,28 +111,42 @@
>  #define EP93XX_I2S_BASE			EP93XX_APB_IOMEM(0x00020000)
>  
>  #define EP93XX_SECURITY_BASE		EP93XX_APB_IOMEM(0x00030000)
> +#define EP93XX_SECURITY_REG(x)		(EP93XX_SECURITY_BASE + (x))
> +#define EP93XX_SECURITY_UNIQID		EP93XX_SECURITY_REG(0x2440)
>  
>  #define EP93XX_GPIO_BASE		EP93XX_APB_IOMEM(0x00040000)
>  #define EP93XX_GPIO_REG(x)		(EP93XX_GPIO_BASE + (x))
> +#define EP93XX_GPIO_A_DATA		EP93XX_GPIO_REG(0x00)
> +#define EP93XX_GPIO_B_DATA		EP93XX_GPIO_REG(0x04)
> +#define EP93XX_GPIO_C_DATA		EP93XX_GPIO_REG(0x08)
> +#define EP93XX_GPIO_D_DATA		EP93XX_GPIO_REG(0x0C)
> +#define EP93XX_GPIO_A_DIR		EP93XX_GPIO_REG(0x10)
> +#define EP93XX_GPIO_B_DIR		EP93XX_GPIO_REG(0x14)
> +#define EP93XX_GPIO_C_DIR		EP93XX_GPIO_REG(0x18)
> +#define EP93XX_GPIO_D_DIR		EP93XX_GPIO_REG(0x1C)

Are these being used for something? EP93xx already has full gpiolib
support, so there should be no need to define these registers.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[H Hartley Sweeten]

On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote:
> From: Matthieu Crapet <mcrapet@gmail.com>
> 
> In early days Technologic Systems fixed the 0x163 value in redboot
> instead of 0x2a1, this patch allow to overwrite it.
> 
> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>

As others have already pointed out, this is a pure hack and not
suitable for mainline.

The bootloader for systems that needs this really should be updated.
Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based
system and doesn't even have a platform init in mainline.

NAK.

Regards,
Hartley

[PATCH v1.0 3/4] EP93XX: Add more register definition

[H Hartley Sweeten]

On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote:
> Add register definition for GPIO A,B,C and D data and data direction,
> Security, Chip ID, ...
> 
> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
> ---
> 
>  arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h |   15 +++++++++++++++
>  1 files changed, 15 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
> index c5216fc..a5f721e 100644
> --- a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
> +++ b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
> @@ -111,28 +111,42 @@
>  #define EP93XX_I2S_BASE			EP93XX_APB_IOMEM(0x00020000)
>  
>  #define EP93XX_SECURITY_BASE		EP93XX_APB_IOMEM(0x00030000)
> +#define EP93XX_SECURITY_REG(x)		(EP93XX_SECURITY_BASE + (x))
> +#define EP93XX_SECURITY_UNIQID		EP93XX_SECURITY_REG(0x2440)
>  
>  #define EP93XX_GPIO_BASE		EP93XX_APB_IOMEM(0x00040000)
>  #define EP93XX_GPIO_REG(x)		(EP93XX_GPIO_BASE + (x))
> +#define EP93XX_GPIO_A_DATA		EP93XX_GPIO_REG(0x00)
> +#define EP93XX_GPIO_B_DATA		EP93XX_GPIO_REG(0x04)
> +#define EP93XX_GPIO_C_DATA		EP93XX_GPIO_REG(0x08)
> +#define EP93XX_GPIO_D_DATA		EP93XX_GPIO_REG(0x0C)
> +#define EP93XX_GPIO_A_DIR		EP93XX_GPIO_REG(0x10)
> +#define EP93XX_GPIO_B_DIR		EP93XX_GPIO_REG(0x14)
> +#define EP93XX_GPIO_C_DIR		EP93XX_GPIO_REG(0x18)
> +#define EP93XX_GPIO_D_DIR		EP93XX_GPIO_REG(0x1C)
>  #define EP93XX_GPIO_F_INT_TYPE1		EP93XX_GPIO_REG(0x4c)
>  #define EP93XX_GPIO_F_INT_TYPE2		EP93XX_GPIO_REG(0x50)
>  #define EP93XX_GPIO_F_INT_ACK		EP93XX_GPIO_REG(0x54)
>  #define EP93XX_GPIO_F_INT_ENABLE	EP93XX_GPIO_REG(0x58)
>  #define EP93XX_GPIO_F_INT_STATUS	EP93XX_GPIO_REG(0x5c)
> +#define EP93XX_GPIO_F_INT_DEBOUNCE	EP93XX_GPIO_REG(0x64)
>  #define EP93XX_GPIO_A_INT_TYPE1		EP93XX_GPIO_REG(0x90)
>  #define EP93XX_GPIO_A_INT_TYPE2		EP93XX_GPIO_REG(0x94)
>  #define EP93XX_GPIO_A_INT_ACK		EP93XX_GPIO_REG(0x98)
>  #define EP93XX_GPIO_A_INT_ENABLE	EP93XX_GPIO_REG(0x9c)
> +#define EP93XX_GPIO_A_INT_DEBOUNCE	EP93XX_GPIO_REG(0xa8)
>  #define EP93XX_GPIO_A_INT_STATUS	EP93XX_GPIO_REG(0xa0)
>  #define EP93XX_GPIO_B_INT_TYPE1		EP93XX_GPIO_REG(0xac)
>  #define EP93XX_GPIO_B_INT_TYPE2		EP93XX_GPIO_REG(0xb0)
>  #define EP93XX_GPIO_B_INT_ACK		EP93XX_GPIO_REG(0xb4)
>  #define EP93XX_GPIO_B_INT_ENABLE	EP93XX_GPIO_REG(0xb8)
>  #define EP93XX_GPIO_B_INT_STATUS	EP93XX_GPIO_REG(0xbc)
> +#define EP93XX_GPIO_B_INT_DEBOUNCE	EP93XX_GPIO_REG(0xc4)
>  #define EP93XX_GPIO_EEDRIVE		EP93XX_GPIO_REG(0xc8)

The ep93xx has been converted to full gpiolib support.  There
is no need for the GPIO register defines.  Also, it's a bad
idea to have them since anything using these will be "breaking"
the gpiolib API.

If you need to use the gpio debounce the ep93xx core already has
support for this.  Please see ep93xx_gpio_int_debounce() in
arch/arm/mach-ep93xx/core.c.

On a side note.  What tree did you base this patch on?  The
EP93XX_GPIO_EEDRIVE is not currently in mainline.

>  #define EP93XX_AAC_BASE			EP93XX_APB_IOMEM(0x00080000)
>  
> +#define EP93XX_SPI_PHYS_BASE		EP93XX_APB_PHYS(0x000a0000)
>  #define EP93XX_SPI_BASE			EP93XX_APB_IOMEM(0x000a0000)
>  
>  #define EP93XX_IRDA_BASE		EP93XX_APB_IOMEM(0x000b0000)
> @@ -221,6 +235,7 @@
>  #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV	(1<<16)
>  #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN	(1<<15)
>  #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV	(1<<0)
> +#define EP93XX_SYSCON_CHIPID		EP93XX_SYSCON_REG(0x94)
>  #define EP93XX_SYSCON_SWLOCK		EP93XX_SYSCON_REG(0xc0)
>  
>  #define EP93XX_WATCHDOG_BASE		EP93XX_APB_IOMEM(0x00140000)

NAK.

Regards,
Hartley

[PATCH v1.0 3/4] EP93XX: Add more register definition

[Christian Gagneraud]

H Hartley Sweeten wrote:
> On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote:
>> Add register definition for GPIO A,B,C and D data and data direction,
>> Security, Chip ID, ...
>>
>> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
>> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
>> ---
>>
>>  arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h |   15 +++++++++++++++
>>  1 files changed, 15 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
>> index c5216fc..a5f721e 100644
>> --- a/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
>> +++ b/arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
>> @@ -111,28 +111,42 @@
>>  #define EP93XX_I2S_BASE			EP93XX_APB_IOMEM(0x00020000)
>>  
>>  #define EP93XX_SECURITY_BASE		EP93XX_APB_IOMEM(0x00030000)
>> +#define EP93XX_SECURITY_REG(x)		(EP93XX_SECURITY_BASE + (x))
>> +#define EP93XX_SECURITY_UNIQID		EP93XX_SECURITY_REG(0x2440)
>>  
>>  #define EP93XX_GPIO_BASE		EP93XX_APB_IOMEM(0x00040000)
>>  #define EP93XX_GPIO_REG(x)		(EP93XX_GPIO_BASE + (x))
>> +#define EP93XX_GPIO_A_DATA		EP93XX_GPIO_REG(0x00)
>> +#define EP93XX_GPIO_B_DATA		EP93XX_GPIO_REG(0x04)
>> +#define EP93XX_GPIO_C_DATA		EP93XX_GPIO_REG(0x08)
>> +#define EP93XX_GPIO_D_DATA		EP93XX_GPIO_REG(0x0C)
>> +#define EP93XX_GPIO_A_DIR		EP93XX_GPIO_REG(0x10)
>> +#define EP93XX_GPIO_B_DIR		EP93XX_GPIO_REG(0x14)
>> +#define EP93XX_GPIO_C_DIR		EP93XX_GPIO_REG(0x18)
>> +#define EP93XX_GPIO_D_DIR		EP93XX_GPIO_REG(0x1C)
>>  #define EP93XX_GPIO_F_INT_TYPE1		EP93XX_GPIO_REG(0x4c)
>>  #define EP93XX_GPIO_F_INT_TYPE2		EP93XX_GPIO_REG(0x50)
>>  #define EP93XX_GPIO_F_INT_ACK		EP93XX_GPIO_REG(0x54)
>>  #define EP93XX_GPIO_F_INT_ENABLE	EP93XX_GPIO_REG(0x58)
>>  #define EP93XX_GPIO_F_INT_STATUS	EP93XX_GPIO_REG(0x5c)
>> +#define EP93XX_GPIO_F_INT_DEBOUNCE	EP93XX_GPIO_REG(0x64)
>>  #define EP93XX_GPIO_A_INT_TYPE1		EP93XX_GPIO_REG(0x90)
>>  #define EP93XX_GPIO_A_INT_TYPE2		EP93XX_GPIO_REG(0x94)
>>  #define EP93XX_GPIO_A_INT_ACK		EP93XX_GPIO_REG(0x98)
>>  #define EP93XX_GPIO_A_INT_ENABLE	EP93XX_GPIO_REG(0x9c)
>> +#define EP93XX_GPIO_A_INT_DEBOUNCE	EP93XX_GPIO_REG(0xa8)
>>  #define EP93XX_GPIO_A_INT_STATUS	EP93XX_GPIO_REG(0xa0)
>>  #define EP93XX_GPIO_B_INT_TYPE1		EP93XX_GPIO_REG(0xac)
>>  #define EP93XX_GPIO_B_INT_TYPE2		EP93XX_GPIO_REG(0xb0)
>>  #define EP93XX_GPIO_B_INT_ACK		EP93XX_GPIO_REG(0xb4)
>>  #define EP93XX_GPIO_B_INT_ENABLE	EP93XX_GPIO_REG(0xb8)
>>  #define EP93XX_GPIO_B_INT_STATUS	EP93XX_GPIO_REG(0xbc)
>> +#define EP93XX_GPIO_B_INT_DEBOUNCE	EP93XX_GPIO_REG(0xc4)
>>  #define EP93XX_GPIO_EEDRIVE		EP93XX_GPIO_REG(0xc8)
> 
> The ep93xx has been converted to full gpiolib support.  There
> is no need for the GPIO register defines.  Also, it's a bad
> idea to have them since anything using these will be "breaking"
> the gpiolib API.
> 
> If you need to use the gpio debounce the ep93xx core already has
> support for this.  Please see ep93xx_gpio_int_debounce() in
> arch/arm/mach-ep93xx/core.c.

This was needed for a GPIO based keypad. I will have a look on how to 
convert it to use GPIO lib.

> 
> On a side note.  What tree did you base this patch on?  The
> EP93XX_GPIO_EEDRIVE is not currently in mainline.

Linus tree + a couple of pending patches from this ML.

> 
>>  #define EP93XX_AAC_BASE			EP93XX_APB_IOMEM(0x00080000)
>>  
>> +#define EP93XX_SPI_PHYS_BASE		EP93XX_APB_PHYS(0x000a0000)
>>  #define EP93XX_SPI_BASE			EP93XX_APB_IOMEM(0x000a0000)
>>  
>>  #define EP93XX_IRDA_BASE		EP93XX_APB_IOMEM(0x000b0000)
>> @@ -221,6 +235,7 @@
>>  #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV	(1<<16)
>>  #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN	(1<<15)
>>  #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV	(1<<0)
>> +#define EP93XX_SYSCON_CHIPID		EP93XX_SYSCON_REG(0x94)
>>  #define EP93XX_SYSCON_SWLOCK		EP93XX_SYSCON_REG(0xc0)
>>  
>>  #define EP93XX_WATCHDOG_BASE		EP93XX_APB_IOMEM(0x00140000)
> 
> NAK.

OK for GPIO and SPI, but what about the SECURITY and SYSCON_CHIPID 
stuff? The idea behind that is to extend in some way board/cpu 
specific information.
For example the TS-7XXX boards comes with some options, there is 
currently a patch that add a /proc entry to display cpu and board 
information (CPU version, CPLD/FPGA firmware version, state of 
configuration jumpers, HW options installed, ...)


Regards,
Chris

> 
> Regards,
> Hartley
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Christian Gagneraud]

H Hartley Sweeten wrote:
> On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote:
>> From: Matthieu Crapet <mcrapet@gmail.com>
>>
>> In early days Technologic Systems fixed the 0x163 value in redboot
>> instead of 0x2a1, this patch allow to overwrite it.
>>
>> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
>> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
> 
> As others have already pointed out, this is a pure hack and not
> suitable for mainline.
> 
> The bootloader for systems that needs this really should be updated.
> Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based
> system and doesn't even have a platform init in mainline.

I see your point, but what if the bootloader can't be updated? Does 
that mean that people using these boards will have to bother with 
applying patches on mainline kernel for ever?
Can't we find a way to address this issue, I'm pretty sure this is not 
the only board that need this kind of asm hack.

Regards,
Chris

> 
> NAK.
> 
> Regards,
> Hartley

[PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem

[Christian Gagneraud]

Hi,

What people think about enabling sparsemem on EP93XX? I know this 
patch as it is will break all but this board.

Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that 
will suit all the supported boards?

Regards,
Chris

Christian Gagneraud wrote:
> Tested on TS7260 with 64MB SDRAM (8*8MB). (Other boards will be tested
> soon-ish). Special thanks to Matthieu Crappet, Charlie M.
> 
> I'm not sure what's the impact for other machine based on EP93XX, it's likely
> that SECTION_SIZE_BITS and MAX_PHYSMEM_BITS needs to be define with default
> values that suits everyone
> 
> PS: Has to be apply on top of this patch:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2009-October/001706.html
> 
> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
> ---
> 
>  arch/arm/Kconfig                           |    1 +
>  arch/arm/include/asm/memory.h              |    2 ++
>  arch/arm/mach-ep93xx/include/mach/memory.h |   30 ++++++++++++++++++++++++++++
>  3 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 1c4119c..0f1d52f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -288,6 +288,7 @@ config ARCH_EP93XX
>  	select CPU_ARM920T
>  	select ARM_AMBA
>  	select ARM_VIC
> +	select ARCH_SPARSEMEM_ENABLE
>  	select GENERIC_GPIO
>  	select HAVE_CLK
>  	select COMMON_CLKDEV
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index cefedf0..6be9d9b 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -125,8 +125,10 @@
>   * private definitions which should NOT be used outside memory.h
>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
>   */
> +#ifndef __phys_to_virt
>  #define __virt_to_phys(x)	((x) - PAGE_OFFSET + PHYS_OFFSET)
>  #define __phys_to_virt(x)	((x) - PHYS_OFFSET + PAGE_OFFSET)
> +#endif
>  
>  /*
>   * Convert a physical address to a Page Frame Number and back
> diff --git a/arch/arm/mach-ep93xx/include/mach/memory.h b/arch/arm/mach-ep93xx/include/mach/memory.h
> index 554064e..4cb3329 100644
> --- a/arch/arm/mach-ep93xx/include/mach/memory.h
> +++ b/arch/arm/mach-ep93xx/include/mach/memory.h
> @@ -19,4 +19,34 @@
>  #error "Kconfig bug: No EP93xx PHYS_OFFSET set"
>  #endif
>  
> +#ifdef CONFIG_MACH_TS72XX
> +/*
> + * Non-linear mapping like so:
> + * phys       => virt
> + * 0x00000000 => 0xc0000000
> + * 0x01000000 => 0xc1000000
> + * 0x04000000 => 0xc4000000
> + * 0x05000000 => 0xc5000000
> + * 0xe0000000 => 0xc8000000
> + * 0xe1000000 => 0xc9000000
> + * 0xe4000000 => 0xcc000000
> + * 0xe5000000 => 0xcd000000
> + *
> + * As suggested here: http://marc.info/?l=linux-arm&m=122754446724900&w=2
> + *
> + * Note that static inline functions won't work here because
> + * arch/arm/include/asm/memory.h uses "#ifndef __virt_to_phys" to check whether to
> + * use generic functions or not.
> + */
> +#define __phys_to_virt(p)   \
> +            (((p) & 0x07ffffff) | (((p) & 0xe0000000) ? 0x08000000 : 0) | PAGE_OFFSET)
> +
> +#define __virt_to_phys(v)   \
> +            (((v) & 0x07ffffff) | (((v) & 0x08000000) ? 0xe0000000 : 0 ))
> +
> +#define SECTION_SIZE_BITS 24
> +#define MAX_PHYSMEM_BITS 32
> +
> +#endif /* CONFIG_ARCH_TS72XX */
> +
>  #endif
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Alexander Clouter]

Christian Gagneraud <cgagneraud@techworks.ie> wrote:
>
> H Hartley Sweeten wrote:
>
>> On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote:
>>> From: Matthieu Crapet <mcrapet@gmail.com>
>>>
>>> In early days Technologic Systems fixed the 0x163 value in redboot
>>> instead of 0x2a1, this patch allow to overwrite it.
>>>
>>> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
>>> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
>> 
>> As others have already pointed out, this is a pure hack and not
>> suitable for mainline.
>> 
>> The bootloader for systems that needs this really should be updated.
>> Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based
>> system and doesn't even have a platform init in mainline.
> 
> I see your point, but what if the bootloader can't be updated? Does 
> that mean that people using these boards will have to bother with 
> applying patches on mainline kernel for ever?
>
The price for buying broken hardware and not grumbling at the venduh.

Fortunately I have already grumbled at TS in the past and they promised 
to fix this for their new boards.

> Can't we find a way to address this issue, I'm pretty sure this is not 
> the only board that need this kind of asm hack.
> 
It's not the only board, but as the 'asm hack' is something that can be 
done in userspace as a post-kernel compiling process.  You have to do 
<something> to get it onto the FLASH of the board, no harm inserting a 
very trivial step.

The moment you start being 'liberal' with machine id's from borkened 
bootloaders you remove the point of having them altogether.  Without 
them you cannot have the same kernel boot *every* ep93xx SoC...

Cheers

-- 
Alexander Clouter
.sigmonster says: BOFH excuse #447:
                  According to Microsoft, it's by design

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Mikael Pettersson]

Christian Gagneraud writes:
 > H Hartley Sweeten wrote:
 > > On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote:
 > >> From: Matthieu Crapet <mcrapet@gmail.com>
 > >>
 > >> In early days Technologic Systems fixed the 0x163 value in redboot
 > >> instead of 0x2a1, this patch allow to overwrite it.
 > >>
 > >> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
 > >> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
 > > 
 > > As others have already pointed out, this is a pure hack and not
 > > suitable for mainline.
 > > 
 > > The bootloader for systems that needs this really should be updated.
 > > Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based
 > > system and doesn't even have a platform init in mainline.
 > 
 > I see your point, but what if the bootloader can't be updated? Does 
 > that mean that people using these boards will have to bother with 
 > applying patches on mainline kernel for ever?
 > Can't we find a way to address this issue, I'm pretty sure this is not 
 > the only board that need this kind of asm hack.

All you need to do is to wrap the kernel binary image with
a small shim that corrects the Machine ID in r1. devio can
do that, as can (I think) printf(1).

No need to replace the bootloader or hack the kernel.

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Marek Vasut]

Dne Po 5. ??jna 2009 17:15:55 Mikael Pettersson napsal(a):
> Christian Gagneraud writes:
>  > H Hartley Sweeten wrote:
>  > > On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote:
>  > >> From: Matthieu Crapet <mcrapet@gmail.com>
>  > >>
>  > >> In early days Technologic Systems fixed the 0x163 value in redboot
>  > >> instead of 0x2a1, this patch allow to overwrite it.
>  > >>
>  > >> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
>  > >> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
>  > >
>  > > As others have already pointed out, this is a pure hack and not
>  > > suitable for mainline.
>  > >
>  > > The bootloader for systems that needs this really should be updated.
>  > > Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based
>  > > system and doesn't even have a platform init in mainline.
>  >
>  > I see your point, but what if the bootloader can't be updated? Does
>  > that mean that people using these boards will have to bother with
>  > applying patches on mainline kernel for ever?
>  > Can't we find a way to address this issue, I'm pretty sure this is not
>  > the only board that need this kind of asm hack.
> 
> All you need to do is to wrap the kernel binary image with
> a small shim that corrects the Machine ID in r1. devio can
> do that, as can (I think) printf(1).
> 
> No need to replace the bootloader or hack the kernel.

devio 'wl 0xe59f1000,4' 'wl 0xe28ff004,4' 'wl $MACH,4' >> id.bin
cat id.bin zImage > zImage.crippled

Like this (I used this on Toradex board where those morons fixed machine id too).
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH v1.0 3/4] EP93XX: Add more register definition

[H Hartley Sweeten]

On Monday, October 05, 2009 5:06 AM, Christian Gagneraud wrote:
>> The ep93xx has been converted to full gpiolib support.  There
>> is no need for the GPIO register defines.  Also, it's a bad
>> idea to have them since anything using these will be "breaking"
>> the gpiolib API.
>> 
>> If you need to use the gpio debounce the ep93xx core already has
>> support for this.  Please see ep93xx_gpio_int_debounce() in
>> arch/arm/mach-ep93xx/core.c.
>
> This was needed for a GPIO based keypad. I will have a look on how to 
> convert it to use GPIO lib.

If you are referring to Matthieu Crapet's 0017-ts72xx_dio_keypad.patch,
that patch appears to have already been converted over to use gpiolib.

Regardless, the in tree matrix_keypad.c driver will probably work
instead of introducing another GPIO based keypad driver.

>> On a side note.  What tree did you base this patch on?  The
>> EP93XX_GPIO_EEDRIVE is not currently in mainline.
>
> Linus tree + a couple of pending patches from this ML.

Bad form.  Pending patches could always be dropped at some point.  You
should only base your patches on published trees'.

>>>  #define EP93XX_AAC_BASE			EP93XX_APB_IOMEM(0x00080000)
>>>  
>>> +#define EP93XX_SPI_PHYS_BASE		EP93XX_APB_PHYS(0x000a0000)
>>>  #define EP93XX_SPI_BASE			EP93XX_APB_IOMEM(0x000a0000)
>>>  
>>>  #define EP93XX_IRDA_BASE		EP93XX_APB_IOMEM(0x000b0000)
>>> @@ -221,6 +235,7 @@
>>>  #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV	(1<<16)
>>>  #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN	(1<<15)
>>>  #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV	(1<<0)
>>> +#define EP93XX_SYSCON_CHIPID		EP93XX_SYSCON_REG(0x94)
>>>  #define EP93XX_SYSCON_SWLOCK		EP93XX_SYSCON_REG(0xc0)
>>>  
>>>  #define EP93XX_WATCHDOG_BASE		EP93XX_APB_IOMEM(0x00140000)
>> 
>> NAK.
>
> OK for GPIO and SPI, but what about the SECURITY and SYSCON_CHIPID 
> stuff? The idea behind that is to extend in some way board/cpu 
> specific information.
> For example the TS-7XXX boards comes with some options, there is 
> currently a patch that add a /proc entry to display cpu and board 
> information (CPU version, CPLD/FPGA firmware version, state of 
> configuration jumpers, HW options installed, ...)

I think you are referring to Matthieu's 0006-ep93xx_cpuinfo.patch.
This is IMHO a hack.  I have another approach for this that I proposed
to Russell a while ago.  He had some concern's about breaking userspace
tools at that time.  I am planning on resubmitting my patch shortly
in order to get more opinions.

Please hold off on this for a bit.

Regards,
Hartley

[PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem

[H Hartley Sweeten]

On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote:
> Hi,
> 
> What people think about enabling sparsemem on EP93XX? I know this 
> patch as it is will break all but this board.
> 
> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that 
> will suit all the supported boards?

With sparsemem enabled what is your memory detected during boot?  For
instance on my ep9307 based system with flatmem I get:

Memory: 32MB 32MB = 64MB total
Memory: 44552KB available (3452K code, 254K data, 124K init, 0K highmem)

And cat /proc/iomem shows:

c0000000-c1ffffff : System RAM
  c0027000-c0385fff : Kernel text
  c03a0000-c03df88f : Kernel data
c4000000-c5ffffff : System RAM

So the kernel finds two 32MB chunks which is what the bootloader passed
in the ATAGS.  And the addresses match what was passed.

What is your intended result by switching to sparsemem?

I have also messed with sparsemem and I get the same results as above
with it enabled.  I don't see any real reason to switch to sparsemem.

The _only_ reason I can see is if a system has more than 8 banks of
memory.  I think that is the current limit for flatmem support in the
kernel.  There are only two configuration I know of that can cause this
on the ep93xx when only on chip select is used:

512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 0 -> 16 banks
512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 0 -> 16 banks

Both of these configuration can be "fixed" by having the bootloader set
the SROMLL bit = 1. 

512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 1 -> 8 banks
512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 1 -> 1 bank

Please refer to the following document for more information:

http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf

Regards,
Hartley

[PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem

[Christian Gagneraud]

H Hartley Sweeten wrote:
> On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote:
>> Hi,
>>
>> What people think about enabling sparsemem on EP93XX? I know this 
>> patch as it is will break all but this board.
>>
>> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that 
>> will suit all the supported boards?
> 
> With sparsemem enabled what is your memory detected during boot?  For
> instance on my ep9307 based system with flatmem I get:
> 
> Memory: 32MB 32MB = 64MB total
> Memory: 44552KB available (3452K code, 254K data, 124K init, 0K highmem)
           ^^^^^
Are you missing 16MB?

Here is what i get with sparsemem:

Memory: 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB = 64MB total 

Memory: 63264KB available (1252K code, 231K data, 64K init, 0K highmem)

> And cat /proc/iomem shows:
> 
> c0000000-c1ffffff : System RAM
>   c0027000-c0385fff : Kernel text
>   c03a0000-c03df88f : Kernel data
> c4000000-c5ffffff : System RAM


00000000-007fffff : System RAM 

   00020000-00276fff : Kernel text 

   00278000-002c1923 : Kernel data 

01000000-017fffff : System RAM 

04000000-047fffff : System RAM 

05000000-057fffff : System RAM
80010000-8001ffff : ep93xx-eth 

   80010000-8001ffff : ep93xx-eth 

80020000-80020fff : ep93xx-ohci 

808c0000-808c0fff : apb:uart1 

   808c0000-808c003f : uart-pl010 

808d0000-808d0fff : apb:uart2 

   808d0000-808d003f : uart-pl010 

808e0000-808e0fff : apb:uart3 

   808e0000-808e003f : uart-pl010 

80920000-8092010b : ep93xx-rtc
e0000000-e07fffff : System RAM 

e1000000-e17fffff : System RAM 

e4000000-e47fffff : System RAM 

e5000000-e57fffff : System RAM


For boards shipped with 32MB, there's one 32MB chip on SD_CS3 that 
shows at 0x00000000, for boards shipped with 64MB there's another 32MB 
chip on SD_CS2 which pop up at 0xe0000000

That's for the models that offer 32 or 64MB, but TS have other models 
that offer 64 or 128MB, these boards are designed the same way: 1 64MB 
chip on SD_CS3 and optional a second 64MB chip on SD_CS2.
I was told that in that case 16 banks needed to be define (and btw it 
couldn't be handled , I didn't check it yet.

Before sparsemem, we had to use discontigmem (and patch it),now with 
parsemem there's no needs for such a thing anymore, the only needed 
bits are 4 #define.


> 
> So the kernel finds two 32MB chunks which is what the bootloader passed
> in the ATAGS.  And the addresses match what was passed.
> 
> What is your intended result by switching to sparsemem?
> 
> I have also messed with sparsemem and I get the same results as above
> with it enabled.  I don't see any real reason to switch to sparsemem.
> 
> The _only_ reason I can see is if a system has more than 8 banks of
> memory.  I think that is the current limit for flatmem support in the
> kernel.  There are only two configuration I know of that can cause this
> on the ep93xx when only on chip select is used:
> 
> 512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 0 -> 16 banks
> 512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 0 -> 16 banks
> 
> Both of these configuration can be "fixed" by having the bootloader set
> the SROMLL bit = 1. 
> 
> 512 Mbit (16-bit wide device) = 64 MBytes with SROMLL = 1 -> 8 banks
> 512 Mbit (2 x 16-bit wide device) = 128 Mbytes with SROMLL = 1 -> 1 bank
> 
> Please refer to the following document for more information:
> 
> http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf

Interesting, thank you.

Regards,
Chris

> 
> Regards,
> Hartley

[PATCH v1.0 3/4] EP93XX: Add more register definition

[Christian Gagneraud]

H Hartley Sweeten wrote:
> On Monday, October 05, 2009 5:06 AM, Christian Gagneraud wrote:
>>> The ep93xx has been converted to full gpiolib support.  There
>>> is no need for the GPIO register defines.  Also, it's a bad
>>> idea to have them since anything using these will be "breaking"
>>> the gpiolib API.
>>>
>>> If you need to use the gpio debounce the ep93xx core already has
>>> support for this.  Please see ep93xx_gpio_int_debounce() in
>>> arch/arm/mach-ep93xx/core.c.
>> This was needed for a GPIO based keypad. I will have a look on how to 
>> convert it to use GPIO lib.
> 
> If you are referring to Matthieu Crapet's 0017-ts72xx_dio_keypad.patch,
> that patch appears to have already been converted over to use gpiolib.
> 
> Regardless, the in tree matrix_keypad.c driver will probably work
> instead of introducing another GPIO based keypad driver.
> 
>>> On a side note.  What tree did you base this patch on?  The
>>> EP93XX_GPIO_EEDRIVE is not currently in mainline.
>> Linus tree + a couple of pending patches from this ML.
> 
> Bad form.  Pending patches could always be dropped at some point.  You
> should only base your patches on published trees'.
> 
>>>>  #define EP93XX_AAC_BASE			EP93XX_APB_IOMEM(0x00080000)
>>>>  
>>>> +#define EP93XX_SPI_PHYS_BASE		EP93XX_APB_PHYS(0x000a0000)
>>>>  #define EP93XX_SPI_BASE			EP93XX_APB_IOMEM(0x000a0000)
>>>>  
>>>>  #define EP93XX_IRDA_BASE		EP93XX_APB_IOMEM(0x000b0000)
>>>> @@ -221,6 +235,7 @@
>>>>  #define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV	(1<<16)
>>>>  #define EP93XX_SYSCON_KEYTCHCLKDIV_KEN	(1<<15)
>>>>  #define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV	(1<<0)
>>>> +#define EP93XX_SYSCON_CHIPID		EP93XX_SYSCON_REG(0x94)
>>>>  #define EP93XX_SYSCON_SWLOCK		EP93XX_SYSCON_REG(0xc0)
>>>>  
>>>>  #define EP93XX_WATCHDOG_BASE		EP93XX_APB_IOMEM(0x00140000)
>>> NAK.
>> OK for GPIO and SPI, but what about the SECURITY and SYSCON_CHIPID 
>> stuff? The idea behind that is to extend in some way board/cpu 
>> specific information.
>> For example the TS-7XXX boards comes with some options, there is 
>> currently a patch that add a /proc entry to display cpu and board 
>> information (CPU version, CPLD/FPGA firmware version, state of 
>> configuration jumpers, HW options installed, ...)
> 
> I think you are referring to Matthieu's 0006-ep93xx_cpuinfo.patch.
> This is IMHO a hack.  I have another approach for this that I proposed

Yes, this is a hack, and that's why I'm here, I would like to see most 
of these ideas pushed to mainline, and I know that almost all these 
patches won't be accepted, they need rework, heavy rework for some.

> to Russell a while ago.  He had some concern's about breaking userspace
> tools at that time.  I am planning on resubmitting my patch shortly
> in order to get more opinions.

That's true it could break some user space tools, so why not another 
/proc entry like /proc/machineinfo or /proc/boardinfo, ....
(without separator, to mimic /proc/cpuinfo)

In that respect, it will gives more freedom to display whatever 
revelant information machine maintainers can think of.

The approach you have in your "arm: add /proc/cpuinfo extension for 
ep93xx" patch sounds good to me.

Regards,
Chris

> 
> Please hold off on this for a bit.
> 
> Regards,
> Hartley
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v1.0 2/4] TS72XX: Allow to override machine ID

[Christian Gagneraud]

Marek Vasut wrote:
> Dne Po 5. ??jna 2009 17:15:55 Mikael Pettersson napsal(a):
>> Christian Gagneraud writes:
>>  > H Hartley Sweeten wrote:
>>  > > On Saturday, October 03, 2009 6:14 PM, Christian Gagneraud wrote:
>>  > >> From: Matthieu Crapet <mcrapet@gmail.com>
>>  > >>
>>  > >> In early days Technologic Systems fixed the 0x163 value in redboot
>>  > >> instead of 0x2a1, this patch allow to overwrite it.
>>  > >>
>>  > >> Signed-off-by: Matthieu Crapet <mcrapet@gmail.com>
>>  > >> Signed-off-by: Christian Gagneraud <cgagneraud@techworks.ie>
>>  > >
>>  > > As others have already pointed out, this is a pure hack and not
>>  > > suitable for mainline.
>>  > >
>>  > > The bootloader for systems that needs this really should be updated.
>>  > > Machine ID 0x163 (355) is ARCH_CX861XX which isn't an ep93xx based
>>  > > system and doesn't even have a platform init in mainline.
>>  >
>>  > I see your point, but what if the bootloader can't be updated? Does
>>  > that mean that people using these boards will have to bother with
>>  > applying patches on mainline kernel for ever?
>>  > Can't we find a way to address this issue, I'm pretty sure this is not
>>  > the only board that need this kind of asm hack.
>>
>> All you need to do is to wrap the kernel binary image with
>> a small shim that corrects the Machine ID in r1. devio can
>> do that, as can (I think) printf(1).
>>
>> No need to replace the bootloader or hack the kernel.
> 
> devio 'wl 0xe59f1000,4' 'wl 0xe28ff004,4' 'wl $MACH,4' >> id.bin
> cat id.bin zImage > zImage.crippled

Thank you for the tip, i will have a look at this.

Regards,
Chris

> 
> Like this (I used this on Toradex board where those morons fixed machine id too).
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>

[PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem

[H Hartley Sweeten]

On Monday, October 05, 2009 11:17 AM, Christian Gagneraud wrote:
> H Hartley Sweeten wrote:
>> On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote:
>>> Hi,
>>>
>>> What people think about enabling sparsemem on EP93XX? I know this 
>>> patch as it is will break all but this board.
>>>
>>> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that 
>>> will suit all the supported boards?
>> 
>> With sparsemem enabled what is your memory detected during boot?  For
>> instance on my ep9307 based system with flatmem I get:
>> 
>> Memory: 32MB 32MB = 64MB total
>> Memory: 44552KB available (3452K code, 254K data, 124K init, 0K highmem)
>           ^^^^^
> Are you missing 16MB?

No.  My rootfs is in /dev/ram and uses the remaining space.

> Here is what i get with sparsemem:
> 
> Memory: 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB = 64MB total 
> 
> Memory: 63264KB available (1252K code, 231K data, 64K init, 0K highmem)
>
> 00000000-007fffff : System RAM 
>   00020000-00276fff : Kernel text 
>   00278000-002c1923 : Kernel data 
> 01000000-017fffff : System RAM 
> 04000000-047fffff : System RAM 
> 05000000-057fffff : System RAM
> e0000000-e07fffff : System RAM 
> e1000000-e17fffff : System RAM 
> e4000000-e47fffff : System RAM 
> e5000000-e57fffff : System RAM
>
> For boards shipped with 32MB, there's one 32MB chip on SD_CS3 that 
> shows at 0x00000000, for boards shipped with 64MB there's another 32MB 
> chip on SD_CS2 which pop up at 0xe0000000

OK.  That makes sense.  I was under the impression that the 64MB board
was using a single chip select.
 
> That's for the models that offer 32 or 64MB, but TS have other models 
> that offer 64 or 128MB, these boards are designed the same way: 1 64MB 
> chip on SD_CS3 and optional a second 64MB chip on SD_CS2.
> I was told that in that case 16 banks needed to be define (and btw it 
> couldn't be handled , I didn't check it yet.

The single chip 64MB board would work fine but it would use 8 banks.  The
128MB board would be a problem with flatmem because of the 16 banks.  In
order to support this NR_BANKS would have to be increased in
arch/arm/include/asm/setup.h.

> Before sparsemem, we had to use discontigmem (and patch it),now with 
> parsemem there's no needs for such a thing anymore, the only needed 
> bits are 4 #define.

Sparsemem is probably a good solution for the multiple chip selects.  But
we need to make sure that any solution used works for all ep93xx variants.

The ep93xx has 4 sdram chip-selects but, because of the ASDO (sync/async)
boot, there are 5 possible base addresses for them.  Then, depending on
the bus width and the density of memory used, the node mapping for each
bank can vary greatly.  Even worse, node mapping changes depending on the
SROMLL bit.  The document referenced below has all the information needed
but at this point I don't know of a good solution.

> http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf

Maybe Russell can help (Cced).

Regards,
Hartley

[PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem

[Christian Gagneraud]

H Hartley Sweeten wrote:
> On Monday, October 05, 2009 11:17 AM, Christian Gagneraud wrote:
>> H Hartley Sweeten wrote:
>>> On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote:
>>>> Hi,
>>>>
>>>> What people think about enabling sparsemem on EP93XX? I know this 
>>>> patch as it is will break all but this board.
>>>>
>>>> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that 
>>>> will suit all the supported boards?
>>> With sparsemem enabled what is your memory detected during boot?  For
>>> instance on my ep9307 based system with flatmem I get:
>>>
>>> Memory: 32MB 32MB = 64MB total
>>> Memory: 44552KB available (3452K code, 254K data, 124K init, 0K highmem)
>>           ^^^^^
>> Are you missing 16MB?
> 
> No.  My rootfs is in /dev/ram and uses the remaining space.
> 
>> Here is what i get with sparsemem:
>>
>> Memory: 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB = 64MB total 
>>
>> Memory: 63264KB available (1252K code, 231K data, 64K init, 0K highmem)
>>
>> 00000000-007fffff : System RAM 
>>   00020000-00276fff : Kernel text 
>>   00278000-002c1923 : Kernel data 
>> 01000000-017fffff : System RAM 
>> 04000000-047fffff : System RAM 
>> 05000000-057fffff : System RAM
>> e0000000-e07fffff : System RAM 
>> e1000000-e17fffff : System RAM 
>> e4000000-e47fffff : System RAM 
>> e5000000-e57fffff : System RAM
>>
>> For boards shipped with 32MB, there's one 32MB chip on SD_CS3 that 
>> shows at 0x00000000, for boards shipped with 64MB there's another 32MB 
>> chip on SD_CS2 which pop up at 0xe0000000
> 
> OK.  That makes sense.  I was under the impression that the 64MB board
> was using a single chip select.
>  
>> That's for the models that offer 32 or 64MB, but TS have other models 
>> that offer 64 or 128MB, these boards are designed the same way: 1 64MB 
>> chip on SD_CS3 and optional a second 64MB chip on SD_CS2.
>> I was told that in that case 16 banks needed to be define (and btw it 
>> couldn't be handled , I didn't check it yet.
> 
> The single chip 64MB board would work fine but it would use 8 banks.  The
> 128MB board would be a problem with flatmem because of the 16 banks.  In
> order to support this NR_BANKS would have to be increased in
> arch/arm/include/asm/setup.h.
> 
>> Before sparsemem, we had to use discontigmem (and patch it),now with 
>> parsemem there's no needs for such a thing anymore, the only needed 
>> bits are 4 #define.
> 
> Sparsemem is probably a good solution for the multiple chip selects.  But
> we need to make sure that any solution used works for all ep93xx variants.
> 
> The ep93xx has 4 sdram chip-selects but, because of the ASDO (sync/async)
> boot, there are 5 possible base addresses for them.  Then, depending on
> the bus width and the density of memory used, the node mapping for each
> bank can vary greatly.  Even worse, node mapping changes depending on the
> SROMLL bit.  The document referenced below has all the information needed
> but at this point I don't know of a good solution.
> 
>> http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf

Actually, in the EP93XX User's Manual, the table 13-11 on pages 3-12 
to 13-16 gives all the possibilities.

When SROMLL=0, SECTION_SIZE_BITS=24 suits all the cases (segments are 
always spaced by a multiple of 16MB: 0xNM00.0000 with N=0,C,D,E,F 
depending of the chip select, and M=1,2,..,F).

Now for SROMLL=1, I see at least 4 exceptions:
- 64MBit/32bit/11x8x4banks => 4 segments of 2MB spaced by 4MB:
   - 0xN000-0xN01F
   - 0xN040-...
   - 0xN080-...
   - 0xN0C0-...

   23 >= SECTION_SIZE_BITS >= 22

- 128MBit/32bit/12x9x4banks => 1 segment of 32 MB
   - 0xN000-0xN1FF

   SECTION_SIZE_BITS >= 25

- 256Mbit/32bit/13x9x4banks => 2 segments of 32 MB spaced by 64MB:
   - 0xN000-0xN1FF
   - 0xN400-...

   26 >= SECTION_SIZE_BITS >=25

- 512Mbit/32bit/13x10x4 => 1 segment of 128 MB
   - 0xN000-0xN7FF

   SECTION_SIZE_BITS>=27

(Am I right Russel?)

So on 12 possibilities, there's only 4 exceptions.

And finally for the virt<->phys:

There's 4 chip select, one of them can pop-up at two different 
addresses. The biggest SDRAM segment being 128MB, we
have the following possible address ranges:
0x0000-0x07FF
0xC000-0xC7FF
0xD000-0xD7FF
0xE000-0xE7FF
0xF000-0xF7FF

So why not a mapping like this one:
0xC000 => PAGE_OFFSET + 0x0000 (1100.0XXX => XX00.0XXX)
0xD000 => PAGE_OFFSET + 0x0800 (1101.0XXX => XX00.1XXX)
0xE000 => PAGE_OFFSET + 0x1000 (1110.0XXX => XX01.0XXX)
0xF000 => PAGE_OFFSET + 0x1800 (1111.0XXX => XX01.1XXX)
0x0000 => PAGE_OFFSET + 0x2000 (0000.0XXX => XX10.0XXX)

Which should be done with:
((pa&0x80000000) ? (pa&0x07FFFFFF)|((pa&0x30000000)>>1) : 
(pa|0x20000000)) | PAGE_OFFSET

and for virt_to_phys something like:
(va&0x07FFFFFFF)| ((va&0x20000000) ? ((va&0x18000000)<<1)|0xC0000000 : 
  0x00000000)
(NB: this macro is PHYS_OFFSET agnostic and allow the use of multiple 
chips select)

A simpler possibility would be to activate sparsemem only for ts72xx 
and stuff memory.h with:

#if defined(CONFIG_SPARSEMEM)
#if defined(CONFIG_MACH_TS72XX)
...
#else
#error ...
#endif
#endif


What do you think?

Regards,
Chris


> 
> Maybe Russell can help (Cced).
> 
> Regards,
> Hartley

[PATCH v1.0 4/4] MM: Switch TS72XX to use sparemem

[Christian Gagneraud]

Christian Gagneraud wrote:
> H Hartley Sweeten wrote:
>> On Monday, October 05, 2009 11:17 AM, Christian Gagneraud wrote:
>>> H Hartley Sweeten wrote:
>>>> On Monday, October 05, 2009 5:21 AM, Christian Gagneraud wrote:
>>>>> Hi,
>>>>>
>>>>> What people think about enabling sparsemem on EP93XX? I know this 
>>>>> patch as it is will break all but this board.
>>>>>
>>>>> Can we define defaults SECTION_SIZE_BITS and MAX_PHYSMEM_BITS that 
>>>>> will suit all the supported boards?
>>>> With sparsemem enabled what is your memory detected during boot?  For
>>>> instance on my ep9307 based system with flatmem I get:
>>>>
>>>> Memory: 32MB 32MB = 64MB total
>>>> Memory: 44552KB available (3452K code, 254K data, 124K init, 0K 
>>>> highmem)
>>>           ^^^^^
>>> Are you missing 16MB?
>>
>> No.  My rootfs is in /dev/ram and uses the remaining space.
>>
>>> Here is what i get with sparsemem:
>>>
>>> Memory: 8MB 8MB 8MB 8MB 8MB 8MB 8MB 8MB = 64MB total
>>> Memory: 63264KB available (1252K code, 231K data, 64K init, 0K highmem)
>>>
>>> 00000000-007fffff : System RAM   00020000-00276fff : Kernel text   
>>> 00278000-002c1923 : Kernel data 01000000-017fffff : System RAM 
>>> 04000000-047fffff : System RAM 05000000-057fffff : System RAM
>>> e0000000-e07fffff : System RAM e1000000-e17fffff : System RAM 
>>> e4000000-e47fffff : System RAM e5000000-e57fffff : System RAM
>>>
>>> For boards shipped with 32MB, there's one 32MB chip on SD_CS3 that 
>>> shows at 0x00000000, for boards shipped with 64MB there's another 
>>> 32MB chip on SD_CS2 which pop up at 0xe0000000
>>
>> OK.  That makes sense.  I was under the impression that the 64MB board
>> was using a single chip select.
>>  
>>> That's for the models that offer 32 or 64MB, but TS have other models 
>>> that offer 64 or 128MB, these boards are designed the same way: 1 
>>> 64MB chip on SD_CS3 and optional a second 64MB chip on SD_CS2.
>>> I was told that in that case 16 banks needed to be define (and btw it 
>>> couldn't be handled , I didn't check it yet.
>>
>> The single chip 64MB board would work fine but it would use 8 banks.  The
>> 128MB board would be a problem with flatmem because of the 16 banks.  In
>> order to support this NR_BANKS would have to be increased in
>> arch/arm/include/asm/setup.h.
>>
>>> Before sparsemem, we had to use discontigmem (and patch it),now with 
>>> parsemem there's no needs for such a thing anymore, the only needed 
>>> bits are 4 #define.
>>
>> Sparsemem is probably a good solution for the multiple chip selects.  But
>> we need to make sure that any solution used works for all ep93xx 
>> variants.
>>
>> The ep93xx has 4 sdram chip-selects but, because of the ASDO (sync/async)
>> boot, there are 5 possible base addresses for them.  Then, depending on
>> the bus width and the density of memory used, the node mapping for each
>> bank can vary greatly.  Even worse, node mapping changes depending on the
>> SROMLL bit.  The document referenced below has all the information needed
>> but at this point I don't know of a good solution.
>>
>>> http://arm.cirrus.com/files/HOWTO/EP93xx%20SDRAM%20Address%20Ranges.pdf
> 
> Actually, in the EP93XX User's Manual, the table 13-11 on pages 3-12 to 
> 13-16 gives all the possibilities.

It is exactly the same table actually, sorry for the noise.

Regards,
Chris.

> 
> When SROMLL=0, SECTION_SIZE_BITS=24 suits all the cases (segments are 
> always spaced by a multiple of 16MB: 0xNM00.0000 with N=0,C,D,E,F 
> depending of the chip select, and M=1,2,..,F).
> 
> Now for SROMLL=1, I see at least 4 exceptions:
> - 64MBit/32bit/11x8x4banks => 4 segments of 2MB spaced by 4MB:
>   - 0xN000-0xN01F
>   - 0xN040-...
>   - 0xN080-...
>   - 0xN0C0-...
> 
>   23 >= SECTION_SIZE_BITS >= 22
> 
> - 128MBit/32bit/12x9x4banks => 1 segment of 32 MB
>   - 0xN000-0xN1FF
> 
>   SECTION_SIZE_BITS >= 25
> 
> - 256Mbit/32bit/13x9x4banks => 2 segments of 32 MB spaced by 64MB:
>   - 0xN000-0xN1FF
>   - 0xN400-...
> 
>   26 >= SECTION_SIZE_BITS >=25
> 
> - 512Mbit/32bit/13x10x4 => 1 segment of 128 MB
>   - 0xN000-0xN7FF
> 
>   SECTION_SIZE_BITS>=27
> 
> (Am I right Russel?)
> 
> So on 12 possibilities, there's only 4 exceptions.
> 
> And finally for the virt<->phys:
> 
> There's 4 chip select, one of them can pop-up at two different 
> addresses. The biggest SDRAM segment being 128MB, we
> have the following possible address ranges:
> 0x0000-0x07FF
> 0xC000-0xC7FF
> 0xD000-0xD7FF
> 0xE000-0xE7FF
> 0xF000-0xF7FF
> 
> So why not a mapping like this one:
> 0xC000 => PAGE_OFFSET + 0x0000 (1100.0XXX => XX00.0XXX)
> 0xD000 => PAGE_OFFSET + 0x0800 (1101.0XXX => XX00.1XXX)
> 0xE000 => PAGE_OFFSET + 0x1000 (1110.0XXX => XX01.0XXX)
> 0xF000 => PAGE_OFFSET + 0x1800 (1111.0XXX => XX01.1XXX)
> 0x0000 => PAGE_OFFSET + 0x2000 (0000.0XXX => XX10.0XXX)
> 
> Which should be done with:
> ((pa&0x80000000) ? (pa&0x07FFFFFF)|((pa&0x30000000)>>1) : 
> (pa|0x20000000)) | PAGE_OFFSET
> 
> and for virt_to_phys something like:
> (va&0x07FFFFFFF)| ((va&0x20000000) ? ((va&0x18000000)<<1)|0xC0000000 : 
>  0x00000000)
> (NB: this macro is PHYS_OFFSET agnostic and allow the use of multiple 
> chips select)
> 
> A simpler possibility would be to activate sparsemem only for ts72xx and 
> stuff memory.h with:
> 
> #if defined(CONFIG_SPARSEMEM)
> #if defined(CONFIG_MACH_TS72XX)
> ...
> #else
> #error ...
> #endif
> #endif
> 
> 
> What do you think?
> 
> Regards,
> Chris
> 
> 
>>
>> Maybe Russell can help (Cced).
>>
>> Regards,
>> Hartley
> 
>