ARM: S3C64XX: Initial support for Wolfson/Simtec Cragganmore/Banff

The Cragganmore carrier card and Banff CPU module are used on Wolfson Microelectronics reference systems. This initial support covers the core system which is a fairly generic S3C6410 based design, further patches will add support for the key features of the reference system.

The initial board bringup and therefore much of the key code was done by Ben Dooks for Simtec, with additional work (especially around the integration of the Wolfson devices) being done by myself.

---
 arch/arm/mach-s3c64xx/Kconfig             |   24 ++
 arch/arm/mach-s3c64xx/Makefile            |    1 +
 arch/arm/mach-s3c64xx/include/mach/irqs.h |    4 +-
 arch/arm/mach-s3c64xx/mach-crag6410.c     |  575 +++++++++++++++++++++++++++++
 4 files changed, 603 insertions(+), 1 deletions(-)
 create mode 100644 arch/arm/mach-s3c64xx/mach-crag6410.c

index e4177e2..ca36d9c 100644
@@ -266,3 +266,27 @@ config MACH_SMARTQ7
 	select MACH_SMARTQ
 	help
 	    Machine support for the SmartQ 7
+
+config MACH_WLF_CRAGG_6410
+	bool "Wolfson Cragganmore 6410"
+	select CPU_S3C6410
+	select S3C64XX_SETUP_SDHCI
+	select S3C64XX_SETUP_I2C1
+	select S3C64XX_SETUP_IDE
+	select S3C64XX_SETUP_FB_24BPP
+	select S3C64XX_SETUP_KEYPAD
+	select SAMSUNG_DEV_ADC
+	select SAMSUNG_DEV_KEYPAD
+	select S3C_DEV_USB_HOST
+	select S3C_DEV_USB_HSOTG
+	select S3C_DEV_HSMMC
+	select S3C_DEV_HSMMC1
+	select S3C_DEV_HSMMC2
+	select S3C_DEV_I2C1
+	select S3C_DEV_WDT
+	select S3C_DEV_RTC
+	select S3C64XX_DEV_SPI
+	select S3C24XX_GPIO_EXTRA128
+	help
+	  Machine support for the Wolfson Cragganmore S3C6410 variant.
+

index 4657363..88d7fd2 100644
@@ -59,6 +59,7 @@ obj-$(CONFIG_MACH_HMT)		+= mach-hmt.o
 obj-$(CONFIG_MACH_SMARTQ)	+= mach-smartq.o
 obj-$(CONFIG_MACH_SMARTQ5)	+= mach-smartq5.o
 obj-$(CONFIG_MACH_SMARTQ7)	+= mach-smartq7.o
+obj-$(CONFIG_MACH_WLF_CRAGG_6410) += mach-crag6410.o
 
 # device support
 

index 8e2df26..ddb63a1 100644
@@ -198,7 +198,9 @@
  * interrupt controllers). */
 #define IRQ_BOARD_START (IRQ_EINT_GROUP9_BASE + IRQ_EINT_GROUP9_NR + 1)
 
-#ifdef CONFIG_SMDK6410_WM1190_EV1
+#ifdef CONFIG_MACH_WLF_CRAGG_6410
+#define IRQ_BOARD_NR 128
+#elif defined(CONFIG_SMDK6410_WM1190_EV1)
 #define IRQ_BOARD_NR 64
 #elif defined(CONFIG_SMDK6410_WM1192_EV1)
 #define IRQ_BOARD_NR 64

1.7.4.1

(Cc'ing Russell King)

Hi Mark,

Looks ok after quickly review.

But I'm not sure this can be sent to upstream during the next merge window. Because of Linus' complaint, Russell does not want to add new stuff now, maybe you know. Basically my tree was sent to upstream via RMK when merge window.

Hmm...for now I will make some branch for new stuff like this and keep it until everyone is happy. Of course, if any consolidation work in Linux ARM world, I will update.

Or...if any good idea, please let me know :)

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <[email protected]>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.

Hrm, right. I had thought that the restriction there applied to the trees that Russell manages directly himself (the core ARM code) rather than those subtrees which he pulls in for the subarchitectures.

A separate tree, ideally merged into -next would be good (though of course that's not really the -next rules...) if we are going to stop doing any updates to machines.

I guess the other question is how is the device tree work for the Samsung CPUs going? Grant mentioned that you guys were actively working on this but I've not found any patches yet (and of course everything there is blocked on the core ARM device tree work).

Mark,

People (eg, Ingo) have been saying that the core ARM code is in good shape and is not a problem.

If you look at what Linus complained about, it was the platform stuff. It's the platform stuff which has got out of control, and we have common themes duplicated under different SoC classes.

Eg, why do we have two ways of managing SRAM - one for Davinci and one for OMAP? Why can't we have one way of declaring "here is the SRAM, please allocate X bytes from it" ? Really it's not about SRAM at all, but memory regions, so actually we need an allocator like the Davinci one but can be wrapped up and re-used not only for SRAM but other similar purposes as well (eg, where you need both the virtual and physical addresses.)

Thomas found in his IRQ cleanup patches that many of the ARM irqchip implementations were largely similar - again, why can't we have these commonalities merged?

Linus also complained about the 30 odd GPIO implementations - again its a similar question (but I'm thankful to see that some effort is being put into that.)

It's not the core ARM code which needs consolidating. It is the platform stuff which needs attention.

What scares me at the moment is that looking at the diffstat in linux-next, it looks to me like its business as usual for arch/arm, and we're heading again for another 60k line insertions for the next merge window.

And just remember this: at the last merge window, I deleted two SoC platforms and consolidated chunks of code for a bunch of ARM Ltd's development platforms - all of which got lost in the noise of new additions to arch/arm. There is no way that I can sort this out on my own - the problem is _far_ too big for any one individual to attack unless we permantly freeze arch/arm for the next few years against new additions.

At the moment, the only outcome I can see is that Linus is going to have another rant at the next merge window, and that will be game over for ARM in mainline.

We need more people taking Linus' concern seriously.

I know, I read and participated in the thread.

This is very true.

Indeed; however, that's the tree you manage so it seemed natural that this was the tree you were applying the rule to and you have already refused to take some core ARM code enhancements as a result of this policy and obviously there was the thread today with the clk API.

Hrm, looking at the stats currently I'm seeing only 5000 net insertions currently. But still, code size increases.

You're only seeing two extremes here, and I don't see that Linus having another rant is going to immediately result in ARM being thrown out of mainline. Reading the thread there seemed to be a general understanding that addressing this is a big project and we're not going to resolve anything immediately.

I think we can work on improving the situation in mainline without completely stalling new development, and I think that will help get manpower to work on the refactoring and consolidation that we need. If we can point at work that's progressing in the right direction that should be OK - there will probably be grumbling still, but there's engagement.

For example, if we identify specific areas for focus, especially those where we have realistic consolodations either in place or easy to implement (like the GPIOs with the memory mapped GPIOs, or the clock API if we get the common clock code merged), and push back hard on new code in those areas I think we've got a good chance of getting progress where we're focusing. A clear "you need to do this thing instead" has (in my exeperience) a reasonable shot at getting people to do whatever the other thing is, and even a "this needs to be done in a better way but I'm not sure what" can work. This sort of approach to gradual improvement in the framework and consolodation of common code has been working fairly well for us in the audio drivers.

A total refusal to accept any new code until there have been some non-specific general improvements in the architecture doesn't drive contributions in that way - it's just a flat no, it doesn't give people a route they can follow to make it possible to get whatever it is they're trying to do done in mainline. If there's no possibility of getting the end result included the motivation to work on mainline infrastructure (be that intrinsic motivation or making a case to managers that some time needs to be allocated) is damaged.

I think we need to offer people constructive routes to doing so. We need to set the bar on mainline contributions higher, but we also need to avoid setting the bar so high that we drive people away from mainline entirely.

I'm very concerned that if we stop accepting any new code at all for ARM into mainline then I think we're likely to cause serious damage to ARM support in mainline anyway - it'll drive the development effort for new silicon and boards out of mainline and back into vendor trees, right at a time when we're making headway in getting people working in mainline.