[GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2

[GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following board enhancements for 3.8.

* This pull request is based on a merge of
  a) The renesas/boards branch of the arm-soc tree
  b) The soc branch of the renesas tree,
     which I have sent a separate pull requst for

* "sh: clkfwk: add sh_clk_fsidiv_register()" is a driver patch
  which is a dependency of
  - ARM: shmobile: sh7372: use sh_clk_fsidiv_register() for FSI-DIV clocks
  - ARM: shmobile: r8a7740: add FSI-DVI clocks
  I have spoken to the driver maintainer, Paul Mundt, and he has indicated
  that he thinks it is best to merge all in one go and acked the patch for
  inclusion in this pull-request.

* The following patches
  - ARM: shmobile: use FSI driver's audio clock on ap4evb
  - ARM: shmobile: use FSI driver's audio clock on mackerel
  - ARM: shmobile: use FSI driver's audio clock on armadillo800eva
  Have a compile-time dependency on the following patch which is present in
  the for-next branch of Mark Brown's sound tree on kernel.org
  - ASoC: fsi: add master clock control functions
    (ab6f6d85210c4d0265cf48e9958c04e08595055a)

----------------------------------------------------------------
The following changes since commit ab3ff12a78a64b851ab22726ab99dca6ad37bf94:

  Merge branch 'soc' into boards (2012-11-08 17:49:35 +0900)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git boards

for you to fetch changes up to 12818d82ccad9868a820dbb193b4f9b797cd02d4:

  ARM: shmobile: use FSI driver's audio clock on ap4evb (2012-11-08 17:52:05 +0900)

----------------------------------------------------------------
Kuninori Morimoto (7):
      ARM: shmobile: marzen: add USB phy support
      ARM: shmobile: marzen: add USB EHCI driver support
      ARM: shmobile: marzen: add USB OHCI driver support
      ARM: shmobile: mackerel: enable DMAEngine on USB Host
      ARM: shmobile: use FSI driver's audio clock on armadillo800eva
      ARM: shmobile: use FSI driver's audio clock on mackerel
      ARM: shmobile: use FSI driver's audio clock on ap4evb

 arch/arm/configs/marzen_defconfig              |   14 +-
 arch/arm/mach-shmobile/Kconfig                 |    2 +
 arch/arm/mach-shmobile/board-ap4evb.c          |  139 +-----------------
 arch/arm/mach-shmobile/board-armadillo800eva.c |   38 +----
 arch/arm/mach-shmobile/board-mackerel.c        |   74 +---------
 arch/arm/mach-shmobile/board-marzen.c          |  186 +++++++++++++++++++++++-
 6 files changed, 205 insertions(+), 248 deletions(-)

[PATCH 1/7] ARM: shmobile: marzen: add USB phy 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@verge.net.au>
---
 arch/arm/configs/marzen_defconfig     |    3 ++-
 arch/arm/mach-shmobile/board-marzen.c |   21 +++++++++++++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index 5b8215f..8a861b7 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -78,7 +78,8 @@ CONFIG_GPIO_SYSFS=y
 CONFIG_THERMAL=y
 CONFIG_RCAR_THERMAL=y
 CONFIG_SSB=y
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB=y
+CONFIG_USB_RCAR_PHY=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHI=y
 CONFIG_UIO=y
diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 69f7f46..74c7f0b 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -144,11 +144,32 @@ static struct platform_device hspi_device = {
 	.num_resources	= ARRAY_SIZE(hspi_resources),
 };
 
+/* USB PHY */
+static struct resource usb_phy_resources[] = {
+	[0] = {
+		.start		= 0xffe70000,
+		.end		= 0xffe70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start		= 0xfff70000,
+		.end		= 0xfff70900 - 1,
+		.flags		= IORESOURCE_MEM,
+	},
+};
+
+static struct platform_device usb_phy_device = {
+	.name		= "rcar_usb_phy",
+	.resource	= usb_phy_resources,
+	.num_resources	= ARRAY_SIZE(usb_phy_resources),
+};
+
 static struct platform_device *marzen_devices[] __initdata = {
 	&eth_device,
 	&sdhi0_device,
 	&thermal_device,
 	&hspi_device,
+	&usb_phy_device,
 };
 
 static void __init marzen_init(void)
-- 
1.7.10.4

[PATCH 1/7] ARM: shmobile: marzen: add USB phy support

[Sergei Shtylyov]

Hello.

On 11/09/2012 10:31 AM, Simon Horman wrote:

> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
>   arch/arm/configs/marzen_defconfig     |    3 ++-
>   arch/arm/mach-shmobile/board-marzen.c |   21 +++++++++++++++++++++
>   2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
> index 69f7f46..74c7f0b 100644
> --- a/arch/arm/mach-shmobile/board-marzen.c
> +++ b/arch/arm/mach-shmobile/board-marzen.c
> @@ -144,11 +144,32 @@ static struct platform_device hspi_device = {
>   	.num_resources	= ARRAY_SIZE(hspi_resources),
>   };
>   
> +/* USB PHY */
> +static struct resource usb_phy_resources[] = {
> +	[0] = {
> +		.start		= 0xffe70000,

    Why not 0xffe70800? 0xffe70000 is where the EHCI registers start.
I don't see why they should be overlapped like this.

> +		.end		= 0xffe70900 - 1,
> +		.flags		= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start		= 0xfff70000,
> +		.end		= 0xfff70900 - 1,

    Hm, this PHY register range doesn't seem to be documented?

> +		.flags		= IORESOURCE_MEM,
> +	},
> +};
> +
> +static struct platform_device usb_phy_device = {
> +	.name		= "rcar_usb_phy",
> +	.resource	= usb_phy_resources,
> +	.num_resources	= ARRAY_SIZE(usb_phy_resources),
> +};
> +
>   static struct platform_device *marzen_devices[] __initdata = {
>   	&eth_device,
>   	&sdhi0_device,
>   	&thermal_device,
>   	&hspi_device,
> +	&usb_phy_device,
>   };
>   
>   static void __init marzen_init(void)

    Finally, the same question as for EHCI: why this ended up in the 
board file instead of setup-r8a7779.c?

WBR, Sergei

[PATCH 1/7] ARM: shmobile: marzen: add USB phy support

[Kuninori Morimoto]

Hi Sergei

> > +/* USB PHY */
> > +static struct resource usb_phy_resources[] = {
> > +	[0] = {
> > +		.start		= 0xffe70000,
> 
>     Why not 0xffe70800? 0xffe70000 is where the EHCI registers start.
> I don't see why they should be overlapped like this.

Current rcar-phy try to access 0xffe7009x

> > +	[1] = {
> > +		.start		= 0xfff70000,
> > +		.end		= 0xfff70900 - 1,
> 
>     Hm, this PHY register range doesn't seem to be documented?

0xffe70000 is for port0/1
0xfff70000 is for port2

But this 0xfff70000 is only for 0xfff7009x access

Best regards
---
Kuninori Morimoto

[PATCH 1/7] ARM: shmobile: marzen: add USB phy support

[Sergei Shtylyov]

Hello.

On 14-03-2013 4:44, Kuninori Morimoto wrote:

>>> +/* USB PHY */
>>> +static struct resource usb_phy_resources[] = {
>>> +	[0] = {
>>> +		.start		= 0xffe70000,

>>      Why not 0xffe70800? 0xffe70000 is where the EHCI registers start.
>> I don't see why they should be overlapped like this.

> Current rcar-phy try to access 0xffe7009x

    That should be changed too IHO, as these registers are not really PHY 
related, they control EHCI itself. These writes should be done somewhere in 
setup-r8a7779.c probably.

>>> +	[1] = {
>>> +		.start		= 0xfff70000,
>>> +		.end		= 0xfff70900 - 1,

>>      Hm, this PHY register range doesn't seem to be documented?

> 0xffe70000 is for port0/1
> 0xfff70000 is for port2

> But this 0xfff70000 is only for 0xfff7009x access

    Yeah, I understood that it's only for the extra EHCI registers.

> Best regards
> ---
> Kuninori Morimoto

WBR, Sergei

[PATCH 2/7] ARM: shmobile: marzen: add USB EHCI driver support

[Simon Horman]

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

This patch supports CN21/CN22 USB 2.0 (port 0/1/2),
and enable USB momery on defconfig

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/configs/marzen_defconfig     |    6 ++
 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-marzen.c |  108 ++++++++++++++++++++++++++++++++-
 3 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index 8a861b7..6540dfb 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -47,6 +47,8 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FW_LOADER is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_BROADCOM is not set
 # CONFIG_NET_VENDOR_FARADAY is not set
@@ -82,6 +84,10 @@ CONFIG_USB=y
 CONFIG_USB_RCAR_PHY=y
 CONFIG_MMC=y
 CONFIG_MMC_SDHI=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_STORAGE=y
 CONFIG_UIO=y
 CONFIG_UIO_PDRV_GENIRQ=y
 # CONFIG_IOMMU_SUPPORT is not set
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 4eddca1..4eae11c 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -29,6 +29,7 @@ config ARCH_R8A7779
 	select ARM_GIC
 	select CPU_V7
 	select SH_CLK_CPG
+	select USB_ARCH_HAS_EHCI
 
 config ARCH_EMEV2
 	bool "Emma Mobile EV2"
diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 74c7f0b..707b3bd 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -34,6 +34,9 @@
 #include <linux/spi/sh_hspi.h>
 #include <linux/mmc/sh_mobile_sdhi.h>
 #include <linux/mfd/tmio.h>
+#include <linux/usb/otg.h>
+#include <linux/usb/ehci_pdriver.h>
+#include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
 #include <mach/common.h>
@@ -172,6 +175,101 @@ static struct platform_device *marzen_devices[] __initdata = {
 	&usb_phy_device,
 };
 
+/* USB */
+static struct usb_phy *phy;
+static int usb_power_on(struct platform_device *pdev)
+{
+	if (!phy)
+		return -EIO;
+
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	usb_phy_init(phy);
+
+	return 0;
+}
+
+static void usb_power_off(struct platform_device *pdev)
+{
+	if (!phy)
+		return;
+
+	usb_phy_shutdown(phy);
+
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+}
+
+static struct usb_ehci_pdata ehcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ehci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70000,
+		.end	= 0xffe70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_spi(44),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci0_device = {
+	.name	= "ehci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci0_resources),
+	.resource	= ehci0_resources,
+};
+
+static struct resource ehci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70000,
+		.end	= 0xfff70400 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_spi(45),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ehci1_device = {
+	.name	= "ehci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ehcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ehci1_resources),
+	.resource	= ehci1_resources,
+};
+
+static struct platform_device *marzen_late_devices[] __initdata = {
+	&ehci0_device,
+	&ehci1_device,
+};
+
+void __init marzen_init_late(void)
+{
+	/* get usb phy */
+	phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+	shmobile_init_late();
+	platform_add_devices(marzen_late_devices,
+			     ARRAY_SIZE(marzen_late_devices));
+}
+
 static void __init marzen_init(void)
 {
 	regulator_register_always_on(0, "fixed-3.3V", fixed3v3_power_consumers,
@@ -209,6 +307,14 @@ static void __init marzen_init(void)
 	gpio_request(GPIO_FN_HSPI_TX0,	NULL);
 	gpio_request(GPIO_FN_HSPI_RX0,	NULL);
 
+	/* USB (CN21) */
+	gpio_request(GPIO_FN_USB_OVC0, NULL);
+	gpio_request(GPIO_FN_USB_OVC1, NULL);
+	gpio_request(GPIO_FN_USB_OVC2, NULL);
+
+	/* USB (CN22) */
+	gpio_request(GPIO_FN_USB_PENC2, NULL);
+
 	r8a7779_add_standard_devices();
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
@@ -221,6 +327,6 @@ MACHINE_START(MARZEN, "marzen")
 	.init_irq	= r8a7779_init_irq,
 	.handle_irq	= gic_handle_irq,
 	.init_machine	= marzen_init,
-	.init_late	= shmobile_init_late,
+	.init_late	= marzen_init_late,
 	.timer		= &shmobile_timer,
 MACHINE_END
-- 
1.7.10.4

[PATCH 2/7] ARM: shmobile: marzen: add USB EHCI driver support

[Sergei Shtylyov]

Hello.

On 11/09/2012 10:31 AM, Simon Horman wrote:

> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch supports CN21/CN22 USB 2.0 (port 0/1/2),
> and enable USB momery on defconfig

    Sorry for late comment but I'm studying this code just now (in order 
to add R-Car M1A USB support).

> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
> ---
>   arch/arm/configs/marzen_defconfig     |    6 ++
>   arch/arm/mach-shmobile/Kconfig        |    1 +
>   arch/arm/mach-shmobile/board-marzen.c |  108 ++++++++++++++++++++++++++++++++-
>   3 files changed, 114 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
> index 74c7f0b..707b3bd 100644
> --- a/arch/arm/mach-shmobile/board-marzen.c
> +++ b/arch/arm/mach-shmobile/board-marzen.c
> @@ -34,6 +34,9 @@
[...]
> @@ -172,6 +175,101 @@ static struct platform_device *marzen_devices[] __initdata = {
>   	&usb_phy_device,
>   };
>   
> +/* USB */
> +static struct usb_phy *phy;
> +static int usb_power_on(struct platform_device *pdev)
> +{
> +	if (!phy)
> +		return -EIO;
> +
> +	pm_runtime_enable(&pdev->dev);
> +	pm_runtime_get_sync(&pdev->dev);
> +
> +	usb_phy_init(phy);
> +
> +	return 0;
> +}
> +
> +static void usb_power_off(struct platform_device *pdev)
> +{
> +	if (!phy)
> +		return;
> +
> +	usb_phy_shutdown(phy);
> +
> +	pm_runtime_put_sync(&pdev->dev);
> +	pm_runtime_disable(&pdev->dev);
> +}
> +
> +static struct usb_ehci_pdata ehcix_pdata = {
> +	.power_on	= usb_power_on,
> +	.power_off	= usb_power_off,
> +	.power_suspend	= usb_power_off,
> +};
> +
> +static struct resource ehci0_resources[] = {
> +	[0] = {
> +		.start	= 0xffe70000,
> +		.end	= 0xffe70400 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_spi(44),
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device ehci0_device = {
> +	.name	= "ehci-platform",
> +	.id	= 0,
> +	.dev	= {
> +		.dma_mask		= &ehci0_device.dev.coherent_dma_mask,
> +		.coherent_dma_mask	= 0xffffffff,
> +		.platform_data		= &ehcix_pdata,
> +	},
> +	.num_resources	= ARRAY_SIZE(ehci0_resources),
> +	.resource	= ehci0_resources,
> +};
> +
> +static struct resource ehci1_resources[] = {
> +	[0] = {
> +		.start	= 0xfff70000,
> +		.end	= 0xfff70400 - 1,
> +		.flags	= IORESOURCE_MEM,
> +	},
> +	[1] = {
> +		.start	= gic_spi(45),
> +		.flags	= IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device ehci1_device = {
> +	.name	= "ehci-platform",
> +	.id	= 1,
> +	.dev	= {
> +		.dma_mask		= &ehci1_device.dev.coherent_dma_mask,
> +		.coherent_dma_mask	= 0xffffffff,
> +		.platform_data		= &ehcix_pdata,
> +	},
> +	.num_resources	= ARRAY_SIZE(ehci1_resources),
> +	.resource	= ehci1_resources,
> +};
> +
> +static struct platform_device *marzen_late_devices[] __initdata = {
> +	&ehci0_device,
> +	&ehci1_device,
> +};
> +
> +void __init marzen_init_late(void)
> +{
> +	/* get usb phy */
> +	phy = usb_get_phy(USB_PHY_TYPE_USB2);
> +
> +	shmobile_init_late();
> +	platform_add_devices(marzen_late_devices,
> +			     ARRAY_SIZE(marzen_late_devices));
> +}
> +
>

    Morimoto-san, I don't understand why this SoC specific platform device
ended up in the board file? Could you explain your reasons please?
    I think this is generally a bad practice as this approach scales badly.

WVR, Sergei

[PATCH 2/7] ARM: shmobile: marzen: add USB EHCI driver support

[Kuninori Morimoto]

Hi Sergei

> > +/* USB */
> > +static struct usb_phy *phy;
> > +static int usb_power_on(struct platform_device *pdev)
> > +{
> > +	if (!phy)
> > +		return -EIO;
> > +
> > +	pm_runtime_enable(&pdev->dev);
> > +	pm_runtime_get_sync(&pdev->dev);
> > +
> > +	usb_phy_init(phy);
> > +
> > +	return 0;
> > +}
> > +
> > +static void usb_power_off(struct platform_device *pdev)
> > +{
> > +	if (!phy)
> > +		return;
> > +
> > +	usb_phy_shutdown(phy);
> > +
> > +	pm_runtime_put_sync(&pdev->dev);
> > +	pm_runtime_disable(&pdev->dev);
> > +}
> > +
> > +static struct usb_ehci_pdata ehcix_pdata = {
> > +	.power_on	= usb_power_on,
> > +	.power_off	= usb_power_off,
> > +	.power_suspend	= usb_power_off,
> > +};
(snip)
>     Morimoto-san, I don't understand why this SoC specific platform device
> ended up in the board file? Could you explain your reasons please?
>     I think this is generally a bad practice as this approach scales badly.

Do you mean it should exist in setup-r8a7779.c ?

I forgot detail of it, but these usb is using callback function,
and it is using *phy*.
This phy came from marzen_init_late() with usb_get_phy(USB_PHY_TYPE_USB2);
This usb_get_phy() is not needed if board doesn't have USB.

You can modify it if you want

Best regards
---
Kuninori Morimoto

[PATCH 2/7] ARM: shmobile: marzen: add USB EHCI driver support

[Kuninori Morimoto]

Hi Sergei

> >     Morimoto-san, I don't understand why this SoC specific platform device
> > ended up in the board file? Could you explain your reasons please?
> >     I think this is generally a bad practice as this approach scales badly.
> 
> Do you mean it should exist in setup-r8a7779.c ?
> 
> I forgot detail of it, but these usb is using callback function,
> and it is using *phy*.
> This phy came from marzen_init_late() with usb_get_phy(USB_PHY_TYPE_USB2);
> This usb_get_phy() is not needed if board doesn't have USB.
> 
> You can modify it if you want

And, as you pointed in USB ML,
This rcar_usb_phy driver will need board specific initialization.
(it is not implemented at this point...)


Best regards
---
Kuninori Morimoto

[PATCH 2/7] ARM: shmobile: marzen: add USB EHCI driver support

[Sergei Shtylyov]

Hello.

On 14-03-2013 4:29, Kuninori Morimoto wrote:

>>> +/* USB */
>>> +static struct usb_phy *phy;
>>> +static int usb_power_on(struct platform_device *pdev)
>>> +{
>>> +	if (!phy)
>>> +		return -EIO;
>>> +
>>> +	pm_runtime_enable(&pdev->dev);
>>> +	pm_runtime_get_sync(&pdev->dev);
>>> +
>>> +	usb_phy_init(phy);
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static void usb_power_off(struct platform_device *pdev)
>>> +{
>>> +	if (!phy)
>>> +		return;
>>> +
>>> +	usb_phy_shutdown(phy);
>>> +
>>> +	pm_runtime_put_sync(&pdev->dev);
>>> +	pm_runtime_disable(&pdev->dev);
>>> +}
>>> +
>>> +static struct usb_ehci_pdata ehcix_pdata = {
>>> +	.power_on	= usb_power_on,
>>> +	.power_off	= usb_power_off,
>>> +	.power_suspend	= usb_power_off,
>>> +};
> (snip)

>>      Morimoto-san, I don't understand why this SoC specific platform device
>> ended up in the board file? Could you explain your reasons please?
>>      I think this is generally a bad practice as this approach scales badly.

> Do you mean it should exist in setup-r8a7779.c ?

    Yes.

> I forgot detail of it, but these usb is using callback function,
> and it is using *phy*.

   But this PHY also belongs to SoC.

> This phy came from marzen_init_late() with usb_get_phy(USB_PHY_TYPE_USB2);
> This usb_get_phy() is not needed if board doesn't have USB.

    Anyway, there should be ways to separate the board specific platform code 
and the SoC specific one. That's what other subarches do.

> You can modify it if you want

    Yes, I definitely would like to try.

WBR, Sergei

[PATCH 2/7] ARM: shmobile: marzen: add USB EHCI driver support

[Kuninori Morimoto]

Hi Sergei

> > I forgot detail of it, but these usb is using callback function,
> > and it is using *phy*.
> 
>    But this PHY also belongs to SoC.
> 
> > This phy came from marzen_init_late() with usb_get_phy(USB_PHY_TYPE_USB2);
> > This usb_get_phy() is not needed if board doesn't have USB.
> 
>     Anyway, there should be ways to separate the board specific platform code 
> and the SoC specific one. That's what other subarches do.
>
> > You can modify it if you want
> 
>     Yes, I definitely would like to try.

I checked CPG :: MSTP for USB0/1/2 and USB Host/Function,
and GIC number for it.
It seems no conflict each other
I guess EHCI/OHCI goes to setup seems no problem.

But, as you pointed on USB ML,
USB-PHY :: USBPCTRL0 depends on platform
(Host/Function selection, and OVC pin setting)

rcar_usb_phy driver belongs to platform


Best regards
---
Kuninori Morimoto

[PATCH 2/7] ARM: shmobile: marzen: add USB EHCI driver support

[Sergei Shtylyov]

Hello.

On 15-03-2013 4:52, Kuninori Morimoto wrote:

>>> I forgot detail of it, but these usb is using callback function,
>>> and it is using *phy*.

>>     But this PHY also belongs to SoC.

>>> This phy came from marzen_init_late() with usb_get_phy(USB_PHY_TYPE_USB2);
>>> This usb_get_phy() is not needed if board doesn't have USB.

>>      Anyway, there should be ways to separate the board specific platform code
>> and the SoC specific one. That's what other subarches do.

>>> You can modify it if you want

>>      Yes, I definitely would like to try.

> I checked CPG :: MSTP for USB0/1/2 and USB Host/Function,
> and GIC number for it.
> It seems no conflict each other
> I guess EHCI/OHCI goes to setup seems no problem.

> But, as you pointed on USB ML,
> USB-PHY :: USBPCTRL0 depends on platform
> (Host/Function selection, and OVC pin setting)

> rcar_usb_phy driver belongs to platform

    No, it doesn't. Only it's (future) platform data will belong to the board --
that's what they were designed for.

WBR, Sergei

[PATCH 3/7] ARM: shmobile: marzen: add USB OHCI driver support

[Simon Horman]

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

This patch supports CN21/CN22 USB 1.x (port 0/1/2),
and enable input event on defconfig

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/configs/marzen_defconfig     |    5 +--
 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-marzen.c |   57 +++++++++++++++++++++++++++++++++
 3 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index 6540dfb..728a43c 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -61,9 +61,8 @@ CONFIG_SMSC911X=y
 # CONFIG_NET_VENDOR_STMICRO is not set
 # CONFIG_WLAN is not set
 # CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
+CONFIG_INPUT_EVDEV=y
 # CONFIG_INPUT_MOUSE is not set
-# CONFIG_SERIO is not set
 # CONFIG_VT is not set
 # CONFIG_LEGACY_PTYS is not set
 # CONFIG_DEVKMEM is not set
@@ -86,6 +85,8 @@ CONFIG_MMC=y
 CONFIG_MMC_SDHI=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_STORAGE=y
 CONFIG_UIO=y
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 4eae11c..9255546 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -30,6 +30,7 @@ config ARCH_R8A7779
 	select CPU_V7
 	select SH_CLK_CPG
 	select USB_ARCH_HAS_EHCI
+	select USB_ARCH_HAS_OHCI
 
 config ARCH_EMEV2
 	bool "Emma Mobile EV2"
diff --git a/arch/arm/mach-shmobile/board-marzen.c b/arch/arm/mach-shmobile/board-marzen.c
index 707b3bd..449f928 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
@@ -36,6 +36,7 @@
 #include <linux/mfd/tmio.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
 #include <linux/pm_runtime.h>
 #include <mach/hardware.h>
 #include <mach/r8a7779.h>
@@ -255,9 +256,65 @@ static struct platform_device ehci1_device = {
 	.resource	= ehci1_resources,
 };
 
+static struct usb_ohci_pdata ohcix_pdata = {
+	.power_on	= usb_power_on,
+	.power_off	= usb_power_off,
+	.power_suspend	= usb_power_off,
+};
+
+static struct resource ohci0_resources[] = {
+	[0] = {
+		.start	= 0xffe70400,
+		.end	= 0xffe70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_spi(44),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci0_device = {
+	.name	= "ohci-platform",
+	.id	= 0,
+	.dev	= {
+		.dma_mask		= &ohci0_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci0_resources),
+	.resource	= ohci0_resources,
+};
+
+static struct resource ohci1_resources[] = {
+	[0] = {
+		.start	= 0xfff70400,
+		.end	= 0xfff70800 - 1,
+		.flags	= IORESOURCE_MEM,
+	},
+	[1] = {
+		.start	= gic_spi(45),
+		.flags	= IORESOURCE_IRQ,
+	},
+};
+
+static struct platform_device ohci1_device = {
+	.name	= "ohci-platform",
+	.id	= 1,
+	.dev	= {
+		.dma_mask		= &ohci1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= 0xffffffff,
+		.platform_data		= &ohcix_pdata,
+	},
+	.num_resources	= ARRAY_SIZE(ohci1_resources),
+	.resource	= ohci1_resources,
+};
+
 static struct platform_device *marzen_late_devices[] __initdata = {
 	&ehci0_device,
 	&ehci1_device,
+	&ohci0_device,
+	&ohci1_device,
 };
 
 void __init marzen_init_late(void)
-- 
1.7.10.4

[PATCH 4/7] ARM: shmobile: mackerel: enable DMAEngine on USB Host

[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@verge.net.au>
---
 arch/arm/mach-shmobile/board-mackerel.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index f274252..d5fe365 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -816,6 +816,8 @@ static struct platform_device usbhs1_device = {
 	.id	= 1,
 	.dev = {
 		.platform_data		= &usbhs1_private.info,
+		.dma_mask		= &usbhs1_device.dev.coherent_dma_mask,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
 	},
 	.num_resources	= ARRAY_SIZE(usbhs1_resources),
 	.resource	= usbhs1_resources,
-- 
1.7.10.4

[PATCH 5/7] ARM: shmobile: use FSI driver's audio clock on armadillo800eva

[Simon Horman]

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

Current FSI driver can control audio clock without platform
call-back functions
This patch removed board-specific call-back/settings

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

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index fe27d7e..3d4c0e4 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -768,32 +768,6 @@ static struct platform_device ceu0_device = {
 };
 
 /* FSI */
-static int fsi_hdmi_set_rate(struct device *dev, int rate, int enable)
-{
-	struct clk *fsib;
-	int ret;
-
-	/* it support 48KHz only */
-	if (48000 != rate)
-		return -EINVAL;
-
-	fsib = clk_get(dev, "ickb");
-	if (IS_ERR(fsib))
-		return -EINVAL;
-
-	if (enable) {
-		ret = SH_FSI_ACKMD_256 | SH_FSI_BPFMD_64;
-		clk_enable(fsib);
-	} else {
-		ret = 0;
-		clk_disable(fsib);
-	}
-
-	clk_put(fsib);
-
-	return ret;
-}
-
 static struct sh_fsi_platform_info fsi_info = {
 	/* FSI-WM8978 */
 	.port_a = {
@@ -802,8 +776,8 @@ static struct sh_fsi_platform_info fsi_info = {
 	/* FSI-HDMI */
 	.port_b = {
 		.flags		= SH_FSI_FMT_SPDIF |
-				  SH_FSI_ENABLE_STREAM_MODE,
-		.set_rate	= fsi_hdmi_set_rate,
+				  SH_FSI_ENABLE_STREAM_MODE |
+				  SH_FSI_CLK_CPG,
 		.tx_id		= SHDMA_SLAVE_FSIB_TX,
 	}
 };
@@ -938,13 +912,11 @@ static void __init eva_clock_init(void)
 	struct clk *xtal1	= clk_get(NULL, "extal1");
 	struct clk *usb24s	= clk_get(NULL, "usb24s");
 	struct clk *fsibck	= clk_get(NULL, "fsibck");
-	struct clk *fsib	= clk_get(&fsi_device.dev, "ickb");
 
 	if (IS_ERR(system)	||
 	    IS_ERR(xtal1)	||
 	    IS_ERR(usb24s)	||
-	    IS_ERR(fsibck)	||
-	    IS_ERR(fsib)) {
+	    IS_ERR(fsibck)) {
 		pr_err("armadillo800eva board clock init failed\n");
 		goto clock_error;
 	}
@@ -956,9 +928,7 @@ static void __init eva_clock_init(void)
 	clk_set_parent(usb24s, system);
 
 	/* FSIBCK is 12.288MHz, and it is parent of FSI-B */
-	clk_set_parent(fsib, fsibck);
 	clk_set_rate(fsibck, 12288000);
-	clk_set_rate(fsib,   12288000);
 
 clock_error:
 	if (!IS_ERR(system))
@@ -969,8 +939,6 @@ clock_error:
 		clk_put(usb24s);
 	if (!IS_ERR(fsibck))
 		clk_put(fsibck);
-	if (!IS_ERR(fsib))
-		clk_put(fsib);
 }
 
 /*
-- 
1.7.10.4

[PATCH 6/7] ARM: shmobile: use FSI driver's audio clock on mackerel

[Simon Horman]

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

Current FSI driver can control audio clock without platform
call-back functions
This patch removed board-specific call-back/settings

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

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index d5fe365..bf2bcb9 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -862,76 +862,6 @@ static struct platform_device leds_device = {
 
 /* FSI */
 #define IRQ_FSI evt2irq(0x1840)
-static int __fsi_set_round_rate(struct clk *clk, long rate, int enable)
-{
-	int ret;
-
-	if (rate <= 0)
-		return 0;
-
-	if (!enable) {
-		clk_disable(clk);
-		return 0;
-	}
-
-	ret = clk_set_rate(clk, clk_round_rate(clk, rate));
-	if (ret < 0)
-		return ret;
-
-	return clk_enable(clk);
-}
-
-static int fsi_b_set_rate(struct device *dev, int rate, int enable)
-{
-	struct clk *fsib_clk;
-	struct clk *fdiv_clk = clk_get(NULL, "fsidivb");
-	long fsib_rate = 0;
-	long fdiv_rate = 0;
-	int ackmd_bpfmd;
-	int ret;
-
-	/* clock start */
-	switch (rate) {
-	case 44100:
-		fsib_rate	= rate * 256;
-		ackmd_bpfmd	= SH_FSI_ACKMD_256 | SH_FSI_BPFMD_64;
-		break;
-	case 48000:
-		fsib_rate	= 85428000; /* around 48kHz x 256 x 7 */
-		fdiv_rate	= rate * 256;
-		ackmd_bpfmd	= SH_FSI_ACKMD_256 | SH_FSI_BPFMD_64;
-		break;
-	default:
-		pr_err("unsupported rate in FSI2 port B\n");
-		return -EINVAL;
-	}
-
-	/* FSI B setting */
-	fsib_clk = clk_get(dev, "ickb");
-	if (IS_ERR(fsib_clk))
-		return -EIO;
-
-	/* fsib */
-	ret = __fsi_set_round_rate(fsib_clk, fsib_rate, enable);
-	if (ret < 0)
-		goto fsi_set_rate_end;
-
-	/* FSI DIV */
-	ret = __fsi_set_round_rate(fdiv_clk, fdiv_rate, enable);
-	if (ret < 0) {
-		/* disable FSI B */
-		if (enable)
-			__fsi_set_round_rate(fsib_clk, fsib_rate, 0);
-		goto fsi_set_rate_end;
-	}
-
-	ret = ackmd_bpfmd;
-
-fsi_set_rate_end:
-	clk_put(fsib_clk);
-	return ret;
-}
-
 static struct sh_fsi_platform_info fsi_info = {
 	.port_a = {
 		.flags = SH_FSI_BRS_INV,
@@ -942,8 +872,8 @@ static struct sh_fsi_platform_info fsi_info = {
 		.flags = SH_FSI_BRS_INV	|
 			SH_FSI_BRM_INV	|
 			SH_FSI_LRS_INV	|
+			SH_FSI_CLK_CPG	|
 			SH_FSI_FMT_SPDIF,
-		.set_rate = fsi_b_set_rate,
 	}
 };
 
-- 
1.7.10.4

[PATCH 7/7] ARM: shmobile: use FSI driver's audio clock on ap4evb

[Simon Horman]

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

Current FSI driver can control audio clock without platform
call-back functions
This patch removed board-specific call-back/settings

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

diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
index cefdd03..4065785 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -658,133 +658,16 @@ static struct platform_device lcdc_device = {
 
 /* FSI */
 #define IRQ_FSI		evt2irq(0x1840)
-static int __fsi_set_rate(struct clk *clk, long rate, int enable)
-{
-	int ret = 0;
-
-	if (rate <= 0)
-		return ret;
-
-	if (enable) {
-		ret = clk_set_rate(clk, rate);
-		if (0 == ret)
-			ret = clk_enable(clk);
-	} else {
-		clk_disable(clk);
-	}
-
-	return ret;
-}
-
-static int __fsi_set_round_rate(struct clk *clk, long rate, int enable)
-{
-	return __fsi_set_rate(clk, clk_round_rate(clk, rate), enable);
-}
-
-static int fsi_ak4642_set_rate(struct device *dev, int rate, int enable)
-{
-	struct clk *fsia_ick;
-	struct clk *fsiack;
-	int ret = -EIO;
-
-	fsia_ick = clk_get(dev, "icka");
-	if (IS_ERR(fsia_ick))
-		return PTR_ERR(fsia_ick);
-
-	/*
-	 * FSIACK is connected to AK4642,
-	 * and use external clock pin from it.
-	 * it is parent of fsia_ick now.
-	 */
-	fsiack = clk_get_parent(fsia_ick);
-	if (!fsiack)
-		goto fsia_ick_out;
-
-	/*
-	 * we get 1/1 divided clock by setting same rate to fsiack and fsia_ick
-	 *
-	 ** FIXME **
-	 * Because the freq_table of external clk (fsiack) are all 0,
-	 * the return value of clk_round_rate became 0.
-	 * So, it use __fsi_set_rate here.
-	 */
-	ret = __fsi_set_rate(fsiack, rate, enable);
-	if (ret < 0)
-		goto fsiack_out;
-
-	ret = __fsi_set_round_rate(fsia_ick, rate, enable);
-	if ((ret < 0) && enable)
-		__fsi_set_round_rate(fsiack, rate, 0); /* disable FSI ACK */
-
-fsiack_out:
-	clk_put(fsiack);
-
-fsia_ick_out:
-	clk_put(fsia_ick);
-
-	return 0;
-}
-
-static int fsi_hdmi_set_rate(struct device *dev, int rate, int enable)
-{
-	struct clk *fsib_clk;
-	struct clk *fdiv_clk = clk_get(NULL, "fsidivb");
-	long fsib_rate = 0;
-	long fdiv_rate = 0;
-	int ackmd_bpfmd;
-	int ret;
-
-	switch (rate) {
-	case 44100:
-		fsib_rate	= rate * 256;
-		ackmd_bpfmd	= SH_FSI_ACKMD_256 | SH_FSI_BPFMD_64;
-		break;
-	case 48000:
-		fsib_rate	= 85428000; /* around 48kHz x 256 x 7 */
-		fdiv_rate	= rate * 256;
-		ackmd_bpfmd	= SH_FSI_ACKMD_256 | SH_FSI_BPFMD_64;
-		break;
-	default:
-		pr_err("unsupported rate in FSI2 port B\n");
-		return -EINVAL;
-	}
-
-	/* FSI B setting */
-	fsib_clk = clk_get(dev, "ickb");
-	if (IS_ERR(fsib_clk))
-		return -EIO;
-
-	ret = __fsi_set_round_rate(fsib_clk, fsib_rate, enable);
-	if (ret < 0)
-		goto fsi_set_rate_end;
-
-	/* FSI DIV setting */
-	ret = __fsi_set_round_rate(fdiv_clk, fdiv_rate, enable);
-	if (ret < 0) {
-		/* disable FSI B */
-		if (enable)
-			__fsi_set_round_rate(fsib_clk, fsib_rate, 0);
-		goto fsi_set_rate_end;
-	}
-
-	ret = ackmd_bpfmd;
-
-fsi_set_rate_end:
-	clk_put(fsib_clk);
-	return ret;
-}
-
 static struct sh_fsi_platform_info fsi_info = {
 	.port_a = {
 		.flags		= SH_FSI_BRS_INV,
-		.set_rate	= fsi_ak4642_set_rate,
 	},
 	.port_b = {
 		.flags		= SH_FSI_BRS_INV |
 				  SH_FSI_BRM_INV |
 				  SH_FSI_LRS_INV |
+				  SH_FSI_CLK_CPG |
 				  SH_FSI_FMT_SPDIF,
-		.set_rate	= fsi_hdmi_set_rate,
 	},
 };
 
@@ -1144,25 +1027,6 @@ out:
 		clk_put(hdmi_ick);
 }
 
-static void __init fsi_init_pm_clock(void)
-{
-	struct clk *fsia_ick;
-	int ret;
-
-	fsia_ick = clk_get(&fsi_device.dev, "icka");
-	if (IS_ERR(fsia_ick)) {
-		ret = PTR_ERR(fsia_ick);
-		pr_err("Cannot get FSI ICK: %d\n", ret);
-		return;
-	}
-
-	ret = clk_set_parent(fsia_ick, &sh7372_fsiack_clk);
-	if (ret < 0)
-		pr_err("Cannot set FSI-A parent: %d\n", ret);
-
-	clk_put(fsia_ick);
-}
-
 /* TouchScreen */
 #ifdef CONFIG_AP4EVB_QHD
 # define GPIO_TSC_IRQ	GPIO_FN_IRQ28_123
@@ -1476,7 +1340,6 @@ static void __init ap4evb_init(void)
 				       ARRAY_SIZE(domain_devices));
 
 	hdmi_init_pm_clock();
-	fsi_init_pm_clock();
 	sh7372_pm_init();
 	pm_clk_add(&fsi_device.dev, "spu2");
 	pm_clk_add(&lcdc1_device.dev, "hdmi");
-- 
1.7.10.4

[GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2

[Arnd Bergmann]

On Friday 09 November 2012, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> please consider the following board enhancements for 3.8.
> 
> * This pull request is based on a merge of
>   a) The renesas/boards branch of the arm-soc tree
>   b) The soc branch of the renesas tree,
>      which I have sent a separate pull requst for
> 
> * "sh: clkfwk: add sh_clk_fsidiv_register()" is a driver patch
>   which is a dependency of
>   - ARM: shmobile: sh7372: use sh_clk_fsidiv_register() for FSI-DIV clocks
>   - ARM: shmobile: r8a7740: add FSI-DVI clocks
>   I have spoken to the driver maintainer, Paul Mundt, and he has indicated
>   that he thinks it is best to merge all in one go and acked the patch for
>   inclusion in this pull-request.
> 
> * The following patches
>   - ARM: shmobile: use FSI driver's audio clock on ap4evb
>   - ARM: shmobile: use FSI driver's audio clock on mackerel
>   - ARM: shmobile: use FSI driver's audio clock on armadillo800eva
>   Have a compile-time dependency on the following patch which is present in
>   the for-next branch of Mark Brown's sound tree on kernel.org
>   - ASoC: fsi: add master clock control functions
>     (ab6f6d85210c4d0265cf48e9958c04e08595055a)

Hi Simon,

I've pulled this into a new next/boards2 branch because of the new dependency,
but I'm not entirely happy with the way that the dependency came in through
your tree.

It's generally ok to have external dependencies where they can't be avoided,
but please remember these rules:

* When you send a branch that has an external dependency, actually base your
  branch on top of the other one, so that it can be independently verified.
  If you have a dependency and send your patches without that one included,
  it's clear that your code can't be tested in the version you are sending,
  and it breaks any attempt to test just the arm-soc tree or your branch
  rather than the entire for-next tree.

* Make sure that the branch you depend on will not get rebased before it
  gets submitted to the mainline kernel.

* Always let the person that owns the dependency know that the changes in
  their tree are also included elsewhere and that things go bad if those
  changes get rebased after all, or won't make it into the merge window
  for some reason.

I have taken Mark on Cc to let him know about the dependency now, and I've
merged ab6f6d85210c4d0265cf48e9958c04e08595055a (which has only shmobile
specific ASoC patches) into the next/boards2 branch before merging your
branch. This is still not perfect because it breaks bisection, but it's
the best I could do aside from forcing you do do another round-trip.

	Arnd

[GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2

[Simon Horman]

On Mon, Nov 12, 2012 at 09:11:03PM +0000, Arnd Bergmann wrote:
> On Friday 09 November 2012, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> > 
> > please consider the following board enhancements for 3.8.
> > 
> > * This pull request is based on a merge of
> >   a) The renesas/boards branch of the arm-soc tree
> >   b) The soc branch of the renesas tree,
> >      which I have sent a separate pull requst for
> > 
> > * "sh: clkfwk: add sh_clk_fsidiv_register()" is a driver patch
> >   which is a dependency of
> >   - ARM: shmobile: sh7372: use sh_clk_fsidiv_register() for FSI-DIV clocks
> >   - ARM: shmobile: r8a7740: add FSI-DVI clocks
> >   I have spoken to the driver maintainer, Paul Mundt, and he has indicated
> >   that he thinks it is best to merge all in one go and acked the patch for
> >   inclusion in this pull-request.
> > 
> > * The following patches
> >   - ARM: shmobile: use FSI driver's audio clock on ap4evb
> >   - ARM: shmobile: use FSI driver's audio clock on mackerel
> >   - ARM: shmobile: use FSI driver's audio clock on armadillo800eva
> >   Have a compile-time dependency on the following patch which is present in
> >   the for-next branch of Mark Brown's sound tree on kernel.org
> >   - ASoC: fsi: add master clock control functions
> >     (ab6f6d85210c4d0265cf48e9958c04e08595055a)
> 
> Hi Simon,
> 
> I've pulled this into a new next/boards2 branch because of the new dependency,
> but I'm not entirely happy with the way that the dependency came in through
> your tree.
> 
> It's generally ok to have external dependencies where they can't be avoided,
> but please remember these rules:
> 
> * When you send a branch that has an external dependency, actually base your
>   branch on top of the other one, so that it can be independently verified.
>   If you have a dependency and send your patches without that one included,
>   it's clear that your code can't be tested in the version you are sending,
>   and it breaks any attempt to test just the arm-soc tree or your branch
>   rather than the entire for-next tree.
> 
> * Make sure that the branch you depend on will not get rebased before it
>   gets submitted to the mainline kernel.
> 
> * Always let the person that owns the dependency know that the changes in
>   their tree are also included elsewhere and that things go bad if those
>   changes get rebased after all, or won't make it into the merge window
>   for some reason.
> 
> I have taken Mark on Cc to let him know about the dependency now, and I've
> merged ab6f6d85210c4d0265cf48e9958c04e08595055a (which has only shmobile
> specific ASoC patches) into the next/boards2 branch before merging your
> branch. This is still not perfect because it breaks bisection, but it's
> the best I could do aside from forcing you do do another round-trip.

Thanks and sorry about that. I'll be more careful next time.

[GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2

[Mark Brown]

On Mon, Nov 12, 2012 at 09:11:03PM +0000, Arnd Bergmann wrote:

> * Always let the person that owns the dependency know that the changes in
>   their tree are also included elsewhere and that things go bad if those
>   changes get rebased after all, or won't make it into the merge window
>   for some reason.

Please never pull anything from me unless there's a signed tag for it,
anything else I won't know about and may be rebased or vanish or
something.

> I have taken Mark on Cc to let him know about the dependency now, and I've
> merged ab6f6d85210c4d0265cf48e9958c04e08595055a (which has only shmobile
> specific ASoC patches) into the next/boards2 branch before merging your
> branch. This is still not perfect because it breaks bisection, but it's
> the best I could do aside from forcing you do do another round-trip.

What's the bisection problem?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/9edeb3cc/attachment.sig>

[GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2

[Arnd Bergmann]

On Tuesday 13 November 2012, Mark Brown wrote:
>   Show Details
>   On Mon, Nov 12, 2012 at 09:11:03PM +0000, Arnd Bergmann wrote:
> 
> > * Always let the person that owns the dependency know that the changes in
> >   their tree are also included elsewhere and that things go bad if those
> >   changes get rebased after all, or won't make it into the merge window
> >   for some reason.
> 
> Please never pull anything from me unless there's a signed tag for it,
> anything else I won't know about and may be rebased or vanish or
> something.

Ok, thanks for the reminder. Do you have a signed tag containing ab6f6d8521?

> > I have taken Mark on Cc to let him know about the dependency now, and I've
> > merged ab6f6d85210c4d0265cf48e9958c04e08595055a (which has only shmobile
> > specific ASoC patches) into the next/boards2 branch before merging your
> > branch. This is still not perfect because it breaks bisection, but it's
> > the best I could do aside from forcing you do do another round-trip.
> 
> What's the bisection problem?

I merged ab6f6d8521 first, and then Simon's branch, which means that the
linear (first-parent) history is ok, but bisecting the entire state of
the tree may end up in a commit in his branch in a state before it was
merged into mine, where it doesn't contain the patches it depends on,
and as Simon mentioned in his pull request, that will cause a build
failure.

	Arnd

[GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2

[Mark Brown]

On Tue, Nov 13, 2012 at 08:48:03AM +0000, Arnd Bergmann wrote:
> On Tuesday 13 November 2012, Mark Brown wrote:

> > Please never pull anything from me unless there's a signed tag for it,
> > anything else I won't know about and may be rebased or vanish or
> > something.

> Ok, thanks for the reminder. Do you have a signed tag containing ab6f6d8521?

Nope, your e-mail was the first I'd heard of the cross-merge.  I guess I
could create one if this is going to get redone for some reason...

> > > I have taken Mark on Cc to let him know about the dependency now, and I've
> > > merged ab6f6d85210c4d0265cf48e9958c04e08595055a (which has only shmobile
> > > specific ASoC patches) into the next/boards2 branch before merging your
> > > branch. This is still not perfect because it breaks bisection, but it's
> > > the best I could do aside from forcing you do do another round-trip.

> > What's the bisection problem?

> I merged ab6f6d8521 first, and then Simon's branch, which means that the
> linear (first-parent) history is ok, but bisecting the entire state of
> the tree may end up in a commit in his branch in a state before it was
> merged into mine, where it doesn't contain the patches it depends on,
> and as Simon mentioned in his pull request, that will cause a build
> failure.

Oh, I'd missed the fact that this wasn't coming in via a merge into
Simon's tree.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121113/498f1a12/attachment.sig>

[GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2

[Arnd Bergmann]

On Tuesday 13 November 2012, Mark Brown wrote:
> On Tue, Nov 13, 2012 at 08:48:03AM +0000, Arnd Bergmann wrote:
> > On Tuesday 13 November 2012, Mark Brown wrote:
> 
> > > Please never pull anything from me unless there's a signed tag for it,
> > > anything else I won't know about and may be rebased or vanish or
> > > something.
> 
> > Ok, thanks for the reminder. Do you have a signed tag containing ab6f6d8521?
> 
> Nope, your e-mail was the first I'd heard of the cross-merge.  I guess I
> could create one if this is going to get redone for some reason...

I'm not planning to pull this one into somewhere else, just want to make
sure that you remeber it's been pulled into arm-soc. You mentioned above
that having a tag helps you with your bookkeeping.

	Arnd

[GIT PULL v3] Renesas ARM-based SoC boards for v3.8 #2

[Mark Brown]

On Tue, Nov 13, 2012 at 10:27:10AM +0000, Arnd Bergmann wrote:

> I'm not planning to pull this one into somewhere else, just want to make
> sure that you remeber it's been pulled into arm-soc. You mentioned above
> that having a tag helps you with your bookkeeping.

It's not that it's particularly helpful for my bookkeeping (I rarely if
ever look at the tags), it's more that if I've not signed a tag then it
means that I'm either not aware of or not OK with the branch being used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121114/44a0a8ca/attachment.sig>