[PATCH] ARM: S3C64XX: Initial support for Wolfson/Simtec Cragganmore/Banff

[PATCH] ARM: S3C64XX: Initial support for Wolfson/Simtec Cragganmore/Banff

[Mark Brown]

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.

Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
 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

diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index e4177e2..ca36d9c 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -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.
+
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 4657363..88d7fd2 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -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
 
diff --git a/arch/arm/mach-s3c64xx/include/mach/irqs.h b/arch/arm/mach-s3c64xx/include/mach/irqs.h
index 8e2df26..ddb63a1 100644
--- a/arch/arm/mach-s3c64xx/include/mach/irqs.h
+++ b/arch/arm/mach-s3c64xx/include/mach/irqs.h
@@ -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
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c
new file mode 100644
index 0000000..3fc4e8e
--- /dev/null
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -0,0 +1,575 @@
+/* linux/arch/arm/mach-s3c64xx/mach-crag6410.c
+ *
+ * Copyright 2011 Wolfson Microelectronics plc
+ *	Mark Brown <broonie@opensource.wolfsonmicro.com>
+ *
+ * Copyright 2011 Simtec Electronics
+ *	Ben Dooks <ben@simtec.co.uk>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/serial_core.h>
+#include <linux/platform_device.h>
+#include <linux/fb.h>
+#include <linux/io.h>
+#include <linux/init.h>
+#include <linux/gpio.h>
+#include <linux/delay.h>
+#include <linux/regulator/machine.h>
+#include <linux/pwm_backlight.h>
+#include <linux/dm9000.h>
+#include <linux/gpio_keys.h>
+#include <linux/basic_mmio_gpio.h>
+#include <linux/spi/spi.h>
+
+#include <linux/i2c/pca953x.h>
+
+#include <video/platform_lcd.h>
+
+#include <linux/mfd/wm831x/core.h>
+#include <linux/mfd/wm831x/pdata.h>
+#include <linux/mfd/wm831x/gpio.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+
+#include <mach/hardware.h>
+#include <mach/map.h>
+
+#include <mach/s3c6410.h>
+#include <mach/regs-fb.h>
+#include <mach/regs-sys.h>
+#include <mach/regs-gpio.h>
+#include <mach/regs-modem.h>
+
+#include <mach/gpio-bank-o.h>
+#include <mach/regs-gpio-memport.h>
+
+#include <plat/regs-serial.h>
+#include <plat/fb.h>
+#include <plat/sdhci.h>
+#include <plat/gpio-cfg.h>
+#include <plat/s3c64xx-spi.h>
+
+#include <plat/keypad.h>
+#include <plat/clock.h>
+#include <plat/devs.h>
+#include <plat/cpu.h>
+#include <plat/adc.h>
+#include <plat/iic.h>
+#include <plat/pm.h>
+
+#define BANFF_PMIC_IRQ_BASE  IRQ_BOARD_START
+
+#define PCA935X_GPIO_BASE GPIO_BOARD_START
+#define CODEC_GPIO_BASE (GPIO_BOARD_START + 8)
+
+/* serial port setup */
+
+#define UCON (S3C2410_UCON_DEFAULT | S3C2410_UCON_UCLK)
+#define ULCON (S3C2410_LCON_CS8 | S3C2410_LCON_PNONE | S3C2410_LCON_STOPB)
+#define UFCON (S3C2410_UFCON_RXTRIG8 | S3C2410_UFCON_FIFOMODE)
+
+static struct s3c2410_uartcfg crag6410_uartcfgs[] __initdata = {
+	[0] = {
+		.hwport	     = 0,
+		.flags	     = 0,
+		.ucon	     = UCON,
+		.ulcon	     = ULCON,
+		.ufcon	     = UFCON,
+	},
+	[1] = {
+		.hwport	     = 1,
+		.flags	     = 0,
+		.ucon	     = UCON,
+		.ulcon	     = ULCON,
+		.ufcon	     = UFCON,
+	},
+	[2] = {
+		.hwport	     = 2,
+		.flags	     = 0,
+		.ucon	     = UCON,
+		.ulcon	     = ULCON,
+		.ufcon	     = UFCON,
+	},
+	[3] = {
+		.hwport	     = 3,
+		.flags	     = 0,
+		.ucon	     = UCON,
+		.ulcon	     = ULCON,
+		.ufcon	     = UFCON,
+	},
+};
+
+static struct platform_pwm_backlight_data crag6410_backlight_data = {
+	.pwm_id		= 0,
+	.max_brightness	= 1000,
+	.dft_brightness	= 600,
+	.pwm_period_ns	= 100000,	/* about 1kHz */
+};
+
+static struct platform_device crag6410_backlight_device = {
+	.name		= "pwm-backlight",
+	.id		= -1,
+	.dev		= {
+		.parent	= &s3c_device_timer[0].dev,
+		.platform_data = &crag6410_backlight_data,
+	},
+};
+
+static void crag6410_lcd_power_set(struct plat_lcd_data *pd, unsigned int power)
+{
+	pr_debug("%s: setting power %d\n", __func__, power);
+
+	if (power) {
+		gpio_set_value(S3C64XX_GPB(0), 1);
+		msleep(1);
+		s3c_gpio_cfgpin(S3C64XX_GPF(14), S3C_GPIO_SFN(2));
+	} else {
+		gpio_direction_output(S3C64XX_GPF(14), 0);
+		gpio_set_value(S3C64XX_GPB(0), 0);
+	}
+}
+
+static struct platform_device crag6410_lcd_powerdev = {
+	.name			= "platform-lcd",
+	.id			= -1,
+	.dev.parent		= &s3c_device_fb.dev,
+	.dev.platform_data	= &(struct plat_lcd_data) {
+		.set_power	= crag6410_lcd_power_set,
+	},
+};
+
+/* 640x480 URT */
+static struct s3c_fb_pd_win crag6410_fb_win0 = {
+	/* this is to ensure we use win0 */
+	.win_mode	= {
+		.left_margin	= 150,
+		.right_margin	= 80,
+		.upper_margin	= 40,
+		.lower_margin	= 5,
+		.hsync_len	= 40,
+		.vsync_len	= 5,
+		.xres		= 640,
+		.yres		= 480,
+	},
+	.max_bpp	= 32,
+	.default_bpp	= 16,
+	.virtual_y	= 480 * 2,
+	.virtual_x	= 640,
+};
+
+/* 405566 clocks per frame => 60Hz refresh requires 24333960Hz clock */
+static struct s3c_fb_platdata crag6410_lcd_pdata __initdata = {
+	.setup_gpio	= s3c64xx_fb_gpio_setup_24bpp,
+	.win[0]		= &crag6410_fb_win0,
+	.vidcon0	= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+	.vidcon1	= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+};
+
+/* 2x6 keypadd */
+
+static uint32_t crag6410_keymap[] __initdata = {
+	/* KEY(row, col, keycode) */
+	KEY(0, 0, KEY_VOLUMEUP),
+	KEY(0, 1, KEY_HOME),
+	KEY(0, 2, KEY_VOLUMEDOWN),
+	KEY(0, 3, KEY_HELP),
+	KEY(0, 4, KEY_MENU),
+	KEY(0, 5, KEY_MEDIA),
+	KEY(1, 0, 232),
+	KEY(1, 1, KEY_DOWN),
+	KEY(1, 2, KEY_LEFT),
+	KEY(1, 3, KEY_UP),
+	KEY(1, 4, KEY_RIGHT),
+	KEY(1, 5, KEY_CAMERA),
+};
+
+static struct matrix_keymap_data crag6410_keymap_data __initdata = {
+	.keymap		= crag6410_keymap,
+	.keymap_size	= ARRAY_SIZE(crag6410_keymap),
+};
+
+static struct samsung_keypad_platdata crag6410_keypad_data __initdata = {
+	.keymap_data	= &crag6410_keymap_data,
+	.rows		= 2,
+	.cols		= 6,
+};
+
+static struct gpio_keys_button crag6410_gpio_keys[] = {
+	[0] = {
+		.code	= KEY_SUSPEND,
+		.gpio	= S3C64XX_GPL(10),	/* EINT 18 */
+		.type	= EV_SW,
+		.wakeup	= 1,
+		.active_low = 1,
+	},
+};
+
+static struct gpio_keys_platform_data crag6410_gpio_keydata = {
+	.buttons	= crag6410_gpio_keys,
+	.nbuttons	= ARRAY_SIZE(crag6410_gpio_keys),
+};
+
+static struct platform_device crag6410_gpio_keydev = {
+	.name		= "gpio-keys",
+	.id		= 0,
+	.dev.platform_data = &crag6410_gpio_keydata,
+};
+
+static struct resource crag6410_dm9k_resource[] = {
+	[0] = {
+		.start	= S3C64XX_PA_XM0CSN5,
+		.end	= S3C64XX_PA_XM0CSN5 + 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= S3C64XX_PA_XM0CSN5 + (1 << 8),
+		.end	= S3C64XX_PA_XM0CSN5 + (1 << 8) + 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[2] = {
+		.start	= S3C_EINT(17),
+		.end	= S3C_EINT(17),
+		.flags	= IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
+	},
+};
+
+static struct dm9000_plat_data mini6410_dm9k_pdata = {
+	.flags	= DM9000_PLATF_16BITONLY,
+};
+
+static struct platform_device crag6410_dm9k_device = {
+	.name		= "dm9000",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(crag6410_dm9k_resource),
+	.resource	= crag6410_dm9k_resource,
+	.dev.platform_data = &mini6410_dm9k_pdata,
+};
+
+static struct resource crag6410_mmgpio_resource[] = {
+	[0] = {
+		.start	= S3C64XX_PA_XM0CSN4 + 1,
+		.end	= S3C64XX_PA_XM0CSN4 + 1,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device crag6410_mmgpio = {
+	.name		= "basic-mmio-gpio",
+	.id		= -1,
+	.resource	= crag6410_mmgpio_resource,
+	.num_resources	= ARRAY_SIZE(crag6410_mmgpio_resource),
+	.dev.platform_data = &(struct bgpio_pdata) {
+		.base	= -1,
+	},
+};
+
+static struct platform_device *crag6410_devices[] __initdata = {
+	&s3c_device_hsmmc0,
+	&s3c_device_hsmmc1,
+	&s3c_device_hsmmc2,
+	&s3c_device_i2c0,
+	&s3c_device_i2c1,
+	&s3c_device_fb,
+	&s3c_device_ohci,
+	&s3c_device_usb_hsotg,
+	&s3c_device_adc,
+	&s3c_device_rtc,
+	&s3c_device_ts,
+	&s3c_device_timer[0],
+	&s3c64xx_device_iis0,
+	&s3c64xx_device_iis1,
+	&samsung_asoc_dma,
+	&samsung_device_keypad,
+	&crag6410_gpio_keydev,
+	&crag6410_dm9k_device,
+	&s3c64xx_device_spi0,
+	&crag6410_mmgpio,
+	&crag6410_lcd_powerdev,
+	&crag6410_backlight_device,
+};
+
+static struct pca953x_platform_data crag6410_pca_data = {
+	.gpio_base	= PCA935X_GPIO_BASE,
+	.irq_base	= 0,
+};
+
+static struct regulator_consumer_supply vddarm_consumers[] __initdata  = {
+	REGULATOR_SUPPLY("vddarm", NULL),
+};
+
+static struct regulator_init_data vddarm __initdata = {
+	.constraints = {
+		.name = "VDDARM",
+		.min_uV = 1000000,
+		.max_uV = 1300000,
+		.always_on = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(vddarm_consumers),
+	.consumer_supplies = vddarm_consumers,
+};
+
+static struct regulator_init_data vddint __initdata = {
+	.constraints = {
+		.name = "VDDINT",
+		.min_uV = 1000000,
+		.max_uV = 1200000,
+		.always_on = 1,
+		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+	},
+};
+
+static struct regulator_init_data vddmem __initdata = {
+	.constraints = {
+		.name = "VDDMEM",
+		.always_on = 1,
+	},
+};
+
+static struct regulator_init_data vddsys __initdata = {
+	.constraints = {
+		.name = "VDDSYS,VDDEXT,VDDPCM,VDDSS",
+		.always_on = 1,
+	},
+};
+
+static struct regulator_consumer_supply vddmmc_consumers[] __initdata  = {
+	REGULATOR_SUPPLY("vmmc", "s3c-sdhci.0"),
+	REGULATOR_SUPPLY("vmmc", "s3c-sdhci.1"),
+	REGULATOR_SUPPLY("vmmc", "s3c-sdhci.2"),
+};
+
+static struct regulator_init_data vddmmc __initdata = {
+	.constraints = {
+		.name = "VDDMMC,UH",
+		.always_on = 1,
+	},
+	.num_consumer_supplies = ARRAY_SIZE(vddmmc_consumers),
+	.consumer_supplies = vddmmc_consumers,
+};
+
+
+static struct regulator_init_data vddotgi __initdata = {
+	.constraints = {
+		.name = "VDDOTGi",
+		.always_on = 1,
+	},
+};
+
+static struct regulator_init_data vddotg __initdata = {
+	.constraints = {
+		.name = "VDDOTG",
+		.always_on = 1,
+	},
+};
+
+static struct regulator_init_data vddhi __initdata = {
+	.constraints = {
+		.name = "VDDHI",
+		.always_on = 1,
+	},
+};
+
+static struct regulator_init_data vddadc __initdata = {
+	.constraints = {
+		.name = "VDDADC,VDDDAC",
+		.always_on = 1,
+	},
+};
+
+static struct regulator_init_data vddmem0 __initdata = {
+	.constraints = {
+		.name = "VDDMEM0",
+		.always_on = 1,
+	},
+};
+
+static struct regulator_init_data vddpll __initdata = {
+	.constraints = {
+		.name = "VDDPLL",
+		.always_on = 1,
+	},
+};
+
+static struct regulator_init_data vddlcd __initdata = {
+	.constraints = {
+		.name = "VDDLCD",
+		.always_on = 1,
+	},
+};
+
+static struct regulator_init_data vddalive __initdata = {
+	.constraints = {
+		.name = "VDDALIVE",
+		.always_on = 1,
+	},
+};
+
+static struct wm831x_status_pdata banff_red_led __initdata = {
+	.name = "banff:red:",
+	.default_src = WM831X_STATUS_MANUAL,
+};
+
+static struct wm831x_status_pdata banff_green_led __initdata = {
+	.name = "banff:green:",
+	.default_src = WM831X_STATUS_MANUAL,
+};
+
+static struct wm831x_touch_pdata touch_pdata __initdata = {
+	.data_irq = S3C_EINT(26),
+};
+
+static __init int crag_pmic_pre_init(struct wm831x *wm831x)
+{
+	/* Touchscreen data IRQ - CMOS, DBVDD, active high*/
+	wm831x_reg_write(wm831x, WM831X_GPIO11_CONTROL,
+			 WM831X_GPN_POL | WM831X_GPN_ENA | 0x6);
+
+	/* Touchscreen pen down IRQ - CMOS, DBVDD, active high*/
+	wm831x_reg_write(wm831x, WM831X_GPIO12_CONTROL,
+			 WM831X_GPN_POL | WM831X_GPN_ENA | 0x7);
+
+	return 0;
+}
+
+static struct wm831x_pdata crag_pmic_pdata __initdata = {
+	.pre_init = crag_pmic_pre_init,
+
+	.irq_base = BANFF_PMIC_IRQ_BASE,
+	.gpio_base = GPIO_BOARD_START + 8,
+
+	.dcdc = {
+		&vddarm,  /* DCDC1 */
+		&vddint,  /* DCDC2 */
+		&vddmem,  /* DCDC3 */
+	},
+
+	.ldo = {
+		 &vddsys,   /* LDO1 */
+		 &vddmmc,   /* LDO2 */
+		 NULL,      /* LDO3 */
+		 &vddotgi,  /* LDO4 */
+		 &vddotg,   /* LDO5 */
+		 &vddhi,    /* LDO6 */
+		 &vddadc,   /* LDO7 */
+		 &vddmem0,  /* LDO8 */
+		 &vddpll,   /* LDO9 */
+		 &vddlcd,   /* LDO10 */
+		 &vddalive, /* LDO11 */
+	 },
+
+	.status = {
+		 &banff_green_led,
+		 &banff_red_led,
+	 },
+
+	.touch = &touch_pdata,
+};
+
+static struct i2c_board_info i2c_devs0[] __initdata = {
+	{ I2C_BOARD_INFO("24c08", 0x50), },
+	{ I2C_BOARD_INFO("tca6408", 0x20),
+	  .platform_data = &crag6410_pca_data,
+	},
+	{ I2C_BOARD_INFO("wm8312", 0x34),
+	  .platform_data = &crag_pmic_pdata,
+	  .irq = S3C_EINT(23),
+	},
+};
+
+static struct s3c2410_platform_i2c i2c0_pdata = {
+	.frequency = 400000,
+};
+
+static struct i2c_board_info i2c_devs1[] __initdata = {
+	{ I2C_BOARD_INFO("wm8311", 0x34),
+	  .platform_data = &glenfarclas_pmic_pdata,
+	},
+};
+
+static void __init crag6410_map_io(void)
+{
+	s3c64xx_init_io(NULL, 0);
+	s3c24xx_init_clocks(12000000);
+	s3c24xx_init_uarts(crag6410_uartcfgs, ARRAY_SIZE(crag6410_uartcfgs));
+
+	/* LCD type and Bypass set by bootloader */
+}
+
+static struct s3c_sdhci_platdata crag6410_hsmmc2_pdata = {
+	.max_width		= 4,
+	.cd_type		= S3C_SDHCI_CD_PERMANENT,
+};
+
+static struct s3c_sdhci_platdata crag6410_hsmmc1_pdata = {
+	.max_width		= 4,
+	.cd_type		= S3C_SDHCI_CD_GPIO,
+	.ext_cd_gpio		= S3C64XX_GPF(11),
+};
+
+static void crag6410_cfg_sdhci0(struct platform_device *dev, int width)
+{
+	/* Set all the necessary GPG pins to special-function 2 */
+	s3c_gpio_cfgrange_nopull(S3C64XX_GPG(0), 2 + width, S3C_GPIO_SFN(2));
+
+	/* force card-detected for prototype 0 */
+	s3c_gpio_setpull(S3C64XX_GPG(6), S3C_GPIO_PULL_DOWN);
+}
+
+static struct s3c_sdhci_platdata crag6410_hsmmc0_pdata = {
+	.max_width		= 4,
+	.cd_type		= S3C_SDHCI_CD_INTERNAL,
+	.cfg_gpio		= crag6410_cfg_sdhci0,
+};
+
+static void __init crag6410_machine_init(void)
+{
+	/* Open drain IRQs need pullups */
+	s3c_gpio_setpull(S3C64XX_GPM(0), S3C_GPIO_PULL_UP);
+	s3c_gpio_setpull(S3C64XX_GPN(0), S3C_GPIO_PULL_UP);
+
+	gpio_request(S3C64XX_GPB(0), "LCD power");
+	gpio_direction_output(S3C64XX_GPB(0), 0);
+
+	gpio_request(S3C64XX_GPF(14), "LCD PWM");
+	gpio_direction_output(S3C64XX_GPF(14), 0);  /* turn off */
+
+	gpio_request(S3C64XX_GPB(1), "SD power");
+	gpio_direction_output(S3C64XX_GPB(1), 0);
+
+	gpio_request(S3C64XX_GPF(10), "nRESETSEL");
+	gpio_direction_output(S3C64XX_GPF(10), 1);
+
+	s3c_sdhci0_set_platdata(&crag6410_hsmmc0_pdata);
+	s3c_sdhci1_set_platdata(&crag6410_hsmmc1_pdata);
+	s3c_sdhci2_set_platdata(&crag6410_hsmmc2_pdata);
+
+	s3c_i2c0_set_platdata(&i2c0_pdata);
+	s3c_i2c1_set_platdata(NULL);
+	s3c_fb_set_platdata(&crag6410_lcd_pdata);
+
+	i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
+	i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
+
+	samsung_keypad_set_platdata(&crag6410_keypad_data);
+
+	platform_add_devices(crag6410_devices, ARRAY_SIZE(crag6410_devices));
+
+	s3c_pm_init();
+}
+
+MACHINE_START(WLF_CRAGG_6410, "Wolfson Cragganmore 6410")
+	/* Maintainer: Mark Brown <broonie@opensource.wolfsonmicro.com> */
+	.boot_params	= S3C64XX_PA_SDRAM + 0x100,
+	.init_irq	= s3c6410_init_irq,
+	.map_io		= crag6410_map_io,
+	.init_machine	= crag6410_machine_init,
+	.timer		= &s3c24xx_timer,
+MACHINE_END
-- 
1.7.4.1

[PATCH] ARM: S3C64XX: Initial support for Wolfson/Simtec Cragganmore/Banff

[Kukjin Kim]

Mark Brown wrote:
> 
> 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.
> 
> Signed-off-by: Ben Dooks <ben@simtec.co.uk>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> ---
>  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
> 
(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 <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

[PATCH] ARM: S3C64XX: Initial support for Wolfson/Simtec Cragganmore/Banff

[Mark Brown]

On Thu, Apr 14, 2011 at 07:56:22AM +0900, Kukjin Kim wrote:

> 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.

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.

> 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 :)

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).

[PATCH] ARM: S3C64XX: Initial support for Wolfson/Simtec Cragganmore/Banff

[Russell King - ARM Linux]

On Wed, Apr 13, 2011 at 06:24:08PM -0700, Mark Brown wrote:
> On Thu, Apr 14, 2011 at 07:56:22AM +0900, Kukjin Kim wrote:
> > 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.
> 
> 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.

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.

[PATCH] ARM: S3C64XX: Initial support for Wolfson/Simtec Cragganmore/Banff

[Mark Brown]

On Thu, Apr 14, 2011 at 11:14:31AM +0100, Russell King - ARM Linux wrote:

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

I know, I read and participated in the thread.

> 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.

This is very true.

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

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.

> 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.

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

> 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.

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.

> We need more people taking Linus' concern seriously.

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.