ARM: PRIMA2: some patches prepared to support new SiRF SoCs

From: Barry Song <[email protected]>

we will have SiRFMarco and SiRFPolo, all of them will be in the generic board.

Signed-off-by Barry Song <[email protected]>

---
 arch/arm/mach-prima2/Makefile                      |    2 +-
 arch/arm/mach-prima2/{prima2.c => board-generic.c} |   10 ++++++----
 2 files changed, 7 insertions(+), 5 deletions(-)
 rename arch/arm/mach-prima2/{prima2.c => board-generic.c} (81%)

arch/arm/mach-prima2/board-generic.c renamed from arch/arm/mach-prima2/prima2.c +4 -3

similarity index 81%
rename from arch/arm/mach-prima2/prima2.c
rename to arch/arm/mach-prima2/board-generic.c
index e9a17ae..f06b887 100644
@@ -30,12 +30,13 @@ void __init sirfsoc_init_late(void)
 	sirfsoc_pm_init();
 }
 
-static const char *prima2cb_dt_match[] __initdata = {
-       "sirf,prima2-cb",
+#ifdef CONFIG_ARCH_PRIMA2
+static const char *prima2_dt_match[] __initdata = {
+       "sirf,prima2",
        NULL
 };
 
-MACHINE_START(PRIMA2_EVB, "prima2cb")
+DT_MACHINE_START(PRIMA2_DT, "Generic PRIMA2 (Flattened Device Tree)")
 	/* Maintainer: Barry Song <[email protected]> */
 	.atag_offset	= 0x100,
 	.map_io         = sirfsoc_map_lluart,

Quoted 11 lines

From: Barry Song <[email protected]>

we will have SiRFMarco and SiRFPolo, all of them will be in the generic board.

Signed-off-by Barry Song <[email protected]>

---
 arch/arm/mach-prima2/Makefile                      |    2 +-
 arch/arm/mach-prima2/{prima2.c => board-generic.c} |   10 ++++++----
 2 files changed, 7 insertions(+), 5 deletions(-)
 rename arch/arm/mach-prima2/{prima2.c => board-generic.c} (81%)

I would prefer not to have a board-* file in there, because it's not specific to a board. If you want to get rid of the prima2 name in it, you can call it common.c.

Quoted 20 lines

arch/arm/mach-prima2/board-generic.c renamed from arch/arm/mach-prima2/prima2.c +3 -2

similarity index 81%
rename from arch/arm/mach-prima2/prima2.c
rename to arch/arm/mach-prima2/board-generic.c
index e9a17ae..f06b887 100644
@@ -30,12 +30,13 @@ void __init sirfsoc_init_late(void)
      sirfsoc_pm_init();
 }
 
-static const char *prima2cb_dt_match[] __initdata = {
-       "sirf,prima2-cb",
+#ifdef CONFIG_ARCH_PRIMA2
+static const char *prima2_dt_match[] __initdata = {
+       "sirf,prima2",
        NULL
 };
 

Quoted 6 lines

arch/arm/mach-prima2/board-generic.c renamed from arch/arm/mach-prima2/prima2.c +1 -1

-MACHINE_START(PRIMA2_EVB, "prima2cb")
+DT_MACHINE_START(PRIMA2_DT, "Generic PRIMA2 (Flattened Device Tree)")
      /* Maintainer: Barry Song <[email protected]> */
      .atag_offset    = 0x100,
      .map_io         = sirfsoc_map_lluart,

arch/arm/mach-prima2/board-generic.c MACHINE_START(PRIMA2_EVB, "prima2cb") · line 51

Quoted 8 lines

arch/arm/mach-prima2/board-generic.c renamed from arch/arm/mach-prima2/prima2.c +2 -1

@@ -44,6 +45,7 @@ MACHINE_START(PRIMA2_EVB, "prima2cb")
      .dma_zone_size  = SZ_256M,
      .init_machine   = sirfsoc_mach_init,
      .init_late      = sirfsoc_init_late,
-     .dt_compat      = prima2cb_dt_match,
+     .dt_compat      = prima2_dt_match,
      .restart        = sirfsoc_restart,
 MACHINE_END
+#endif

I suppose this never really worked before then?

Arnd

2012/8/21 Arnd Bergmann <[email protected]>:

Quoted 5 lines · Barry Song

I would prefer not to have a board-* file in there, because it's not specific to a board. If you want to get rid of the prima2 name in it, you can call it common.c.

that is fine to me. i rename to board-generic.c just because omap and some others did like that.
and i'll add marco and polo DT_MACHINE_START to this file too.

Quoted 19 lines

Quoted 19 lines

arch/arm/mach-prima2/board-generic.c renamed from arch/arm/mach-prima2/prima2.c +3 -2

similarity index 81%
rename from arch/arm/mach-prima2/prima2.c
rename to arch/arm/mach-prima2/board-generic.c
index e9a17ae..f06b887 100644
@@ -30,12 +30,13 @@ void __init sirfsoc_init_late(void)
      sirfsoc_pm_init();
 }
 
-static const char *prima2cb_dt_match[] __initdata = {
-       "sirf,prima2-cb",
+#ifdef CONFIG_ARCH_PRIMA2
+static const char *prima2_dt_match[] __initdata = {
+       "sirf,prima2",
        NULL
 };
 

Quoted 16 lines

Quoted 6 lines

arch/arm/mach-prima2/board-generic.c renamed from arch/arm/mach-prima2/prima2.c +1 -1

-MACHINE_START(PRIMA2_EVB, "prima2cb")
+DT_MACHINE_START(PRIMA2_DT, "Generic PRIMA2 (Flattened Device Tree)")
      /* Maintainer: Barry Song <[email protected]> */
      .atag_offset    = 0x100,
      .map_io         = sirfsoc_map_lluart,

arch/arm/mach-prima2/board-generic.c MACHINE_START(PRIMA2_EVB, "prima2cb") · line 51

Quoted 8 lines

arch/arm/mach-prima2/board-generic.c renamed from arch/arm/mach-prima2/prima2.c +2 -1

@@ -44,6 +45,7 @@ MACHINE_START(PRIMA2_EVB, "prima2cb")
      .dma_zone_size  = SZ_256M,
      .init_machine   = sirfsoc_mach_init,
      .init_late      = sirfsoc_init_late,
-     .dt_compat      = prima2cb_dt_match,
+     .dt_compat      = prima2_dt_match,
      .restart        = sirfsoc_restart,
 MACHINE_END
+#endif

I suppose this never really worked before then?

i am not sure what you mean, but this does work and i tested and found prima2 can boot normally.

Quoted 7 lines

2012/8/21 Arnd Bergmann <[email protected]>:

Quoted 5 lines · Barry Song

I would prefer not to have a board-* file in there, because it's not specific to a board. If you want to get rid of the prima2 name in it, you can call it common.c.

Quoted 3 lines

that is fine to me. i rename to board-generic.c just because omap and some others did like that.
and i'll add marco and polo DT_MACHINE_START to this file too.

Ok. For the older platforms that have a lot of non-DT board files, it makes sense to have a separate board-generic.c file.

Quoted 37 lines

Quoted 36 lines

Quoted 26 lines

arch/arm/mach-prima2/board-generic.c renamed from arch/arm/mach-prima2/prima2.c +4 -3

similarity index 81%
rename from arch/arm/mach-prima2/prima2.c
rename to arch/arm/mach-prima2/board-generic.c
index e9a17ae..f06b887 100644
@@ -30,12 +30,13 @@ void __init sirfsoc_init_late(void)
      sirfsoc_pm_init();
 }
 
-static const char *prima2cb_dt_match[] __initdata = {
-       "sirf,prima2-cb",
+#ifdef CONFIG_ARCH_PRIMA2
+static const char *prima2_dt_match[] __initdata = {
+       "sirf,prima2",
        NULL
 };
 
-MACHINE_START(PRIMA2_EVB, "prima2cb")
+DT_MACHINE_START(PRIMA2_DT, "Generic PRIMA2 (Flattened Device Tree)")
      /* Maintainer: Barry Song <[email protected]> */
      .atag_offset    = 0x100,
      .map_io         = sirfsoc_map_lluart,

arch/arm/mach-prima2/board-generic.c MACHINE_START(PRIMA2_EVB, "prima2cb") · line 51

Quoted 8 lines

arch/arm/mach-prima2/board-generic.c renamed from arch/arm/mach-prima2/prima2.c +2 -1

@@ -44,6 +45,7 @@ MACHINE_START(PRIMA2_EVB, "prima2cb")
      .dma_zone_size  = SZ_256M,
      .init_machine   = sirfsoc_mach_init,
      .init_late      = sirfsoc_init_late,
-     .dt_compat      = prima2cb_dt_match,
+     .dt_compat      = prima2_dt_match,
      .restart        = sirfsoc_restart,
 MACHINE_END
+#endif

I suppose this never really worked before then?

Quoted 2 lines

i am not sure what you mean, but this does work and i tested and found prima2 can boot normally.

I mean the old version, not the new one. If you use MACHINE_START, you cannot access the device tree data from the boot loader, which means that none of the device drivers find their devices.

I also just noticed that you ahve both the .atag_offset and the .dt_compat field set here, which is a bit strange as the dt_compat field was previously unused. Now, the .atag_offset field is unused, so you should remove that.

Arnd

Quoted 3 lines

I mean the old version, not the new one. If you use MACHINE_START, you cannot access the device tree data from the boot loader, which means that none of the device drivers find their devices.

sorry i didn't get you.

DT is read to 0x3608000 by bootloader, and bootm has param "bootm 0x02008000 - 0x3608000" as:

bootcmd=mmc read 0 0x3608000 0x3780 0x80;mmc read 0 0x02008000 0x1800 0x1800;fdt addr 0x3608000;
fdt resize;bootm 0x02008000 - 0x3608000

kernel has been always able to read DT data from bootloader.

From: Barry Song <[email protected]>

We will have SiRF Marco and Polo, so rename the dir to mach-sirf and add Kconfig menu

Signed-off-by Baohua Song <[email protected]>

---
 arch/arm/Kconfig                                   |   10 +++++-----
 arch/arm/Makefile                                  |    2 +-
 arch/arm/mach-sirf/Kconfig                         |   16 ++++++++++++++++
 arch/arm/{mach-prima2 => mach-sirf}/Makefile       |    0
 arch/arm/{mach-prima2 => mach-sirf}/Makefile.boot  |    0
 .../arm/{mach-prima2 => mach-sirf}/board-generic.c |    0
 arch/arm/{mach-prima2 => mach-sirf}/common.h       |    0
 .../include/mach/clkdev.h                          |    0
 .../include/mach/debug-macro.S                     |    0
 .../include/mach/entry-macro.S                     |    0
 .../{mach-prima2 => mach-sirf}/include/mach/gpio.h |    0
 .../include/mach/hardware.h                        |    0
 .../{mach-prima2 => mach-sirf}/include/mach/irqs.h |    0
 .../{mach-prima2 => mach-sirf}/include/mach/map.h  |    0

Quoted 6 lines

From: Barry Song <[email protected]>

We will have SiRF Marco and Polo, so rename the dir to mach-sirf and add Kconfig menu

Signed-off-by Baohua Song <[email protected]>

Quoted 15 lines

---
 arch/arm/Kconfig                                   |   10 +++++-----
 arch/arm/Makefile                                  |    2 +-
 arch/arm/mach-sirf/Kconfig                         |   16 ++++++++++++++++
 arch/arm/{mach-prima2 => mach-sirf}/Makefile       |    0
 arch/arm/{mach-prima2 => mach-sirf}/Makefile.boot  |    0
 .../arm/{mach-prima2 => mach-sirf}/board-generic.c |    0
 arch/arm/{mach-prima2 => mach-sirf}/common.h       |    0
 .../include/mach/clkdev.h                          |    0
 .../include/mach/debug-macro.S                     |    0
 .../include/mach/entry-macro.S                     |    0
 .../{mach-prima2 => mach-sirf}/include/mach/gpio.h |    0
 .../include/mach/hardware.h                        |    0
 .../{mach-prima2 => mach-sirf}/include/mach/irqs.h |    0
 .../{mach-prima2 => mach-sirf}/include/mach/map.h  |    0

I'm not sure if we should rename all of these right now. I've been thinking about moving all of recent and simple ARMv7 based platforms (socfpga, zynq, prima2, ...) into a single directory, where they would basically end up being one file per platform. We should discuss this at the ARM mini summit, and I can let you know the outcome of it. I don't object on the rename in principle, but it might end up causing extra churn.

arch/arm/mach-sirf/Kconfig line 5

Quoted 6 lines

arch/arm/mach-sirf/Kconfig new file +5 -0

+if ARCH_SIRF
+
+choice
+       prompt "Qualcomm SiRF SoC Type"
+       default ARCH_PRIMA2

I'm curious about this: I did read that Samsung acquired CSR, and you list the chips as Qualcomm. What's the story here?

arch/arm/mach-sirf/Kconfig line 14

Quoted 9 lines

arch/arm/mach-sirf/Kconfig new file +8 -0

+config ARCH_PRIMA2
+       bool "CSR SiRFSoC PRIMA2 ARM Cortex A9 Platform"
+       select CPU_V7
+       select ZONE_DMA
+       help
+          Support for CSR SiRFSoC ARM Cortex A9 Platform
+
+endchoice

Is this still needed? When you add other SoC type here, would you build kernels that are for just one of them in practice? If they are completely generic anyway, you can skip the submenu.

Arnd

for the moment, that is needed just because the DEBUG UART base address is difficult for different SoC. debug-macro.S is very early, it depends on the SIRFSOC_UART1_PA_BASE.

/* UART-1: used as serial debug port */
#ifdef CONFIG_ARCH_PRIMA2
#define SIRFSOC_UART1_PA_BASE 0xb0060000
#elif defined(CONFIG_ARCH_MARCO)
#define SIRFSOC_UART1_PA_BASE 0xcc060000
#endif
otherwise, PRIMA2 and MARCO can co-exist.

i think i can find some ways to set the rp dynamically according to chip type.

         .macro  addruart, rp, rv, tmp
         ldr     \rp, =SIRFSOC_UART1_PA_BASE             @ physical
         ldr     \rv, =SIRFSOC_UART1_VA_BASE             @ virtual

.endm

Quoted 11 lines

for the moment, that is needed just because the DEBUG UART base address is difficult for different SoC. debug-macro.S is very early, it depends on the SIRFSOC_UART1_PA_BASE.

/* UART-1: used as serial debug port */
#ifdef CONFIG_ARCH_PRIMA2
#define SIRFSOC_UART1_PA_BASE 0xb0060000
#elif defined(CONFIG_ARCH_MARCO)
#define SIRFSOC_UART1_PA_BASE 0xcc060000
#endif
otherwise, PRIMA2 and MARCO can co-exist.

Ok, I see.

Quoted 5 lines

i think i can find some ways to set the rp dynamically according to chip type.

         .macro  addruart, rp, rv, tmp
         ldr     \rp, =SIRFSOC_UART1_PA_BASE             @ physical
         ldr     \rv, =SIRFSOC_UART1_VA_BASE             @ virtual

.endm

The most common way to do this is to have multiple entries in arch/arm/Kconfig.debug in the "Kernel low-level debugging port" menu. For production kernels, you would just leave out DEBUG_LL while for debugging you have to pick one UART.

Arnd

then i add these to Kconfig.debug as it is a common way

config DEBUG_PRIMA2_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART1" depends on ARCH_PRIMA2
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFprimaII devices.

config DEBUG_MARCO_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART2" depends on ARCH_MARCO
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFmarco devices.

and these in mach-prima2/include/mach/uart.h

  #ifdef CONFIG_DEBUG_PRIMA2_UART1
  #define SIRFSOC_UART1_PA_BASE          0xb0060000
  #elif defined(CONFIG_DEBUG_MARCO_UART1)
  #define SIRFSOC_UART1_PA_BASE          0xcc060000
  #endif

the above codes seem still ugly ?

Quoted 24 lines

then i add these to Kconfig.debug as it is a common way

config DEBUG_PRIMA2_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART1" depends on ARCH_PRIMA2
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFprimaII devices.

config DEBUG_MARCO_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART2" depends on ARCH_MARCO
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFmarco devices.

and these in mach-prima2/include/mach/uart.h

  #ifdef CONFIG_DEBUG_PRIMA2_UART1
  #define SIRFSOC_UART1_PA_BASE          0xb0060000
  #elif defined(CONFIG_DEBUG_MARCO_UART1)
  #define SIRFSOC_UART1_PA_BASE          0xcc060000
  #endif

Quoted 2 lines

the above codes seem still ugly ?

No, that's fine, about as a good as it gets with today's kernel capabilities. Just fix the description to have the correct SoC name instead of "DaVinci DA8XX" ;-)

Arnd

2012/8/21 Arnd Bergmann <[email protected]>:

Quoted 25 lines · Barry Song

Quoted 24 lines

then i add these to Kconfig.debug as it is a common way

config DEBUG_PRIMA2_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART1" depends on ARCH_PRIMA2
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFprimaII devices.

config DEBUG_MARCO_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART2" depends on ARCH_MARCO
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFmarco devices.

and these in mach-prima2/include/mach/uart.h

  #ifdef CONFIG_DEBUG_PRIMA2_UART1
  #define SIRFSOC_UART1_PA_BASE          0xb0060000
  #elif defined(CONFIG_DEBUG_MARCO_UART1)
  #define SIRFSOC_UART1_PA_BASE          0xcc060000
  #endif

Quoted 6 lines

Quoted 2 lines

the above codes seem still ugly ?

No, that's fine, about as a good as it gets with today's kernel capabilities. Just fix the description to have the correct SoC name instead of "DaVinci DA8XX" ;-)

except the DEBUG_LL uart base address, i missed the zreladdr-y. for primaii, it is 0x00008000, for marco, it is 0x40008000 as marco's memory space begins from 0x4000000.
i would to have AUTO_ZRELADDR for the whole SiRF series. but for uImage load address difference in uImage header, which blocks multiple SoCs from using same uImage, is "KERNEL_NOLOAD" uImage type the current generic solution?

Quoted 3 lines

Arnd

-barry

2012/8/28 Barry Song <[email protected]>:

Quoted 33 lines

2012/8/21 Arnd Bergmann <[email protected]>:

Quoted 25 lines · Barry Song

Quoted 24 lines

then i add these to Kconfig.debug as it is a common way

config DEBUG_PRIMA2_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART1" depends on ARCH_PRIMA2
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFprimaII devices.

config DEBUG_MARCO_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART2" depends on ARCH_MARCO
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFmarco devices.

and these in mach-prima2/include/mach/uart.h

  #ifdef CONFIG_DEBUG_PRIMA2_UART1
  #define SIRFSOC_UART1_PA_BASE          0xb0060000
  #elif defined(CONFIG_DEBUG_MARCO_UART1)
  #define SIRFSOC_UART1_PA_BASE          0xcc060000
  #endif

Quoted 6 lines

Quoted 2 lines

the above codes seem still ugly ?

No, that's fine, about as a good as it gets with today's kernel capabilities. Just fix the description to have the correct SoC name instead of "DaVinci DA8XX" ;-)

Quoted 7 lines

except the DEBUG_LL uart base address, i missed the zreladdr-y. for primaii, it is 0x00008000, for marco, it is 0x40008000 as marco's memory space begins from 0x4000000.
i would to have AUTO_ZRELADDR for the whole SiRF series. but for uImage load address difference in uImage header, which blocks multiple SoCs from using same uImage, is "KERNEL_NOLOAD" uImage type the current generic solution?

also add Stephen Warren.

i have two verified ways to resolve this problem:

1. use "kernel noload", build uImage by:

make uImage UIMAGE_TYPE=kernel_noload
and add the following patch in kernel:

Quoted 46 lines

2012/8/28 Barry Song <[email protected]>:

Quoted 33 lines

2012/8/21 Arnd Bergmann <[email protected]>:

Quoted 25 lines · Barry Song

Quoted 24 lines

then i add these to Kconfig.debug as it is a common way

config DEBUG_PRIMA2_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART1" depends on ARCH_PRIMA2
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFprimaII devices.

config DEBUG_MARCO_UART1
bool "Kernel low-level debugging on DaVinci DA8XX using UART2" depends on ARCH_MARCO
help
Say Y here if you want the debug print routines to direct their output to UART1 serial port on SiRFmarco devices.

and these in mach-prima2/include/mach/uart.h

  #ifdef CONFIG_DEBUG_PRIMA2_UART1
  #define SIRFSOC_UART1_PA_BASE          0xb0060000
  #elif defined(CONFIG_DEBUG_MARCO_UART1)
  #define SIRFSOC_UART1_PA_BASE          0xcc060000
  #endif

Quoted 6 lines

Quoted 2 lines

the above codes seem still ugly ?

No, that's fine, about as a good as it gets with today's kernel capabilities. Just fix the description to have the correct SoC name instead of "DaVinci DA8XX" ;-)

Quoted 7 lines

except the DEBUG_LL uart base address, i missed the zreladdr-y. for primaii, it is 0x00008000, for marco, it is 0x40008000 as marco's memory space begins from 0x4000000.
i would to have AUTO_ZRELADDR for the whole SiRF series. but for uImage load address difference in uImage header, which blocks multiple SoCs from using same uImage, is "KERNEL_NOLOAD" uImage type the current generic solution?

also add Stephen Warren.

i have two verified ways to resolve this problem:

Quoted 4 lines

1. use "kernel noload", build uImage by:

make uImage UIMAGE_TYPE=kernel_noload
and add the following patch in kernel:

Very recent U-Boot have a bootz command, which acts just like bootm, but allows use of a raw zImage or the kernel, rather than a uImage-wrapped-zImage. This was implemented by Marek Vasut.

2012/8/21 Arnd Bergmann <[email protected]>:

Quoted 23 lines · Barry Song

Quoted 21 lines

From: Barry Song <[email protected]>

We will have SiRF Marco and Polo, so rename the dir to mach-sirf and add Kconfig menu

Signed-off-by Baohua Song <[email protected]>

---
 arch/arm/Kconfig                                   |   10 +++++-----
 arch/arm/Makefile                                  |    2 +-
 arch/arm/mach-sirf/Kconfig                         |   16 ++++++++++++++++
 arch/arm/{mach-prima2 => mach-sirf}/Makefile       |    0
 arch/arm/{mach-prima2 => mach-sirf}/Makefile.boot  |    0
 .../arm/{mach-prima2 => mach-sirf}/board-generic.c |    0
 arch/arm/{mach-prima2 => mach-sirf}/common.h       |    0
 .../include/mach/clkdev.h                          |    0
 .../include/mach/debug-macro.S                     |    0
 .../include/mach/entry-macro.S                     |    0
 .../{mach-prima2 => mach-sirf}/include/mach/gpio.h |    0
 .../include/mach/hardware.h                        |    0
 .../{mach-prima2 => mach-sirf}/include/mach/irqs.h |    0
 .../{mach-prima2 => mach-sirf}/include/mach/map.h  |    0

Quoted 6 lines

I'm not sure if we should rename all of these right now. I've been thinking about moving all of recent and simple ARMv7 based platforms (socfpga, zynq, prima2, ...) into a single directory, where they would basically end up being one file per platform. We should discuss this at the ARM mini summit, and I can let you know the outcome of it. I don't object on the rename in principle, but it might end up causing extra churn.

ok. i will follow the output of ARM mini summit.

i would think merging several SoCs into a dir still needs much time. if the whole rename is too aggresive for the moment, how about keeping the mach-prima2 temporarily, but this prima2 dir will also include the coming Marco stuff?

Quoted 6 lines

From: Barry Song <[email protected]>

We will have SiRF Marco and Polo, so rename the dir to mach-sirf and add Kconfig menu

Signed-off-by Baohua Song <[email protected]>

Quoted 15 lines

---
 arch/arm/Kconfig                                   |   10 +++++-----
 arch/arm/Makefile                                  |    2 +-
 arch/arm/mach-sirf/Kconfig                         |   16 ++++++++++++++++
 arch/arm/{mach-prima2 => mach-sirf}/Makefile       |    0
 arch/arm/{mach-prima2 => mach-sirf}/Makefile.boot  |    0
 .../arm/{mach-prima2 => mach-sirf}/board-generic.c |    0
 arch/arm/{mach-prima2 => mach-sirf}/common.h       |    0
 .../include/mach/clkdev.h                          |    0
 .../include/mach/debug-macro.S                     |    0
 .../include/mach/entry-macro.S                     |    0
 .../{mach-prima2 => mach-sirf}/include/mach/gpio.h |    0
 .../include/mach/hardware.h                        |    0
 .../{mach-prima2 => mach-sirf}/include/mach/irqs.h |    0
 .../{mach-prima2 => mach-sirf}/include/mach/map.h  |    0

I'm not sure if we should rename all of these right now. I've been thinking about moving all of recent and simple ARMv7 based platforms (socfpga, zynq, prima2, ...) into a single directory, where they would basically end up being one file per platform. We should discuss this at the ARM mini summit, and I can let you know the outcome of it. I don't object on the rename in principle, but it might end up causing extra churn.

arch/arm/mach-sirf/Kconfig line 5

Quoted 6 lines

arch/arm/mach-sirf/Kconfig new file +5 -0

+if ARCH_SIRF
+
+choice
+       prompt "Qualcomm SiRF SoC Type"
+       default ARCH_PRIMA2

I'm curious about this: I did read that Samsung acquired CSR, and you list the chips as Qualcomm. What's the story here?

arch/arm/mach-sirf/Kconfig line 14

Quoted 9 lines

arch/arm/mach-sirf/Kconfig new file +8 -0

+config ARCH_PRIMA2
+       bool "CSR SiRFSoC PRIMA2 ARM Cortex A9 Platform"
+       select CPU_V7
+       select ZONE_DMA
+       help
+          Support for CSR SiRFSoC ARM Cortex A9 Platform
+
+endchoice

Is this still needed? When you add other SoC type here, would you build kernels that are for just one of them in practice? If they are completely generic anyway, you can skip the submenu.

Arnd

Quoted 9 lines

arch/arm/mach-sirf/Kconfig line 5

Quoted 6 lines

arch/arm/mach-sirf/Kconfig new file +5 -0

+if ARCH_SIRF
+
+choice
+       prompt "Qualcomm SiRF SoC Type"
+       default ARCH_PRIMA2

I'm curious about this: I did read that Samsung acquired CSR, and you list the chips as Qualcomm. What's the story here?

BTW, i just want to clarify Samsung acquired the mobile business of CSR, not including our primaII or other SoCs.