[GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15

[GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

please consider these Renesas ARM based SoC board updates for v3.15.


The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:

  Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards-for-v3.15

for you to fetch changes up to 235cda29e4d5047622ff9b82b1f0b4cb6cf95f6c:

  ARM: shmobile: Remove Lager USBHS UDC ifdefs (2014-02-04 14:28:33 +0900)

----------------------------------------------------------------
Renesas ARM based SoC Board Updates for v3.15

* r8a7791 (R-Car M2) based Koelsch board
  - Fix error return code check from clk_get()
  - Add SATA0 support
  - Conditionally select MICREL_PHY for Multiplatform

* r8a7790 (R-Car H2) based Lager board
  - Add USBHS support
  - Fix error return code check from clk_get()
  - Add SATA support
  - Make spi_flash_data const
  - Add VIN1 SoC camera support
  - Conditionally select CONFIG_MICREL_PHY

* r8a7778 (R-Car M1) based Bock-W board
  - Add USB Func DMAEngine support
  - Use HPBIF DMAEngine for sound
  - Use SSI DMAEngine for sound

* emev2 (Emma Mobile EV2) based kzm9d board
  - Use common clock framework

* r8a773a0 (SH-Mobile AG5) based kzm9g board
  - Add zboot support

* Many boards
  - Conditionally select SMSC_PHY

----------------------------------------------------------------
Ben Dooks (2):
      ARM: shmobile: lager: fix error return code check from clk_get()
      ARM: shmobile: koelsch: fix error return code check from clk_get()

Geert Uytterhoeven (1):
      ARM: shmobile: lager: Make spi_flash_data const

Kuninori Morimoto (3):
      ARM: shmobile: bockw: use SSI DMAEngine for sound
      ARM: shmobile: bockw: use HPBIF DMAEngine for sound
      ARM: shmobile: bockw: add USB Func DMAEngine support

Magnus Damm (1):
      ARM: shmobile: Remove Lager USBHS UDC ifdefs

Sergei Shtylyov (1):
      ARM: shmobile: Lager: conditionally select CONFIG_MICREL_PHY

Simon Horman (7):
      ARM: shmobile: koelsch: Conditionally select MICREL_PHY for Multiplatform
      ARM: shmobile: ape6evm: Conditionally select SMSC_PHY
      ARM: shmobile: armadillo800eva: Conditionally select SMSC_PHY
      ARM: shmobile: bockw: Sort Kconfig node's selections
      ARM: shmobile: kzm9d: Conditionally select SMSC_PHY
      ARM: shmobile: mackerel: Conditionally select SMSC_PHY
      ARM: shmobile: marzen: Conditionally select SMSC_PHY

Takashi Yoshii (1):
      ARM: shmobile: kzm9d: Use common clock framework

Ulrich Hecht (1):
      ARM: mach-shmobile: kzm9g: add zboot support

Valentine Barshak (4):
      ARM: shmobile: lager: Add VIN1 SoC camera support
      ARM: shmobile: lager: Add SATA support
      ARM: shmobile: koelsch: Add SATA0 support
      ARM: shmobile: lager: Add USBHS support

 arch/arm/mach-shmobile/Kconfig                     |  15 +-
 arch/arm/mach-shmobile/board-bockw.c               |  24 +-
 arch/arm/mach-shmobile/board-koelsch-reference.c   |   4 +-
 arch/arm/mach-shmobile/board-koelsch.c             |  17 +
 arch/arm/mach-shmobile/board-kzm9d-reference.c     |   5 +-
 arch/arm/mach-shmobile/board-lager-reference.c     |   4 +-
 arch/arm/mach-shmobile/board-lager.c               | 229 +++++++++++-
 arch/arm/mach-shmobile/include/mach/head-kzm9g.txt | 410 +++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/zboot.h        |   3 +
 arch/arm/mach-shmobile/include/mach/zboot_macros.h |  43 +++
 10 files changed, 737 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/include/mach/head-kzm9g.txt

[PATCH 01/21] ARM: shmobile: Lager: conditionally select CONFIG_MICREL_PHY

[Simon Horman]

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Now that support for KSZ8041RNLI is added to the Micrel PHY driver and we intend
to support PHY IRQs on the Lager board, we have to enable the Micrel driver.
Do this by selecting CONFIG_MICREL_PHY for Lager if CONFIG_SH_ETH is enabled.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 3386406..a127252 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -54,6 +54,7 @@ config MACH_KZM9D
 config MACH_LAGER
 	bool "Lager board"
 	depends on ARCH_R8A7790
+	select MICREL_PHY if SH_ETH
 
 comment "Renesas ARM SoCs System Configuration"
 endif
@@ -261,6 +262,7 @@ config MACH_LAGER
 	bool "Lager board"
 	depends on ARCH_R8A7790
 	select USE_OF
+	select MICREL_PHY if SH_ETH
 
 config MACH_KOELSCH
 	bool "Koelsch board"
-- 
1.8.5.2

[PATCH 02/21] ARM: shmobile: bockw: use SSI DMAEngine for sound

[Simon Horman]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

R-Car sound driver is supporting Mem <-> SSI
direct transfer via DMAEngine.
Current HPB-DMA is using double plane transfer,
but the sound may have noise since SSI doesn't have FIFO.
This patch supports it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-bockw.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c
index c475220..bdb78a7 100644
--- a/arch/arm/mach-shmobile/board-bockw.c
+++ b/arch/arm/mach-shmobile/board-bockw.c
@@ -332,12 +332,12 @@ static struct rsnd_ssi_platform_info rsnd_ssi[] = {
 	RSND_SSI_UNUSED, /* SSI 0 */
 	RSND_SSI_UNUSED, /* SSI 1 */
 	RSND_SSI_UNUSED, /* SSI 2 */
-	RSND_SSI_SET(1, 0, gic_iid(0x85), RSND_SSI_PLAY),
-	RSND_SSI_SET(2, 0, gic_iid(0x85), RSND_SSI_CLK_PIN_SHARE),
-	RSND_SSI_SET(0, 0, gic_iid(0x86), RSND_SSI_PLAY),
-	RSND_SSI_SET(0, 0, gic_iid(0x86), 0),
-	RSND_SSI_SET(3, 0, gic_iid(0x86), RSND_SSI_PLAY),
-	RSND_SSI_SET(4, 0, gic_iid(0x86), RSND_SSI_CLK_PIN_SHARE),
+	RSND_SSI_SET(1, HPBDMA_SLAVE_SSI3_TX, gic_iid(0x85), RSND_SSI_PLAY),
+	RSND_SSI_SET(2, HPBDMA_SLAVE_SSI4_RX, gic_iid(0x85), RSND_SSI_CLK_PIN_SHARE),
+	RSND_SSI_SET(0, HPBDMA_SLAVE_SSI5_TX, gic_iid(0x86), RSND_SSI_PLAY),
+	RSND_SSI_SET(0, HPBDMA_SLAVE_SSI6_RX, gic_iid(0x86), 0),
+	RSND_SSI_SET(3, HPBDMA_SLAVE_SSI7_TX, gic_iid(0x86), RSND_SSI_PLAY),
+	RSND_SSI_SET(4, HPBDMA_SLAVE_SSI8_RX, gic_iid(0x86), RSND_SSI_CLK_PIN_SHARE),
 };
 
 static struct rsnd_scu_platform_info rsnd_scu[9] = {
-- 
1.8.5.2

[PATCH 03/21] ARM: shmobile: bockw: use HPBIF DMAEngine for sound

[Simon Horman]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

R-Car sound driver is supporting Mem <-> SRU <-> SSI
transfer via DMAEngine.
The sound will be less noise if it uses SRU path
since it has FIFO.
This patch supports it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-bockw.c | 22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c
index bdb78a7..24b4161 100644
--- a/arch/arm/mach-shmobile/board-bockw.c
+++ b/arch/arm/mach-shmobile/board-bockw.c
@@ -332,16 +332,24 @@ static struct rsnd_ssi_platform_info rsnd_ssi[] = {
 	RSND_SSI_UNUSED, /* SSI 0 */
 	RSND_SSI_UNUSED, /* SSI 1 */
 	RSND_SSI_UNUSED, /* SSI 2 */
-	RSND_SSI_SET(1, HPBDMA_SLAVE_SSI3_TX, gic_iid(0x85), RSND_SSI_PLAY),
-	RSND_SSI_SET(2, HPBDMA_SLAVE_SSI4_RX, gic_iid(0x85), RSND_SSI_CLK_PIN_SHARE),
-	RSND_SSI_SET(0, HPBDMA_SLAVE_SSI5_TX, gic_iid(0x86), RSND_SSI_PLAY),
-	RSND_SSI_SET(0, HPBDMA_SLAVE_SSI6_RX, gic_iid(0x86), 0),
-	RSND_SSI_SET(3, HPBDMA_SLAVE_SSI7_TX, gic_iid(0x86), RSND_SSI_PLAY),
-	RSND_SSI_SET(4, HPBDMA_SLAVE_SSI8_RX, gic_iid(0x86), RSND_SSI_CLK_PIN_SHARE),
+	RSND_SSI_SET(1, HPBDMA_SLAVE_HPBIF3_TX, gic_iid(0x85), RSND_SSI_PLAY),
+	RSND_SSI_SET(2, HPBDMA_SLAVE_HPBIF4_RX, gic_iid(0x85), RSND_SSI_CLK_PIN_SHARE),
+	RSND_SSI_SET(0, HPBDMA_SLAVE_HPBIF5_TX, gic_iid(0x86), RSND_SSI_PLAY),
+	RSND_SSI_SET(0, HPBDMA_SLAVE_HPBIF6_RX, gic_iid(0x86), 0),
+	RSND_SSI_SET(3, HPBDMA_SLAVE_HPBIF7_TX, gic_iid(0x86), RSND_SSI_PLAY),
+	RSND_SSI_SET(4, HPBDMA_SLAVE_HPBIF8_RX, gic_iid(0x86), RSND_SSI_CLK_PIN_SHARE),
 };
 
 static struct rsnd_scu_platform_info rsnd_scu[9] = {
-	/* no member at this point */
+	{ .flags = 0, }, /* SRU 0 */
+	{ .flags = 0, }, /* SRU 1 */
+	{ .flags = 0, }, /* SRU 2 */
+	{ .flags = RSND_SCU_USE_HPBIF, },
+	{ .flags = RSND_SCU_USE_HPBIF, },
+	{ .flags = RSND_SCU_USE_HPBIF, },
+	{ .flags = RSND_SCU_USE_HPBIF, },
+	{ .flags = RSND_SCU_USE_HPBIF, },
+	{ .flags = RSND_SCU_USE_HPBIF, },
 };
 
 enum {
-- 
1.8.5.2

[PATCH 04/21] ARM: shmobile: bockw: add USB Func DMAEngine support

[Simon Horman]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-bockw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-bockw.c b/arch/arm/mach-shmobile/board-bockw.c
index 24b4161..684a529 100644
--- a/arch/arm/mach-shmobile/board-bockw.c
+++ b/arch/arm/mach-shmobile/board-bockw.c
@@ -168,6 +168,8 @@ static struct renesas_usbhs_platform_info usbhs_info __initdata = {
 	},
 	.driver_param = {
 		.buswait_bwait	= 4,
+		.d0_tx_id	= HPBDMA_SLAVE_USBFUNC_TX,
+		.d1_rx_id	= HPBDMA_SLAVE_USBFUNC_RX,
 	},
 };
 
-- 
1.8.5.2

[PATCH 05/21] ARM: shmobile: koelsch: Conditionally select MICREL_PHY for Multiplatform

[Simon Horman]

The koelsch board uses has an SH ethernet controller which uses a Micrel
phy. Select MICREL_PHY for koelsch if SH_ETH is enabled to make use of the
Micrel-specific phy driver rather than relying on the generic phy driver.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index a127252..958ccf3d 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -45,6 +45,7 @@ config MACH_GENMAI
 config MACH_KOELSCH
 	bool "Koelsch board"
 	depends on ARCH_R8A7791
+	select MICREL_PHY if SH_ETH
 
 config MACH_KZM9D
 	bool "KZM9D board"
-- 
1.8.5.2

[PATCH 06/21] ARM: mach-shmobile: kzm9g: add zboot support

[Simon Horman]

From: Ulrich Hecht <ulrich.hecht@gmail.com>

Adds support to run the kernel on the uninitialized KZM9G board, using for
instance the mask ROM boot loader or JTAG. This patch tries to emulate the
style of the corresponding "mackerel" implementation. The DRAM controller
setup code has been adapted from u-boot.

Signed-off-by: Ulrich Hecht <ulrich.hecht@gmail.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/include/mach/head-kzm9g.txt | 410 +++++++++++++++++++++
 arch/arm/mach-shmobile/include/mach/zboot.h        |   3 +
 arch/arm/mach-shmobile/include/mach/zboot_macros.h |  43 +++
 3 files changed, 456 insertions(+)
 create mode 100644 arch/arm/mach-shmobile/include/mach/head-kzm9g.txt

diff --git a/arch/arm/mach-shmobile/include/mach/head-kzm9g.txt b/arch/arm/mach-shmobile/include/mach/head-kzm9g.txt
new file mode 100644
index 0000000..9531f46
--- /dev/null
+++ b/arch/arm/mach-shmobile/include/mach/head-kzm9g.txt
@@ -0,0 +1,410 @@
+LIST "KZM9G low-level initialization routine."
+LIST "Adapted from u-boot KZM9G support code."
+
+LIST "Copyright (C) 2013 Ulrich Hecht"
+
+LIST "This program is free software; you can redistribute it and/or modify"
+LIST "it under the terms of the GNU General Public License version 2 as"
+LIST "published by the Free Software Foundation."
+
+LIST "This program is distributed in the hope that it will be useful,"
+LIST "but WITHOUT ANY WARRANTY; without even the implied warranty of"
+LIST "MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the"
+LIST "GNU General Public License for more details."
+
+
+LIST "Register definitions:"
+
+LIST "Secure control register"
+#define LIFEC_SEC_SRC (0xE6110008)
+
+LIST "RWDT"
+#define RWDT_BASE   (0xE6020000)
+#define RWTCSRA0 (RWDT_BASE + 0x04)
+
+LIST "HPB Semaphore Control Registers"
+#define HPBSCR_BASE (0xE6000000)
+#define HPBCTRL6 (HPBSCR_BASE + 0x1030)
+
+#define SBSC1_BASE  (0xFE400000)
+#define SDCR0A		(SBSC1_BASE + 0x0008)
+#define SDCR1A		(SBSC1_BASE + 0x000C)
+#define SDPCRA		(SBSC1_BASE + 0x0010)
+#define SDCR0SA		(SBSC1_BASE + 0x0018)
+#define SDCR1SA		(SBSC1_BASE + 0x001C)
+#define RTCSRA		(SBSC1_BASE + 0x0020)
+#define RTCORA		(SBSC1_BASE + 0x0028)
+#define RTCORHA		(SBSC1_BASE + 0x002C)
+#define SDWCRC0A	(SBSC1_BASE + 0x0040)
+#define SDWCRC1A	(SBSC1_BASE + 0x0044)
+#define SDWCR00A	(SBSC1_BASE + 0x0048)
+#define SDWCR01A	(SBSC1_BASE + 0x004C)
+#define SDWCR10A	(SBSC1_BASE + 0x0050)
+#define SDWCR11A	(SBSC1_BASE + 0x0054)
+#define SDWCR2A		(SBSC1_BASE + 0x0060)
+#define SDWCRC2A	(SBSC1_BASE + 0x0064)
+#define ZQCCRA		(SBSC1_BASE + 0x0068)
+#define SDMRACR0A	(SBSC1_BASE + 0x0084)
+#define SDMRTMPCRA	(SBSC1_BASE + 0x008C)
+#define SDMRTMPMSKA	(SBSC1_BASE + 0x0094)
+#define SDGENCNTA	(SBSC1_BASE + 0x009C)
+#define SDDRVCR0A	(SBSC1_BASE + 0x00B4)
+#define DLLCNT0A	(SBSC1_BASE + 0x0354)
+
+#define SDMRA1  (0xFE500000)
+#define SDMRA2  (0xFE5C0000)
+#define SDMRA3  (0xFE504000)
+
+#define SBSC2_BASE  (0xFB400000)
+#define SDCR0B		(SBSC2_BASE + 0x0008)
+#define SDCR1B		(SBSC2_BASE + 0x000C)
+#define SDPCRB		(SBSC2_BASE + 0x0010)
+#define SDCR0SB		(SBSC2_BASE + 0x0018)
+#define SDCR1SB		(SBSC2_BASE + 0x001C)
+#define RTCSRB		(SBSC2_BASE + 0x0020)
+#define RTCORB		(SBSC2_BASE + 0x0028)
+#define RTCORHB		(SBSC2_BASE + 0x002C)
+#define SDWCRC0B	(SBSC2_BASE + 0x0040)
+#define SDWCRC1B	(SBSC2_BASE + 0x0044)
+#define SDWCR00B	(SBSC2_BASE + 0x0048)
+#define SDWCR01B	(SBSC2_BASE + 0x004C)
+#define SDWCR10B	(SBSC2_BASE + 0x0050)
+#define SDWCR11B	(SBSC2_BASE + 0x0054)
+#define SDPDCR0B	(SBSC2_BASE + 0x0058)
+#define SDWCR2B		(SBSC2_BASE + 0x0060)
+#define SDWCRC2B	(SBSC2_BASE + 0x0064)
+#define ZQCCRB		(SBSC2_BASE + 0x0068)
+#define SDMRACR0B	(SBSC2_BASE + 0x0084)
+#define SDMRTMPCRB	(SBSC2_BASE + 0x008C)
+#define SDMRTMPMSKB	(SBSC2_BASE + 0x0094)
+#define SDGENCNTB	(SBSC2_BASE + 0x009C)
+#define DPHYCNT0B	(SBSC2_BASE + 0x00A0)
+#define DPHYCNT1B	(SBSC2_BASE + 0x00A4)
+#define DPHYCNT2B	(SBSC2_BASE + 0x00A8)
+#define SDDRVCR0B	(SBSC2_BASE + 0x00B4)
+#define DLLCNT0B	(SBSC2_BASE + 0x0354)
+
+#define SDMRB1  (0xFB500000)
+#define SDMRB2  (0xFB5C0000)
+#define SDMRB3  (0xFB504000)
+
+#define CPG_BASE   (0xE6150000)
+#define FRQCRA		(CPG_BASE + 0x0000)
+#define FRQCRB		(CPG_BASE + 0x0004)
+#define FRQCRD		(CPG_BASE + 0x00E4)
+#define VCLKCR1		(CPG_BASE + 0x0008)
+#define VCLKCR2		(CPG_BASE + 0x000C)
+#define VCLKCR3		(CPG_BASE + 0x001C)
+#define ZBCKCR		(CPG_BASE + 0x0010)
+#define FLCKCR		(CPG_BASE + 0x0014)
+#define SD0CKCR		(CPG_BASE + 0x0074)
+#define SD1CKCR		(CPG_BASE + 0x0078)
+#define SD2CKCR		(CPG_BASE + 0x007C)
+#define FSIACKCR	(CPG_BASE + 0x0018)
+#define SUBCKCR		(CPG_BASE + 0x0080)
+#define SPUACKCR	(CPG_BASE + 0x0084)
+#define SPUVCKCR	(CPG_BASE + 0x0094)
+#define MSUCKCR		(CPG_BASE + 0x0088)
+#define HSICKCR		(CPG_BASE + 0x008C)
+#define FSIBCKCR	(CPG_BASE + 0x0090)
+#define MFCK1CR		(CPG_BASE + 0x0098)
+#define MFCK2CR		(CPG_BASE + 0x009C)
+#define DSITCKCR	(CPG_BASE + 0x0060)
+#define DSI0PCKCR	(CPG_BASE + 0x0064)
+#define DSI1PCKCR	(CPG_BASE + 0x0068)
+#define DSI0PHYCR	(CPG_BASE + 0x006C)
+#define DVFSCR3		(CPG_BASE + 0x0174)
+#define DVFSCR4		(CPG_BASE + 0x0178)
+#define DVFSCR5		(CPG_BASE + 0x017C)
+#define MPMODE		(CPG_BASE + 0x00CC)
+
+#define PLLECR		(CPG_BASE + 0x00D0)
+#define PLL0CR		(CPG_BASE + 0x00D8)
+#define PLL1CR		(CPG_BASE + 0x0028)
+#define PLL2CR		(CPG_BASE + 0x002C)
+#define PLL3CR		(CPG_BASE + 0x00DC)
+#define PLL0STPCR	(CPG_BASE + 0x00F0)
+#define PLL1STPCR	(CPG_BASE + 0x00C8)
+#define PLL2STPCR	(CPG_BASE + 0x00F8)
+#define PLL3STPCR	(CPG_BASE + 0x00FC)
+#define RMSTPCR0	(CPG_BASE + 0x0110)
+#define RMSTPCR1	(CPG_BASE + 0x0114)
+#define RMSTPCR2	(CPG_BASE + 0x0118)
+#define RMSTPCR3	(CPG_BASE + 0x011C)
+#define RMSTPCR4	(CPG_BASE + 0x0120)
+#define RMSTPCR5	(CPG_BASE + 0x0124)
+#define SMSTPCR0	(CPG_BASE + 0x0130)
+#define SMSTPCR2	(CPG_BASE + 0x0138)
+#define SMSTPCR3	(CPG_BASE + 0x013C)
+#define CPGXXCR4	(CPG_BASE + 0x0150)
+#define SRCR0		(CPG_BASE + 0x80A0)
+#define SRCR2		(CPG_BASE + 0x80B0)
+#define SRCR3		(CPG_BASE + 0x80A8)
+#define VREFCR		(CPG_BASE + 0x00EC)
+#define PCLKCR		(CPG_BASE + 0x1020)
+
+#define PORT32CR (0xE6051020)
+#define PORT33CR (0xE6051021)
+#define PORT34CR (0xE6051022)
+#define PORT35CR (0xE6051023)
+
+LIST "DRAM initialization code:"
+
+EW RWTCSRA0, 0xA507
+
+ED_AND LIFEC_SEC_SRC, 0xFFFF7FFF
+
+ED_AND SMSTPCR3,0xFFFF7FFF
+ED_AND SRCR3, 0xFFFF7FFF
+ED_AND SMSTPCR2,0xFFFBFFFF
+ED_AND SRCR2, 0xFFFBFFFF
+ED PLLECR, 0x00000000
+
+WAIT_MASK PLLECR, 0x00000F00, 0x00000000
+WAIT_MASK FRQCRB, 0x80000000, 0x00000000
+
+ED PLL0CR, 0x2D000000
+ED PLL1CR, 0x17100000
+ED FRQCRB, 0x96235880
+WAIT_MASK FRQCRB, 0x80000000, 0x00000000
+
+ED FLCKCR, 0x0000000B
+ED_AND SMSTPCR0, 0xFFFFFFFD
+
+ED_AND SRCR0, 0xFFFFFFFD
+ED 0xE6001628, 0x514
+ED 0xE6001648, 0x514
+ED 0xE6001658, 0x514
+ED 0xE6001678, 0x514
+
+ED DVFSCR4, 0x00092000
+ED DVFSCR5, 0x000000DC
+ED PLLECR, 0x00000000
+WAIT_MASK PLLECR, 0x00000F00, 0x00000000
+
+ED FRQCRA, 0x0012453C
+ED FRQCRB, 0x80431350
+WAIT_MASK FRQCRB, 0x80000000, 0x00000000
+ED FRQCRD, 0x00000B0B
+WAIT_MASK FRQCRD, 0x80000000, 0x00000000
+
+ED PCLKCR, 0x00000003
+ED VCLKCR1, 0x0000012F
+ED VCLKCR2, 0x00000119
+ED VCLKCR3, 0x00000119
+ED ZBCKCR, 0x00000002
+ED FLCKCR, 0x00000005
+ED SD0CKCR, 0x00000080
+ED SD1CKCR, 0x00000080
+ED SD2CKCR, 0x00000080
+ED FSIACKCR, 0x0000003F
+ED FSIBCKCR, 0x0000003F
+ED SUBCKCR, 0x00000080
+ED SPUACKCR, 0x0000000B
+ED SPUVCKCR, 0x0000000B
+ED MSUCKCR, 0x0000013F
+ED HSICKCR, 0x00000080
+ED MFCK1CR, 0x0000003F
+ED MFCK2CR, 0x0000003F
+ED DSITCKCR, 0x00000107
+ED DSI0PCKCR, 0x00000313
+ED DSI1PCKCR, 0x0000130D
+ED DSI0PHYCR, 0x2A800E0E
+ED PLL0CR, 0x1E000000
+ED PLL0CR, 0x2D000000
+ED PLL1CR, 0x17100000
+ED PLL2CR, 0x27000080
+ED PLL3CR, 0x1D000000
+ED PLL0STPCR, 0x00080000
+ED PLL1STPCR, 0x000120C0
+ED PLL2STPCR, 0x00012000
+ED PLL3STPCR, 0x00000030
+ED PLLECR, 0x0000000B
+WAIT_MASK PLLECR, 0x00000B00, 0x00000B00
+
+ED DVFSCR3, 0x000120F0
+ED MPMODE, 0x00000020
+ED VREFCR, 0x0000028A
+ED RMSTPCR0, 0xE4628087
+ED RMSTPCR1, 0xFFFFFFFF
+ED RMSTPCR2, 0x53FFFFFF
+ED RMSTPCR3, 0xFFFFFFFF
+ED RMSTPCR4, 0x00800D3D
+ED RMSTPCR5, 0xFFFFF3FF
+ED SMSTPCR2, 0x00000000
+ED SRCR2,  0x00040000
+ED_AND PLLECR, 0xFFFFFFF7
+WAIT_MASK PLLECR, 0x00000800, 0x00000000
+
+LIST "set SBSC operational"
+ED HPBCTRL6, 0x00000001
+WAIT_MASK HPBCTRL6, 0x00000001, 0x00000001
+
+LIST "set SBSC operating frequency"
+ED FRQCRD, 0x00001414
+WAIT_MASK FRQCRD, 0x80000000, 0x00000000
+ED PLL3CR, 0x1D000000
+ED_OR PLLECR, 0x00000008
+WAIT_MASK PLLECR, 0x00000800, 0x00000800
+
+LIST "enable DLL oscillation in DDRPHY"
+ED_OR DLLCNT0A, 0x00000002
+
+LIST "wait >= 100 ns"
+ED SDGENCNTA, 0x00000005
+WAIT_MASK SDGENCNTA, 0xFFFFFFFF, 0x00000000
+
+LIST "target LPDDR2 device settings"
+ED SDCR0A, 0xACC90159
+ED SDCR1A, 0x00010059
+ED SDWCRC0A, 0x50874114
+ED SDWCRC1A, 0x33199B37
+ED SDWCRC2A, 0x008F2313
+ED SDWCR00A, 0x31020707
+ED SDWCR01A, 0x0017040A
+ED SDWCR10A, 0x31020707
+ED SDWCR11A, 0x0017040A
+
+ED SDDRVCR0A, 0x055557ff
+
+ED SDWCR2A, 0x30000000
+
+LIST "drive CKE high"
+ED_OR SDPCRA, 0x00000080
+WAIT_MASK SDPCRA, 0x00000080, 0x00000080
+
+LIST "wait >= 200 us"
+ED SDGENCNTA, 0x00002710
+WAIT_MASK SDGENCNTA, 0xFFFFFFFF, 0x00000000
+
+LIST "issue reset command to LPDDR2 device"
+ED SDMRACR0A, 0x0000003F
+ED SDMRA1, 0x00000000
+
+LIST "wait >= 10 (or 1) us (docs inconsistent)"
+ED SDGENCNTA, 0x000001F4
+WAIT_MASK SDGENCNTA, 0xFFFFFFFF, 0x00000000
+
+LIST "MRW ZS initialization calibration command"
+ED SDMRACR0A, 0x0000FF0A
+ED SDMRA3, 0x00000000
+
+LIST "wait >= 1 us"
+ED SDGENCNTA, 0x00000032
+WAIT_MASK SDGENCNTA, 0xFFFFFFFF, 0x00000000
+
+LIST "specify operating mode in LPDDR2"
+ED SDMRACR0A, 0x00002201
+ED SDMRA1, 0x00000000
+ED SDMRACR0A, 0x00000402
+ED SDMRA1, 0x00000000
+ED SDMRACR0A, 0x00000203
+ED SDMRA1, 0x00000000
+
+LIST "initialize DDR interface"
+ED SDMRA2, 0x00000000
+
+LIST "temperature sensor control"
+ED SDMRTMPCRA, 0x88800004
+ED SDMRTMPMSKA,0x00000004
+
+LIST "auto-refreshing control"
+ED RTCORA, 0xA55A0032
+ED RTCORHA, 0xA55A000C
+ED RTCSRA, 0xA55A2048
+
+ED_OR SDCR0A, 0x00000800
+ED_OR SDCR1A, 0x00000400
+
+LIST "auto ZQ calibration control"
+ED ZQCCRA, 0xFFF20000
+
+ED_OR DLLCNT0B, 0x00000002
+ED SDGENCNTB, 0x00000005
+WAIT_MASK SDGENCNTB, 0xFFFFFFFF, 0x00000000
+
+ED SDCR0B, 0xACC90159
+ED SDCR1B, 0x00010059
+ED SDWCRC0B, 0x50874114
+ED SDWCRC1B, 0x33199B37
+ED SDWCRC2B, 0x008F2313
+ED SDWCR00B, 0x31020707
+ED SDWCR01B, 0x0017040A
+ED SDWCR10B, 0x31020707
+ED SDWCR11B, 0x0017040A
+ED SDDRVCR0B, 0x055557ff
+ED SDWCR2B, 0x30000000
+ED_OR SDPCRB, 0x00000080
+WAIT_MASK SDPCRB, 0x00000080, 0x00000080
+
+ED SDGENCNTB, 0x00002710
+WAIT_MASK SDGENCNTB, 0xFFFFFFFF, 0x00000000
+ED SDMRACR0B, 0x0000003F
+
+LIST "upstream u-boot writes to SDMRA1A for both SBSC 1 and 2, which does"
+LIST "not seem to make a lot of sense..."
+ED SDMRB1, 0x00000000
+
+ED SDGENCNTB, 0x000001F4
+WAIT_MASK SDGENCNTB, 0xFFFFFFFF, 0x00000000
+
+ED SDMRACR0B, 0x0000FF0A
+ED SDMRB3, 0x00000000
+ED SDGENCNTB, 0x00000032
+WAIT_MASK SDGENCNTB, 0xFFFFFFFF, 0x00000000
+
+ED SDMRACR0B, 0x00002201
+ED SDMRB1, 0x00000000
+ED SDMRACR0B, 0x00000402
+ED SDMRB1, 0x00000000
+ED SDMRACR0B, 0x00000203
+ED SDMRB1, 0x00000000
+ED SDMRB2, 0x00000000
+ED SDMRTMPCRB, 0x88800004
+ED SDMRTMPMSKB, 0x00000004
+ED RTCORB,  0xA55A0032
+ED RTCORHB, 0xA55A000C
+ED RTCSRB,  0xA55A2048
+ED_OR SDCR0B, 0x00000800
+ED_OR SDCR1B, 0x00000400
+ED ZQCCRB, 0xFFF20000
+ED_OR SDPDCR0B, 0x00030000
+ED DPHYCNT1B, 0xA5390000
+ED DPHYCNT0B, 0x00001200
+ED DPHYCNT1B, 0x07CE0000
+ED DPHYCNT0B, 0x00001247
+WAIT_MASK DPHYCNT2B, 0xFFFFFFFF, 0x07CE0000
+
+ED_AND SDPDCR0B, 0xFFFCFFFF
+
+ED FRQCRD, 0x00000B0B
+WAIT_MASK FRQCRD, 0x80000000, 0x00000000
+
+ED CPGXXCR4, 0xfffffffc
+
+LIST "Setup SCIF4 / workaround"
+EB PORT32CR, 0x12
+EB PORT33CR, 0x22
+EB PORT34CR, 0x12
+EB PORT35CR, 0x22
+
+EW 0xE6C80000, 0
+EB 0xE6C80004, 0x19
+EW 0xE6C80008, 0x0030
+EW 0xE6C80018, 0
+EW 0xE6C80030, 0x0014
+
+LIST "Magic to avoid hangs and corruption on DRAM writes."
+
+LIST "It has been observed that the system would most often hang while"
+LIST "decompressing the kernel, and if it didn't it would always write"
+LIST "a corrupt image to DRAM."
+LIST "This problem does not occur in u-boot, and the reason is that"
+LIST "u-boot performs an additional cache invalidation after setting up"
+LIST "the DRAM controller. Such an invalidation should not be necessary at"
+LIST "this point, and attempts at removing parts of the routine to arrive"
+LIST "at the minimal snippet of code necessary to avoid the DRAM stability"
+LIST "problem yielded the following:"
+
+MRC p15, 0, r0, c1, c0, 0
+MCR p15, 0, r0, c1, c0, 0
diff --git a/arch/arm/mach-shmobile/include/mach/zboot.h b/arch/arm/mach-shmobile/include/mach/zboot.h
index c3c4669..727cc78 100644
--- a/arch/arm/mach-shmobile/include/mach/zboot.h
+++ b/arch/arm/mach-shmobile/include/mach/zboot.h
@@ -12,6 +12,9 @@
 #ifdef CONFIG_MACH_MACKEREL
 #define MEMORY_START	0x40000000
 #include "mach/head-mackerel.txt"
+#elif defined(CONFIG_MACH_KZM9G) || defined(CONFIG_MACH_KZM9G_REFERENCE)
+#define MEMORY_START	0x43000000
+#include "mach/head-kzm9g.txt"
 #else
 #error "unsupported board."
 #endif
diff --git a/arch/arm/mach-shmobile/include/mach/zboot_macros.h b/arch/arm/mach-shmobile/include/mach/zboot_macros.h
index aa6111f..14fd3d5 100644
--- a/arch/arm/mach-shmobile/include/mach/zboot_macros.h
+++ b/arch/arm/mach-shmobile/include/mach/zboot_macros.h
@@ -62,4 +62,47 @@
 2 :
 .endm
 
+/* loop until a given value has been read (with mask) */
+.macro WAIT_MASK, addr, data, cmp
+	LDR	r0, 2f
+	LDR	r1, 3f
+	LDR	r2, 4f
+1:
+	LDR	r3, [r0, #0]
+	AND	r3, r1, r3
+	CMP	r2, r3
+	BNE	1b
+	B	5f
+2:	.long	\addr
+3:	.long	\data
+4:	.long	\cmp
+5:
+.endm
+
+/* read 32-bit value from addr, "or" an immediate and write back */
+.macro ED_OR, addr, data
+	LDR r4, 1f
+	LDR r5, 2f
+	LDR r6, [r4]
+	ORR r5, r6, r5
+	STR r5, [r4]
+	B	3f
+1:	.long	\addr
+2:	.long	\data
+3:
+.endm
+
+/* read 32-bit value from addr, "and" an immediate and write back */
+.macro ED_AND, addr, data
+	LDR r4, 1f
+	LDR r5, 2f
+	LDR r6, [r4]
+	AND r5, r6, r5
+	STR r5, [r4]
+	B	3f
+1:	.long \addr
+2:	.long \data
+3:
+.endm
+
 #endif /* __ZBOOT_MACRO_H */
-- 
1.8.5.2

[PATCH 07/21] ARM: shmobile: lager: Add VIN1 SoC camera support

[Simon Horman]

From: Valentine Barshak <valentine.barshak@cogentembedded.com>

This adds VIN1 SoC camera along with ADV7180 subdevice support to Lager.
VIN0 camera is not registered because it has ADV7612 I2C subdevice
which is not supported yet.

Changes in V2:
* made lager_add_vin_device function static.

Changes in V3:
* capitalized ARM in the subject.

Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c | 76 ++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index f20c10a..c5643e1 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -27,6 +27,7 @@
 #include <linux/mmc/host.h>
 #include <linux/mmc/sh_mmcif.h>
 #include <linux/pinctrl/machine.h>
+#include <linux/platform_data/camera-rcar.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_data/rcar-du.h>
 #include <linux/platform_device.h>
@@ -39,6 +40,7 @@
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7790.h>
+#include <media/soc_camera.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <linux/mtd/partitions.h>
@@ -291,6 +293,62 @@ static const struct resource qspi_resources[] __initconst = {
 	DEFINE_RES_IRQ(gic_spi(184)),
 };
 
+/* VIN */
+static const struct resource vin_resources[] __initconst = {
+	/* VIN0 */
+	DEFINE_RES_MEM(0xe6ef0000, 0x1000),
+	DEFINE_RES_IRQ(gic_spi(188)),
+	/* VIN1 */
+	DEFINE_RES_MEM(0xe6ef1000, 0x1000),
+	DEFINE_RES_IRQ(gic_spi(189)),
+};
+
+static void __init lager_add_vin_device(unsigned idx,
+					struct rcar_vin_platform_data *pdata)
+{
+	struct platform_device_info vin_info = {
+		.parent		= &platform_bus,
+		.name		= "r8a7790-vin",
+		.id		= idx,
+		.res		= &vin_resources[idx * 2],
+		.num_res	= 2,
+		.dma_mask	= DMA_BIT_MASK(32),
+		.data		= pdata,
+		.size_data	= sizeof(*pdata),
+	};
+
+	BUG_ON(idx > 1);
+
+	platform_device_register_full(&vin_info);
+}
+
+#define LAGER_CAMERA(idx, name, addr, pdata, flag)			\
+static struct i2c_board_info i2c_cam##idx##_device = {			\
+	I2C_BOARD_INFO(name, addr),					\
+};									\
+									\
+static struct rcar_vin_platform_data vin##idx##_pdata = {		\
+	.flags = flag,							\
+};									\
+									\
+static struct soc_camera_link cam##idx##_link = {			\
+	.bus_id = idx,							\
+	.board_info = &i2c_cam##idx##_device,				\
+	.i2c_adapter_id = 2,						\
+	.module_name = name,						\
+	.priv = pdata,							\
+}
+
+/* Camera 0 is not currently supported due to adv7612 support missing */
+LAGER_CAMERA(1, "adv7180", 0x20, NULL, RCAR_VIN_BT656);
+
+static void __init lager_add_camera1_device(void)
+{
+	platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1,
+				      &cam1_link, sizeof(cam1_link));
+	lager_add_vin_device(1, &vin1_pdata);
+}
+
 static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* DU (CN10: ARGB0, CN13: LVDS) */
 	PIN_MAP_MUX_GROUP_DEFAULT("rcar-du-r8a7790", "pfc-r8a7790",
@@ -319,6 +377,22 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
 				  "eth_rmii", "eth"),
 	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790",
 				  "intc_irq0", "intc"),
+	/* VIN0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-vin.0", "pfc-r8a7790",
+				  "vin0_data24", "vin0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-vin.0", "pfc-r8a7790",
+				  "vin0_sync", "vin0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-vin.0", "pfc-r8a7790",
+				  "vin0_field", "vin0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-vin.0", "pfc-r8a7790",
+				  "vin0_clkenb", "vin0"),
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-vin.0", "pfc-r8a7790",
+				  "vin0_clk", "vin0"),
+	/* VIN1 */
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-vin.1", "pfc-r8a7790",
+				  "vin1_data8", "vin1"),
+	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-vin.1", "pfc-r8a7790",
+				  "vin1_clk", "vin1"),
 };
 
 static void __init lager_add_standard_devices(void)
@@ -368,6 +442,8 @@ static void __init lager_add_standard_devices(void)
 				      &vccq_sdhi0_info, sizeof(struct gpio_regulator_config));
 	platform_device_register_data(&platform_bus, "gpio-regulator", gpio_regulator_idx++,
 				      &vccq_sdhi2_info, sizeof(struct gpio_regulator_config));
+
+	lager_add_camera1_device();
 }
 
 /*
-- 
1.8.5.2

[PATCH 08/21] ARM: shmobile: kzm9d: Use common clock framework

[Simon Horman]

From: Takashi Yoshii <takasi-y@ops.dti.ne.jp>

Use common clock framework version of clock
 drivers/clk/shmobile/clk-emev2.c
instead of sh-clkfwk version
 arch/arm/mach-shmobile/clock-emev2.c
when it is configured as a part of multi-platform.

Signed-off-by: Takashi Yoshii <takasi-y@ops.dti.ne.jp>
Acked-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-kzm9d-reference.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-kzm9d-reference.c b/arch/arm/mach-shmobile/board-kzm9d-reference.c
index 054d8d5..853003c 100644
--- a/arch/arm/mach-shmobile/board-kzm9d-reference.c
+++ b/arch/arm/mach-shmobile/board-kzm9d-reference.c
@@ -20,15 +20,14 @@
 
 #include <linux/init.h>
 #include <linux/of_platform.h>
+#include <linux/clk-provider.h>
 #include <mach/emev2.h>
 #include <mach/common.h>
 #include <asm/mach/arch.h>
 
 static void __init kzm9d_add_standard_devices(void)
 {
-	if (!IS_ENABLED(CONFIG_COMMON_CLK))
-		emev2_clock_init();
-
+	of_clk_init(NULL);
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
-- 
1.8.5.2

[PATCH 09/21] ARM: shmobile: lager: Make spi_flash_data const

[Simon Horman]

From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>

Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index c5643e1..aa8f1d9 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -265,7 +265,7 @@ static struct mtd_partition spi_flash_part[] = {
 	},
 };
 
-static struct flash_platform_data spi_flash_data = {
+static const struct flash_platform_data spi_flash_data = {
 	.name           = "m25p80",
 	.parts          = spi_flash_part,
 	.nr_parts       = ARRAY_SIZE(spi_flash_part),
-- 
1.8.5.2

[PATCH 10/21] ARM: shmobile: lager: Add SATA support

[Simon Horman]

From: Valentine Barshak <valentine.barshak@cogentembedded.com>

This adds SATA support to Lager board. Only SATA1 port is available.

Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
Acked-by: Magnus Damm <damm@opensource.se>
[horms+renesas@verge.net.au: resolved trivial conflicts]
[horms+renesas@verge.net.au: capitalised "ARM" in subject]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index aa8f1d9..8dde446 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -349,6 +349,21 @@ static void __init lager_add_camera1_device(void)
 	lager_add_vin_device(1, &vin1_pdata);
 }
 
+/* SATA1 */
+static const struct resource sata1_resources[] __initconst = {
+	DEFINE_RES_MEM(0xee500000, 0x2000),
+	DEFINE_RES_IRQ(gic_spi(106)),
+};
+
+static const struct platform_device_info sata1_info __initconst = {
+	.parent		= &platform_bus,
+	.name		= "sata-r8a7790",
+	.id		= 1,
+	.res		= sata1_resources,
+	.num_res	= ARRAY_SIZE(sata1_resources),
+	.dma_mask	= DMA_BIT_MASK(32),
+};
+
 static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* DU (CN10: ARGB0, CN13: LVDS) */
 	PIN_MAP_MUX_GROUP_DEFAULT("rcar-du-r8a7790", "pfc-r8a7790",
@@ -444,6 +459,8 @@ static void __init lager_add_standard_devices(void)
 				      &vccq_sdhi2_info, sizeof(struct gpio_regulator_config));
 
 	lager_add_camera1_device();
+
+	platform_device_register_full(&sata1_info);
 }
 
 /*
-- 
1.8.5.2

[PATCH 11/21] ARM: shmobile: koelsch: Add SATA0 support

[Simon Horman]

From: Valentine Barshak <valentine.barshak@cogentembedded.com>

This adds SATA0 support to Koelsch board.
SATA1 is not available since its pinmux
configuration is fixed to PCIe.

Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
Acked-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-koelsch.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-koelsch.c b/arch/arm/mach-shmobile/board-koelsch.c
index de7cc64..2ab5c75 100644
--- a/arch/arm/mach-shmobile/board-koelsch.c
+++ b/arch/arm/mach-shmobile/board-koelsch.c
@@ -148,6 +148,21 @@ static const struct gpio_keys_platform_data koelsch_keys_pdata __initconst = {
 	.nbuttons	= ARRAY_SIZE(gpio_buttons),
 };
 
+/* SATA0 */
+static const struct resource sata0_resources[] __initconst = {
+	DEFINE_RES_MEM(0xee300000, 0x2000),
+	DEFINE_RES_IRQ(gic_spi(105)),
+};
+
+static const struct platform_device_info sata0_info __initconst = {
+	.parent		= &platform_bus,
+	.name		= "sata-r8a7791",
+	.id		= 0,
+	.res		= sata0_resources,
+	.num_res	= ARRAY_SIZE(sata0_resources),
+	.dma_mask	= DMA_BIT_MASK(32),
+};
+
 static const struct pinctrl_map koelsch_pinctrl_map[] = {
 	/* DU */
 	PIN_MAP_MUX_GROUP_DEFAULT("rcar-du-r8a7791", "pfc-r8a7791",
@@ -192,6 +207,8 @@ static void __init koelsch_add_standard_devices(void)
 				      sizeof(koelsch_keys_pdata));
 
 	koelsch_add_du_device();
+
+	platform_device_register_full(&sata0_info);
 }
 
 /*
-- 
1.8.5.2

[PATCH 12/21] ARM: shmobile: ape6evm: Conditionally select SMSC_PHY

[Simon Horman]

The ape6evm board uses has an SMSC911X ethernet controller which uses an
SMSC phy. Select SMSC_PHY for ape6evm if SMSC911X is enabled to make use of the
SMSC-specific phy driver rather than relying on the generic phy driver.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 958ccf3d..2673f68 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -156,11 +156,13 @@ comment "Renesas ARM SoCs Board Type"
 config MACH_APE6EVM
 	bool "APE6EVM board"
 	depends on ARCH_R8A73A4
+	select SMSC_PHY if SMSC911X
 	select USE_OF
 
 config MACH_APE6EVM_REFERENCE
 	bool "APE6EVM board - Reference Device Tree Implementation"
 	depends on ARCH_R8A73A4
+	select SMSC_PHY if SMSC911X
 	select USE_OF
 	---help---
 	   Use reference implementation of APE6EVM board support
-- 
1.8.5.2

[PATCH 13/21] ARM: shmobile: armadillo800eva: Conditionally select SMSC_PHY

[Simon Horman]

The armadillo800eva board uses has an SH ethernet controller which uses an
SMSC phy. Select SMSC_PHY for koelsch if SH_ETH is enabled to make use of the
SMSC-specific phy driver rather than relying on the generic phy driver.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 2673f68..b624b5a 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -184,6 +184,7 @@ config MACH_ARMADILLO800EVA
 	depends on ARCH_R8A7740
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select SMSC_PHY if SH_ETH
 	select SND_SOC_WM8978 if SND_SIMPLE_CARD
 	select USE_OF
 
@@ -192,6 +193,7 @@ config MACH_ARMADILLO800EVA_REFERENCE
 	depends on ARCH_R8A7740
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select SMSC_PHY if SH_ETH
 	select SND_SOC_WM8978 if SND_SIMPLE_CARD
 	select USE_OF
 	---help---
-- 
1.8.5.2

[PATCH 14/21] ARM: shmobile: bockw: Sort Kconfig node's selections

[Simon Horman]

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index b624b5a..6f16983 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -207,11 +207,11 @@ config MACH_BOCKW
 	bool "BOCK-W platform"
 	depends on ARCH_R8A7778
 	select ARCH_REQUIRE_GPIOLIB
-	select RENESAS_INTC_IRQPIN
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
-	select USE_OF
+	select RENESAS_INTC_IRQPIN
 	select SND_SOC_AK4554 if SND_SIMPLE_CARD
 	select SND_SOC_AK4642 if SND_SIMPLE_CARD
+	select USE_OF
 
 config MACH_BOCKW_REFERENCE
 	bool "BOCK-W  - Reference Device Tree Implementation"
-- 
1.8.5.2

[PATCH 15/21] ARM: shmobile: kzm9d: Conditionally select SMSC_PHY

[Simon Horman]

The kzm9d board uses has an SMSC911X ethernet controller which uses an
SMSC phy. Select SMSC_PHY for kzm9d if SMSC911X is enabled to make use of the
SMSC-specific phy driver rather than relying on the generic phy driver.

This only covers the case of multiplatform kzm9d
as there is currently no Kconfig node for non-multiplatform kzm9d.
One could be added if desired.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 6f16983..b735ea8 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -51,6 +51,7 @@ config MACH_KZM9D
 	bool "KZM9D board"
 	depends on ARCH_EMEV2
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select SMSC_PHY if SMSC911X
 
 config MACH_LAGER
 	bool "Lager board"
-- 
1.8.5.2

[PATCH 16/21] ARM: shmobile: mackerel: Conditionally select SMSC_PHY

[Simon Horman]

The mackerel board uses has an SMSC911X ethernet controller which uses an
SMSC phy. Select SMSC_PHY for mackerel if SMSC911X is enabled to make use of the
SMSC-specific phy driver rather than relying on the generic phy driver.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index b735ea8..f8005ef 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -177,6 +177,7 @@ config MACH_MACKEREL
 	depends on ARCH_SH7372
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select SMSC_PHY if SMSC911X
 	select SND_SOC_AK4642 if SND_SIMPLE_CARD
 	select USE_OF
 
-- 
1.8.5.2

[PATCH 17/21] ARM: shmobile: marzen: Conditionally select SMSC_PHY

[Simon Horman]

The marzen board uses has an SMSC911X ethernet controller which uses an
SMSC phy. Select SMSC_PHY for marzen if SMSC911X is enabled to make use of the
SMSC-specific phy driver rather than relying on the generic phy driver.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index f8005ef..7e3f42b 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -250,6 +250,7 @@ config MACH_MARZEN
 	depends on ARCH_R8A7779
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select SMSC_PHY if SMSC911X
 	select USE_OF
 
 config MACH_MARZEN_REFERENCE
@@ -257,6 +258,7 @@ config MACH_MARZEN_REFERENCE
 	depends on ARCH_R8A7779
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
+	select SMSC_PHY if SMSC911X
 	select USE_OF
 	---help---
 	   Use reference implementation of Marzen board support
-- 
1.8.5.2

[PATCH 18/21] ARM: shmobile: lager: fix error return code check from clk_get()

[Simon Horman]

From: Ben Dooks <ben.dooks@codethink.co.uk>

The lager_add_standard_devices() function calls clk_get() but then fails
to check that it returns an error pointer instead of NULL on failure.

This was added by 4a606af2 ("ARM: shmobile: lager-reference: Instantiate
clkdevs for SCIF and CMT") patch in Simon Horman's renesas-boards2-for-v3.14
tag.

The issue is not serious as it does not cause a crash and seems to not be
actually causing any issues now the other clock bugs have been fixed.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[horms+renesas@verge.net.au: tweaked changelog]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-lager-reference.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-lager-reference.c b/arch/arm/mach-shmobile/board-lager-reference.c
index a6e271d..dc8d76b 100644
--- a/arch/arm/mach-shmobile/board-lager-reference.c
+++ b/arch/arm/mach-shmobile/board-lager-reference.c
@@ -44,14 +44,14 @@ static void __init lager_add_standard_devices(void)
 
 	for (i = 0; i < ARRAY_SIZE(scif_names); ++i) {
 		clk = clk_get(NULL, scif_names[i]);
-		if (clk) {
+		if (!IS_ERR(clk)) {
 			clk_register_clkdev(clk, NULL, "sh-sci.%u", i);
 			clk_put(clk);
 		}
 	}
 
 	clk = clk_get(NULL, "cmt0");
-	if (clk) {
+	if (!IS_ERR(clk)) {
 		clk_register_clkdev(clk, NULL, "sh_cmt.0");
 		clk_put(clk);
 	}
-- 
1.8.5.2

[PATCH 19/21] ARM: shmobile: koelsch: fix error return code check from clk_get()

[Simon Horman]

From: Ben Dooks <ben.dooks@codethink.co.uk>

The koelsch_add_standard_devices() function calls clk_get() but then fails
to check that it returns an error pointer instead of NULL on failure.

This was added by f31239ef ("ARM: shmobile: koelsch-reference:
Instantiate clkdevs for SCIF and CMT") in Simon Horman's
renesas-boards2-for-v3.14 tag.

The issue is not serious as it does not cause a crash and seems to not be
actually causing any issues now the other clock bugs have been fixed.

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[horms+renesas@verge.net.au: tweaked changelog]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-koelsch-reference.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-koelsch-reference.c b/arch/arm/mach-shmobile/board-koelsch-reference.c
index 652b592..feb8d97 100644
--- a/arch/arm/mach-shmobile/board-koelsch-reference.c
+++ b/arch/arm/mach-shmobile/board-koelsch-reference.c
@@ -45,14 +45,14 @@ static void __init koelsch_add_standard_devices(void)
 
 	for (i = 0; i < ARRAY_SIZE(scif_names); ++i) {
 		clk = clk_get(NULL, scif_names[i]);
-		if (clk) {
+		if (!IS_ERR(clk)) {
 			clk_register_clkdev(clk, NULL, "sh-sci.%u", i);
 			clk_put(clk);
 		}
 	}
 
 	clk = clk_get(NULL, "cmt0");
-	if (clk) {
+	if (!IS_ERR(clk)) {
 		clk_register_clkdev(clk, NULL, "sh_cmt.0");
 		clk_put(clk);
 	}
-- 
1.8.5.2

[PATCH 20/21] ARM: shmobile: lager: Add USBHS support

[Simon Horman]

From: Valentine Barshak <valentine.barshak@cogentembedded.com>

This adds USBHS PHY and registers USBHS device if the driver is enabled.

Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
Acked-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c | 138 +++++++++++++++++++++++++++++++++++
 1 file changed, 138 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 8dde446..4a95a45 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -30,6 +30,7 @@
 #include <linux/platform_data/camera-rcar.h>
 #include <linux/platform_data/gpio-rcar.h>
 #include <linux/platform_data/rcar-du.h>
+#include <linux/platform_data/usb-rcar-gen2-phy.h>
 #include <linux/platform_device.h>
 #include <linux/phy.h>
 #include <linux/regulator/driver.h>
@@ -37,6 +38,8 @@
 #include <linux/regulator/gpio-regulator.h>
 #include <linux/regulator/machine.h>
 #include <linux/sh_eth.h>
+#include <linux/usb/phy.h>
+#include <linux/usb/renesas_usbhs.h>
 #include <mach/common.h>
 #include <mach/irqs.h>
 #include <mach/r8a7790.h>
@@ -364,6 +367,131 @@ static const struct platform_device_info sata1_info __initconst = {
 	.dma_mask	= DMA_BIT_MASK(32),
 };
 
+/* USBHS */
+#if IS_ENABLED(CONFIG_USB_RENESAS_USBHS_UDC)
+static const struct resource usbhs_resources[] __initconst = {
+	DEFINE_RES_MEM(0xe6590000, 0x100),
+	DEFINE_RES_IRQ(gic_spi(107)),
+};
+
+struct usbhs_private {
+	struct renesas_usbhs_platform_info info;
+	struct usb_phy *phy;
+};
+
+#define usbhs_get_priv(pdev) \
+	container_of(renesas_usbhs_get_info(pdev), struct usbhs_private, info)
+
+static int usbhs_power_ctrl(struct platform_device *pdev,
+				void __iomem *base, int enable)
+{
+	struct usbhs_private *priv = usbhs_get_priv(pdev);
+
+	if (!priv->phy)
+		return -ENODEV;
+
+	if (enable) {
+		int retval = usb_phy_init(priv->phy);
+
+		if (!retval)
+			retval = usb_phy_set_suspend(priv->phy, 0);
+		return retval;
+	}
+
+	usb_phy_set_suspend(priv->phy, 1);
+	usb_phy_shutdown(priv->phy);
+	return 0;
+}
+
+static int usbhs_hardware_init(struct platform_device *pdev)
+{
+	struct usbhs_private *priv = usbhs_get_priv(pdev);
+	struct usb_phy *phy;
+
+	phy = usb_get_phy_dev(&pdev->dev, 0);
+	if (IS_ERR(phy))
+		return PTR_ERR(phy);
+
+	priv->phy = phy;
+	return 0;
+}
+
+static int usbhs_hardware_exit(struct platform_device *pdev)
+{
+	struct usbhs_private *priv = usbhs_get_priv(pdev);
+
+	if (!priv->phy)
+		return 0;
+
+	usb_put_phy(priv->phy);
+	priv->phy = NULL;
+	return 0;
+}
+
+static int usbhs_get_id(struct platform_device *pdev)
+{
+	return USBHS_GADGET;
+}
+
+static u32 lager_usbhs_pipe_type[] = {
+	USB_ENDPOINT_XFER_CONTROL,
+	USB_ENDPOINT_XFER_ISOC,
+	USB_ENDPOINT_XFER_ISOC,
+	USB_ENDPOINT_XFER_BULK,
+	USB_ENDPOINT_XFER_BULK,
+	USB_ENDPOINT_XFER_BULK,
+	USB_ENDPOINT_XFER_INT,
+	USB_ENDPOINT_XFER_INT,
+	USB_ENDPOINT_XFER_INT,
+	USB_ENDPOINT_XFER_BULK,
+	USB_ENDPOINT_XFER_BULK,
+	USB_ENDPOINT_XFER_BULK,
+	USB_ENDPOINT_XFER_BULK,
+	USB_ENDPOINT_XFER_BULK,
+	USB_ENDPOINT_XFER_BULK,
+	USB_ENDPOINT_XFER_BULK,
+};
+
+static struct usbhs_private usbhs_priv __initdata = {
+	.info = {
+		.platform_callback = {
+			.power_ctrl	= usbhs_power_ctrl,
+			.hardware_init	= usbhs_hardware_init,
+			.hardware_exit	= usbhs_hardware_exit,
+			.get_id		= usbhs_get_id,
+		},
+		.driver_param = {
+			.buswait_bwait	= 4,
+			.pipe_type = lager_usbhs_pipe_type,
+			.pipe_size = ARRAY_SIZE(lager_usbhs_pipe_type),
+		},
+	}
+};
+
+static void __init lager_register_usbhs(void)
+{
+	usb_bind_phy("renesas_usbhs", 0, "usb_phy_rcar_gen2");
+	platform_device_register_resndata(&platform_bus,
+					  "renesas_usbhs", -1,
+					  usbhs_resources,
+					  ARRAY_SIZE(usbhs_resources),
+					  &usbhs_priv.info,
+					  sizeof(usbhs_priv.info));
+}
+#else	/* CONFIG_USB_RENESAS_USBHS_UDC */
+static inline void lager_register_usbhs(void) { }
+#endif	/* CONFIG_USB_RENESAS_USBHS_UDC */
+
+/* USBHS PHY */
+static const struct rcar_gen2_phy_platform_data usbhs_phy_pdata __initconst = {
+	.chan0_pci = 0,	/* Channel 0 is USBHS */
+	.chan2_pci = 1,	/* Channel 2 is PCI USB */
+};
+
+static const struct resource usbhs_phy_resources[] __initconst = {
+	DEFINE_RES_MEM(0xe6590100, 0x100),
+};
+
 static const struct pinctrl_map lager_pinctrl_map[] = {
 	/* DU (CN10: ARGB0, CN13: LVDS) */
 	PIN_MAP_MUX_GROUP_DEFAULT("rcar-du-r8a7790", "pfc-r8a7790",
@@ -408,6 +536,9 @@ static const struct pinctrl_map lager_pinctrl_map[] = {
 				  "vin1_data8", "vin1"),
 	PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-vin.1", "pfc-r8a7790",
 				  "vin1_clk", "vin1"),
+	/* USB0 */
+	PIN_MAP_MUX_GROUP_DEFAULT("renesas_usbhs", "pfc-r8a7790",
+				  "usb0", "usb0"),
 };
 
 static void __init lager_add_standard_devices(void)
@@ -461,6 +592,13 @@ static void __init lager_add_standard_devices(void)
 	lager_add_camera1_device();
 
 	platform_device_register_full(&sata1_info);
+
+	platform_device_register_resndata(&platform_bus, "usb_phy_rcar_gen2",
+					  -1, usbhs_phy_resources,
+					  ARRAY_SIZE(usbhs_phy_resources),
+					  &usbhs_phy_pdata,
+					  sizeof(usbhs_phy_pdata));
+	lager_register_usbhs();
 }
 
 /*
-- 
1.8.5.2

[PATCH 21/21] ARM: shmobile: Remove Lager USBHS UDC ifdefs

[Simon Horman]

From: Magnus Damm <damm@opensource.se>

Remove ifdefs to make the Lager USBHS device always present.
This makes it more like other devices, no need to be special.

Also, these ifdefs by themselves do not hurt much, but combined
with USB Host device ifdefs that were proposed earlier we could
basically end up with a kernel that drives VBUS incorrectly
depending on the kernel configuration - lets not do that.

Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/board-lager.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-lager.c b/arch/arm/mach-shmobile/board-lager.c
index 4a95a45..fdcc868 100644
--- a/arch/arm/mach-shmobile/board-lager.c
+++ b/arch/arm/mach-shmobile/board-lager.c
@@ -368,7 +368,6 @@ static const struct platform_device_info sata1_info __initconst = {
 };
 
 /* USBHS */
-#if IS_ENABLED(CONFIG_USB_RENESAS_USBHS_UDC)
 static const struct resource usbhs_resources[] __initconst = {
 	DEFINE_RES_MEM(0xe6590000, 0x100),
 	DEFINE_RES_IRQ(gic_spi(107)),
@@ -478,9 +477,6 @@ static void __init lager_register_usbhs(void)
 					  &usbhs_priv.info,
 					  sizeof(usbhs_priv.info));
 }
-#else	/* CONFIG_USB_RENESAS_USBHS_UDC */
-static inline void lager_register_usbhs(void) { }
-#endif	/* CONFIG_USB_RENESAS_USBHS_UDC */
 
 /* USBHS PHY */
 static const struct rcar_gen2_phy_platform_data usbhs_phy_pdata __initconst = {
-- 
1.8.5.2

Re: [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15

[Olof Johansson]

On Thu, Feb 06, 2014 at 03:17:08PM +0900, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
> 
> please consider these Renesas ARM based SoC board updates for v3.15.
> 
> 
> The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
> 
>   Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards-for-v3.15
> 
> for you to fetch changes up to 235cda29e4d5047622ff9b82b1f0b4cb6cf95f6c:
> 
>   ARM: shmobile: Remove Lager USBHS UDC ifdefs (2014-02-04 14:28:33 +0900)
> 
> ----------------------------------------------------------------
> Renesas ARM based SoC Board Updates for v3.15
> 
> * r8a7791 (R-Car M2) based Koelsch board
>   - Fix error return code check from clk_get()
>   - Add SATA0 support
>   - Conditionally select MICREL_PHY for Multiplatform
> 
> * r8a7790 (R-Car H2) based Lager board
>   - Add USBHS support
>   - Fix error return code check from clk_get()
>   - Add SATA support
>   - Make spi_flash_data const
>   - Add VIN1 SoC camera support
>   - Conditionally select CONFIG_MICREL_PHY
> 
> * r8a7778 (R-Car M1) based Bock-W board
>   - Add USB Func DMAEngine support
>   - Use HPBIF DMAEngine for sound
>   - Use SSI DMAEngine for sound
> 
> * emev2 (Emma Mobile EV2) based kzm9d board
>   - Use common clock framework
> 
> * r8a773a0 (SH-Mobile AG5) based kzm9g board
>   - Add zboot support
> 
> * Many boards
>   - Conditionally select SMSC_PHY

Simon,

I've pulled this into next/boards (as renesas/boards), but I'd like to get an
understanding of how much more legacy board code you expect to add. I'd like to
see it slow down to nearly nothing as things move over to device tree, and I'm
a little confused that we've still got this much coming in.


Thanks!

-Olof

Re: [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15

[Magnus Damm]

On Thu, Feb 20, 2014 at 5:23 PM, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Feb 06, 2014 at 03:17:08PM +0900, Simon Horman wrote:
>> Hi Olof, Hi Kevin, Hi Arnd,
>>
>> please consider these Renesas ARM based SoC board updates for v3.15.
>>
>>
>> The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
>>
>>   Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards-for-v3.15
>>
>> for you to fetch changes up to 235cda29e4d5047622ff9b82b1f0b4cb6cf95f6c:
>>
>>   ARM: shmobile: Remove Lager USBHS UDC ifdefs (2014-02-04 14:28:33 +0900)
>>
>> ----------------------------------------------------------------
>> Renesas ARM based SoC Board Updates for v3.15
>>
>> * r8a7791 (R-Car M2) based Koelsch board
>>   - Fix error return code check from clk_get()
>>   - Add SATA0 support
>>   - Conditionally select MICREL_PHY for Multiplatform
>>
>> * r8a7790 (R-Car H2) based Lager board
>>   - Add USBHS support
>>   - Fix error return code check from clk_get()
>>   - Add SATA support
>>   - Make spi_flash_data const
>>   - Add VIN1 SoC camera support
>>   - Conditionally select CONFIG_MICREL_PHY
>>
>> * r8a7778 (R-Car M1) based Bock-W board
>>   - Add USB Func DMAEngine support
>>   - Use HPBIF DMAEngine for sound
>>   - Use SSI DMAEngine for sound
>>
>> * emev2 (Emma Mobile EV2) based kzm9d board
>>   - Use common clock framework
>>
>> * r8a773a0 (SH-Mobile AG5) based kzm9g board
>>   - Add zboot support
>>
>> * Many boards
>>   - Conditionally select SMSC_PHY
>
> Simon,
>
> I've pulled this into next/boards (as renesas/boards), but I'd like to get an
> understanding of how much more legacy board code you expect to add. I'd like to
> see it slow down to nearly nothing as things move over to device tree, and I'm
> a little confused that we've still got this much coming in.

Hi Olof,

Thanks for your email. I agree that the number of board file commits
is definitely larger than zero so some clarification is in order.

As you probably recall, we earlier agreed on not adding any new board
files. That part is clear I believe so I will skip that.

Regarding the legacy board code, we have quite ok hardware support
coverage as it is now, but some devices drivers are of course still
under development. This means that in some cases integration is on
going or has not happened yet. You may see those kind of changes as
significant commits in the pull requests for board support.

In general we want to use upstream to host our continued incremental
development efforts. We do however often prioritize hardware support
over DT binding design in an early stage of driver development. This
to learn about the hardware and see what kind of abstractions that
need to be done. Once when we feel that the driver has good enough
hardware coverage then we commit to DT bindings.

In the Legacy Lager/Koelsch board code the following devices are
supported as platform devices:

ETHER, SCIF, DU, I2C, SATA*, USB*, MSIOF*, SDHI*, QSPI*, MMCIF,
Audio*, VIN*, Thermal, IRQC, PFC, CMT

* Platform device support under development in v3.15-pre

In the Multiplatform DT for Lager/Koelsch the following devices have DT support:

ETHER, SCIF**, I2C, SATA, MSIOF, SDHI, QSPI, MMCIF, Thermal, IRQC, PFC, CMT**

** Driver DT binding development on-going but integration not finalized

In Multiplatform DT for Lager/Koelsch the following devices lack DT bindings:

DU (drm/kms)
USB (host/function/phy)
Audio (alsa-soc + dmac)
VIN (v4l2 + camera sensor)

Our plan is to migrate over to the DT Multiplatform code base as soon
as ever possible, but at the same time we do not want to commit long
term support of potentially premature DT bindings. Our short term
solution to that is to use platform devices for a limited number of
devices together with DT Multiplatform.

If you would like use to adjust our way forwards please let me know!

Thanks,

/ magnus

Re: [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15

[Arnd Bergmann]

On Tuesday 25 February 2014, Magnus Damm wrote:
> On Thu, Feb 20, 2014 at 5:23 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Thu, Feb 06, 2014 at 03:17:08PM +0900, Simon Horman wrote:
> Thanks for your email. I agree that the number of board file commits
> is definitely larger than zero so some clarification is in order.
> 
> As you probably recall, we earlier agreed on not adding any new board
> files. That part is clear I believe so I will skip that.
> 
> Regarding the legacy board code, we have quite ok hardware support
> coverage as it is now, but some devices drivers are of course still
> under development. This means that in some cases integration is on
> going or has not happened yet. You may see those kind of changes as
> significant commits in the pull requests for board support.

[adding Ben Dooks, since he was complaining about this as well]

My feeling is that we should adjust the strategy for shmobile. We've
had good success with the dual strategy of keeping board support
separate for DT-enabled and ATAGS-only boards in the sense that
we did not have to coordinate updates for bindings between subsystem
and architecture git trees, which has always been source for
problems on other platforms.

However, the price for this seems to be that it's still not possible
to get a properly working system without a board file, and my feeling
is that it's taking too long to get there. In particular, we now see
new drivers getting added (I noticed VIN, which Ben mentioned before)
that start out with just platform_device support but no DT support.
This is bad, because it means DT users are always behind.

> In the Legacy Lager/Koelsch board code the following devices are
> supported as platform devices:
> 
> ETHER, SCIF, DU, I2C, SATA*, USB*, MSIOF*, SDHI*, QSPI*, MMCIF,
> Audio*, VIN*, Thermal, IRQC, PFC, CMT
> 
> * Platform device support under development in v3.15-pre
> 
> In the Multiplatform DT for Lager/Koelsch the following devices have DT support:
> 
> ETHER, SCIF**, I2C, SATA, MSIOF, SDHI, QSPI, MMCIF, Thermal, IRQC, PFC, CMT**
> 
> ** Driver DT binding development on-going but integration not finalized
> 
> In Multiplatform DT for Lager/Koelsch the following devices lack DT bindings:
> 
> DU (drm/kms)
> USB (host/function/phy)
> Audio (alsa-soc + dmac)
> VIN (v4l2 + camera sensor)

Ok, thanks for the list.

> Our plan is to migrate over to the DT Multiplatform code base as soon
> as ever possible, but at the same time we do not want to commit long
> term support of potentially premature DT bindings. Our short term
> solution to that is to use platform devices for a limited number of
> devices together with DT Multiplatform.
> 
> If you would like use to adjust our way forwards please let me know!

I think you should try to close the gap between ATAGS and DT now and
stop the dual strategy. You seem to have come far enough with the
basic infrastructure (clock, pinctrl, irq, timer, ...) that all the
devices missing DT support now are on-chip peripherals. If this is the
case, it should be possible to use auxdata registration in the
per-soc files to connect the platform data to the remaining devices
that are lacking DT bindings. This means we have to be more careful
with the dependencies when a driver gains a DT binding, but at least
we can enforce that any driver in the future only gets merged with
a proper DT binding as we do for other subarchitectures, and you don't
have to implement probing twice for each new driver.

	Arnd

Re: [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15

[Magnus Damm]

On Wed, Feb 26, 2014 at 1:04 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 25 February 2014, Magnus Damm wrote:
>> On Thu, Feb 20, 2014 at 5:23 PM, Olof Johansson <olof@lixom.net> wrote:
>> > On Thu, Feb 06, 2014 at 03:17:08PM +0900, Simon Horman wrote:
>> Thanks for your email. I agree that the number of board file commits
>> is definitely larger than zero so some clarification is in order.
>>
>> As you probably recall, we earlier agreed on not adding any new board
>> files. That part is clear I believe so I will skip that.
>>
>> Regarding the legacy board code, we have quite ok hardware support
>> coverage as it is now, but some devices drivers are of course still
>> under development. This means that in some cases integration is on
>> going or has not happened yet. You may see those kind of changes as
>> significant commits in the pull requests for board support.
>
> [adding Ben Dooks, since he was complaining about this as well]
>
> My feeling is that we should adjust the strategy for shmobile. We've
> had good success with the dual strategy of keeping board support
> separate for DT-enabled and ATAGS-only boards in the sense that
> we did not have to coordinate updates for bindings between subsystem
> and architecture git trees, which has always been source for
> problems on other platforms.

Hi Arnd,

You're right that many of our boot loaders only provide us with ATAG
information. In the kernel we have long since made use of appended DTB
to handle those cases. The last bit of code that depended on ATAGS and
mach-type being passed from the boot loader was removed in the
following patch:

[PATCH] ARM: shmobile: Update romImage to relocate appended DTB
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/compressed/head-shmobile.S?id,408d149299e99c89fc4be80fb4fe00a7016f02

> However, the price for this seems to be that it's still not possible
> to get a properly working system without a board file, and my feeling
> is that it's taking too long to get there. In particular, we now see
> new drivers getting added (I noticed VIN, which Ben mentioned before)
> that start out with just platform_device support but no DT support.
> This is bad, because it means DT users are always behind.

From my side it is possible to boot working systems with DT only
(without a board file) for a wide range of SoCs and boards. Actually,
for KZM9D we have no board code - instead there is only Multiplatform
DT. Any left over C board code for KZM9D and the legacy EMEV2SoC code
is removed in:

[PATCH 00/03] ARM: shmobile: Clean up the EMEV2 and KZM9D code base
http://www.spinics.net/lists/arm-kernel/msg307379.html

To be clear, I believe all our boards can boot without a board file.
The only exception is sh7372 and Mackerel which will be phased out.

Please note that device support may however be limited with DT. This
since several device drivers are under constant development to be able
to support the latest hardware features. And the hardware is being
updated quite regularly, so it seems to me that our only choice is to
keep on updating software support.

>> In the Legacy Lager/Koelsch board code the following devices are
>> supported as platform devices:
>>
>> ETHER, SCIF, DU, I2C, SATA*, USB*, MSIOF*, SDHI*, QSPI*, MMCIF,
>> Audio*, VIN*, Thermal, IRQC, PFC, CMT
>>
>> * Platform device support under development in v3.15-pre
>>
>> In the Multiplatform DT for Lager/Koelsch the following devices have DT support:
>>
>> ETHER, SCIF**, I2C, SATA, MSIOF, SDHI, QSPI, MMCIF, Thermal, IRQC, PFC, CMT**
>>
>> ** Driver DT binding development on-going but integration not finalized
>>
>> In Multiplatform DT for Lager/Koelsch the following devices lack DT bindings:
>>
>> DU (drm/kms)
>> USB (host/function/phy)
>> Audio (alsa-soc + dmac)
>> VIN (v4l2 + camera sensor)
>
> Ok, thanks for the list.
>
>> Our plan is to migrate over to the DT Multiplatform code base as soon
>> as ever possible, but at the same time we do not want to commit long
>> term support of potentially premature DT bindings. Our short term
>> solution to that is to use platform devices for a limited number of
>> devices together with DT Multiplatform.
>>
>> If you would like use to adjust our way forwards please let me know!
>
> I think you should try to close the gap between ATAGS and DT now and
> stop the dual strategy. You seem to have come far enough with the
> basic infrastructure (clock, pinctrl, irq, timer, ...) that all the
> devices missing DT support now are on-chip peripherals. If this is the
> case, it should be possible to use auxdata registration in the
> per-soc files to connect the platform data to the remaining devices
> that are lacking DT bindings. This means we have to be more careful
> with the dependencies when a driver gains a DT binding, but at least
> we can enforce that any driver in the future only gets merged with
> a proper DT binding as we do for other subarchitectures, and you don't
> have to implement probing twice for each new driver.

I agree about closing the gap and using DT as much as ever possible.
Perhaps we need to discuss a bit more about how to proceed.

In my mind this all boils down to two separate issues:

1) How to close the gap:

Our current plan is to copy the left over non-DT devices from legacy
board code to our DT board support. This can be done with or without
AUXDATA, exactly how to do it is a separate (but perhaps important?)
issue. When the DT board support is in OK state then we remove the
legacy board code. How long time that takes depends on the level of
board support. For the boards and devices I listed above I believe it
can be done in less than a week. If you want us to do this differently
then please advice us about your preference.

Regarding AUXDATA, it seems mainly useful for simple devices that have
no dependencies on other parts of the system. Our remaining portion of
non-DT device drivers are however all relatively complex devices with
many dependencies and sometimes odd topology. On such device drivers
our prototyping showed that AUXDATA mainly came with drawbacks of
having to commit to bindings prematurely but we could not really see
any upside. We would like to hear more from you how you think we
should proceed.


2) How to handle continuous driver development and integration

As you have seen, most of our simple device drivers have already been
successfully converted to DT. What remains are more complex devices.

Since we do upstream first we rely on being able to develop device
driver code incrementally over several kernel releases. To allow early
use, development and testing we also integrate the device drivers
continuously. We have been doing this for many years now and it seems
to work really well for us. That device drivers are reused and
improved over several years is quite common.

So far we have been developing basic support via platform device
interfaces and directly exposed that to our users via board code
written in C. Over time we start feeling confident that we have good
enough support level and understanding of the hardware for a
particular driver. When that point has been reached then we define
bindings to enable DT support. From there we probably keep on
iterating even more. This is what we currently do.

In mach-shmobile you see a lot of board changes coming from us when we
are performing continuous driver integration. I would like to ask you
for advice if you can recommend us any other development model that
may fit better with the ARM SoC way of doing things.

Thanks,

/ magnus

Re: [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15

[Olof Johansson]

On Fri, Feb 28, 2014 at 01:21:05PM +0900, Magnus Damm wrote:
> On Wed, Feb 26, 2014 at 1:04 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 25 February 2014, Magnus Damm wrote:
> >> On Thu, Feb 20, 2014 at 5:23 PM, Olof Johansson <olof@lixom.net> wrote:
> >> > On Thu, Feb 06, 2014 at 03:17:08PM +0900, Simon Horman wrote:
> >> Thanks for your email. I agree that the number of board file commits
> >> is definitely larger than zero so some clarification is in order.
> >>
> >> As you probably recall, we earlier agreed on not adding any new board
> >> files. That part is clear I believe so I will skip that.
> >>
> >> Regarding the legacy board code, we have quite ok hardware support
> >> coverage as it is now, but some devices drivers are of course still
> >> under development. This means that in some cases integration is on
> >> going or has not happened yet. You may see those kind of changes as
> >> significant commits in the pull requests for board support.
> >
> > [adding Ben Dooks, since he was complaining about this as well]
> >
> > My feeling is that we should adjust the strategy for shmobile. We've
> > had good success with the dual strategy of keeping board support
> > separate for DT-enabled and ATAGS-only boards in the sense that
> > we did not have to coordinate updates for bindings between subsystem
> > and architecture git trees, which has always been source for
> > problems on other platforms.
> 
> Hi Arnd,
> 
> You're right that many of our boot loaders only provide us with ATAG
> information. In the kernel we have long since made use of appended DTB
> to handle those cases. The last bit of code that depended on ATAGS and
> mach-type being passed from the boot loader was removed in the
> following patch:
> 
> [PATCH] ARM: shmobile: Update romImage to relocate appended DTB
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/compressed/head-shmobile.S?id,408d149299e99c89fc4be80fb4fe00a7016f02
> 
> > However, the price for this seems to be that it's still not possible
> > to get a properly working system without a board file, and my feeling
> > is that it's taking too long to get there. In particular, we now see
> > new drivers getting added (I noticed VIN, which Ben mentioned before)
> > that start out with just platform_device support but no DT support.
> > This is bad, because it means DT users are always behind.
> 
> From my side it is possible to boot working systems with DT only
> (without a board file) for a wide range of SoCs and boards. Actually,
> for KZM9D we have no board code - instead there is only Multiplatform
> DT. Any left over C board code for KZM9D and the legacy EMEV2SoC code
> is removed in:
> 
> [PATCH 00/03] ARM: shmobile: Clean up the EMEV2 and KZM9D code base
> http://www.spinics.net/lists/arm-kernel/msg307379.html
> 
> To be clear, I believe all our boards can boot without a board file.
> The only exception is sh7372 and Mackerel which will be phased out.
> 
> Please note that device support may however be limited with DT. This
> since several device drivers are under constant development to be able
> to support the latest hardware features. And the hardware is being
> updated quite regularly, so it seems to me that our only choice is to
> keep on updating software support.
> 
> >> In the Legacy Lager/Koelsch board code the following devices are
> >> supported as platform devices:
> >>
> >> ETHER, SCIF, DU, I2C, SATA*, USB*, MSIOF*, SDHI*, QSPI*, MMCIF,
> >> Audio*, VIN*, Thermal, IRQC, PFC, CMT
> >>
> >> * Platform device support under development in v3.15-pre
> >>
> >> In the Multiplatform DT for Lager/Koelsch the following devices have DT support:
> >>
> >> ETHER, SCIF**, I2C, SATA, MSIOF, SDHI, QSPI, MMCIF, Thermal, IRQC, PFC, CMT**
> >>
> >> ** Driver DT binding development on-going but integration not finalized
> >>
> >> In Multiplatform DT for Lager/Koelsch the following devices lack DT bindings:
> >>
> >> DU (drm/kms)
> >> USB (host/function/phy)
> >> Audio (alsa-soc + dmac)
> >> VIN (v4l2 + camera sensor)
> >
> > Ok, thanks for the list.
> >
> >> Our plan is to migrate over to the DT Multiplatform code base as soon
> >> as ever possible, but at the same time we do not want to commit long
> >> term support of potentially premature DT bindings. Our short term
> >> solution to that is to use platform devices for a limited number of
> >> devices together with DT Multiplatform.
> >>
> >> If you would like use to adjust our way forwards please let me know!
> >
> > I think you should try to close the gap between ATAGS and DT now and
> > stop the dual strategy. You seem to have come far enough with the
> > basic infrastructure (clock, pinctrl, irq, timer, ...) that all the
> > devices missing DT support now are on-chip peripherals. If this is the
> > case, it should be possible to use auxdata registration in the
> > per-soc files to connect the platform data to the remaining devices
> > that are lacking DT bindings. This means we have to be more careful
> > with the dependencies when a driver gains a DT binding, but at least
> > we can enforce that any driver in the future only gets merged with
> > a proper DT binding as we do for other subarchitectures, and you don't
> > have to implement probing twice for each new driver.
> 
> I agree about closing the gap and using DT as much as ever possible.
> Perhaps we need to discuss a bit more about how to proceed.
> 
> In my mind this all boils down to two separate issues:
> 
> 1) How to close the gap:
> 
> Our current plan is to copy the left over non-DT devices from legacy
> board code to our DT board support. This can be done with or without
> AUXDATA, exactly how to do it is a separate (but perhaps important?)
> issue. When the DT board support is in OK state then we remove the
> legacy board code. How long time that takes depends on the level of
> board support. For the boards and devices I listed above I believe it
> can be done in less than a week. If you want us to do this differently
> then please advice us about your preference.
> 
> Regarding AUXDATA, it seems mainly useful for simple devices that have
> no dependencies on other parts of the system. Our remaining portion of
> non-DT device drivers are however all relatively complex devices with
> many dependencies and sometimes odd topology. On such device drivers
> our prototyping showed that AUXDATA mainly came with drawbacks of
> having to commit to bindings prematurely but we could not really see
> any upside. We would like to hear more from you how you think we
> should proceed.

I think you can do at least some of this without committing to bindings all
that early. Keep in mind that bindings can be amended over time, so if you
start a driver with a trivial binding you can add properties over time as
needed.

I think some of this could be easier to discuss if you include one or two
examples of the more complex drivers that you need to tackle.

Using AUXDATA to attach platform data is easy to do but messy to undo, since it
tends to require interlocked changes with the driver trees, which means shared
branches and merge conflicts across the wider tree. It has been done before
though so it's not impossible. :-)

> 2) How to handle continuous driver development and integration
> 
> As you have seen, most of our simple device drivers have already been
> successfully converted to DT. What remains are more complex devices.
> 
> Since we do upstream first we rely on being able to develop device
> driver code incrementally over several kernel releases. To allow early
> use, development and testing we also integrate the device drivers
> continuously. We have been doing this for many years now and it seems
> to work really well for us. That device drivers are reused and
> improved over several years is quite common.
> 
> So far we have been developing basic support via platform device
> interfaces and directly exposed that to our users via board code
> written in C. Over time we start feeling confident that we have good
> enough support level and understanding of the hardware for a
> particular driver. When that point has been reached then we define
> bindings to enable DT support. From there we probably keep on
> iterating even more. This is what we currently do.
> 
> In mach-shmobile you see a lot of board changes coming from us when we
> are performing continuous driver integration. I would like to ask you
> for advice if you can recommend us any other development model that
> may fit better with the ARM SoC way of doing things.

Again, I think it might be beneficial to talk about one or two specific
examples here instead of the generic situation, and figure it out from there.


-Olof

Re: [GIT PULL 00/21] Renesas ARM based SoC Board Updates for v3.15

[Ben Dooks]

On 25/02/14 17:04, Arnd Bergmann wrote:
> On Tuesday 25 February 2014, Magnus Damm wrote:
>> On Thu, Feb 20, 2014 at 5:23 PM, Olof Johansson <olof@lixom.net> wrote:
>>> On Thu, Feb 06, 2014 at 03:17:08PM +0900, Simon Horman wrote:
>> Thanks for your email. I agree that the number of board file commits
>> is definitely larger than zero so some clarification is in order.
>>
>> As you probably recall, we earlier agreed on not adding any new board
>> files. That part is clear I believe so I will skip that.
>>
>> Regarding the legacy board code, we have quite ok hardware support
>> coverage as it is now, but some devices drivers are of course still
>> under development. This means that in some cases integration is on
>> going or has not happened yet. You may see those kind of changes as
>> significant commits in the pull requests for board support.
>
> [adding Ben Dooks, since he was complaining about this as well]

that's putting it mildly....

> My feeling is that we should adjust the strategy for shmobile. We've
> had good success with the dual strategy of keeping board support
> separate for DT-enabled and ATAGS-only boards in the sense that
> we did not have to coordinate updates for bindings between subsystem
> and architecture git trees, which has always been source for
> problems on other platforms.

Personally, I would be happy with no more platform support at-all.

> However, the price for this seems to be that it's still not possible
> to get a properly working system without a board file, and my feeling
> is that it's taking too long to get there. In particular, we now see
> new drivers getting added (I noticed VIN, which Ben mentioned before)
> that start out with just platform_device support but no DT support.
> This is bad, because it means DT users are always behind.

Agreed, for development purposes my current development tree I
am using on the Lager is showing:

  136 files changed, 13142 insertions(+), 1765 deletions(-)

This includes a specific lager_defconfig and Simon's development
work at the time 3.14-rc3 was out.

>> In the Legacy Lager/Koelsch board code the following devices are
>> supported as platform devices:
>>
>> ETHER, SCIF, DU, I2C, SATA*, USB*, MSIOF*, SDHI*, QSPI*, MMCIF,
>> Audio*, VIN*, Thermal, IRQC, PFC, CMT
>>
>> * Platform device support under development in v3.15-pre
>>
>> In the Multiplatform DT for Lager/Koelsch the following devices have DT support:
>>
>> ETHER, SCIF**, I2C, SATA, MSIOF, SDHI, QSPI, MMCIF, Thermal, IRQC, PFC, CMT**

I've tested Ether, I2C, SHDI and MMCIF.

>> ** Driver DT binding development on-going but integration not finalized
>>
>> In Multiplatform DT for Lager/Koelsch the following devices lack DT bindings:
>>
>> DU (drm/kms)
>> USB (host/function/phy)
>> Audio (alsa-soc + dmac)
>> VIN (v4l2 + camera sensor)
>
> Ok, thanks for the list.

The ALSA is on list and seems to be working with minor patches for
the odd issue we found when testing. I will re-post the DMAC branch
tonight for people to review.

VIN, I've sent patches for but these need to be re-sent with some
updates for soc-camera as well as the video input driver updates.

The USB is currently work in progress, both Sergei and I have sent
patches for the PHY, I have patches for DT for the USB host on list.

I feel this would have been faster if we had not found multiple issues
such as the pm_runtime, and bugs in some of the dt support that seems
to have missed being tested until the above have been attempted.

I hope between Geert, Laurent, Sergei and the people at Renesas we've
made some significant steps forward this release cycle. The issues
with pm_runtime should now be sorted as well as other device-tree
problems with shmobile.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius