[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following defconfig enhancements for 3.8.

----------------------------------------------------------------
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

  Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

are available in the git repository at:

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

for you to fetch changes up to 9a32fd6529e90d1dde157d155ae8e3fca61c31f7:

  ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig (2012-10-15 10:23:59 +0900)

----------------------------------------------------------------
Kuninori Morimoto (2):
      ARM: shmobile: mackerel: defconfig update
      ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig

 arch/arm/configs/armadillo800eva_defconfig |    2 +-
 arch/arm/configs/mackerel_defconfig        |   18 ++++++++++++++++--
 2 files changed, 17 insertions(+), 3 deletions(-)

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following defconfig enhancements for 3.8.

----------------------------------------------------------------
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:

  Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)

are available in the git repository at:

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

for you to fetch changes up to 9a32fd6529e90d1dde157d155ae8e3fca61c31f7:

  ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig (2012-10-15 10:23:59 +0900)

----------------------------------------------------------------
Kuninori Morimoto (2):
      ARM: shmobile: mackerel: defconfig update
      ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig

 arch/arm/configs/armadillo800eva_defconfig |    2 +-
 arch/arm/configs/mackerel_defconfig        |   18 ++++++++++++++++--
 2 files changed, 17 insertions(+), 3 deletions(-)

[PATCH 1/2] ARM: shmobile: mackerel: defconfig update

[Simon Horman]

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

This patch enables following devices by default
 - I2C
 - HDMI
 - USB (host/gadget)
 - ALSA (FSI)
 - DMAEngine

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/configs/mackerel_defconfig |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index 306a2e2..7b79a0b 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -70,17 +70,31 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=8
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_LEGACY_PTYS is not set
 # CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
 # CONFIG_MFD_SUPPORT is not set
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_SH_MOBILE_LCDC=y
+CONFIG_FB_SH_MOBILE_HDMI=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_LOGO_LINUX_MONO is not set
 # CONFIG_LOGO_LINUX_CLUT224 is not set
-# CONFIG_HID_SUPPORT is not set
-# CONFIG_USB_SUPPORT is not set
+# CONFIG_SND_SUPPORT_OLD_API is not set
+# CONFIG_SND_VERBOSE_PROCFS is not set
+# CONFIG_SND_DRIVERS is not set
+# CONFIG_SND_ARM is not set
+CONFIG_SND_SOC_SH4_FSI=y
+CONFIG_USB=y
+CONFIG_USB_RENESAS_USBHS_HCD=y
+CONFIG_USB_RENESAS_USBHS=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_RENESAS_USBHS_UDC=y
+CONFIG_DMADEVICES=y
+CONFIG_SH_DMAE=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT2_FS_POSIX_ACL=y
-- 
1.7.10.4

[PATCH 1/2] ARM: shmobile: mackerel: defconfig update

[Simon Horman]

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

This patch enables following devices by default
 - I2C
 - HDMI
 - USB (host/gadget)
 - ALSA (FSI)
 - DMAEngine

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/arm/configs/mackerel_defconfig |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index 306a2e2..7b79a0b 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -70,17 +70,31 @@ CONFIG_SERIAL_SH_SCI_NR_UARTS=8
 CONFIG_SERIAL_SH_SCI_CONSOLE=y
 # CONFIG_LEGACY_PTYS is not set
 # CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
 # CONFIG_MFD_SUPPORT is not set
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_SH_MOBILE_LCDC=y
+CONFIG_FB_SH_MOBILE_HDMI=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_LOGO_LINUX_MONO is not set
 # CONFIG_LOGO_LINUX_CLUT224 is not set
-# CONFIG_HID_SUPPORT is not set
-# CONFIG_USB_SUPPORT is not set
+# CONFIG_SND_SUPPORT_OLD_API is not set
+# CONFIG_SND_VERBOSE_PROCFS is not set
+# CONFIG_SND_DRIVERS is not set
+# CONFIG_SND_ARM is not set
+CONFIG_SND_SOC_SH4_FSI=y
+CONFIG_USB=y
+CONFIG_USB_RENESAS_USBHS_HCD=y
+CONFIG_USB_RENESAS_USBHS=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_RENESAS_USBHS_UDC=y
+CONFIG_DMADEVICES=y
+CONFIG_SH_DMAE=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT2_FS_POSIX_ACL=y
-- 
1.7.10.4

[PATCH 2/2] ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig

[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/armadillo800eva_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index f78d259..a18593d 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -20,7 +20,7 @@ CONFIG_MACH_ARMADILLO800EVA=y
 # CONFIG_SH_TIMER_TMU is not set
 CONFIG_ARM_THUMB=y
 CONFIG_CPU_BPREDICT_DISABLE=y
-# CONFIG_CACHE_L2X0 is not set
+CONFIG_CACHE_L2X0=y
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
 CONFIG_ARM_ERRATA_460075=y
-- 
1.7.10.4

[PATCH 2/2] ARM: shmobile: armadillo800eva: enable L2X0 cache on defconfig

[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/armadillo800eva_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index f78d259..a18593d 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -20,7 +20,7 @@ CONFIG_MACH_ARMADILLO800EVA=y
 # CONFIG_SH_TIMER_TMU is not set
 CONFIG_ARM_THUMB=y
 CONFIG_CPU_BPREDICT_DISABLE=y
-# CONFIG_CACHE_L2X0 is not set
+CONFIG_CACHE_L2X0=y
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
 CONFIG_ARM_ERRATA_460075=y
-- 
1.7.10.4

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Wednesday 17 October 2012, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> please consider the following defconfig enhancements for 3.8.

These look good to me, but I wonder what happened to the plan to reduce
the number of defconfig files we discussed before. Since you can build
a combined kernel that runs on all (or most) of the supported boards,
can you add a combined shmobile_defconfig that is able to work on
a wide variety of hardware and drop some of the less common defconfig
files?

Most of the modern platforms nowadays have just one defconfig that
covers everything.

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Wednesday 17 October 2012, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> please consider the following defconfig enhancements for 3.8.

These look good to me, but I wonder what happened to the plan to reduce
the number of defconfig files we discussed before. Since you can build
a combined kernel that runs on all (or most) of the supported boards,
can you add a combined shmobile_defconfig that is able to work on
a wide variety of hardware and drop some of the less common defconfig
files?

Most of the modern platforms nowadays have just one defconfig that
covers everything.

	Arnd

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> On Wednesday 17 October 2012, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> > 
> > please consider the following defconfig enhancements for 3.8.
> 
> These look good to me, but I wonder what happened to the plan to reduce
> the number of defconfig files we discussed before. Since you can build
> a combined kernel that runs on all (or most) of the supported boards,
> can you add a combined shmobile_defconfig that is able to work on
> a wide variety of hardware and drop some of the less common defconfig
> files?
> 
> Most of the modern platforms nowadays have just one defconfig that
> covers everything.

Hi Arnd,

I wonder if such consolidation only makes sense for boards that
make use of DT. If so, I can see that we may be able to come
up with a single configuration for the Armadillo800eva, KZM9G
and KZM9D boards. But not for older boards such as the Mackerel which
have not been converted to use DT.

I am also wondering if more of the drivers that SH Mobile uses need to
become DT aware before a consolidated configuration can work.  In
particular, I am thinking about the SCI serial driver and the location of
the serial port that can be used for serial console and early printk - this
features in the kernel command line of the per-board defconfigs and is
relied on by developers.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> On Wednesday 17 October 2012, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> > 
> > please consider the following defconfig enhancements for 3.8.
> 
> These look good to me, but I wonder what happened to the plan to reduce
> the number of defconfig files we discussed before. Since you can build
> a combined kernel that runs on all (or most) of the supported boards,
> can you add a combined shmobile_defconfig that is able to work on
> a wide variety of hardware and drop some of the less common defconfig
> files?
> 
> Most of the modern platforms nowadays have just one defconfig that
> covers everything.

Hi Arnd,

I wonder if such consolidation only makes sense for boards that
make use of DT. If so, I can see that we may be able to come
up with a single configuration for the Armadillo800eva, KZM9G
and KZM9D boards. But not for older boards such as the Mackerel which
have not been converted to use DT.

I am also wondering if more of the drivers that SH Mobile uses need to
become DT aware before a consolidated configuration can work.  In
particular, I am thinking about the SCI serial driver and the location of
the serial port that can be used for serial console and early printk - this
features in the kernel command line of the per-board defconfigs and is
relied on by developers.

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Thursday 18 October 2012 09:58:11 Simon Horman wrote:
> On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> > On Wednesday 17 October 2012, Simon Horman wrote:
> > > Hi Olof, Hi Arnd,
> > > 
> > > please consider the following defconfig enhancements for 3.8.
> > 
> > These look good to me, but I wonder what happened to the plan to reduce
> > the number of defconfig files we discussed before. Since you can build
> > a combined kernel that runs on all (or most) of the supported boards,
> > can you add a combined shmobile_defconfig that is able to work on
> > a wide variety of hardware and drop some of the less common defconfig
> > files?
> > 
> > Most of the modern platforms nowadays have just one defconfig that
> > covers everything.
> 
> Hi Arnd,
> 
> I wonder if such consolidation only makes sense for boards that
> make use of DT. If so, I can see that we may be able to come
> up with a single configuration for the Armadillo800eva, KZM9G
> and KZM9D boards. But not for older boards such as the Mackerel which
> have not been converted to use DT.

Usually you should just be able to enable any boards together,
independent of whether they are using DT or not. It's possible
that shmobile does something different from the other platforms
that I'm not aware of, of course. If you look at e.g.
omap2plus_defconfig or imx_v6_v7_defconfig, they both enable
all the available boards.

> I am also wondering if more of the drivers that SH Mobile uses need to
> become DT aware before a consolidated configuration can work.  In
> particular, I am thinking about the SCI serial driver and the location of
> the serial port that can be used for serial console and early printk - this
> features in the kernel command line of the per-board defconfigs and is
> relied on by developers.

Device drivers that don't use DT should get their configuration from
platform_data. The command line can be used to override those, but it's
also normally passed by the boot loader, which also has to configure
e.g. how much memory is present or which uart to use.

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Thursday 18 October 2012 09:58:11 Simon Horman wrote:
> On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> > On Wednesday 17 October 2012, Simon Horman wrote:
> > > Hi Olof, Hi Arnd,
> > > 
> > > please consider the following defconfig enhancements for 3.8.
> > 
> > These look good to me, but I wonder what happened to the plan to reduce
> > the number of defconfig files we discussed before. Since you can build
> > a combined kernel that runs on all (or most) of the supported boards,
> > can you add a combined shmobile_defconfig that is able to work on
> > a wide variety of hardware and drop some of the less common defconfig
> > files?
> > 
> > Most of the modern platforms nowadays have just one defconfig that
> > covers everything.
> 
> Hi Arnd,
> 
> I wonder if such consolidation only makes sense for boards that
> make use of DT. If so, I can see that we may be able to come
> up with a single configuration for the Armadillo800eva, KZM9G
> and KZM9D boards. But not for older boards such as the Mackerel which
> have not been converted to use DT.

Usually you should just be able to enable any boards together,
independent of whether they are using DT or not. It's possible
that shmobile does something different from the other platforms
that I'm not aware of, of course. If you look at e.g.
omap2plus_defconfig or imx_v6_v7_defconfig, they both enable
all the available boards.

> I am also wondering if more of the drivers that SH Mobile uses need to
> become DT aware before a consolidated configuration can work.  In
> particular, I am thinking about the SCI serial driver and the location of
> the serial port that can be used for serial console and early printk - this
> features in the kernel command line of the per-board defconfigs and is
> relied on by developers.

Device drivers that don't use DT should get their configuration from
platform_data. The command line can be used to override those, but it's
also normally passed by the boot loader, which also has to configure
e.g. how much memory is present or which uart to use.

	Arnd

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Thu, Oct 18, 2012 at 07:29:30AM +0000, Arnd Bergmann wrote:
> On Thursday 18 October 2012 09:58:11 Simon Horman wrote:
> > On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> > > On Wednesday 17 October 2012, Simon Horman wrote:
> > > > Hi Olof, Hi Arnd,
> > > > 
> > > > please consider the following defconfig enhancements for 3.8.
> > > 
> > > These look good to me, but I wonder what happened to the plan to reduce
> > > the number of defconfig files we discussed before. Since you can build
> > > a combined kernel that runs on all (or most) of the supported boards,
> > > can you add a combined shmobile_defconfig that is able to work on
> > > a wide variety of hardware and drop some of the less common defconfig
> > > files?
> > > 
> > > Most of the modern platforms nowadays have just one defconfig that
> > > covers everything.
> > 
> > Hi Arnd,
> > 
> > I wonder if such consolidation only makes sense for boards that
> > make use of DT. If so, I can see that we may be able to come
> > up with a single configuration for the Armadillo800eva, KZM9G
> > and KZM9D boards. But not for older boards such as the Mackerel which
> > have not been converted to use DT.
> 
> Usually you should just be able to enable any boards together,
> independent of whether they are using DT or not. It's possible
> that shmobile does something different from the other platforms
> that I'm not aware of, of course. If you look at e.g.
> omap2plus_defconfig or imx_v6_v7_defconfig, they both enable
> all the available boards.

Thanks, I'll see what I can do within the scope of the boards
that I have access to.

> > I am also wondering if more of the drivers that SH Mobile uses need to
> > become DT aware before a consolidated configuration can work.  In
> > particular, I am thinking about the SCI serial driver and the location of
> > the serial port that can be used for serial console and early printk - this
> > features in the kernel command line of the per-board defconfigs and is
> > relied on by developers.
> 
> Device drivers that don't use DT should get their configuration from
> platform_data. The command line can be used to override those, but it's
> also normally passed by the boot loader, which also has to configure
> e.g. how much memory is present or which uart to use.

Understood.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Thu, Oct 18, 2012 at 07:29:30AM +0000, Arnd Bergmann wrote:
> On Thursday 18 October 2012 09:58:11 Simon Horman wrote:
> > On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> > > On Wednesday 17 October 2012, Simon Horman wrote:
> > > > Hi Olof, Hi Arnd,
> > > > 
> > > > please consider the following defconfig enhancements for 3.8.
> > > 
> > > These look good to me, but I wonder what happened to the plan to reduce
> > > the number of defconfig files we discussed before. Since you can build
> > > a combined kernel that runs on all (or most) of the supported boards,
> > > can you add a combined shmobile_defconfig that is able to work on
> > > a wide variety of hardware and drop some of the less common defconfig
> > > files?
> > > 
> > > Most of the modern platforms nowadays have just one defconfig that
> > > covers everything.
> > 
> > Hi Arnd,
> > 
> > I wonder if such consolidation only makes sense for boards that
> > make use of DT. If so, I can see that we may be able to come
> > up with a single configuration for the Armadillo800eva, KZM9G
> > and KZM9D boards. But not for older boards such as the Mackerel which
> > have not been converted to use DT.
> 
> Usually you should just be able to enable any boards together,
> independent of whether they are using DT or not. It's possible
> that shmobile does something different from the other platforms
> that I'm not aware of, of course. If you look at e.g.
> omap2plus_defconfig or imx_v6_v7_defconfig, they both enable
> all the available boards.

Thanks, I'll see what I can do within the scope of the boards
that I have access to.

> > I am also wondering if more of the drivers that SH Mobile uses need to
> > become DT aware before a consolidated configuration can work.  In
> > particular, I am thinking about the SCI serial driver and the location of
> > the serial port that can be used for serial console and early printk - this
> > features in the kernel command line of the per-board defconfigs and is
> > relied on by developers.
> 
> Device drivers that don't use DT should get their configuration from
> platform_data. The command line can be used to override those, but it's
> also normally passed by the boot loader, which also has to configure
> e.g. how much memory is present or which uart to use.

Understood.

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> On Thu, Oct 18, 2012 at 07:29:30AM +0000, Arnd Bergmann wrote:
> > On Thursday 18 October 2012 09:58:11 Simon Horman wrote:
> > > On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> > > > On Wednesday 17 October 2012, Simon Horman wrote:
> > > > > Hi Olof, Hi Arnd,
> > > > > 
> > > > > please consider the following defconfig enhancements for 3.8.
> > > > 
> > > > These look good to me, but I wonder what happened to the plan to reduce
> > > > the number of defconfig files we discussed before. Since you can build
> > > > a combined kernel that runs on all (or most) of the supported boards,
> > > > can you add a combined shmobile_defconfig that is able to work on
> > > > a wide variety of hardware and drop some of the less common defconfig
> > > > files?
> > > > 
> > > > Most of the modern platforms nowadays have just one defconfig that
> > > > covers everything.
> > > 
> > > Hi Arnd,
> > > 
> > > I wonder if such consolidation only makes sense for boards that
> > > make use of DT. If so, I can see that we may be able to come
> > > up with a single configuration for the Armadillo800eva, KZM9G
> > > and KZM9D boards. But not for older boards such as the Mackerel which
> > > have not been converted to use DT.
> > 
> > Usually you should just be able to enable any boards together,
> > independent of whether they are using DT or not. It's possible
> > that shmobile does something different from the other platforms
> > that I'm not aware of, of course. If you look at e.g.
> > omap2plus_defconfig or imx_v6_v7_defconfig, they both enable
> > all the available boards.
> 
> Thanks, I'll see what I can do within the scope of the boards
> that I have access to.
> 
> > > I am also wondering if more of the drivers that SH Mobile uses need to
> > > become DT aware before a consolidated configuration can work.  In
> > > particular, I am thinking about the SCI serial driver and the location of
> > > the serial port that can be used for serial console and early printk - this
> > > features in the kernel command line of the per-board defconfigs and is
> > > relied on by developers.
> > 
> > Device drivers that don't use DT should get their configuration from
> > platform_data. The command line can be used to override those, but it's
> > also normally passed by the boot loader, which also has to configure
> > e.g. how much memory is present or which uart to use.
> 
> Understood.

I have made a limited amount of progress on this trying to create a
defconfig that will work on both the Marzen and Armadillo 800 EVA boards.

* Serial console appears to work, although for the Marzen at
  least enabling earlyprintk seems to require the bootloader to specify
  e.g.  console=ttySC2,115200 earlyprintk

  This is done by fully specifying bootargs in U-Boot.
  The boodloaders on the Marzen board has an ampty bootargs by default.

  I guess I can live without earlyprink by default,
  though it does seem to be a regression in the user experience.

* A more significant problem seems to be the use of CONFIG_MEMORY_START
  to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h

  I'm not sure that I see an easy way to get around this one.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> On Thu, Oct 18, 2012 at 07:29:30AM +0000, Arnd Bergmann wrote:
> > On Thursday 18 October 2012 09:58:11 Simon Horman wrote:
> > > On Wed, Oct 17, 2012 at 01:42:29PM +0000, Arnd Bergmann wrote:
> > > > On Wednesday 17 October 2012, Simon Horman wrote:
> > > > > Hi Olof, Hi Arnd,
> > > > > 
> > > > > please consider the following defconfig enhancements for 3.8.
> > > > 
> > > > These look good to me, but I wonder what happened to the plan to reduce
> > > > the number of defconfig files we discussed before. Since you can build
> > > > a combined kernel that runs on all (or most) of the supported boards,
> > > > can you add a combined shmobile_defconfig that is able to work on
> > > > a wide variety of hardware and drop some of the less common defconfig
> > > > files?
> > > > 
> > > > Most of the modern platforms nowadays have just one defconfig that
> > > > covers everything.
> > > 
> > > Hi Arnd,
> > > 
> > > I wonder if such consolidation only makes sense for boards that
> > > make use of DT. If so, I can see that we may be able to come
> > > up with a single configuration for the Armadillo800eva, KZM9G
> > > and KZM9D boards. But not for older boards such as the Mackerel which
> > > have not been converted to use DT.
> > 
> > Usually you should just be able to enable any boards together,
> > independent of whether they are using DT or not. It's possible
> > that shmobile does something different from the other platforms
> > that I'm not aware of, of course. If you look at e.g.
> > omap2plus_defconfig or imx_v6_v7_defconfig, they both enable
> > all the available boards.
> 
> Thanks, I'll see what I can do within the scope of the boards
> that I have access to.
> 
> > > I am also wondering if more of the drivers that SH Mobile uses need to
> > > become DT aware before a consolidated configuration can work.  In
> > > particular, I am thinking about the SCI serial driver and the location of
> > > the serial port that can be used for serial console and early printk - this
> > > features in the kernel command line of the per-board defconfigs and is
> > > relied on by developers.
> > 
> > Device drivers that don't use DT should get their configuration from
> > platform_data. The command line can be used to override those, but it's
> > also normally passed by the boot loader, which also has to configure
> > e.g. how much memory is present or which uart to use.
> 
> Understood.

I have made a limited amount of progress on this trying to create a
defconfig that will work on both the Marzen and Armadillo 800 EVA boards.

* Serial console appears to work, although for the Marzen at
  least enabling earlyprintk seems to require the bootloader to specify
  e.g.  console=ttySC2,115200 earlyprintk

  This is done by fully specifying bootargs in U-Boot.
  The boodloaders on the Marzen board has an ampty bootargs by default.

  I guess I can live without earlyprink by default,
  though it does seem to be a regression in the user experience.

* A more significant problem seems to be the use of CONFIG_MEMORY_START
  to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h

  I'm not sure that I see an easy way to get around this one.

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Friday 19 October 2012, Simon Horman wrote:
> On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> I have made a limited amount of progress on this trying to create a
> defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
> 
> * Serial console appears to work, although for the Marzen at
>   least enabling earlyprintk seems to require the bootloader to specify
>   e.g.  console=ttySC2,115200 earlyprintk
> 
>   This is done by fully specifying bootargs in U-Boot.
>   The boodloaders on the Marzen board has an ampty bootargs by default.
>
>   I guess I can live without earlyprink by default,
>   though it does seem to be a regression in the user experience.

Right. So who is using the defconfig for these boards? Usually most
people using it actually have their own configuration files that are
tuned for their needs, and you often also need to change the command
line in order to configure the root partition etc.

> * A more significant problem seems to be the use of CONFIG_MEMORY_START
>   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> 
>   I'm not sure that I see an easy way to get around this one.

ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Friday 19 October 2012, Simon Horman wrote:
> On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> I have made a limited amount of progress on this trying to create a
> defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
> 
> * Serial console appears to work, although for the Marzen at
>   least enabling earlyprintk seems to require the bootloader to specify
>   e.g.  console=ttySC2,115200 earlyprintk
> 
>   This is done by fully specifying bootargs in U-Boot.
>   The boodloaders on the Marzen board has an ampty bootargs by default.
>
>   I guess I can live without earlyprink by default,
>   though it does seem to be a regression in the user experience.

Right. So who is using the defconfig for these boards? Usually most
people using it actually have their own configuration files that are
tuned for their needs, and you often also need to change the command
line in order to configure the root partition etc.

> * A more significant problem seems to be the use of CONFIG_MEMORY_START
>   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> 
>   I'm not sure that I see an easy way to get around this one.

ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?

	Arnd

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> On Friday 19 October 2012, Simon Horman wrote:
> > On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> > I have made a limited amount of progress on this trying to create a
> > defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
> > 
> > * Serial console appears to work, although for the Marzen at
> >   least enabling earlyprintk seems to require the bootloader to specify
> >   e.g.  console=ttySC2,115200 earlyprintk
> > 
> >   This is done by fully specifying bootargs in U-Boot.
> >   The boodloaders on the Marzen board has an ampty bootargs by default.
> >
> >   I guess I can live without earlyprink by default,
> >   though it does seem to be a regression in the user experience.
> 
> Right. So who is using the defconfig for these boards? Usually most
> people using it actually have their own configuration files that are
> tuned for their needs, and you often also need to change the command
> line in order to configure the root partition etc.

I imagine they are primarily used by developers, like myself, but
to be honest I am unsure. Ideally I would like the defconfig to be as
useful as possible out of the box. But I agree that most users probably
end up making some customisations, e.g. to the location of the rootfs.

> > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > 
> >   I'm not sure that I see an easy way to get around this one.
> 
> ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?

Thanks, I will look into that.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> On Friday 19 October 2012, Simon Horman wrote:
> > On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> > I have made a limited amount of progress on this trying to create a
> > defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
> > 
> > * Serial console appears to work, although for the Marzen at
> >   least enabling earlyprintk seems to require the bootloader to specify
> >   e.g.  console=ttySC2,115200 earlyprintk
> > 
> >   This is done by fully specifying bootargs in U-Boot.
> >   The boodloaders on the Marzen board has an ampty bootargs by default.
> >
> >   I guess I can live without earlyprink by default,
> >   though it does seem to be a regression in the user experience.
> 
> Right. So who is using the defconfig for these boards? Usually most
> people using it actually have their own configuration files that are
> tuned for their needs, and you often also need to change the command
> line in order to configure the root partition etc.

I imagine they are primarily used by developers, like myself, but
to be honest I am unsure. Ideally I would like the defconfig to be as
useful as possible out of the box. But I agree that most users probably
end up making some customisations, e.g. to the location of the rootfs.

> > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > 
> >   I'm not sure that I see an easy way to get around this one.
> 
> ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?

Thanks, I will look into that.

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > On Friday 19 October 2012, Simon Horman wrote:
> > > On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> > > I have made a limited amount of progress on this trying to create a
> > > defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
> > > 
> > > * Serial console appears to work, although for the Marzen at
> > >   least enabling earlyprintk seems to require the bootloader to specify
> > >   e.g.  console=ttySC2,115200 earlyprintk
> > > 
> > >   This is done by fully specifying bootargs in U-Boot.
> > >   The boodloaders on the Marzen board has an ampty bootargs by default.
> > >
> > >   I guess I can live without earlyprink by default,
> > >   though it does seem to be a regression in the user experience.
> > 
> > Right. So who is using the defconfig for these boards? Usually most
> > people using it actually have their own configuration files that are
> > tuned for their needs, and you often also need to change the command
> > line in order to configure the root partition etc.
> 
> I imagine they are primarily used by developers, like myself, but
> to be honest I am unsure. Ideally I would like the defconfig to be as
> useful as possible out of the box. But I agree that most users probably
> end up making some customisations, e.g. to the location of the rootfs.
> 
> > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > 
> > >   I'm not sure that I see an easy way to get around this one.
> > 
> > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?

I believe that this leaves mach-shmobile with three areas
where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.

* arch/arm/mach-shmobile/headsmp.S

  This uses PLAT_PHYS_OFFSET.

  I believe this can be replaced with a run-time calculation. Though I
  haven't thought about the details yet.

* arch/arm/boot/compressed/head-shmobile.S

  This makes use of CONFIG_MEMORY_START.

  This is only used if CONFIG_ZBOOT_ROM is set.

  I'm unsure if this can be replaced with a run-time calculation or not.
  But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
  the default at this time.


* arch/arm/mach-shmobile/Makefile.boot

 This makes use of CONFIG_MEMORY_START to set zreladdr.

 I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
 However, it is not yet clear to me how that can be used in conjunction
 with a uImage.  As I understand it the boot loader on many of our boards,
 including the Marzen board which is my first target for this work, boot
 uImage imagess.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > On Friday 19 October 2012, Simon Horman wrote:
> > > On Thu, Oct 18, 2012 at 05:13:10PM +0900, Simon Horman wrote:
> > > I have made a limited amount of progress on this trying to create a
> > > defconfig that will work on both the Marzen and Armadillo 800 EVA boards.
> > > 
> > > * Serial console appears to work, although for the Marzen at
> > >   least enabling earlyprintk seems to require the bootloader to specify
> > >   e.g.  console=ttySC2,115200 earlyprintk
> > > 
> > >   This is done by fully specifying bootargs in U-Boot.
> > >   The boodloaders on the Marzen board has an ampty bootargs by default.
> > >
> > >   I guess I can live without earlyprink by default,
> > >   though it does seem to be a regression in the user experience.
> > 
> > Right. So who is using the defconfig for these boards? Usually most
> > people using it actually have their own configuration files that are
> > tuned for their needs, and you often also need to change the command
> > line in order to configure the root partition etc.
> 
> I imagine they are primarily used by developers, like myself, but
> to be honest I am unsure. Ideally I would like the defconfig to be as
> useful as possible out of the box. But I agree that most users probably
> end up making some customisations, e.g. to the location of the rootfs.
> 
> > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > 
> > >   I'm not sure that I see an easy way to get around this one.
> > 
> > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?

I believe that this leaves mach-shmobile with three areas
where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.

* arch/arm/mach-shmobile/headsmp.S

  This uses PLAT_PHYS_OFFSET.

  I believe this can be replaced with a run-time calculation. Though I
  haven't thought about the details yet.

* arch/arm/boot/compressed/head-shmobile.S

  This makes use of CONFIG_MEMORY_START.

  This is only used if CONFIG_ZBOOT_ROM is set.

  I'm unsure if this can be replaced with a run-time calculation or not.
  But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
  the default at this time.


* arch/arm/mach-shmobile/Makefile.boot

 This makes use of CONFIG_MEMORY_START to set zreladdr.

 I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
 However, it is not yet clear to me how that can be used in conjunction
 with a uImage.  As I understand it the boot loader on many of our boards,
 including the Marzen board which is my first target for this work, boot
 uImage imagess.

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

(adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)

On Monday 22 October 2012, Simon Horman wrote:
> On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > On Friday 19 October 2012, Simon Horman wrote:
> > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > 
> > > >   I'm not sure that I see an easy way to get around this one.
> > > 
> > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> 
> I believe that this leaves mach-shmobile with three areas
> where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.

Hmm, I just noticed that in fact shmobile is the only remaining
platform that uses CONFIG_MEMORY_START with a per-board or per-soc
setting.

> * arch/arm/mach-shmobile/headsmp.S
> 
>   This uses PLAT_PHYS_OFFSET.
> 
>   I believe this can be replaced with a run-time calculation. Though I
>   haven't thought about the details yet.
> 
> * arch/arm/boot/compressed/head-shmobile.S
> 
>   This makes use of CONFIG_MEMORY_START.
> 
>   This is only used if CONFIG_ZBOOT_ROM is set.
> 
>   I'm unsure if this can be replaced with a run-time calculation or not.
>   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
>   the default at this time.

Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT

> * arch/arm/mach-shmobile/Makefile.boot
> 
>  This makes use of CONFIG_MEMORY_START to set zreladdr.
> 
>  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
>  However, it is not yet clear to me how that can be used in conjunction
>  with a uImage.  As I understand it the boot loader on many of our boards,
>  including the Marzen board which is my first target for this work, boot
>  uImage imagess.

If this doesn't work, we probably also need to find a solution to
build multiple uImage files from the same vmlinux when building a
multiplatform kernel.

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

(adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)

On Monday 22 October 2012, Simon Horman wrote:
> On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > On Friday 19 October 2012, Simon Horman wrote:
> > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > 
> > > >   I'm not sure that I see an easy way to get around this one.
> > > 
> > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> 
> I believe that this leaves mach-shmobile with three areas
> where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.

Hmm, I just noticed that in fact shmobile is the only remaining
platform that uses CONFIG_MEMORY_START with a per-board or per-soc
setting.

> * arch/arm/mach-shmobile/headsmp.S
> 
>   This uses PLAT_PHYS_OFFSET.
> 
>   I believe this can be replaced with a run-time calculation. Though I
>   haven't thought about the details yet.
> 
> * arch/arm/boot/compressed/head-shmobile.S
> 
>   This makes use of CONFIG_MEMORY_START.
> 
>   This is only used if CONFIG_ZBOOT_ROM is set.
> 
>   I'm unsure if this can be replaced with a run-time calculation or not.
>   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
>   the default at this time.

Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT

> * arch/arm/mach-shmobile/Makefile.boot
> 
>  This makes use of CONFIG_MEMORY_START to set zreladdr.
> 
>  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
>  However, it is not yet clear to me how that can be used in conjunction
>  with a uImage.  As I understand it the boot loader on many of our boards,
>  including the Marzen board which is my first target for this work, boot
>  uImage imagess.

If this doesn't work, we probably also need to find a solution to
build multiple uImage files from the same vmlinux when building a
multiplatform kernel.

	Arnd

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Nicolas Pitre]

On Mon, 22 Oct 2012, Arnd Bergmann wrote:

> (adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)
> 
> On Monday 22 October 2012, Simon Horman wrote:
> > On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > > On Friday 19 October 2012, Simon Horman wrote:
> > > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > > 
> > > > >   I'm not sure that I see an easy way to get around this one.
> > > > 
> > > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> > 
> > I believe that this leaves mach-shmobile with three areas
> > where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.
> 
> Hmm, I just noticed that in fact shmobile is the only remaining
> platform that uses CONFIG_MEMORY_START with a per-board or per-soc
> setting.
> 
> > * arch/arm/mach-shmobile/headsmp.S
> > 
> >   This uses PLAT_PHYS_OFFSET.
> > 
> >   I believe this can be replaced with a run-time calculation. Though I
> >   haven't thought about the details yet.

What about this (untested):

diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index b202c12725..9293319fcb 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -64,18 +64,23 @@ ENTRY(v7_invalidate_l1)
 	mov	pc, lr
 ENDPROC(v7_invalidate_l1)
 
-ENTRY(shmobile_invalidate_start)
+ENTRY(shmobile_secondary_entry)
 	bl	v7_invalidate_l1
 	b	secondary_startup
-ENDPROC(shmobile_invalidate_start)
+ENDPROC(shmobile_secondary_entry)
 
 /*
  * Reset vector for secondary CPUs.
  * This will be mapped at address 0 by SBAR register.
  * We need _long_ jump to the physical address.
+ * the loaded address is initialized to the physical address of
+ * shmobile_secondary_entry
+ * in platform_secondary_init().
  */
+	.data
 	.align  12
+	.arm
 ENTRY(shmobile_secondary_vector)
 	ldr     pc, 1f
-1:	.long   shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
+1:	.long   0
 ENDPROC(shmobile_secondary_vector)
diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
index fde0d23121..356f82da16 100644
--- a/arch/arm/mach-shmobile/platsmp.c
+++ b/arch/arm/mach-shmobile/platsmp.c
@@ -76,8 +76,14 @@ int shmobile_platform_cpu_kill(unsigned int cpu)
 
 void __cpuinit platform_secondary_init(unsigned int cpu)
 {
+	long shmobile_secondary_address;
+
 	trace_hardirqs_off();
 
+	shmobile_secondary_address = (long *)(shmobile_secondary_vector) + 1;
+	*shmobile_secondary_address = virt_to_phys(shmobile_secondary_entry);
+	__cpuc_flush_dcache_area(shmobile_secondary_address, sizeof(long));
+
 	if (is_sh73a0())
 		sh73a0_secondary_init(cpu);
 

> > * arch/arm/boot/compressed/head-shmobile.S
> > 
> >   This makes use of CONFIG_MEMORY_START.
> >   This is only used if CONFIG_ZBOOT_ROM is set.
> > 
> >   I'm unsure if this can be replaced with a run-time calculation or not.
> >   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
> >   the default at this time.

This code is meant to be executed from ROM which means a very tailored 
kernel configuration.  In that case it makes little sense to have 
CONFIG_ARM_PATCH_PHYS_VIRT nor CONFIG_AUTO_ZRELADDR turned on anyway.

> Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
> CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT

The right dependency would be CONFIG_AUTO_ZRELADDR, not 
ARM_PATCH_PHYS_VIRT.  The later concerns the final kernel image, not the 
decompressor.

> > * arch/arm/mach-shmobile/Makefile.boot
> > 
> >  This makes use of CONFIG_MEMORY_START to set zreladdr.
> > 
> >  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
> >  However, it is not yet clear to me how that can be used in conjunction
> >  with a uImage.  As I understand it the boot loader on many of our boards,
> >  including the Marzen board which is my first target for this work, boot
> >  uImage imagess.
> 
> If this doesn't work, we probably also need to find a solution to
> build multiple uImage files from the same vmlinux when building a
> multiplatform kernel.

The right solution to the U-Boot problem is to remove uImage creation 
from the kernel entirely.  The U-Boot image format should be created at 
_installation_ time, not at build time.  The fact that the U-Boot image 
format is (or was until very recently) inflexible is not Linux's fault.

If the uImage build target is to remain in the kernel, it should be 
marked incompatible with a multi-arch config.  There is no point 
distributing a multi-arch kernel image when wrapped into a uImage 
format.


Nicolas

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Nicolas Pitre]

On Mon, 22 Oct 2012, Arnd Bergmann wrote:

> (adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)
> 
> On Monday 22 October 2012, Simon Horman wrote:
> > On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > > On Friday 19 October 2012, Simon Horman wrote:
> > > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > > 
> > > > >   I'm not sure that I see an easy way to get around this one.
> > > > 
> > > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> > 
> > I believe that this leaves mach-shmobile with three areas
> > where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.
> 
> Hmm, I just noticed that in fact shmobile is the only remaining
> platform that uses CONFIG_MEMORY_START with a per-board or per-soc
> setting.
> 
> > * arch/arm/mach-shmobile/headsmp.S
> > 
> >   This uses PLAT_PHYS_OFFSET.
> > 
> >   I believe this can be replaced with a run-time calculation. Though I
> >   haven't thought about the details yet.

What about this (untested):

diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index b202c12725..9293319fcb 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -64,18 +64,23 @@ ENTRY(v7_invalidate_l1)
 	mov	pc, lr
 ENDPROC(v7_invalidate_l1)
 
-ENTRY(shmobile_invalidate_start)
+ENTRY(shmobile_secondary_entry)
 	bl	v7_invalidate_l1
 	b	secondary_startup
-ENDPROC(shmobile_invalidate_start)
+ENDPROC(shmobile_secondary_entry)
 
 /*
  * Reset vector for secondary CPUs.
  * This will be mapped at address 0 by SBAR register.
  * We need _long_ jump to the physical address.
+ * the loaded address is initialized to the physical address of
+ * shmobile_secondary_entry
+ * in platform_secondary_init().
  */
+	.data
 	.align  12
+	.arm
 ENTRY(shmobile_secondary_vector)
 	ldr     pc, 1f
-1:	.long   shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
+1:	.long   0
 ENDPROC(shmobile_secondary_vector)
diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
index fde0d23121..356f82da16 100644
--- a/arch/arm/mach-shmobile/platsmp.c
+++ b/arch/arm/mach-shmobile/platsmp.c
@@ -76,8 +76,14 @@ int shmobile_platform_cpu_kill(unsigned int cpu)
 
 void __cpuinit platform_secondary_init(unsigned int cpu)
 {
+	long shmobile_secondary_address;
+
 	trace_hardirqs_off();
 
+	shmobile_secondary_address = (long *)(shmobile_secondary_vector) + 1;
+	*shmobile_secondary_address = virt_to_phys(shmobile_secondary_entry);
+	__cpuc_flush_dcache_area(shmobile_secondary_address, sizeof(long));
+
 	if (is_sh73a0())
 		sh73a0_secondary_init(cpu);
 

> > * arch/arm/boot/compressed/head-shmobile.S
> > 
> >   This makes use of CONFIG_MEMORY_START.
> >   This is only used if CONFIG_ZBOOT_ROM is set.
> > 
> >   I'm unsure if this can be replaced with a run-time calculation or not.
> >   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
> >   the default at this time.

This code is meant to be executed from ROM which means a very tailored 
kernel configuration.  In that case it makes little sense to have 
CONFIG_ARM_PATCH_PHYS_VIRT nor CONFIG_AUTO_ZRELADDR turned on anyway.

> Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
> CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT

The right dependency would be CONFIG_AUTO_ZRELADDR, not 
ARM_PATCH_PHYS_VIRT.  The later concerns the final kernel image, not the 
decompressor.

> > * arch/arm/mach-shmobile/Makefile.boot
> > 
> >  This makes use of CONFIG_MEMORY_START to set zreladdr.
> > 
> >  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
> >  However, it is not yet clear to me how that can be used in conjunction
> >  with a uImage.  As I understand it the boot loader on many of our boards,
> >  including the Marzen board which is my first target for this work, boot
> >  uImage imagess.
> 
> If this doesn't work, we probably also need to find a solution to
> build multiple uImage files from the same vmlinux when building a
> multiplatform kernel.

The right solution to the U-Boot problem is to remove uImage creation 
from the kernel entirely.  The U-Boot image format should be created at 
_installation_ time, not at build time.  The fact that the U-Boot image 
format is (or was until very recently) inflexible is not Linux's fault.

If the uImage build target is to remain in the kernel, it should be 
marked incompatible with a multi-arch config.  There is no point 
distributing a multi-arch kernel image when wrapped into a uImage 
format.


Nicolas

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Mon, Oct 22, 2012 at 02:20:31PM -0400, Nicolas Pitre wrote:
> On Mon, 22 Oct 2012, Arnd Bergmann wrote:
> 
> > (adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)
> > 
> > On Monday 22 October 2012, Simon Horman wrote:
> > > On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > > > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > > > On Friday 19 October 2012, Simon Horman wrote:
> > > > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > > > 
> > > > > >   I'm not sure that I see an easy way to get around this one.
> > > > > 
> > > > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> > > 
> > > I believe that this leaves mach-shmobile with three areas
> > > where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.
> > 
> > Hmm, I just noticed that in fact shmobile is the only remaining
> > platform that uses CONFIG_MEMORY_START with a per-board or per-soc
> > setting.
> > 
> > > * arch/arm/mach-shmobile/headsmp.S
> > > 
> > >   This uses PLAT_PHYS_OFFSET.
> > > 
> > >   I believe this can be replaced with a run-time calculation. Though I
> > >   haven't thought about the details yet.
> 
> What about this (untested):

Thanks. I have not managed to successfully test this yet,
but I think something like this is the right direction.
I will try and massage it into a working version.

> 
> diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
> index b202c12725..9293319fcb 100644
> --- a/arch/arm/mach-shmobile/headsmp.S
> +++ b/arch/arm/mach-shmobile/headsmp.S
> @@ -64,18 +64,23 @@ ENTRY(v7_invalidate_l1)
>  	mov	pc, lr
>  ENDPROC(v7_invalidate_l1)
>  
> -ENTRY(shmobile_invalidate_start)
> +ENTRY(shmobile_secondary_entry)
>  	bl	v7_invalidate_l1
>  	b	secondary_startup
> -ENDPROC(shmobile_invalidate_start)
> +ENDPROC(shmobile_secondary_entry)
>  
>  /*
>   * Reset vector for secondary CPUs.
>   * This will be mapped at address 0 by SBAR register.
>   * We need _long_ jump to the physical address.
> + * the loaded address is initialized to the physical address of
> + * shmobile_secondary_entry
> + * in platform_secondary_init().
>   */
> +	.data
>  	.align  12
> +	.arm
>  ENTRY(shmobile_secondary_vector)
>  	ldr     pc, 1f
> -1:	.long   shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +1:	.long   0
>  ENDPROC(shmobile_secondary_vector)
> diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
> index fde0d23121..356f82da16 100644
> --- a/arch/arm/mach-shmobile/platsmp.c
> +++ b/arch/arm/mach-shmobile/platsmp.c
> @@ -76,8 +76,14 @@ int shmobile_platform_cpu_kill(unsigned int cpu)
>  
>  void __cpuinit platform_secondary_init(unsigned int cpu)
>  {
> +	long shmobile_secondary_address;
> +
>  	trace_hardirqs_off();
>  
> +	shmobile_secondary_address = (long *)(shmobile_secondary_vector) + 1;
> +	*shmobile_secondary_address = virt_to_phys(shmobile_secondary_entry);
> +	__cpuc_flush_dcache_area(shmobile_secondary_address, sizeof(long));
> +
>  	if (is_sh73a0())
>  		sh73a0_secondary_init(cpu);
>  
> 
> > > * arch/arm/boot/compressed/head-shmobile.S
> > > 
> > >   This makes use of CONFIG_MEMORY_START.
> > >   This is only used if CONFIG_ZBOOT_ROM is set.
> > > 
> > >   I'm unsure if this can be replaced with a run-time calculation or not.
> > >   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
> > >   the default at this time.
> 
> This code is meant to be executed from ROM which means a very tailored 
> kernel configuration.  In that case it makes little sense to have 
> CONFIG_ARM_PATCH_PHYS_VIRT nor CONFIG_AUTO_ZRELADDR turned on anyway.

Agreed.

> > Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
> > CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT
> 
> The right dependency would be CONFIG_AUTO_ZRELADDR, not 
> ARM_PATCH_PHYS_VIRT.  The later concerns the final kernel image, not the 
> decompressor.

Thanks.

> > > * arch/arm/mach-shmobile/Makefile.boot
> > > 
> > >  This makes use of CONFIG_MEMORY_START to set zreladdr.
> > > 
> > >  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
> > >  However, it is not yet clear to me how that can be used in conjunction
> > >  with a uImage.  As I understand it the boot loader on many of our boards,
> > >  including the Marzen board which is my first target for this work, boot
> > >  uImage imagess.
> > 
> > If this doesn't work, we probably also need to find a solution to
> > build multiple uImage files from the same vmlinux when building a
> > multiplatform kernel.
> 
> The right solution to the U-Boot problem is to remove uImage creation 
> from the kernel entirely.  The U-Boot image format should be created at 
> _installation_ time, not at build time.  The fact that the U-Boot image 
> format is (or was until very recently) inflexible is not Linux's fault.
> 
> If the uImage build target is to remain in the kernel, it should be 
> marked incompatible with a multi-arch config.  There is no point 
> distributing a multi-arch kernel image when wrapped into a uImage 
> format.

I agree with you reasoning, and that in the long term removing uImage as a
target and having an install-time mechanism would be a nice goal. However,
I wonder what the way forward is. Provide install-scripts in the kernel
tree somewhere? Provide information on the start address under
Documentation/ somewhere?

While I am more than happy to help address the issues raised in this
thread, and others that arise. There do seem to be a number of issues
between where we are now and a more generic shmobile_defconfig. I would
like consideration given to allowing the exixting, working, well-maintained,
per-board defconfigs to be updated until these issues have been resolved.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Mon, Oct 22, 2012 at 02:20:31PM -0400, Nicolas Pitre wrote:
> On Mon, 22 Oct 2012, Arnd Bergmann wrote:
> 
> > (adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)
> > 
> > On Monday 22 October 2012, Simon Horman wrote:
> > > On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > > > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > > > On Friday 19 October 2012, Simon Horman wrote:
> > > > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > > > 
> > > > > >   I'm not sure that I see an easy way to get around this one.
> > > > > 
> > > > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> > > 
> > > I believe that this leaves mach-shmobile with three areas
> > > where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.
> > 
> > Hmm, I just noticed that in fact shmobile is the only remaining
> > platform that uses CONFIG_MEMORY_START with a per-board or per-soc
> > setting.
> > 
> > > * arch/arm/mach-shmobile/headsmp.S
> > > 
> > >   This uses PLAT_PHYS_OFFSET.
> > > 
> > >   I believe this can be replaced with a run-time calculation. Though I
> > >   haven't thought about the details yet.
> 
> What about this (untested):

Thanks. I have not managed to successfully test this yet,
but I think something like this is the right direction.
I will try and massage it into a working version.

> 
> diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
> index b202c12725..9293319fcb 100644
> --- a/arch/arm/mach-shmobile/headsmp.S
> +++ b/arch/arm/mach-shmobile/headsmp.S
> @@ -64,18 +64,23 @@ ENTRY(v7_invalidate_l1)
>  	mov	pc, lr
>  ENDPROC(v7_invalidate_l1)
>  
> -ENTRY(shmobile_invalidate_start)
> +ENTRY(shmobile_secondary_entry)
>  	bl	v7_invalidate_l1
>  	b	secondary_startup
> -ENDPROC(shmobile_invalidate_start)
> +ENDPROC(shmobile_secondary_entry)
>  
>  /*
>   * Reset vector for secondary CPUs.
>   * This will be mapped at address 0 by SBAR register.
>   * We need _long_ jump to the physical address.
> + * the loaded address is initialized to the physical address of
> + * shmobile_secondary_entry
> + * in platform_secondary_init().
>   */
> +	.data
>  	.align  12
> +	.arm
>  ENTRY(shmobile_secondary_vector)
>  	ldr     pc, 1f
> -1:	.long   shmobile_invalidate_start - PAGE_OFFSET + PLAT_PHYS_OFFSET
> +1:	.long   0
>  ENDPROC(shmobile_secondary_vector)
> diff --git a/arch/arm/mach-shmobile/platsmp.c b/arch/arm/mach-shmobile/platsmp.c
> index fde0d23121..356f82da16 100644
> --- a/arch/arm/mach-shmobile/platsmp.c
> +++ b/arch/arm/mach-shmobile/platsmp.c
> @@ -76,8 +76,14 @@ int shmobile_platform_cpu_kill(unsigned int cpu)
>  
>  void __cpuinit platform_secondary_init(unsigned int cpu)
>  {
> +	long shmobile_secondary_address;
> +
>  	trace_hardirqs_off();
>  
> +	shmobile_secondary_address = (long *)(shmobile_secondary_vector) + 1;
> +	*shmobile_secondary_address = virt_to_phys(shmobile_secondary_entry);
> +	__cpuc_flush_dcache_area(shmobile_secondary_address, sizeof(long));
> +
>  	if (is_sh73a0())
>  		sh73a0_secondary_init(cpu);
>  
> 
> > > * arch/arm/boot/compressed/head-shmobile.S
> > > 
> > >   This makes use of CONFIG_MEMORY_START.
> > >   This is only used if CONFIG_ZBOOT_ROM is set.
> > > 
> > >   I'm unsure if this can be replaced with a run-time calculation or not.
> > >   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
> > >   the default at this time.
> 
> This code is meant to be executed from ROM which means a very tailored 
> kernel configuration.  In that case it makes little sense to have 
> CONFIG_ARM_PATCH_PHYS_VIRT nor CONFIG_AUTO_ZRELADDR turned on anyway.

Agreed.

> > Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
> > CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT
> 
> The right dependency would be CONFIG_AUTO_ZRELADDR, not 
> ARM_PATCH_PHYS_VIRT.  The later concerns the final kernel image, not the 
> decompressor.

Thanks.

> > > * arch/arm/mach-shmobile/Makefile.boot
> > > 
> > >  This makes use of CONFIG_MEMORY_START to set zreladdr.
> > > 
> > >  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
> > >  However, it is not yet clear to me how that can be used in conjunction
> > >  with a uImage.  As I understand it the boot loader on many of our boards,
> > >  including the Marzen board which is my first target for this work, boot
> > >  uImage imagess.
> > 
> > If this doesn't work, we probably also need to find a solution to
> > build multiple uImage files from the same vmlinux when building a
> > multiplatform kernel.
> 
> The right solution to the U-Boot problem is to remove uImage creation 
> from the kernel entirely.  The U-Boot image format should be created at 
> _installation_ time, not at build time.  The fact that the U-Boot image 
> format is (or was until very recently) inflexible is not Linux's fault.
> 
> If the uImage build target is to remain in the kernel, it should be 
> marked incompatible with a multi-arch config.  There is no point 
> distributing a multi-arch kernel image when wrapped into a uImage 
> format.

I agree with you reasoning, and that in the long term removing uImage as a
target and having an install-time mechanism would be a nice goal. However,
I wonder what the way forward is. Provide install-scripts in the kernel
tree somewhere? Provide information on the start address under
Documentation/ somewhere?

While I am more than happy to help address the issues raised in this
thread, and others that arise. There do seem to be a number of issues
between where we are now and a more generic shmobile_defconfig. I would
like consideration given to allowing the exixting, working, well-maintained,
per-board defconfigs to be updated until these issues have been resolved.

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Tuesday 30 October 2012, Simon Horman wrote:
> While I am more than happy to help address the issues raised in this
> thread, and others that arise. There do seem to be a number of issues
> between where we are now and a more generic shmobile_defconfig. I would
> like consideration given to allowing the exixting, working, well-maintained,
> per-board defconfigs to be updated until these issues have been resolved.

Yes, no problem. This seemed like a low-hanging fruit initially but has
turned into something much bigger now.

Instead of attacking all these at ones, we can leave them as something
worthwhile doing later. I noticed that out of the 11 shmobile defconfigs,
only three (marzen, kzm9d and kzm9g) actually have a nonzero MEMORY_START.

Maybe it's possible to consolidate all or some of the others first, since
they should still work with the same uImage at the expense of just making
the early debugging a little harder, as we discussed earlier.

For all I know, these three boards are also the ones seeing the most
ongoing development, so you could start by using a shared defconfig
for the oldest (ARM11 based) boards at first that are also less likely
to impact new development starting from the defconfig.

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Arnd Bergmann]

On Tuesday 30 October 2012, Simon Horman wrote:
> While I am more than happy to help address the issues raised in this
> thread, and others that arise. There do seem to be a number of issues
> between where we are now and a more generic shmobile_defconfig. I would
> like consideration given to allowing the exixting, working, well-maintained,
> per-board defconfigs to be updated until these issues have been resolved.

Yes, no problem. This seemed like a low-hanging fruit initially but has
turned into something much bigger now.

Instead of attacking all these at ones, we can leave them as something
worthwhile doing later. I noticed that out of the 11 shmobile defconfigs,
only three (marzen, kzm9d and kzm9g) actually have a nonzero MEMORY_START.

Maybe it's possible to consolidate all or some of the others first, since
they should still work with the same uImage at the expense of just making
the early debugging a little harder, as we discussed earlier.

For all I know, these three boards are also the ones seeing the most
ongoing development, so you could start by using a shared defconfig
for the oldest (ARM11 based) boards at first that are also less likely
to impact new development starting from the defconfig.

	Arnd

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Tue, Oct 30, 2012 at 09:41:27PM +0000, Arnd Bergmann wrote:
> On Tuesday 30 October 2012, Simon Horman wrote:
> > While I am more than happy to help address the issues raised in this
> > thread, and others that arise. There do seem to be a number of issues
> > between where we are now and a more generic shmobile_defconfig. I would
> > like consideration given to allowing the exixting, working, well-maintained,
> > per-board defconfigs to be updated until these issues have been resolved.
> 
> Yes, no problem. This seemed like a low-hanging fruit initially but has
> turned into something much bigger now.
> 
> Instead of attacking all these at ones, we can leave them as something
> worthwhile doing later. I noticed that out of the 11 shmobile defconfigs,
> only three (marzen, kzm9d and kzm9g) actually have a nonzero MEMORY_START.
> 
> Maybe it's possible to consolidate all or some of the others first, since
> they should still work with the same uImage at the expense of just making
> the early debugging a little harder, as we discussed earlier.
> 
> For all I know, these three boards are also the ones seeing the most
> ongoing development, so you could start by using a shared defconfig
> for the oldest (ARM11 based) boards at first that are also less likely
> to impact new development starting from the defconfig.

Thanks, good observations. I will look into that.

My expectation is that marzen and kzm9g will continue to see
heavy development in the near future.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.8

[Simon Horman]

On Tue, Oct 30, 2012 at 09:41:27PM +0000, Arnd Bergmann wrote:
> On Tuesday 30 October 2012, Simon Horman wrote:
> > While I am more than happy to help address the issues raised in this
> > thread, and others that arise. There do seem to be a number of issues
> > between where we are now and a more generic shmobile_defconfig. I would
> > like consideration given to allowing the exixting, working, well-maintained,
> > per-board defconfigs to be updated until these issues have been resolved.
> 
> Yes, no problem. This seemed like a low-hanging fruit initially but has
> turned into something much bigger now.
> 
> Instead of attacking all these at ones, we can leave them as something
> worthwhile doing later. I noticed that out of the 11 shmobile defconfigs,
> only three (marzen, kzm9d and kzm9g) actually have a nonzero MEMORY_START.
> 
> Maybe it's possible to consolidate all or some of the others first, since
> they should still work with the same uImage at the expense of just making
> the early debugging a little harder, as we discussed earlier.
> 
> For all I know, these three boards are also the ones seeing the most
> ongoing development, so you could start by using a shared defconfig
> for the oldest (ARM11 based) boards at first that are also less likely
> to impact new development starting from the defconfig.

Thanks, good observations. I will look into that.

My expectation is that marzen and kzm9g will continue to see
heavy development in the near future.

[GIT PULL] Renesas ARM-based SoC defconfig for v3.9

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following defconfig enhancements for 3.9.

----------------------------------------------------------------
The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:

  Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)

are available in the git repository at:

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

for you to fetch changes up to 34d5821ede67551163eedad3ad35cac2642185cf:

  ARM: mach-shmobile: kzm9g: Enable ARM_APPENDED_DTB in defconfig (2013-01-09 15:08:05 +0900)

----------------------------------------------------------------
Simon Horman (5):
      ARM: mach-shmobile: mackerel: update defconfig
      ARM: shmobile: fix memory size for kota2_defconfig
      ARM: mach-shmobile: kzm9g: use voltage regulators by default
      ARM: mach-shmobile: armadillo: update defconfig
      ARM: mach-shmobile: kzm9g: Enable ARM_APPENDED_DTB in defconfig

 arch/arm/configs/armadillo800eva_defconfig |    2 +-
 arch/arm/configs/kota2_defconfig           |    2 +-
 arch/arm/configs/kzm9g_defconfig           |    3 +++
 arch/arm/configs/mackerel_defconfig        |    3 ++-
 4 files changed, 7 insertions(+), 3 deletions(-)

[GIT PULL] Renesas ARM-based SoC defconfig for v3.9

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following defconfig enhancements for 3.9.

----------------------------------------------------------------
The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:

  Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)

are available in the git repository at:

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

for you to fetch changes up to 34d5821ede67551163eedad3ad35cac2642185cf:

  ARM: mach-shmobile: kzm9g: Enable ARM_APPENDED_DTB in defconfig (2013-01-09 15:08:05 +0900)

----------------------------------------------------------------
Simon Horman (5):
      ARM: mach-shmobile: mackerel: update defconfig
      ARM: shmobile: fix memory size for kota2_defconfig
      ARM: mach-shmobile: kzm9g: use voltage regulators by default
      ARM: mach-shmobile: armadillo: update defconfig
      ARM: mach-shmobile: kzm9g: Enable ARM_APPENDED_DTB in defconfig

 arch/arm/configs/armadillo800eva_defconfig |    2 +-
 arch/arm/configs/kota2_defconfig           |    2 +-
 arch/arm/configs/kzm9g_defconfig           |    3 +++
 arch/arm/configs/mackerel_defconfig        |    3 ++-
 4 files changed, 7 insertions(+), 3 deletions(-)

[PATCH 1/5] ARM: mach-shmobile: mackerel: update defconfig

[Simon Horman]

* Enable ARM_APPENDED_DTB

  Typically the bootloader of a mackerel board does not support DT
  so this option is useful

* Add "rw" to command line

  This appears to be necessary for a successful NFS-root boot

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

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index 2098ce1..8519721 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -23,7 +23,8 @@ CONFIG_AEABI=y
 CONFIG_FORCE_MAX_ZONEORDER\x15
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpudm memchunk.veu0=8m memchunk.spu0=2m mem$0m"
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpudm memchunk.veu0=8m memchunk.spu0=2m mem$0m rw"
 CONFIG_KEXEC=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_PM=y
-- 
1.7.10.4

[PATCH 1/5] ARM: mach-shmobile: mackerel: update defconfig

[Simon Horman]

* Enable ARM_APPENDED_DTB

  Typically the bootloader of a mackerel board does not support DT
  so this option is useful

* Add "rw" to command line

  This appears to be necessary for a successful NFS-root boot

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

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index 2098ce1..8519721 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -23,7 +23,8 @@ CONFIG_AEABI=y
 CONFIG_FORCE_MAX_ZONEORDER=15
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpu=64m memchunk.veu0=8m memchunk.spu0=2m mem=240m"
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpu=64m memchunk.veu0=8m memchunk.spu0=2m mem=240m rw"
 CONFIG_KEXEC=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_PM=y
-- 
1.7.10.4

[PATCH 2/5] ARM: shmobile: fix memory size for kota2_defconfig

[Simon Horman]

The CONFIG_MEMORY_SIZE value is interpreted as a 32 bit integer, which
makes sense on a system without PAE. It appears that a trailing 0 was
appended to the value and after some testing it appears that 0x1e000000 is
the correct value.

Without this patch, building kota2_defconfig results in:

/home/arnd/linux-arm/arch/arm/kernel/setup.c:790:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]

Reported-by: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/kota2_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/kota2_defconfig b/arch/arm/configs/kota2_defconfig
index fa83db1..57ad3d4 100644
--- a/arch/arm/configs/kota2_defconfig
+++ b/arch/arm/configs/kota2_defconfig
@@ -21,7 +21,7 @@ CONFIG_ARCH_SHMOBILE=y
 CONFIG_KEYBOARD_GPIO_POLLED=y
 CONFIG_ARCH_SH73A0=y
 CONFIG_MACH_KOTA2=y
-CONFIG_MEMORY_SIZE=0x1e0000000
+CONFIG_MEMORY_SIZE=0x1e000000
 # CONFIG_SH_TIMER_TMU is not set
 # CONFIG_SWP_EMULATE is not set
 CONFIG_CPU_BPREDICT_DISABLE=y
-- 
1.7.10.4

[PATCH 2/5] ARM: shmobile: fix memory size for kota2_defconfig

[Simon Horman]

The CONFIG_MEMORY_SIZE value is interpreted as a 32 bit integer, which
makes sense on a system without PAE. It appears that a trailing 0 was
appended to the value and after some testing it appears that 0x1e000000 is
the correct value.

Without this patch, building kota2_defconfig results in:

/home/arnd/linux-arm/arch/arm/kernel/setup.c:790:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]

Reported-by: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/kota2_defconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/kota2_defconfig b/arch/arm/configs/kota2_defconfig
index fa83db1..57ad3d4 100644
--- a/arch/arm/configs/kota2_defconfig
+++ b/arch/arm/configs/kota2_defconfig
@@ -21,7 +21,7 @@ CONFIG_ARCH_SHMOBILE=y
 CONFIG_KEYBOARD_GPIO_POLLED=y
 CONFIG_ARCH_SH73A0=y
 CONFIG_MACH_KOTA2=y
-CONFIG_MEMORY_SIZE=0x1e0000000
+CONFIG_MEMORY_SIZE=0x1e000000
 # CONFIG_SH_TIMER_TMU is not set
 # CONFIG_SWP_EMULATE is not set
 CONFIG_CPU_BPREDICT_DISABLE=y
-- 
1.7.10.4

[PATCH 3/5] ARM: mach-shmobile: kzm9g: use voltage regulators by default

[Simon Horman]

This is needed to initialise the MMCIF device in the
absence of platform data.

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

diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index afbae28..7f6ec2c 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -85,6 +85,8 @@ CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_SH_MOBILE=y
 CONFIG_GPIO_PCF857X=y
 # CONFIG_HWMON is not set
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_DUMMY=y
 CONFIG_FB=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-- 
1.7.10.4

[PATCH 3/5] ARM: mach-shmobile: kzm9g: use voltage regulators by default

[Simon Horman]

This is needed to initialise the MMCIF device in the
absence of platform data.

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

diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index afbae28..7f6ec2c 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -85,6 +85,8 @@ CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_SH_MOBILE=y
 CONFIG_GPIO_PCF857X=y
 # CONFIG_HWMON is not set
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_DUMMY=y
 CONFIG_FB=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-- 
1.7.10.4

[PATCH 4/5] ARM: mach-shmobile: armadillo: update defconfig

[Simon Horman]

* Enable ARM_APPENDED_DTB

  Typically the bootloader of an armadillo board does not support DT
  so this option is useful.

* Do not disable CONFIG_SUSPEND

  Suspend seems to work fine on the armadillo

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

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 2e1a825..c29cf04 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -34,12 +34,12 @@ CONFIG_AEABI=y
 CONFIG_FORCE_MAX_ZONEORDER\x13
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
 CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize@96,wsize@96 rw"
 CONFIG_CMDLINE_FORCE=y
 CONFIG_KEXEC=y
 CONFIG_VFP=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-# CONFIG_SUSPEND is not set
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
-- 
1.7.10.4

[PATCH 4/5] ARM: mach-shmobile: armadillo: update defconfig

[Simon Horman]

* Enable ARM_APPENDED_DTB

  Typically the bootloader of an armadillo board does not support DT
  so this option is useful.

* Do not disable CONFIG_SUSPEND

  Suspend seems to work fine on the armadillo

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

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 2e1a825..c29cf04 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -34,12 +34,12 @@ CONFIG_AEABI=y
 CONFIG_FORCE_MAX_ZONEORDER=13
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
 CONFIG_CMDLINE="console=tty0 console=ttySC1,115200 earlyprintk=sh-sci.1,115200 ignore_loglevel root=/dev/nfs ip=dhcp nfsroot=,rsize=4096,wsize=4096 rw"
 CONFIG_CMDLINE_FORCE=y
 CONFIG_KEXEC=y
 CONFIG_VFP=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-# CONFIG_SUSPEND is not set
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
-- 
1.7.10.4

[PATCH 5/5] ARM: mach-shmobile: kzm9g: Enable ARM_APPENDED_DTB in defconfig

[Simon Horman]

Typically the bootloader of a kzm9g board does not support DT
so this option is useful.

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

diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index 7f6ec2c..c6005a0 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -39,6 +39,7 @@ CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
 CONFIG_CMDLINE="console=tty0 console=ttySC4,115200 root=/dev/nfs ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200"
 CONFIG_KEXEC=y
 CONFIG_VFP=y
-- 
1.7.10.4

[PATCH 5/5] ARM: mach-shmobile: kzm9g: Enable ARM_APPENDED_DTB in defconfig

[Simon Horman]

Typically the bootloader of a kzm9g board does not support DT
so this option is useful.

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

diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index 7f6ec2c..c6005a0 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -39,6 +39,7 @@ CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
 CONFIG_CMDLINE="console=tty0 console=ttySC4,115200 root=/dev/nfs ip=dhcp ignore_loglevel earlyprintk=sh-sci.4,115200"
 CONFIG_KEXEC=y
 CONFIG_VFP=y
-- 
1.7.10.4

Re: [PATCH 1/5] ARM: mach-shmobile: mackerel: update defconfig

[Olof Johansson]

Hi,

On Thu, Jan 10, 2013 at 10:23:55AM +0900, Simon Horman wrote:
> * Enable ARM_APPENDED_DTB
> 
>   Typically the bootloader of a mackerel board does not support DT
>   so this option is useful
> 
> * Add "rw" to command line
> 
>   This appears to be necessary for a successful NFS-root boot
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  arch/arm/configs/mackerel_defconfig |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
> index 2098ce1..8519721 100644
> --- a/arch/arm/configs/mackerel_defconfig
> +++ b/arch/arm/configs/mackerel_defconfig
> @@ -23,7 +23,8 @@ CONFIG_AEABI=y
>  CONFIG_FORCE_MAX_ZONEORDER\x15
>  CONFIG_ZBOOT_ROM_TEXT=0x0
>  CONFIG_ZBOOT_ROM_BSS=0x0
> -CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpudm memchunk.veu0=8m memchunk.spu0=2m mem$0m"
> +CONFIG_ARM_APPENDED_DTB=y
> +CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpudm memchunk.veu0=8m memchunk.spu0=2m mem$0m rw"

I don't think memchunk is used outside of arch/sh, so it can be dropped from
this default cmdline?

Also, with DTB, there's little use for an in-kernel default command line since
you can give one with the dtb instead. Perhaps just drop it alltogether and
move it there?


-Olof

[PATCH 1/5] ARM: mach-shmobile: mackerel: update defconfig

[Olof Johansson]

Hi,

On Thu, Jan 10, 2013 at 10:23:55AM +0900, Simon Horman wrote:
> * Enable ARM_APPENDED_DTB
> 
>   Typically the bootloader of a mackerel board does not support DT
>   so this option is useful
> 
> * Add "rw" to command line
> 
>   This appears to be necessary for a successful NFS-root boot
> 
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
>  arch/arm/configs/mackerel_defconfig |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
> index 2098ce1..8519721 100644
> --- a/arch/arm/configs/mackerel_defconfig
> +++ b/arch/arm/configs/mackerel_defconfig
> @@ -23,7 +23,8 @@ CONFIG_AEABI=y
>  CONFIG_FORCE_MAX_ZONEORDER=15
>  CONFIG_ZBOOT_ROM_TEXT=0x0
>  CONFIG_ZBOOT_ROM_BSS=0x0
> -CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpu=64m memchunk.veu0=8m memchunk.spu0=2m mem=240m"
> +CONFIG_ARM_APPENDED_DTB=y
> +CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpu=64m memchunk.veu0=8m memchunk.spu0=2m mem=240m rw"

I don't think memchunk is used outside of arch/sh, so it can be dropped from
this default cmdline?

Also, with DTB, there's little use for an in-kernel default command line since
you can give one with the dtb instead. Perhaps just drop it alltogether and
move it there?


-Olof

Re: [PATCH 1/5] ARM: mach-shmobile: mackerel: update defconfig

[Simon Horman]

On Thu, Jan 10, 2013 at 03:11:11PM -0800, Olof Johansson wrote:
> Hi,
> 
> On Thu, Jan 10, 2013 at 10:23:55AM +0900, Simon Horman wrote:
> > * Enable ARM_APPENDED_DTB
> > 
> >   Typically the bootloader of a mackerel board does not support DT
> >   so this option is useful
> > 
> > * Add "rw" to command line
> > 
> >   This appears to be necessary for a successful NFS-root boot
> > 
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> >  arch/arm/configs/mackerel_defconfig |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
> > index 2098ce1..8519721 100644
> > --- a/arch/arm/configs/mackerel_defconfig
> > +++ b/arch/arm/configs/mackerel_defconfig
> > @@ -23,7 +23,8 @@ CONFIG_AEABI=y
> >  CONFIG_FORCE_MAX_ZONEORDER\x15
> >  CONFIG_ZBOOT_ROM_TEXT=0x0
> >  CONFIG_ZBOOT_ROM_BSS=0x0
> > -CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpudm memchunk.veu0=8m memchunk.spu0=2m mem$0m"
> > +CONFIG_ARM_APPENDED_DTB=y
> > +CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpudm memchunk.veu0=8m memchunk.spu0=2m mem$0m rw"
> 
> I don't think memchunk is used outside of arch/sh, so it can be dropped from
> this default cmdline?
> 
> Also, with DTB, there's little use for an in-kernel default command line since
> you can give one with the dtb instead. Perhaps just drop it alltogether and
> move it there?

Thanks, I'll see about making both of those changes and repost.

[PATCH 1/5] ARM: mach-shmobile: mackerel: update defconfig

[Simon Horman]

On Thu, Jan 10, 2013 at 03:11:11PM -0800, Olof Johansson wrote:
> Hi,
> 
> On Thu, Jan 10, 2013 at 10:23:55AM +0900, Simon Horman wrote:
> > * Enable ARM_APPENDED_DTB
> > 
> >   Typically the bootloader of a mackerel board does not support DT
> >   so this option is useful
> > 
> > * Add "rw" to command line
> > 
> >   This appears to be necessary for a successful NFS-root boot
> > 
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> >  arch/arm/configs/mackerel_defconfig |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
> > index 2098ce1..8519721 100644
> > --- a/arch/arm/configs/mackerel_defconfig
> > +++ b/arch/arm/configs/mackerel_defconfig
> > @@ -23,7 +23,8 @@ CONFIG_AEABI=y
> >  CONFIG_FORCE_MAX_ZONEORDER=15
> >  CONFIG_ZBOOT_ROM_TEXT=0x0
> >  CONFIG_ZBOOT_ROM_BSS=0x0
> > -CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpu=64m memchunk.veu0=8m memchunk.spu0=2m mem=240m"
> > +CONFIG_ARM_APPENDED_DTB=y
> > +CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpu=64m memchunk.veu0=8m memchunk.spu0=2m mem=240m rw"
> 
> I don't think memchunk is used outside of arch/sh, so it can be dropped from
> this default cmdline?
> 
> Also, with DTB, there's little use for an in-kernel default command line since
> you can give one with the dtb instead. Perhaps just drop it alltogether and
> move it there?

Thanks, I'll see about making both of those changes and repost.

[GIT PULL] Renesas ARM-based SoC v3.9

[Simon Horman]

Hi Olof, Hi Arnd,

I have some complex dependencies for mach-shmobile for v3.9
and as such I am sending this email outline the dependencies
of branches on each other. I have also included the multiple
pull requests below though I am happy to post them
individually including the patches they comprise if you
have no objections to the way the branch dependencies are arranged.

I would also be happy to supply a single branch with all changes
with or without merge commits.

All branches are present in the renesas tree
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git

1. Branch: sh-soc
   Description: Pre-requisites for pfc changes for SH SoCs
   Based on: v3.8-rc1

2. Branch: clocksource
   Description: Pre-requisite clocksource change for soc branch
   Based on: v3.8-rc1

3. Branch: pfc
   Description: PFC Updates
   Based on: sh-soc

4. Branch: sh-soc2
   Description: Further PFC changes for SH SoCs
   Based on: pfc

5. Branch: soc
   Description: shmobile (ARM) SoCs updates, including PFC changes.
   Based on: a merge of clocksource and pfc

6. Branch: boards
   Description: Board changes, including PFC changes.
   Based on: A merge of timer/cleanup (present in the arm-soc tree) and soc

7. Branch: pfc2
   Description: Further PFC changes which depend on SoC changes
   Based on: A merge of sh-soc2 and soc

8. Branch: sh-soc3
   Description: Further PFC changes for SH SoCs
   Based on: pfc2

9. Branch: soc2
   Description: Further PFC changes for shmobile (ARM) SoCs
   Based on: A merge of timer/cleanup (present in the arm-soc tree) and pfc2

10. Branch: pfc3
    Description: Description: Further PFC changes which depend on SoC changes
    Based on: A merge of sh-soc3 and soc2

And now to the pull-requests:

================================
1.

The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:

  Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git sh-soc

for you to fetch changes up to 2cbf52318a995c09de88dc7c3067d387d7d9ffe8:

  sh: shx3: Fix last GPIO index (2013-01-07 14:44:46 +0900)

----------------------------------------------------------------
Laurent Pinchart (7):
      sh: sh7264: Rename CRX0CRX1 mark to match GPIO names
      sh: sh7269: Rename CRX0CRX1(CRX2) marks to match GPIO names
      sh: sh7723: Rename GPIO_FN_SIUOSPD to GPIO_FN_SIUAOSPD
      sh: sh7757: Fix GPIO_FN_ET0_MDIO and GPIO_FN_ET1_MDIO GPIO entries
      sh: sh7786: Fix port E, G and J GPIOs
      sh: sh7786: Fix last GPIO index
      sh: shx3: Fix last GPIO index

 arch/sh/include/cpu-sh4/cpu/sh7723.h    |    2 +-
 arch/sh/include/cpu-sh4/cpu/sh7786.h    |    8 +++-----
 arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c |    6 +++---
 arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c |   12 ++++++------
 arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c |    2 +-
 arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c |    4 ++--
 arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c |    6 +++---
 arch/sh/kernel/cpu/sh4a/pinmux-shx3.c   |    2 +-
 8 files changed, 20 insertions(+), 22 deletions(-)

================================
2.

The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:

  Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)

are available in the git repository at:

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

for you to fetch changes up to 892a45dbe32eb565c07d08085e694985e6fbaf26:

  ARM: clocksource: Initialise early (2013-01-16 14:55:11 +0900)

----------------------------------------------------------------
Simon Horman (1):
      ARM: clocksource: Initialise early

 drivers/Makefile |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

================================
3.

The following changes since commit 2cbf52318a995c09de88dc7c3067d387d7d9ffe8:

  sh: shx3: Fix last GPIO index (2013-01-07 14:44:46 +0900)

are available in the git repository at:

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

for you to fetch changes up to 3951da29e5981e3441fdd79a9363fd1af739374b:

  sh-pfc: Support passing resources through platform device (2013-01-07 14:47:55 +0900)

----------------------------------------------------------------
Laurent Pinchart (14):
      sh-pfc: Remove all use of __devinit/__devexit
      sh-pfc: Split platform data from the sh_pfc structure
      sh-pfc: Move private definitions and declarations to private header
      sh-pfc: Merge PFC core and pinctrl
      sh-pfc: Merge PFC core and gpio
      sh-pfc: Move platform device and driver to the core
      sh-pfc: Use devm_kzalloc()
      sh-pfc: Use devm_ioremap_nocache()
      sh-pfc: Let the compiler decide whether to inline functions
      sh-pfc: Remove check for impossible error condition
      sh-pfc: Sort headers alphabetically
      sh-pfc: Use sh_pfc_ namespace prefix through the whole driver
      sh-pfc: Split platform device and platform driver registration
      sh-pfc: Support passing resources through platform device

 drivers/sh/pfc/Kconfig   |   12 +-
 drivers/sh/pfc/Makefile  |    8 +-
 drivers/sh/pfc/core.c    |  327 +++++++++++++++++++++++++---------------------
 drivers/sh/pfc/core.h    |   54 ++++++++
 drivers/sh/pfc/gpio.c    |  113 ++++------------
 drivers/sh/pfc/pinctrl.c |  171 ++++++++----------------
 include/linux/sh_pfc.h   |   35 +----
 7 files changed, 326 insertions(+), 394 deletions(-)
 create mode 100644 drivers/sh/pfc/core.h

================================
4.

The following changes since commit 3951da29e5981e3441fdd79a9363fd1af739374b:

  sh-pfc: Support passing resources through platform device (2013-01-07 14:47:55 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git sh-soc2

for you to fetch changes up to 85a76791fa8c2f1e5467557c52fcbfaff90db586:

  sh: shx3: Register PFC platform device (2013-01-07 14:50:54 +0900)

----------------------------------------------------------------
Laurent Pinchart (13):
      sh: Add PFC platform device registration helper function
      sh: sh7203: Register PFC platform device
      sh: sh7264: Register PFC platform device
      sh: sh7269: Register PFC platform device
      sh: sh7720: Register PFC platform device
      sh: sh7722: Register PFC platform device
      sh: sh7723: Register PFC platform device
      sh: sh7724: Register PFC platform device
      sh: sh7734: Register PFC platform device
      sh: sh7757: Register PFC platform device
      sh: sh7785: Register PFC platform device
      sh: sh7786: Register PFC platform device
      sh: shx3: Register PFC platform device

 arch/sh/Kconfig                         |   12 +++++++++
 arch/sh/include/cpu-common/cpu/pfc.h    |   30 +++++++++++++++++++++
 arch/sh/kernel/cpu/Makefile             |    2 +-
 arch/sh/kernel/cpu/pfc.c                |   44 +++++++++++++++++++++++++++++++
 arch/sh/kernel/cpu/sh2a/pinmux-sh7203.c |    3 ++-
 arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c |    3 ++-
 arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c |    3 ++-
 arch/sh/kernel/cpu/sh3/pinmux-sh7720.c  |    3 ++-
 arch/sh/kernel/cpu/sh4a/pinmux-sh7722.c |    3 ++-
 arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c |    3 ++-
 arch/sh/kernel/cpu/sh4a/pinmux-sh7724.c |    3 ++-
 arch/sh/kernel/cpu/sh4a/pinmux-sh7734.c |    8 +++---
 arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c |    3 ++-
 arch/sh/kernel/cpu/sh4a/pinmux-sh7785.c |    3 ++-
 arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c |    3 ++-
 arch/sh/kernel/cpu/sh4a/pinmux-shx3.c   |    3 ++-
 16 files changed, 113 insertions(+), 16 deletions(-)
 create mode 100644 arch/sh/include/cpu-common/cpu/pfc.h
 create mode 100644 arch/sh/kernel/cpu/pfc.c

================================
5.

The following changes since commit 3951da29e5981e3441fdd79a9363fd1af739374b:

  sh-pfc: Support passing resources through platform device (2013-01-07 14:47:55 +0900)

are available in the git repository at:

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

for you to fetch changes up to 54689817eb3476be410b42a9ce2bff82037b4334:

  ARM: SH-Mobile: sh73a0: Add CPU Hotplug (2013-01-16 14:16:25 +0900)

----------------------------------------------------------------
Bastian Hecht (4):
      ARM: shmobile: sh73a0: Add CPU sleep suspend
      ARM: shmobile: r8a7740: Add CPU sleep suspend
      ARM: SH-Mobile: sh73a0: Secondary CPUs handle own SCU flags
      ARM: SH-Mobile: sh73a0: Add CPU Hotplug

Guennadi Liakhovetski (3):
      ARM: sh7372: add clock lookup entries for DT-based devices
      ARM: sh7372: fix cache clean / invalidate order
      ARM: shmobile: add function declarations for sh7372 DT helper functions

Kuninori Morimoto (2):
      ARM: shmobile: r8a7740: add TMU timer support
      ARM: shmobile: sh73a0: fixup div4_clks bitmap

Laurent Pinchart (8):
      ARM: shmobile: Select PINCTRL
      ARM: shmobile: r8a7740: Register PFC platform device
      ARM: shmobile: r8a7779: Register PFC platform device
      ARM: shmobile: sh7372: Register PFC platform device
      ARM: shmobile: sh73a0: Register PFC platform device
      ARM: shmobile: r8a7740: Add pin control resources
      ARM: shmobile: sh7372: Add pin control resources
      ARM: shmobile: sh73a0: Add pin control resources

Magnus Damm (1):
      ARM: mach-shmobile: sh73a0 external IRQ wake update

Simon Horman (4):
      ARM: shmobile: Remove duplicate inclusion of dma-mapping.h in setup-r8a7740.c
      ARM: mach-shmobile: sh73a0: Allow initialisation of GIC by DT
      ARM: mach-shmobile: sh73a0: Minimal setup using DT
      ARM: mach-shmobile: sh73a0: Initialise MMCIF using DT

 arch/arm/Kconfig                               |    1 +
 arch/arm/boot/dts/sh73a0-reference.dtsi        |   24 ++++++
 arch/arm/boot/dts/sh73a0.dtsi                  |   93 +++++++++++++++++++++++
 arch/arm/mach-shmobile/Makefile                |    3 +-
 arch/arm/mach-shmobile/board-armadillo800eva.c |    2 +
 arch/arm/mach-shmobile/board-kzm9g.c           |    2 +
 arch/arm/mach-shmobile/clock-r8a7740.c         |    6 +-
 arch/arm/mach-shmobile/clock-sh7372.c          |    9 +++
 arch/arm/mach-shmobile/clock-sh73a0.c          |   35 ++++++---
 arch/arm/mach-shmobile/headsmp-sh73a0.S        |   50 +++++++++++++
 arch/arm/mach-shmobile/include/mach/common.h   |    8 ++
 arch/arm/mach-shmobile/intc-sh73a0.c           |   21 ++++--
 arch/arm/mach-shmobile/pfc-r8a7740.c           |   28 ++++++-
 arch/arm/mach-shmobile/pfc-r8a7779.c           |   16 +++-
 arch/arm/mach-shmobile/pfc-sh7372.c            |   28 ++++++-
 arch/arm/mach-shmobile/pfc-sh73a0.c            |   28 ++++++-
 arch/arm/mach-shmobile/pm-r8a7740.c            |   22 ++++++
 arch/arm/mach-shmobile/pm-sh73a0.c             |   32 ++++++++
 arch/arm/mach-shmobile/setup-r8a7740.c         |   95 +++++++++++++++++++++++-
 arch/arm/mach-shmobile/setup-sh73a0.c          |   64 +++++++++++++++-
 arch/arm/mach-shmobile/sleep-sh7372.S          |   12 +--
 arch/arm/mach-shmobile/smp-sh73a0.c            |   66 ++++++++--------
 22 files changed, 580 insertions(+), 65 deletions(-)
 create mode 100644 arch/arm/boot/dts/sh73a0-reference.dtsi
 create mode 100644 arch/arm/boot/dts/sh73a0.dtsi
 create mode 100644 arch/arm/mach-shmobile/headsmp-sh73a0.S
 create mode 100644 arch/arm/mach-shmobile/pm-sh73a0.c

================================
6.

The following changes since commit b7e481b082bf48707020bef270aa726b96d7b4be:

  Merge branches 'soc' and 'clocksource', remote-tracking branch 'arm-soc/timer/cleanup' into boards (2013-01-16 15:27:26 +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 2b88c35a7ddd49301eb73a4660e012bba61a3504:

  ARM: mach-shmobile: kzm9g: Reference DT implementation (2013-01-16 15:27:41 +0900)

----------------------------------------------------------------
Guennadi Liakhovetski (1):
      ARM: mackerel: include the correct .dtsi file

Kuninori Morimoto (3):
      ARM: shmobile: fix sample amixer settings for mackerel
      ARM: shmobile: add sample amixer settings for ap4evb
      ARM: shmobile: add sample amixer settings for armadillo800eva

Laurent Pinchart (2):
      ARM: shmobile: kzm9g: Use of_machine_is_compatible()
      ARM: shmobile: Include sh73a0 DTSI in kzm9g

Nobuhiro Iwamatsu (1):
      ARM: shmobile: Include DTSI of r8a7740 to armadillo800eva

Simon Horman (1):
      ARM: mach-shmobile: kzm9g: Reference DT implementation

 arch/arm/boot/dts/Makefile                     |    1 +
 arch/arm/boot/dts/r8a7740-armadillo800eva.dts  |    2 +-
 arch/arm/boot/dts/sh7372-mackerel.dts          |    2 +-
 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts   |   37 +++++++++
 arch/arm/boot/dts/sh73a0-kzm9g.dts             |    2 +-
 arch/arm/mach-shmobile/Kconfig                 |   10 +++
 arch/arm/mach-shmobile/Makefile                |    1 +
 arch/arm/mach-shmobile/board-ap4evb.c          |    4 +
 arch/arm/mach-shmobile/board-armadillo800eva.c |    8 ++
 arch/arm/mach-shmobile/board-kzm9g-reference.c |   99 ++++++++++++++++++++++++
 arch/arm/mach-shmobile/board-kzm9g.c           |    2 +-
 arch/arm/mach-shmobile/board-mackerel.c        |    4 +-
 12 files changed, 165 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
 create mode 100644 arch/arm/mach-shmobile/board-kzm9g-reference.c

================================
7.

The following changes since commit e35442480c27092fd7c5ecd987a225bab448d031:

  Merge branches 'soc' and 'sh-soc2' into pfc2 (2013-01-16 14:33:26 +0900)

are available in the git repository at:


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

for you to fetch changes up to 5800cb822fbda9378fd8eb8cfd19369b5833bd34:

  sh-pfc: Add shx3 pinmux support (2013-01-16 14:34:00 +0900)

----------------------------------------------------------------
Laurent Pinchart (20):
      sh-pfc: Remove platform device registration
      sh-pfc: Remove unused resource and num_resources platform data fields
      sh-pfc: Move driver from drivers/sh/ to drivers/pinctrl/
      sh-pfc: Support pinmux info in driver data instead of platform data
      sh-pfc: Add r8a7740 pinmux support
      sh-pfc: Add r8a7779 pinmux support
      sh-pfc: Add sh7372 pinmux support
      sh-pfc: Add sh73a0 pinmux support
      sh-pfc: Add sh7203 pinmux support
      sh-pfc: Add sh7264 pinmux support
      sh-pfc: Add sh7269 pinmux support
      sh-pfc: Add sh7720 pinmux support
      sh-pfc: Add sh7722 pinmux support
      sh-pfc: Add sh7723 pinmux support
      sh-pfc: Add sh7724 pinmux support
      sh-pfc: Add sh7734 pinmux support
      sh-pfc: Add sh7757 pinmux support
      sh-pfc: Add sh7785 pinmux support
      sh-pfc: Add sh7786 pinmux support
      sh-pfc: Add shx3 pinmux support

 drivers/pinctrl/Kconfig                      |    2 +-
 drivers/pinctrl/Makefile                     |    2 +
 drivers/pinctrl/sh-pfc/Kconfig               |  116 ++
 drivers/pinctrl/sh-pfc/Makefile              |   21 +
 drivers/{sh/pfc => pinctrl/sh-pfc}/core.c    |  129 +-
 drivers/{sh/pfc => pinctrl/sh-pfc}/core.h    |   19 +-
 drivers/{sh/pfc => pinctrl/sh-pfc}/gpio.c    |   18 +-
 drivers/pinctrl/sh-pfc/pfc-r8a7740.c         | 2611 ++++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c         | 2623 ++++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7203.c          | 1591 +++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7264.c          | 2130 +++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7269.c          | 2833 ++++++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7372.c          | 1657 +++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh73a0.c          | 2797 +++++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7720.c          | 1235 +++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7722.c          | 1778 ++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7723.c          | 1902 +++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7724.c          | 2224 ++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7734.c          | 2474 ++++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7757.c          | 2281 +++++++++++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7785.c          | 1303 ++++++++++++
 drivers/pinctrl/sh-pfc/pfc-sh7786.c          |  836 ++++++++
 drivers/pinctrl/sh-pfc/pfc-shx3.c            |  581 ++++++
 drivers/{sh/pfc => pinctrl/sh-pfc}/pinctrl.c |   28 +-
 drivers/sh/Kconfig                           |    1 -
 drivers/sh/Makefile                          |    1 -
 drivers/sh/pfc/Kconfig                       |   18 -
 drivers/sh/pfc/Makefile                      |    5 -
 include/linux/sh_pfc.h                       |   17 +-
 29 files changed, 31118 insertions(+), 115 deletions(-)
 create mode 100644 drivers/pinctrl/sh-pfc/Kconfig
 create mode 100644 drivers/pinctrl/sh-pfc/Makefile
 rename drivers/{sh/pfc => pinctrl/sh-pfc}/core.c (79%)
 rename drivers/{sh/pfc => pinctrl/sh-pfc}/core.h (63%)
 rename drivers/{sh/pfc => pinctrl/sh-pfc}/gpio.c (89%)
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7740.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7779.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7203.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7264.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7269.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7372.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh73a0.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7720.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7722.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7723.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7724.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7734.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7757.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7785.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7786.c
 create mode 100644 drivers/pinctrl/sh-pfc/pfc-shx3.c
 rename drivers/{sh/pfc => pinctrl/sh-pfc}/pinctrl.c (93%)
 delete mode 100644 drivers/sh/pfc/Kconfig
 delete mode 100644 drivers/sh/pfc/Makefile

================================
8.

The following changes since commit 5800cb822fbda9378fd8eb8cfd19369b5833bd34:

  sh-pfc: Add shx3 pinmux support (2013-01-16 14:34:00 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git sh-soc3

for you to fetch changes up to 09b276b8c3a590839d3dd199c7116ff5f8fe36e6:

  sh: shx3: pinmux: Use driver-provided pinmux info (2013-01-16 14:42:19 +0900)

----------------------------------------------------------------
Laurent Pinchart (12):
      sh: sh7203: pinmux: Use driver-provided pinmux info
      sh: sh7264: pinmux: Use driver-provided pinmux info
      sh: sh7269: pinmux: Use driver-provided pinmux info
      sh: sh7720: pinmux: Use driver-provided pinmux info
      sh: sh7722: pinmux: Use driver-provided pinmux info
      sh: sh7723: pinmux: Use driver-provided pinmux info
      sh: sh7724: pinmux: Use driver-provided pinmux info
      sh: sh7734: pinmux: Use driver-provided pinmux info
      sh: sh7757: pinmux: Use driver-provided pinmux info
      sh: sh7785: pinmux: Use driver-provided pinmux info
      sh: sh7786: pinmux: Use driver-provided pinmux info
      sh: shx3: pinmux: Use driver-provided pinmux info

 arch/sh/kernel/cpu/sh2a/pinmux-sh7203.c | 1581 +----------------
 arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c | 2120 +----------------------
 arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c | 2822 +------------------------------
 arch/sh/kernel/cpu/sh3/pinmux-sh7720.c  | 1225 +-------------
 arch/sh/kernel/cpu/sh4a/pinmux-sh7722.c | 1777 +------------------
 arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c | 1892 +--------------------
 arch/sh/kernel/cpu/sh4a/pinmux-sh7724.c | 2209 +-----------------------
 arch/sh/kernel/cpu/sh4a/pinmux-sh7734.c | 2468 +--------------------------
 arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c | 2266 +------------------------
 arch/sh/kernel/cpu/sh4a/pinmux-sh7785.c | 1293 +-------------
 arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c |  821 +--------
 arch/sh/kernel/cpu/sh4a/pinmux-shx3.c   |  572 +------
 12 files changed, 14 insertions(+), 21032 deletions(-)

================================
9.

The following changes since commit c1857e7b2da094b23db24e0829565264d3ba888d:

  Merge branch 'pfc2', remote-tracking branch 'arm-soc/timer/cleanup' into soc2 (2013-01-16 14:35:00 +0900)

are available in the git repository at:


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

for you to fetch changes up to ed68adfe853db33aad6a294702396736ba220af6:

  ARM: shmobile: sh73a0: Use driver-provided pinmux info (2013-01-16 14:38:47 +0900)

----------------------------------------------------------------
Laurent Pinchart (4):
      ARM: shmobile: r8a7740: Use driver-provided pinmux info
      ARM: shmobile: r8a7779: Use driver-provided pinmux info
      ARM: shmobile: sh7372: Use driver-provided pinmux info
      ARM: shmobile: sh73a0: Use driver-provided pinmux info

 arch/arm/mach-shmobile/Makefile        |    8 -
 arch/arm/mach-shmobile/pfc-r8a7740.c   | 2643 -----------------------------
 arch/arm/mach-shmobile/pfc-r8a7779.c   | 2653 ------------------------------
 arch/arm/mach-shmobile/pfc-sh7372.c    | 1689 -------------------
 arch/arm/mach-shmobile/pfc-sh73a0.c    | 2829 --------------------------------
 arch/arm/mach-shmobile/setup-r8a7740.c |   26 +
 arch/arm/mach-shmobile/setup-r8a7779.c |   25 +
 arch/arm/mach-shmobile/setup-sh7372.c  |   26 +
 arch/arm/mach-shmobile/setup-sh73a0.c  |   25 +
 9 files changed, 102 insertions(+), 9822 deletions(-)
 delete mode 100644 arch/arm/mach-shmobile/pfc-r8a7740.c
 delete mode 100644 arch/arm/mach-shmobile/pfc-r8a7779.c
 delete mode 100644 arch/arm/mach-shmobile/pfc-sh7372.c
 delete mode 100644 arch/arm/mach-shmobile/pfc-sh73a0.c

================================
10.

The following changes since commit 29ef16511e7645caa979b4db432bf30359fd3795:

  Merge branches 'soc2' and 'sh-soc3' into pfc3 (2013-01-16 14:42:55 +0900)

are available in the git repository at:


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

for you to fetch changes up to 52c59e03952165b9d462f7001095eb5b8808aed6:

  sh-pfc: Move sh_pfc.h from include/linux/ to driver directory (2013-01-16 14:43:06 +0900)

----------------------------------------------------------------
Laurent Pinchart (3):
      sh: Remove unused sh_pfc_register_info() function
      sh-pfc: Remove pinmux_info definition
      sh-pfc: Move sh_pfc.h from include/linux/ to driver directory

 arch/sh/include/asm/gpio.h                         |    2 +-
 arch/sh/include/cpu-common/cpu/pfc.h               |    4 ----
 arch/sh/kernel/cpu/pfc.c                           |   13 +------------
 drivers/pinctrl/sh-pfc/core.c                      |    1 -
 drivers/pinctrl/sh-pfc/core.h                      |    3 ++-
 drivers/pinctrl/sh-pfc/gpio.c                      |    1 -
 drivers/pinctrl/sh-pfc/pfc-r8a7740.c               |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-r8a7779.c               |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7203.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7264.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7269.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7372.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh73a0.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7720.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7722.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7723.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7724.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7734.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7757.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7785.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-sh7786.c                |    3 ++-
 drivers/pinctrl/sh-pfc/pfc-shx3.c                  |    3 ++-
 drivers/pinctrl/sh-pfc/pinctrl.c                   |    1 -
 {include/linux => drivers/pinctrl/sh-pfc}/sh_pfc.h |    3 ---
 24 files changed, 36 insertions(+), 40 deletions(-)
 rename {include/linux => drivers/pinctrl/sh-pfc}/sh_pfc.h (98%)

================================

Re: [GIT PULL] Renesas ARM-based SoC v3.9

[Olof Johansson]

On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> I have some complex dependencies for mach-shmobile for v3.9
> and as such I am sending this email outline the dependencies
> of branches on each other. I have also included the multiple
> pull requests below though I am happy to post them
> individually including the patches they comprise if you
> have no objections to the way the branch dependencies are arranged.
> 
> I would also be happy to supply a single branch with all changes
> with or without merge commits.

Hmm, complex indeed.

Is there any way to avoid this sequence of ARM -> sh/pinctrl -> ARM ->
sh/pinctrl dependencies? That's what really makes things look complicated
here. If you could move the final cleanup/code removal pieces out of
the sh/pinctrl branches such that you have a less iterative chain of:

sh/pinctrl -> ARM -> final sh/pinctrl cleanup (removal of struct members, etc)

... but I haven't looked in detail at the per-patch dependencies to see how
tough that would be to arrange.

> All branches are present in the renesas tree
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> 
> 1. Branch: sh-soc
>    Description: Pre-requisites for pfc changes for SH SoCs
>    Based on: v3.8-rc1
> 
> 2. Branch: clocksource
>    Description: Pre-requisite clocksource change for soc branch
>    Based on: v3.8-rc1
> 
> 3. Branch: pfc
>    Description: PFC Updates
>    Based on: sh-soc
> 
> 4. Branch: sh-soc2
>    Description: Further PFC changes for SH SoCs
>    Based on: pfc
> 
> 5. Branch: soc
>    Description: shmobile (ARM) SoCs updates, including PFC changes.
>    Based on: a merge of clocksource and pfc
> 
> 6. Branch: boards
>    Description: Board changes, including PFC changes.
>    Based on: A merge of timer/cleanup (present in the arm-soc tree) and soc
> 
> 7. Branch: pfc2
>    Description: Further PFC changes which depend on SoC changes
>    Based on: A merge of sh-soc2 and soc
> 
> 8. Branch: sh-soc3
>    Description: Further PFC changes for SH SoCs
>    Based on: pfc2
> 
> 9. Branch: soc2
>    Description: Further PFC changes for shmobile (ARM) SoCs
>    Based on: A merge of timer/cleanup (present in the arm-soc tree) and pfc2
> 
> 10. Branch: pfc3
>     Description: Description: Further PFC changes which depend on SoC changes
>     Based on: A merge of sh-soc3 and soc2

Looking at it from the end here, 10 contains only arch/sh and global
changes, and depends on 8 and 9. 8 also contains only sh changes. So it
looks like 8 and 10 could be pruned from this pull request and go through
either SH or pinctrl.

What pieces from branch 7 are stronly needed? A couple of the added pinctrl
modules are used by mach-shmobile boards, it seems. And the structure rename
might also be needed.

Not having to pull in the bulk of 7, 8 and 10 would make a pretty big
difference.

For branch 2 (clocksource include order), I'd like to see an ack from John or
Thomas. Does it really make sense to base that on an ifdef instead of always
initialize early?

Branch 4 seems to be mostly sh-specific updates. With some of the later
dependencies avoided, maybe this branch can be dropped too, not sure?

About half of branch 5 looks like it's generic SoC-updates unrelated
to the pinctrl rework, and branch 6 looks like mostly regular
patches/updates, is that stronly dependent on all the pinctrl
rework? Doesn't look like it should be?


-Olof

[GIT PULL] Renesas ARM-based SoC v3.9

[Olof Johansson]

On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> I have some complex dependencies for mach-shmobile for v3.9
> and as such I am sending this email outline the dependencies
> of branches on each other. I have also included the multiple
> pull requests below though I am happy to post them
> individually including the patches they comprise if you
> have no objections to the way the branch dependencies are arranged.
> 
> I would also be happy to supply a single branch with all changes
> with or without merge commits.

Hmm, complex indeed.

Is there any way to avoid this sequence of ARM -> sh/pinctrl -> ARM ->
sh/pinctrl dependencies? That's what really makes things look complicated
here. If you could move the final cleanup/code removal pieces out of
the sh/pinctrl branches such that you have a less iterative chain of:

sh/pinctrl -> ARM -> final sh/pinctrl cleanup (removal of struct members, etc)

... but I haven't looked in detail at the per-patch dependencies to see how
tough that would be to arrange.

> All branches are present in the renesas tree
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> 
> 1. Branch: sh-soc
>    Description: Pre-requisites for pfc changes for SH SoCs
>    Based on: v3.8-rc1
> 
> 2. Branch: clocksource
>    Description: Pre-requisite clocksource change for soc branch
>    Based on: v3.8-rc1
> 
> 3. Branch: pfc
>    Description: PFC Updates
>    Based on: sh-soc
> 
> 4. Branch: sh-soc2
>    Description: Further PFC changes for SH SoCs
>    Based on: pfc
> 
> 5. Branch: soc
>    Description: shmobile (ARM) SoCs updates, including PFC changes.
>    Based on: a merge of clocksource and pfc
> 
> 6. Branch: boards
>    Description: Board changes, including PFC changes.
>    Based on: A merge of timer/cleanup (present in the arm-soc tree) and soc
> 
> 7. Branch: pfc2
>    Description: Further PFC changes which depend on SoC changes
>    Based on: A merge of sh-soc2 and soc
> 
> 8. Branch: sh-soc3
>    Description: Further PFC changes for SH SoCs
>    Based on: pfc2
> 
> 9. Branch: soc2
>    Description: Further PFC changes for shmobile (ARM) SoCs
>    Based on: A merge of timer/cleanup (present in the arm-soc tree) and pfc2
> 
> 10. Branch: pfc3
>     Description: Description: Further PFC changes which depend on SoC changes
>     Based on: A merge of sh-soc3 and soc2

Looking at it from the end here, 10 contains only arch/sh and global
changes, and depends on 8 and 9. 8 also contains only sh changes. So it
looks like 8 and 10 could be pruned from this pull request and go through
either SH or pinctrl.

What pieces from branch 7 are stronly needed? A couple of the added pinctrl
modules are used by mach-shmobile boards, it seems. And the structure rename
might also be needed.

Not having to pull in the bulk of 7, 8 and 10 would make a pretty big
difference.

For branch 2 (clocksource include order), I'd like to see an ack from John or
Thomas. Does it really make sense to base that on an ifdef instead of always
initialize early?

Branch 4 seems to be mostly sh-specific updates. With some of the later
dependencies avoided, maybe this branch can be dropped too, not sure?

About half of branch 5 looks like it's generic SoC-updates unrelated
to the pinctrl rework, and branch 6 looks like mostly regular
patches/updates, is that stronly dependent on all the pinctrl
rework? Doesn't look like it should be?


-Olof

Re: [GIT PULL] Renesas ARM-based SoC v3.9

[Simon Horman]

On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> I have some complex dependencies for mach-shmobile for v3.9
> and as such I am sending this email outline the dependencies
> of branches on each other. I have also included the multiple
> pull requests below though I am happy to post them
> individually including the patches they comprise if you
> have no objections to the way the branch dependencies are arranged.
> 
> I would also be happy to supply a single branch with all changes
> with or without merge commits.
> 
> All branches are present in the renesas tree
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git

Ping.

> 1. Branch: sh-soc
>    Description: Pre-requisites for pfc changes for SH SoCs
>    Based on: v3.8-rc1
> 
> 2. Branch: clocksource
>    Description: Pre-requisite clocksource change for soc branch
>    Based on: v3.8-rc1
> 
> 3. Branch: pfc
>    Description: PFC Updates
>    Based on: sh-soc
> 
> 4. Branch: sh-soc2
>    Description: Further PFC changes for SH SoCs
>    Based on: pfc
> 
> 5. Branch: soc
>    Description: shmobile (ARM) SoCs updates, including PFC changes.
>    Based on: a merge of clocksource and pfc
> 
> 6. Branch: boards
>    Description: Board changes, including PFC changes.
>    Based on: A merge of timer/cleanup (present in the arm-soc tree) and soc
> 
> 7. Branch: pfc2
>    Description: Further PFC changes which depend on SoC changes
>    Based on: A merge of sh-soc2 and soc
> 
> 8. Branch: sh-soc3
>    Description: Further PFC changes for SH SoCs
>    Based on: pfc2
> 
> 9. Branch: soc2
>    Description: Further PFC changes for shmobile (ARM) SoCs
>    Based on: A merge of timer/cleanup (present in the arm-soc tree) and pfc2
> 
> 10. Branch: pfc3
>     Description: Description: Further PFC changes which depend on SoC changes
>     Based on: A merge of sh-soc3 and soc2
> 
> And now to the pull-requests:
> 
> ================================
> 1.
> 
> The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
> 
>   Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git sh-soc
> 
> for you to fetch changes up to 2cbf52318a995c09de88dc7c3067d387d7d9ffe8:
> 
>   sh: shx3: Fix last GPIO index (2013-01-07 14:44:46 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (7):
>       sh: sh7264: Rename CRX0CRX1 mark to match GPIO names
>       sh: sh7269: Rename CRX0CRX1(CRX2) marks to match GPIO names
>       sh: sh7723: Rename GPIO_FN_SIUOSPD to GPIO_FN_SIUAOSPD
>       sh: sh7757: Fix GPIO_FN_ET0_MDIO and GPIO_FN_ET1_MDIO GPIO entries
>       sh: sh7786: Fix port E, G and J GPIOs
>       sh: sh7786: Fix last GPIO index
>       sh: shx3: Fix last GPIO index
> 
>  arch/sh/include/cpu-sh4/cpu/sh7723.h    |    2 +-
>  arch/sh/include/cpu-sh4/cpu/sh7786.h    |    8 +++-----
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c |    6 +++---
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c |   12 ++++++------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c |    2 +-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c |    4 ++--
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c |    6 +++---
>  arch/sh/kernel/cpu/sh4a/pinmux-shx3.c   |    2 +-
>  8 files changed, 20 insertions(+), 22 deletions(-)
> 
> ================================
> 2.
> 
> The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
> 
>   Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git clocksource
> 
> for you to fetch changes up to 892a45dbe32eb565c07d08085e694985e6fbaf26:
> 
>   ARM: clocksource: Initialise early (2013-01-16 14:55:11 +0900)
> 
> ----------------------------------------------------------------
> Simon Horman (1):
>       ARM: clocksource: Initialise early
> 
>  drivers/Makefile |    8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> ================================
> 3.
> 
> The following changes since commit 2cbf52318a995c09de88dc7c3067d387d7d9ffe8:
> 
>   sh: shx3: Fix last GPIO index (2013-01-07 14:44:46 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git pfc
> 
> for you to fetch changes up to 3951da29e5981e3441fdd79a9363fd1af739374b:
> 
>   sh-pfc: Support passing resources through platform device (2013-01-07 14:47:55 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (14):
>       sh-pfc: Remove all use of __devinit/__devexit
>       sh-pfc: Split platform data from the sh_pfc structure
>       sh-pfc: Move private definitions and declarations to private header
>       sh-pfc: Merge PFC core and pinctrl
>       sh-pfc: Merge PFC core and gpio
>       sh-pfc: Move platform device and driver to the core
>       sh-pfc: Use devm_kzalloc()
>       sh-pfc: Use devm_ioremap_nocache()
>       sh-pfc: Let the compiler decide whether to inline functions
>       sh-pfc: Remove check for impossible error condition
>       sh-pfc: Sort headers alphabetically
>       sh-pfc: Use sh_pfc_ namespace prefix through the whole driver
>       sh-pfc: Split platform device and platform driver registration
>       sh-pfc: Support passing resources through platform device
> 
>  drivers/sh/pfc/Kconfig   |   12 +-
>  drivers/sh/pfc/Makefile  |    8 +-
>  drivers/sh/pfc/core.c    |  327 +++++++++++++++++++++++++---------------------
>  drivers/sh/pfc/core.h    |   54 ++++++++
>  drivers/sh/pfc/gpio.c    |  113 ++++------------
>  drivers/sh/pfc/pinctrl.c |  171 ++++++++----------------
>  include/linux/sh_pfc.h   |   35 +----
>  7 files changed, 326 insertions(+), 394 deletions(-)
>  create mode 100644 drivers/sh/pfc/core.h
> 
> ================================
> 4.
> 
> The following changes since commit 3951da29e5981e3441fdd79a9363fd1af739374b:
> 
>   sh-pfc: Support passing resources through platform device (2013-01-07 14:47:55 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git sh-soc2
> 
> for you to fetch changes up to 85a76791fa8c2f1e5467557c52fcbfaff90db586:
> 
>   sh: shx3: Register PFC platform device (2013-01-07 14:50:54 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (13):
>       sh: Add PFC platform device registration helper function
>       sh: sh7203: Register PFC platform device
>       sh: sh7264: Register PFC platform device
>       sh: sh7269: Register PFC platform device
>       sh: sh7720: Register PFC platform device
>       sh: sh7722: Register PFC platform device
>       sh: sh7723: Register PFC platform device
>       sh: sh7724: Register PFC platform device
>       sh: sh7734: Register PFC platform device
>       sh: sh7757: Register PFC platform device
>       sh: sh7785: Register PFC platform device
>       sh: sh7786: Register PFC platform device
>       sh: shx3: Register PFC platform device
> 
>  arch/sh/Kconfig                         |   12 +++++++++
>  arch/sh/include/cpu-common/cpu/pfc.h    |   30 +++++++++++++++++++++
>  arch/sh/kernel/cpu/Makefile             |    2 +-
>  arch/sh/kernel/cpu/pfc.c                |   44 +++++++++++++++++++++++++++++++
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7203.c |    3 ++-
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c |    3 ++-
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c |    3 ++-
>  arch/sh/kernel/cpu/sh3/pinmux-sh7720.c  |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7722.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7724.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7734.c |    8 +++---
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7785.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-shx3.c   |    3 ++-
>  16 files changed, 113 insertions(+), 16 deletions(-)
>  create mode 100644 arch/sh/include/cpu-common/cpu/pfc.h
>  create mode 100644 arch/sh/kernel/cpu/pfc.c
> 
> ================================
> 5.
> 
> The following changes since commit 3951da29e5981e3441fdd79a9363fd1af739374b:
> 
>   sh-pfc: Support passing resources through platform device (2013-01-07 14:47:55 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git soc
> 
> for you to fetch changes up to 54689817eb3476be410b42a9ce2bff82037b4334:
> 
>   ARM: SH-Mobile: sh73a0: Add CPU Hotplug (2013-01-16 14:16:25 +0900)
> 
> ----------------------------------------------------------------
> Bastian Hecht (4):
>       ARM: shmobile: sh73a0: Add CPU sleep suspend
>       ARM: shmobile: r8a7740: Add CPU sleep suspend
>       ARM: SH-Mobile: sh73a0: Secondary CPUs handle own SCU flags
>       ARM: SH-Mobile: sh73a0: Add CPU Hotplug
> 
> Guennadi Liakhovetski (3):
>       ARM: sh7372: add clock lookup entries for DT-based devices
>       ARM: sh7372: fix cache clean / invalidate order
>       ARM: shmobile: add function declarations for sh7372 DT helper functions
> 
> Kuninori Morimoto (2):
>       ARM: shmobile: r8a7740: add TMU timer support
>       ARM: shmobile: sh73a0: fixup div4_clks bitmap
> 
> Laurent Pinchart (8):
>       ARM: shmobile: Select PINCTRL
>       ARM: shmobile: r8a7740: Register PFC platform device
>       ARM: shmobile: r8a7779: Register PFC platform device
>       ARM: shmobile: sh7372: Register PFC platform device
>       ARM: shmobile: sh73a0: Register PFC platform device
>       ARM: shmobile: r8a7740: Add pin control resources
>       ARM: shmobile: sh7372: Add pin control resources
>       ARM: shmobile: sh73a0: Add pin control resources
> 
> Magnus Damm (1):
>       ARM: mach-shmobile: sh73a0 external IRQ wake update
> 
> Simon Horman (4):
>       ARM: shmobile: Remove duplicate inclusion of dma-mapping.h in setup-r8a7740.c
>       ARM: mach-shmobile: sh73a0: Allow initialisation of GIC by DT
>       ARM: mach-shmobile: sh73a0: Minimal setup using DT
>       ARM: mach-shmobile: sh73a0: Initialise MMCIF using DT
> 
>  arch/arm/Kconfig                               |    1 +
>  arch/arm/boot/dts/sh73a0-reference.dtsi        |   24 ++++++
>  arch/arm/boot/dts/sh73a0.dtsi                  |   93 +++++++++++++++++++++++
>  arch/arm/mach-shmobile/Makefile                |    3 +-
>  arch/arm/mach-shmobile/board-armadillo800eva.c |    2 +
>  arch/arm/mach-shmobile/board-kzm9g.c           |    2 +
>  arch/arm/mach-shmobile/clock-r8a7740.c         |    6 +-
>  arch/arm/mach-shmobile/clock-sh7372.c          |    9 +++
>  arch/arm/mach-shmobile/clock-sh73a0.c          |   35 ++++++---
>  arch/arm/mach-shmobile/headsmp-sh73a0.S        |   50 +++++++++++++
>  arch/arm/mach-shmobile/include/mach/common.h   |    8 ++
>  arch/arm/mach-shmobile/intc-sh73a0.c           |   21 ++++--
>  arch/arm/mach-shmobile/pfc-r8a7740.c           |   28 ++++++-
>  arch/arm/mach-shmobile/pfc-r8a7779.c           |   16 +++-
>  arch/arm/mach-shmobile/pfc-sh7372.c            |   28 ++++++-
>  arch/arm/mach-shmobile/pfc-sh73a0.c            |   28 ++++++-
>  arch/arm/mach-shmobile/pm-r8a7740.c            |   22 ++++++
>  arch/arm/mach-shmobile/pm-sh73a0.c             |   32 ++++++++
>  arch/arm/mach-shmobile/setup-r8a7740.c         |   95 +++++++++++++++++++++++-
>  arch/arm/mach-shmobile/setup-sh73a0.c          |   64 +++++++++++++++-
>  arch/arm/mach-shmobile/sleep-sh7372.S          |   12 +--
>  arch/arm/mach-shmobile/smp-sh73a0.c            |   66 ++++++++--------
>  22 files changed, 580 insertions(+), 65 deletions(-)
>  create mode 100644 arch/arm/boot/dts/sh73a0-reference.dtsi
>  create mode 100644 arch/arm/boot/dts/sh73a0.dtsi
>  create mode 100644 arch/arm/mach-shmobile/headsmp-sh73a0.S
>  create mode 100644 arch/arm/mach-shmobile/pm-sh73a0.c
> 
> ================================
> 6.
> 
> The following changes since commit b7e481b082bf48707020bef270aa726b96d7b4be:
> 
>   Merge branches 'soc' and 'clocksource', remote-tracking branch 'arm-soc/timer/cleanup' into boards (2013-01-16 15:27:26 +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 2b88c35a7ddd49301eb73a4660e012bba61a3504:
> 
>   ARM: mach-shmobile: kzm9g: Reference DT implementation (2013-01-16 15:27:41 +0900)
> 
> ----------------------------------------------------------------
> Guennadi Liakhovetski (1):
>       ARM: mackerel: include the correct .dtsi file
> 
> Kuninori Morimoto (3):
>       ARM: shmobile: fix sample amixer settings for mackerel
>       ARM: shmobile: add sample amixer settings for ap4evb
>       ARM: shmobile: add sample amixer settings for armadillo800eva
> 
> Laurent Pinchart (2):
>       ARM: shmobile: kzm9g: Use of_machine_is_compatible()
>       ARM: shmobile: Include sh73a0 DTSI in kzm9g
> 
> Nobuhiro Iwamatsu (1):
>       ARM: shmobile: Include DTSI of r8a7740 to armadillo800eva
> 
> Simon Horman (1):
>       ARM: mach-shmobile: kzm9g: Reference DT implementation
> 
>  arch/arm/boot/dts/Makefile                     |    1 +
>  arch/arm/boot/dts/r8a7740-armadillo800eva.dts  |    2 +-
>  arch/arm/boot/dts/sh7372-mackerel.dts          |    2 +-
>  arch/arm/boot/dts/sh73a0-kzm9g-reference.dts   |   37 +++++++++
>  arch/arm/boot/dts/sh73a0-kzm9g.dts             |    2 +-
>  arch/arm/mach-shmobile/Kconfig                 |   10 +++
>  arch/arm/mach-shmobile/Makefile                |    1 +
>  arch/arm/mach-shmobile/board-ap4evb.c          |    4 +
>  arch/arm/mach-shmobile/board-armadillo800eva.c |    8 ++
>  arch/arm/mach-shmobile/board-kzm9g-reference.c |   99 ++++++++++++++++++++++++
>  arch/arm/mach-shmobile/board-kzm9g.c           |    2 +-
>  arch/arm/mach-shmobile/board-mackerel.c        |    4 +-
>  12 files changed, 165 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
>  create mode 100644 arch/arm/mach-shmobile/board-kzm9g-reference.c
> 
> ================================
> 7.
> 
> The following changes since commit e35442480c27092fd7c5ecd987a225bab448d031:
> 
>   Merge branches 'soc' and 'sh-soc2' into pfc2 (2013-01-16 14:33:26 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git pfc2
> 
> for you to fetch changes up to 5800cb822fbda9378fd8eb8cfd19369b5833bd34:
> 
>   sh-pfc: Add shx3 pinmux support (2013-01-16 14:34:00 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (20):
>       sh-pfc: Remove platform device registration
>       sh-pfc: Remove unused resource and num_resources platform data fields
>       sh-pfc: Move driver from drivers/sh/ to drivers/pinctrl/
>       sh-pfc: Support pinmux info in driver data instead of platform data
>       sh-pfc: Add r8a7740 pinmux support
>       sh-pfc: Add r8a7779 pinmux support
>       sh-pfc: Add sh7372 pinmux support
>       sh-pfc: Add sh73a0 pinmux support
>       sh-pfc: Add sh7203 pinmux support
>       sh-pfc: Add sh7264 pinmux support
>       sh-pfc: Add sh7269 pinmux support
>       sh-pfc: Add sh7720 pinmux support
>       sh-pfc: Add sh7722 pinmux support
>       sh-pfc: Add sh7723 pinmux support
>       sh-pfc: Add sh7724 pinmux support
>       sh-pfc: Add sh7734 pinmux support
>       sh-pfc: Add sh7757 pinmux support
>       sh-pfc: Add sh7785 pinmux support
>       sh-pfc: Add sh7786 pinmux support
>       sh-pfc: Add shx3 pinmux support
> 
>  drivers/pinctrl/Kconfig                      |    2 +-
>  drivers/pinctrl/Makefile                     |    2 +
>  drivers/pinctrl/sh-pfc/Kconfig               |  116 ++
>  drivers/pinctrl/sh-pfc/Makefile              |   21 +
>  drivers/{sh/pfc => pinctrl/sh-pfc}/core.c    |  129 +-
>  drivers/{sh/pfc => pinctrl/sh-pfc}/core.h    |   19 +-
>  drivers/{sh/pfc => pinctrl/sh-pfc}/gpio.c    |   18 +-
>  drivers/pinctrl/sh-pfc/pfc-r8a7740.c         | 2611 ++++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-r8a7779.c         | 2623 ++++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7203.c          | 1591 +++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7264.c          | 2130 +++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7269.c          | 2833 ++++++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7372.c          | 1657 +++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh73a0.c          | 2797 +++++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7720.c          | 1235 +++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7722.c          | 1778 ++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7723.c          | 1902 +++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7724.c          | 2224 ++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7734.c          | 2474 ++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7757.c          | 2281 +++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7785.c          | 1303 ++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7786.c          |  836 ++++++++
>  drivers/pinctrl/sh-pfc/pfc-shx3.c            |  581 ++++++
>  drivers/{sh/pfc => pinctrl/sh-pfc}/pinctrl.c |   28 +-
>  drivers/sh/Kconfig                           |    1 -
>  drivers/sh/Makefile                          |    1 -
>  drivers/sh/pfc/Kconfig                       |   18 -
>  drivers/sh/pfc/Makefile                      |    5 -
>  include/linux/sh_pfc.h                       |   17 +-
>  29 files changed, 31118 insertions(+), 115 deletions(-)
>  create mode 100644 drivers/pinctrl/sh-pfc/Kconfig
>  create mode 100644 drivers/pinctrl/sh-pfc/Makefile
>  rename drivers/{sh/pfc => pinctrl/sh-pfc}/core.c (79%)
>  rename drivers/{sh/pfc => pinctrl/sh-pfc}/core.h (63%)
>  rename drivers/{sh/pfc => pinctrl/sh-pfc}/gpio.c (89%)
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7740.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7779.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7203.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7264.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7269.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7372.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh73a0.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7720.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7722.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7723.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7724.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7734.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7757.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7785.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7786.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-shx3.c
>  rename drivers/{sh/pfc => pinctrl/sh-pfc}/pinctrl.c (93%)
>  delete mode 100644 drivers/sh/pfc/Kconfig
>  delete mode 100644 drivers/sh/pfc/Makefile
> 
> ================================
> 8.
> 
> The following changes since commit 5800cb822fbda9378fd8eb8cfd19369b5833bd34:
> 
>   sh-pfc: Add shx3 pinmux support (2013-01-16 14:34:00 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git sh-soc3
> 
> for you to fetch changes up to 09b276b8c3a590839d3dd199c7116ff5f8fe36e6:
> 
>   sh: shx3: pinmux: Use driver-provided pinmux info (2013-01-16 14:42:19 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (12):
>       sh: sh7203: pinmux: Use driver-provided pinmux info
>       sh: sh7264: pinmux: Use driver-provided pinmux info
>       sh: sh7269: pinmux: Use driver-provided pinmux info
>       sh: sh7720: pinmux: Use driver-provided pinmux info
>       sh: sh7722: pinmux: Use driver-provided pinmux info
>       sh: sh7723: pinmux: Use driver-provided pinmux info
>       sh: sh7724: pinmux: Use driver-provided pinmux info
>       sh: sh7734: pinmux: Use driver-provided pinmux info
>       sh: sh7757: pinmux: Use driver-provided pinmux info
>       sh: sh7785: pinmux: Use driver-provided pinmux info
>       sh: sh7786: pinmux: Use driver-provided pinmux info
>       sh: shx3: pinmux: Use driver-provided pinmux info
> 
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7203.c | 1581 +----------------
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c | 2120 +----------------------
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c | 2822 +------------------------------
>  arch/sh/kernel/cpu/sh3/pinmux-sh7720.c  | 1225 +-------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7722.c | 1777 +------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c | 1892 +--------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7724.c | 2209 +-----------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7734.c | 2468 +--------------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c | 2266 +------------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7785.c | 1293 +-------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c |  821 +--------
>  arch/sh/kernel/cpu/sh4a/pinmux-shx3.c   |  572 +------
>  12 files changed, 14 insertions(+), 21032 deletions(-)
> 
> ================================
> 9.
> 
> The following changes since commit c1857e7b2da094b23db24e0829565264d3ba888d:
> 
>   Merge branch 'pfc2', remote-tracking branch 'arm-soc/timer/cleanup' into soc2 (2013-01-16 14:35:00 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git soc2
> 
> for you to fetch changes up to ed68adfe853db33aad6a294702396736ba220af6:
> 
>   ARM: shmobile: sh73a0: Use driver-provided pinmux info (2013-01-16 14:38:47 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (4):
>       ARM: shmobile: r8a7740: Use driver-provided pinmux info
>       ARM: shmobile: r8a7779: Use driver-provided pinmux info
>       ARM: shmobile: sh7372: Use driver-provided pinmux info
>       ARM: shmobile: sh73a0: Use driver-provided pinmux info
> 
>  arch/arm/mach-shmobile/Makefile        |    8 -
>  arch/arm/mach-shmobile/pfc-r8a7740.c   | 2643 -----------------------------
>  arch/arm/mach-shmobile/pfc-r8a7779.c   | 2653 ------------------------------
>  arch/arm/mach-shmobile/pfc-sh7372.c    | 1689 -------------------
>  arch/arm/mach-shmobile/pfc-sh73a0.c    | 2829 --------------------------------
>  arch/arm/mach-shmobile/setup-r8a7740.c |   26 +
>  arch/arm/mach-shmobile/setup-r8a7779.c |   25 +
>  arch/arm/mach-shmobile/setup-sh7372.c  |   26 +
>  arch/arm/mach-shmobile/setup-sh73a0.c  |   25 +
>  9 files changed, 102 insertions(+), 9822 deletions(-)
>  delete mode 100644 arch/arm/mach-shmobile/pfc-r8a7740.c
>  delete mode 100644 arch/arm/mach-shmobile/pfc-r8a7779.c
>  delete mode 100644 arch/arm/mach-shmobile/pfc-sh7372.c
>  delete mode 100644 arch/arm/mach-shmobile/pfc-sh73a0.c
> 
> ================================
> 10.
> 
> The following changes since commit 29ef16511e7645caa979b4db432bf30359fd3795:
> 
>   Merge branches 'soc2' and 'sh-soc3' into pfc3 (2013-01-16 14:42:55 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git pfc3
> 
> for you to fetch changes up to 52c59e03952165b9d462f7001095eb5b8808aed6:
> 
>   sh-pfc: Move sh_pfc.h from include/linux/ to driver directory (2013-01-16 14:43:06 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (3):
>       sh: Remove unused sh_pfc_register_info() function
>       sh-pfc: Remove pinmux_info definition
>       sh-pfc: Move sh_pfc.h from include/linux/ to driver directory
> 
>  arch/sh/include/asm/gpio.h                         |    2 +-
>  arch/sh/include/cpu-common/cpu/pfc.h               |    4 ----
>  arch/sh/kernel/cpu/pfc.c                           |   13 +------------
>  drivers/pinctrl/sh-pfc/core.c                      |    1 -
>  drivers/pinctrl/sh-pfc/core.h                      |    3 ++-
>  drivers/pinctrl/sh-pfc/gpio.c                      |    1 -
>  drivers/pinctrl/sh-pfc/pfc-r8a7740.c               |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-r8a7779.c               |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7203.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7264.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7269.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7372.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh73a0.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7720.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7722.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7723.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7724.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7734.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7757.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7785.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7786.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-shx3.c                  |    3 ++-
>  drivers/pinctrl/sh-pfc/pinctrl.c                   |    1 -
>  {include/linux => drivers/pinctrl/sh-pfc}/sh_pfc.h |    3 ---
>  24 files changed, 36 insertions(+), 40 deletions(-)
>  rename {include/linux => drivers/pinctrl/sh-pfc}/sh_pfc.h (98%)
> 
> ================================
> 

[GIT PULL] Renesas ARM-based SoC v3.9

[Simon Horman]

On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> I have some complex dependencies for mach-shmobile for v3.9
> and as such I am sending this email outline the dependencies
> of branches on each other. I have also included the multiple
> pull requests below though I am happy to post them
> individually including the patches they comprise if you
> have no objections to the way the branch dependencies are arranged.
> 
> I would also be happy to supply a single branch with all changes
> with or without merge commits.
> 
> All branches are present in the renesas tree
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git

Ping.

> 1. Branch: sh-soc
>    Description: Pre-requisites for pfc changes for SH SoCs
>    Based on: v3.8-rc1
> 
> 2. Branch: clocksource
>    Description: Pre-requisite clocksource change for soc branch
>    Based on: v3.8-rc1
> 
> 3. Branch: pfc
>    Description: PFC Updates
>    Based on: sh-soc
> 
> 4. Branch: sh-soc2
>    Description: Further PFC changes for SH SoCs
>    Based on: pfc
> 
> 5. Branch: soc
>    Description: shmobile (ARM) SoCs updates, including PFC changes.
>    Based on: a merge of clocksource and pfc
> 
> 6. Branch: boards
>    Description: Board changes, including PFC changes.
>    Based on: A merge of timer/cleanup (present in the arm-soc tree) and soc
> 
> 7. Branch: pfc2
>    Description: Further PFC changes which depend on SoC changes
>    Based on: A merge of sh-soc2 and soc
> 
> 8. Branch: sh-soc3
>    Description: Further PFC changes for SH SoCs
>    Based on: pfc2
> 
> 9. Branch: soc2
>    Description: Further PFC changes for shmobile (ARM) SoCs
>    Based on: A merge of timer/cleanup (present in the arm-soc tree) and pfc2
> 
> 10. Branch: pfc3
>     Description: Description: Further PFC changes which depend on SoC changes
>     Based on: A merge of sh-soc3 and soc2
> 
> And now to the pull-requests:
> 
> ================================================================
> 1.
> 
> The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
> 
>   Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git sh-soc
> 
> for you to fetch changes up to 2cbf52318a995c09de88dc7c3067d387d7d9ffe8:
> 
>   sh: shx3: Fix last GPIO index (2013-01-07 14:44:46 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (7):
>       sh: sh7264: Rename CRX0CRX1 mark to match GPIO names
>       sh: sh7269: Rename CRX0CRX1(CRX2) marks to match GPIO names
>       sh: sh7723: Rename GPIO_FN_SIUOSPD to GPIO_FN_SIUAOSPD
>       sh: sh7757: Fix GPIO_FN_ET0_MDIO and GPIO_FN_ET1_MDIO GPIO entries
>       sh: sh7786: Fix port E, G and J GPIOs
>       sh: sh7786: Fix last GPIO index
>       sh: shx3: Fix last GPIO index
> 
>  arch/sh/include/cpu-sh4/cpu/sh7723.h    |    2 +-
>  arch/sh/include/cpu-sh4/cpu/sh7786.h    |    8 +++-----
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c |    6 +++---
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c |   12 ++++++------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c |    2 +-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c |    4 ++--
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c |    6 +++---
>  arch/sh/kernel/cpu/sh4a/pinmux-shx3.c   |    2 +-
>  8 files changed, 20 insertions(+), 22 deletions(-)
> 
> ================================================================
> 2.
> 
> The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
> 
>   Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git clocksource
> 
> for you to fetch changes up to 892a45dbe32eb565c07d08085e694985e6fbaf26:
> 
>   ARM: clocksource: Initialise early (2013-01-16 14:55:11 +0900)
> 
> ----------------------------------------------------------------
> Simon Horman (1):
>       ARM: clocksource: Initialise early
> 
>  drivers/Makefile |    8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> ================================================================
> 3.
> 
> The following changes since commit 2cbf52318a995c09de88dc7c3067d387d7d9ffe8:
> 
>   sh: shx3: Fix last GPIO index (2013-01-07 14:44:46 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git pfc
> 
> for you to fetch changes up to 3951da29e5981e3441fdd79a9363fd1af739374b:
> 
>   sh-pfc: Support passing resources through platform device (2013-01-07 14:47:55 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (14):
>       sh-pfc: Remove all use of __devinit/__devexit
>       sh-pfc: Split platform data from the sh_pfc structure
>       sh-pfc: Move private definitions and declarations to private header
>       sh-pfc: Merge PFC core and pinctrl
>       sh-pfc: Merge PFC core and gpio
>       sh-pfc: Move platform device and driver to the core
>       sh-pfc: Use devm_kzalloc()
>       sh-pfc: Use devm_ioremap_nocache()
>       sh-pfc: Let the compiler decide whether to inline functions
>       sh-pfc: Remove check for impossible error condition
>       sh-pfc: Sort headers alphabetically
>       sh-pfc: Use sh_pfc_ namespace prefix through the whole driver
>       sh-pfc: Split platform device and platform driver registration
>       sh-pfc: Support passing resources through platform device
> 
>  drivers/sh/pfc/Kconfig   |   12 +-
>  drivers/sh/pfc/Makefile  |    8 +-
>  drivers/sh/pfc/core.c    |  327 +++++++++++++++++++++++++---------------------
>  drivers/sh/pfc/core.h    |   54 ++++++++
>  drivers/sh/pfc/gpio.c    |  113 ++++------------
>  drivers/sh/pfc/pinctrl.c |  171 ++++++++----------------
>  include/linux/sh_pfc.h   |   35 +----
>  7 files changed, 326 insertions(+), 394 deletions(-)
>  create mode 100644 drivers/sh/pfc/core.h
> 
> ================================================================
> 4.
> 
> The following changes since commit 3951da29e5981e3441fdd79a9363fd1af739374b:
> 
>   sh-pfc: Support passing resources through platform device (2013-01-07 14:47:55 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git sh-soc2
> 
> for you to fetch changes up to 85a76791fa8c2f1e5467557c52fcbfaff90db586:
> 
>   sh: shx3: Register PFC platform device (2013-01-07 14:50:54 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (13):
>       sh: Add PFC platform device registration helper function
>       sh: sh7203: Register PFC platform device
>       sh: sh7264: Register PFC platform device
>       sh: sh7269: Register PFC platform device
>       sh: sh7720: Register PFC platform device
>       sh: sh7722: Register PFC platform device
>       sh: sh7723: Register PFC platform device
>       sh: sh7724: Register PFC platform device
>       sh: sh7734: Register PFC platform device
>       sh: sh7757: Register PFC platform device
>       sh: sh7785: Register PFC platform device
>       sh: sh7786: Register PFC platform device
>       sh: shx3: Register PFC platform device
> 
>  arch/sh/Kconfig                         |   12 +++++++++
>  arch/sh/include/cpu-common/cpu/pfc.h    |   30 +++++++++++++++++++++
>  arch/sh/kernel/cpu/Makefile             |    2 +-
>  arch/sh/kernel/cpu/pfc.c                |   44 +++++++++++++++++++++++++++++++
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7203.c |    3 ++-
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c |    3 ++-
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c |    3 ++-
>  arch/sh/kernel/cpu/sh3/pinmux-sh7720.c  |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7722.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7724.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7734.c |    8 +++---
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7785.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c |    3 ++-
>  arch/sh/kernel/cpu/sh4a/pinmux-shx3.c   |    3 ++-
>  16 files changed, 113 insertions(+), 16 deletions(-)
>  create mode 100644 arch/sh/include/cpu-common/cpu/pfc.h
>  create mode 100644 arch/sh/kernel/cpu/pfc.c
> 
> ================================================================
> 5.
> 
> The following changes since commit 3951da29e5981e3441fdd79a9363fd1af739374b:
> 
>   sh-pfc: Support passing resources through platform device (2013-01-07 14:47:55 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git soc
> 
> for you to fetch changes up to 54689817eb3476be410b42a9ce2bff82037b4334:
> 
>   ARM: SH-Mobile: sh73a0: Add CPU Hotplug (2013-01-16 14:16:25 +0900)
> 
> ----------------------------------------------------------------
> Bastian Hecht (4):
>       ARM: shmobile: sh73a0: Add CPU sleep suspend
>       ARM: shmobile: r8a7740: Add CPU sleep suspend
>       ARM: SH-Mobile: sh73a0: Secondary CPUs handle own SCU flags
>       ARM: SH-Mobile: sh73a0: Add CPU Hotplug
> 
> Guennadi Liakhovetski (3):
>       ARM: sh7372: add clock lookup entries for DT-based devices
>       ARM: sh7372: fix cache clean / invalidate order
>       ARM: shmobile: add function declarations for sh7372 DT helper functions
> 
> Kuninori Morimoto (2):
>       ARM: shmobile: r8a7740: add TMU timer support
>       ARM: shmobile: sh73a0: fixup div4_clks bitmap
> 
> Laurent Pinchart (8):
>       ARM: shmobile: Select PINCTRL
>       ARM: shmobile: r8a7740: Register PFC platform device
>       ARM: shmobile: r8a7779: Register PFC platform device
>       ARM: shmobile: sh7372: Register PFC platform device
>       ARM: shmobile: sh73a0: Register PFC platform device
>       ARM: shmobile: r8a7740: Add pin control resources
>       ARM: shmobile: sh7372: Add pin control resources
>       ARM: shmobile: sh73a0: Add pin control resources
> 
> Magnus Damm (1):
>       ARM: mach-shmobile: sh73a0 external IRQ wake update
> 
> Simon Horman (4):
>       ARM: shmobile: Remove duplicate inclusion of dma-mapping.h in setup-r8a7740.c
>       ARM: mach-shmobile: sh73a0: Allow initialisation of GIC by DT
>       ARM: mach-shmobile: sh73a0: Minimal setup using DT
>       ARM: mach-shmobile: sh73a0: Initialise MMCIF using DT
> 
>  arch/arm/Kconfig                               |    1 +
>  arch/arm/boot/dts/sh73a0-reference.dtsi        |   24 ++++++
>  arch/arm/boot/dts/sh73a0.dtsi                  |   93 +++++++++++++++++++++++
>  arch/arm/mach-shmobile/Makefile                |    3 +-
>  arch/arm/mach-shmobile/board-armadillo800eva.c |    2 +
>  arch/arm/mach-shmobile/board-kzm9g.c           |    2 +
>  arch/arm/mach-shmobile/clock-r8a7740.c         |    6 +-
>  arch/arm/mach-shmobile/clock-sh7372.c          |    9 +++
>  arch/arm/mach-shmobile/clock-sh73a0.c          |   35 ++++++---
>  arch/arm/mach-shmobile/headsmp-sh73a0.S        |   50 +++++++++++++
>  arch/arm/mach-shmobile/include/mach/common.h   |    8 ++
>  arch/arm/mach-shmobile/intc-sh73a0.c           |   21 ++++--
>  arch/arm/mach-shmobile/pfc-r8a7740.c           |   28 ++++++-
>  arch/arm/mach-shmobile/pfc-r8a7779.c           |   16 +++-
>  arch/arm/mach-shmobile/pfc-sh7372.c            |   28 ++++++-
>  arch/arm/mach-shmobile/pfc-sh73a0.c            |   28 ++++++-
>  arch/arm/mach-shmobile/pm-r8a7740.c            |   22 ++++++
>  arch/arm/mach-shmobile/pm-sh73a0.c             |   32 ++++++++
>  arch/arm/mach-shmobile/setup-r8a7740.c         |   95 +++++++++++++++++++++++-
>  arch/arm/mach-shmobile/setup-sh73a0.c          |   64 +++++++++++++++-
>  arch/arm/mach-shmobile/sleep-sh7372.S          |   12 +--
>  arch/arm/mach-shmobile/smp-sh73a0.c            |   66 ++++++++--------
>  22 files changed, 580 insertions(+), 65 deletions(-)
>  create mode 100644 arch/arm/boot/dts/sh73a0-reference.dtsi
>  create mode 100644 arch/arm/boot/dts/sh73a0.dtsi
>  create mode 100644 arch/arm/mach-shmobile/headsmp-sh73a0.S
>  create mode 100644 arch/arm/mach-shmobile/pm-sh73a0.c
> 
> ================================================================
> 6.
> 
> The following changes since commit b7e481b082bf48707020bef270aa726b96d7b4be:
> 
>   Merge branches 'soc' and 'clocksource', remote-tracking branch 'arm-soc/timer/cleanup' into boards (2013-01-16 15:27:26 +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 2b88c35a7ddd49301eb73a4660e012bba61a3504:
> 
>   ARM: mach-shmobile: kzm9g: Reference DT implementation (2013-01-16 15:27:41 +0900)
> 
> ----------------------------------------------------------------
> Guennadi Liakhovetski (1):
>       ARM: mackerel: include the correct .dtsi file
> 
> Kuninori Morimoto (3):
>       ARM: shmobile: fix sample amixer settings for mackerel
>       ARM: shmobile: add sample amixer settings for ap4evb
>       ARM: shmobile: add sample amixer settings for armadillo800eva
> 
> Laurent Pinchart (2):
>       ARM: shmobile: kzm9g: Use of_machine_is_compatible()
>       ARM: shmobile: Include sh73a0 DTSI in kzm9g
> 
> Nobuhiro Iwamatsu (1):
>       ARM: shmobile: Include DTSI of r8a7740 to armadillo800eva
> 
> Simon Horman (1):
>       ARM: mach-shmobile: kzm9g: Reference DT implementation
> 
>  arch/arm/boot/dts/Makefile                     |    1 +
>  arch/arm/boot/dts/r8a7740-armadillo800eva.dts  |    2 +-
>  arch/arm/boot/dts/sh7372-mackerel.dts          |    2 +-
>  arch/arm/boot/dts/sh73a0-kzm9g-reference.dts   |   37 +++++++++
>  arch/arm/boot/dts/sh73a0-kzm9g.dts             |    2 +-
>  arch/arm/mach-shmobile/Kconfig                 |   10 +++
>  arch/arm/mach-shmobile/Makefile                |    1 +
>  arch/arm/mach-shmobile/board-ap4evb.c          |    4 +
>  arch/arm/mach-shmobile/board-armadillo800eva.c |    8 ++
>  arch/arm/mach-shmobile/board-kzm9g-reference.c |   99 ++++++++++++++++++++++++
>  arch/arm/mach-shmobile/board-kzm9g.c           |    2 +-
>  arch/arm/mach-shmobile/board-mackerel.c        |    4 +-
>  12 files changed, 165 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/boot/dts/sh73a0-kzm9g-reference.dts
>  create mode 100644 arch/arm/mach-shmobile/board-kzm9g-reference.c
> 
> ================================================================
> 7.
> 
> The following changes since commit e35442480c27092fd7c5ecd987a225bab448d031:
> 
>   Merge branches 'soc' and 'sh-soc2' into pfc2 (2013-01-16 14:33:26 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git pfc2
> 
> for you to fetch changes up to 5800cb822fbda9378fd8eb8cfd19369b5833bd34:
> 
>   sh-pfc: Add shx3 pinmux support (2013-01-16 14:34:00 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (20):
>       sh-pfc: Remove platform device registration
>       sh-pfc: Remove unused resource and num_resources platform data fields
>       sh-pfc: Move driver from drivers/sh/ to drivers/pinctrl/
>       sh-pfc: Support pinmux info in driver data instead of platform data
>       sh-pfc: Add r8a7740 pinmux support
>       sh-pfc: Add r8a7779 pinmux support
>       sh-pfc: Add sh7372 pinmux support
>       sh-pfc: Add sh73a0 pinmux support
>       sh-pfc: Add sh7203 pinmux support
>       sh-pfc: Add sh7264 pinmux support
>       sh-pfc: Add sh7269 pinmux support
>       sh-pfc: Add sh7720 pinmux support
>       sh-pfc: Add sh7722 pinmux support
>       sh-pfc: Add sh7723 pinmux support
>       sh-pfc: Add sh7724 pinmux support
>       sh-pfc: Add sh7734 pinmux support
>       sh-pfc: Add sh7757 pinmux support
>       sh-pfc: Add sh7785 pinmux support
>       sh-pfc: Add sh7786 pinmux support
>       sh-pfc: Add shx3 pinmux support
> 
>  drivers/pinctrl/Kconfig                      |    2 +-
>  drivers/pinctrl/Makefile                     |    2 +
>  drivers/pinctrl/sh-pfc/Kconfig               |  116 ++
>  drivers/pinctrl/sh-pfc/Makefile              |   21 +
>  drivers/{sh/pfc => pinctrl/sh-pfc}/core.c    |  129 +-
>  drivers/{sh/pfc => pinctrl/sh-pfc}/core.h    |   19 +-
>  drivers/{sh/pfc => pinctrl/sh-pfc}/gpio.c    |   18 +-
>  drivers/pinctrl/sh-pfc/pfc-r8a7740.c         | 2611 ++++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-r8a7779.c         | 2623 ++++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7203.c          | 1591 +++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7264.c          | 2130 +++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7269.c          | 2833 ++++++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7372.c          | 1657 +++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh73a0.c          | 2797 +++++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7720.c          | 1235 +++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7722.c          | 1778 ++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7723.c          | 1902 +++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7724.c          | 2224 ++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7734.c          | 2474 ++++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7757.c          | 2281 +++++++++++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7785.c          | 1303 ++++++++++++
>  drivers/pinctrl/sh-pfc/pfc-sh7786.c          |  836 ++++++++
>  drivers/pinctrl/sh-pfc/pfc-shx3.c            |  581 ++++++
>  drivers/{sh/pfc => pinctrl/sh-pfc}/pinctrl.c |   28 +-
>  drivers/sh/Kconfig                           |    1 -
>  drivers/sh/Makefile                          |    1 -
>  drivers/sh/pfc/Kconfig                       |   18 -
>  drivers/sh/pfc/Makefile                      |    5 -
>  include/linux/sh_pfc.h                       |   17 +-
>  29 files changed, 31118 insertions(+), 115 deletions(-)
>  create mode 100644 drivers/pinctrl/sh-pfc/Kconfig
>  create mode 100644 drivers/pinctrl/sh-pfc/Makefile
>  rename drivers/{sh/pfc => pinctrl/sh-pfc}/core.c (79%)
>  rename drivers/{sh/pfc => pinctrl/sh-pfc}/core.h (63%)
>  rename drivers/{sh/pfc => pinctrl/sh-pfc}/gpio.c (89%)
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7740.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-r8a7779.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7203.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7264.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7269.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7372.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh73a0.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7720.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7722.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7723.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7724.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7734.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7757.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7785.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-sh7786.c
>  create mode 100644 drivers/pinctrl/sh-pfc/pfc-shx3.c
>  rename drivers/{sh/pfc => pinctrl/sh-pfc}/pinctrl.c (93%)
>  delete mode 100644 drivers/sh/pfc/Kconfig
>  delete mode 100644 drivers/sh/pfc/Makefile
> 
> ================================================================
> 8.
> 
> The following changes since commit 5800cb822fbda9378fd8eb8cfd19369b5833bd34:
> 
>   sh-pfc: Add shx3 pinmux support (2013-01-16 14:34:00 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git sh-soc3
> 
> for you to fetch changes up to 09b276b8c3a590839d3dd199c7116ff5f8fe36e6:
> 
>   sh: shx3: pinmux: Use driver-provided pinmux info (2013-01-16 14:42:19 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (12):
>       sh: sh7203: pinmux: Use driver-provided pinmux info
>       sh: sh7264: pinmux: Use driver-provided pinmux info
>       sh: sh7269: pinmux: Use driver-provided pinmux info
>       sh: sh7720: pinmux: Use driver-provided pinmux info
>       sh: sh7722: pinmux: Use driver-provided pinmux info
>       sh: sh7723: pinmux: Use driver-provided pinmux info
>       sh: sh7724: pinmux: Use driver-provided pinmux info
>       sh: sh7734: pinmux: Use driver-provided pinmux info
>       sh: sh7757: pinmux: Use driver-provided pinmux info
>       sh: sh7785: pinmux: Use driver-provided pinmux info
>       sh: sh7786: pinmux: Use driver-provided pinmux info
>       sh: shx3: pinmux: Use driver-provided pinmux info
> 
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7203.c | 1581 +----------------
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7264.c | 2120 +----------------------
>  arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c | 2822 +------------------------------
>  arch/sh/kernel/cpu/sh3/pinmux-sh7720.c  | 1225 +-------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7722.c | 1777 +------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7723.c | 1892 +--------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7724.c | 2209 +-----------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7734.c | 2468 +--------------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7757.c | 2266 +------------------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7785.c | 1293 +-------------
>  arch/sh/kernel/cpu/sh4a/pinmux-sh7786.c |  821 +--------
>  arch/sh/kernel/cpu/sh4a/pinmux-shx3.c   |  572 +------
>  12 files changed, 14 insertions(+), 21032 deletions(-)
> 
> ================================================================
> 9.
> 
> The following changes since commit c1857e7b2da094b23db24e0829565264d3ba888d:
> 
>   Merge branch 'pfc2', remote-tracking branch 'arm-soc/timer/cleanup' into soc2 (2013-01-16 14:35:00 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git soc2
> 
> for you to fetch changes up to ed68adfe853db33aad6a294702396736ba220af6:
> 
>   ARM: shmobile: sh73a0: Use driver-provided pinmux info (2013-01-16 14:38:47 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (4):
>       ARM: shmobile: r8a7740: Use driver-provided pinmux info
>       ARM: shmobile: r8a7779: Use driver-provided pinmux info
>       ARM: shmobile: sh7372: Use driver-provided pinmux info
>       ARM: shmobile: sh73a0: Use driver-provided pinmux info
> 
>  arch/arm/mach-shmobile/Makefile        |    8 -
>  arch/arm/mach-shmobile/pfc-r8a7740.c   | 2643 -----------------------------
>  arch/arm/mach-shmobile/pfc-r8a7779.c   | 2653 ------------------------------
>  arch/arm/mach-shmobile/pfc-sh7372.c    | 1689 -------------------
>  arch/arm/mach-shmobile/pfc-sh73a0.c    | 2829 --------------------------------
>  arch/arm/mach-shmobile/setup-r8a7740.c |   26 +
>  arch/arm/mach-shmobile/setup-r8a7779.c |   25 +
>  arch/arm/mach-shmobile/setup-sh7372.c  |   26 +
>  arch/arm/mach-shmobile/setup-sh73a0.c  |   25 +
>  9 files changed, 102 insertions(+), 9822 deletions(-)
>  delete mode 100644 arch/arm/mach-shmobile/pfc-r8a7740.c
>  delete mode 100644 arch/arm/mach-shmobile/pfc-r8a7779.c
>  delete mode 100644 arch/arm/mach-shmobile/pfc-sh7372.c
>  delete mode 100644 arch/arm/mach-shmobile/pfc-sh73a0.c
> 
> ================================================================
> 10.
> 
> The following changes since commit 29ef16511e7645caa979b4db432bf30359fd3795:
> 
>   Merge branches 'soc2' and 'sh-soc3' into pfc3 (2013-01-16 14:42:55 +0900)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git pfc3
> 
> for you to fetch changes up to 52c59e03952165b9d462f7001095eb5b8808aed6:
> 
>   sh-pfc: Move sh_pfc.h from include/linux/ to driver directory (2013-01-16 14:43:06 +0900)
> 
> ----------------------------------------------------------------
> Laurent Pinchart (3):
>       sh: Remove unused sh_pfc_register_info() function
>       sh-pfc: Remove pinmux_info definition
>       sh-pfc: Move sh_pfc.h from include/linux/ to driver directory
> 
>  arch/sh/include/asm/gpio.h                         |    2 +-
>  arch/sh/include/cpu-common/cpu/pfc.h               |    4 ----
>  arch/sh/kernel/cpu/pfc.c                           |   13 +------------
>  drivers/pinctrl/sh-pfc/core.c                      |    1 -
>  drivers/pinctrl/sh-pfc/core.h                      |    3 ++-
>  drivers/pinctrl/sh-pfc/gpio.c                      |    1 -
>  drivers/pinctrl/sh-pfc/pfc-r8a7740.c               |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-r8a7779.c               |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7203.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7264.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7269.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7372.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh73a0.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7720.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7722.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7723.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7724.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7734.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7757.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7785.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-sh7786.c                |    3 ++-
>  drivers/pinctrl/sh-pfc/pfc-shx3.c                  |    3 ++-
>  drivers/pinctrl/sh-pfc/pinctrl.c                   |    1 -
>  {include/linux => drivers/pinctrl/sh-pfc}/sh_pfc.h |    3 ---
>  24 files changed, 36 insertions(+), 40 deletions(-)
>  rename {include/linux => drivers/pinctrl/sh-pfc}/sh_pfc.h (98%)
> 
> ================================================================
> 

Re: [GIT PULL] Renesas ARM-based SoC v3.9

[Olof Johansson]

On Sun, Jan 20, 2013 at 4:32 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
>> Hi Olof, Hi Arnd,
>>
>> I have some complex dependencies for mach-shmobile for v3.9
>> and as such I am sending this email outline the dependencies
>> of branches on each other. I have also included the multiple
>> pull requests below though I am happy to post them
>> individually including the patches they comprise if you
>> have no objections to the way the branch dependencies are arranged.
>>
>> I would also be happy to supply a single branch with all changes
>> with or without merge commits.
>>
>> All branches are present in the renesas tree
>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
>
> Ping.

I replied 4 days ago, did you not get that?


-Olof

[GIT PULL] Renesas ARM-based SoC v3.9

[Olof Johansson]

On Sun, Jan 20, 2013 at 4:32 PM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
>> Hi Olof, Hi Arnd,
>>
>> I have some complex dependencies for mach-shmobile for v3.9
>> and as such I am sending this email outline the dependencies
>> of branches on each other. I have also included the multiple
>> pull requests below though I am happy to post them
>> individually including the patches they comprise if you
>> have no objections to the way the branch dependencies are arranged.
>>
>> I would also be happy to supply a single branch with all changes
>> with or without merge commits.
>>
>> All branches are present in the renesas tree
>> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
>
> Ping.

I replied 4 days ago, did you not get that?


-Olof

Re: [GIT PULL] Renesas ARM-based SoC v3.9

[Laurent Pinchart]

Hi Olof,

On Wednesday 16 January 2013 15:43:10 Olof Johansson wrote:
> On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> > 
> > I have some complex dependencies for mach-shmobile for v3.9 and as such I
> > am sending this email outline the dependencies of branches on each other.
> > I have also included the multiple pull requests below though I am happy to
> > post them individually including the patches they comprise if you have no
> > objections to the way the branch dependencies are arranged.
> > 
> > I would also be happy to supply a single branch with all changes with or
> > without merge commits.
> 
> Hmm, complex indeed.
> 
> Is there any way to avoid this sequence of ARM -> sh/pinctrl -> ARM ->
> sh/pinctrl dependencies? That's what really makes things look complicated
> here. If you could move the final cleanup/code removal pieces out of
> the sh/pinctrl branches such that you have a less iterative chain of:
> 
> sh/pinctrl -> ARM -> final sh/pinctrl cleanup (removal of struct members,
> etc)
> 
> ... but I haven't looked in detail at the per-patch dependencies to see how
> tough that would be to arrange.
> 
> > All branches are present in the renesas tree
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> > 
> > 1. Branch: sh-soc
> > 
> >    Description: Pre-requisites for pfc changes for SH SoCs
> >    Based on: v3.8-rc1
> > 
> > 2. Branch: clocksource
> > 
> >    Description: Pre-requisite clocksource change for soc branch
> >    Based on: v3.8-rc1
> > 
> > 3. Branch: pfc
> > 
> >    Description: PFC Updates
> >    Based on: sh-soc
> > 
> > 4. Branch: sh-soc2
> > 
> >    Description: Further PFC changes for SH SoCs
> >    Based on: pfc
> > 
> > 5. Branch: soc
> > 
> >    Description: shmobile (ARM) SoCs updates, including PFC changes.
> >    Based on: a merge of clocksource and pfc
> > 
> > 6. Branch: boards
> > 
> >    Description: Board changes, including PFC changes.
> >    Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> >    soc
> > 
> > 7. Branch: pfc2
> > 
> >    Description: Further PFC changes which depend on SoC changes
> >    Based on: A merge of sh-soc2 and soc
> > 
> > 8. Branch: sh-soc3
> > 
> >    Description: Further PFC changes for SH SoCs
> >    Based on: pfc2
> > 
> > 9. Branch: soc2
> > 
> >    Description: Further PFC changes for shmobile (ARM) SoCs
> >    Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> >    pfc2
> > 
> > 10. Branch: pfc3
> > 
> >     Description: Description: Further PFC changes which depend on SoC
> >     changes
> >     Based on: A merge of sh-soc3 and soc2
> 
> Looking at it from the end here, 10 contains only arch/sh and global
> changes, and depends on 8 and 9. 8 also contains only sh changes. So it
> looks like 8 and 10 could be pruned from this pull request and go through
> either SH or pinctrl.
> 
> What pieces from branch 7 are stronly needed? A couple of the added pinctrl
> modules are used by mach-shmobile boards, it seems. And the structure rename
> might also be needed.

7 prepares for the move of PFC data from board code to drivers/. The branch 
mostly adds a pinctrl module for each of the supported SoCs, to allow later 
removal of PFC data from board code (in branches 8 and 9).

> Not having to pull in the bulk of 7, 8 and 10 would make a pretty big
> difference.

One way or the other all patches will need to be pulled. If they go through 
multiple trees we'll have to synchronize the multiple pull requests during the 
merge window, which looks pretty error-prone to me (but I might be wrong on 
this).

Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline, 
then push 7 through the pinctrl tree, wait until it reaches mainline, push 8 
through the SH tree and 9 through the ARM tree, wait until they reach 
mainline, and finally push 10 through the pinctrl tree again. We could even 
push each branch through the tree it belongs to, but I doubt we'll be able to 
push everything during a single merge window.

I might be able to move 1 after 7, in which case we would have a single branch 
that would combine both and touch pinctrl only. The other dependencies seem 
pretty difficult to avoid.

What are the main issues with merging the branches in their current state (or 
possibly with 5 and 6 moved aside) through the ARM tree ?

> For branch 2 (clocksource include order), I'd like to see an ack from John
> or Thomas. Does it really make sense to base that on an ifdef instead of
> always initialize early?
> 
> Branch 4 seems to be mostly sh-specific updates. With some of the later
> dependencies avoided, maybe this branch can be dropped too, not sure?

4 moves platform device registration from the sh-pfc module to board code. 
Later pinctrl patches then remove platform device registration from the sh-pfc 
module completely and continue with the rework of the sh-pfc code. 7 thus 
strongly depends on 4.

> About half of branch 5 looks like it's generic SoC-updates unrelated
> to the pinctrl rework, and branch 6 looks like mostly regular
> patches/updates, is that stronly dependent on all the pinctrl
> rework? Doesn't look like it should be?

You're right here. The non-pinctrl patches in 5 could go through a separate 
branch, they shouldn't depend on the pinctrl rework. 6 also has no dependency 
on the pinctrl rework.

-- 
Regards,

Laurent Pinchart

[GIT PULL] Renesas ARM-based SoC v3.9

[Laurent Pinchart]

Hi Olof,

On Wednesday 16 January 2013 15:43:10 Olof Johansson wrote:
> On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> > Hi Olof, Hi Arnd,
> > 
> > I have some complex dependencies for mach-shmobile for v3.9 and as such I
> > am sending this email outline the dependencies of branches on each other.
> > I have also included the multiple pull requests below though I am happy to
> > post them individually including the patches they comprise if you have no
> > objections to the way the branch dependencies are arranged.
> > 
> > I would also be happy to supply a single branch with all changes with or
> > without merge commits.
> 
> Hmm, complex indeed.
> 
> Is there any way to avoid this sequence of ARM -> sh/pinctrl -> ARM ->
> sh/pinctrl dependencies? That's what really makes things look complicated
> here. If you could move the final cleanup/code removal pieces out of
> the sh/pinctrl branches such that you have a less iterative chain of:
> 
> sh/pinctrl -> ARM -> final sh/pinctrl cleanup (removal of struct members,
> etc)
> 
> ... but I haven't looked in detail at the per-patch dependencies to see how
> tough that would be to arrange.
> 
> > All branches are present in the renesas tree
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> > 
> > 1. Branch: sh-soc
> > 
> >    Description: Pre-requisites for pfc changes for SH SoCs
> >    Based on: v3.8-rc1
> > 
> > 2. Branch: clocksource
> > 
> >    Description: Pre-requisite clocksource change for soc branch
> >    Based on: v3.8-rc1
> > 
> > 3. Branch: pfc
> > 
> >    Description: PFC Updates
> >    Based on: sh-soc
> > 
> > 4. Branch: sh-soc2
> > 
> >    Description: Further PFC changes for SH SoCs
> >    Based on: pfc
> > 
> > 5. Branch: soc
> > 
> >    Description: shmobile (ARM) SoCs updates, including PFC changes.
> >    Based on: a merge of clocksource and pfc
> > 
> > 6. Branch: boards
> > 
> >    Description: Board changes, including PFC changes.
> >    Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> >    soc
> > 
> > 7. Branch: pfc2
> > 
> >    Description: Further PFC changes which depend on SoC changes
> >    Based on: A merge of sh-soc2 and soc
> > 
> > 8. Branch: sh-soc3
> > 
> >    Description: Further PFC changes for SH SoCs
> >    Based on: pfc2
> > 
> > 9. Branch: soc2
> > 
> >    Description: Further PFC changes for shmobile (ARM) SoCs
> >    Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> >    pfc2
> > 
> > 10. Branch: pfc3
> > 
> >     Description: Description: Further PFC changes which depend on SoC
> >     changes
> >     Based on: A merge of sh-soc3 and soc2
> 
> Looking at it from the end here, 10 contains only arch/sh and global
> changes, and depends on 8 and 9. 8 also contains only sh changes. So it
> looks like 8 and 10 could be pruned from this pull request and go through
> either SH or pinctrl.
> 
> What pieces from branch 7 are stronly needed? A couple of the added pinctrl
> modules are used by mach-shmobile boards, it seems. And the structure rename
> might also be needed.

7 prepares for the move of PFC data from board code to drivers/. The branch 
mostly adds a pinctrl module for each of the supported SoCs, to allow later 
removal of PFC data from board code (in branches 8 and 9).

> Not having to pull in the bulk of 7, 8 and 10 would make a pretty big
> difference.

One way or the other all patches will need to be pulled. If they go through 
multiple trees we'll have to synchronize the multiple pull requests during the 
merge window, which looks pretty error-prone to me (but I might be wrong on 
this).

Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline, 
then push 7 through the pinctrl tree, wait until it reaches mainline, push 8 
through the SH tree and 9 through the ARM tree, wait until they reach 
mainline, and finally push 10 through the pinctrl tree again. We could even 
push each branch through the tree it belongs to, but I doubt we'll be able to 
push everything during a single merge window.

I might be able to move 1 after 7, in which case we would have a single branch 
that would combine both and touch pinctrl only. The other dependencies seem 
pretty difficult to avoid.

What are the main issues with merging the branches in their current state (or 
possibly with 5 and 6 moved aside) through the ARM tree ?

> For branch 2 (clocksource include order), I'd like to see an ack from John
> or Thomas. Does it really make sense to base that on an ifdef instead of
> always initialize early?
> 
> Branch 4 seems to be mostly sh-specific updates. With some of the later
> dependencies avoided, maybe this branch can be dropped too, not sure?

4 moves platform device registration from the sh-pfc module to board code. 
Later pinctrl patches then remove platform device registration from the sh-pfc 
module completely and continue with the rework of the sh-pfc code. 7 thus 
strongly depends on 4.

> About half of branch 5 looks like it's generic SoC-updates unrelated
> to the pinctrl rework, and branch 6 looks like mostly regular
> patches/updates, is that stronly dependent on all the pinctrl
> rework? Doesn't look like it should be?

You're right here. The non-pinctrl patches in 5 could go through a separate 
branch, they shouldn't depend on the pinctrl rework. 6 also has no dependency 
on the pinctrl rework.

-- 
Regards,

Laurent Pinchart

Re: [GIT PULL] Renesas ARM-based SoC v3.9

[Olof Johansson]

On Mon, Jan 21, 2013 at 04:31:43PM +0100, Laurent Pinchart wrote:
> Hi Olof,
> 
> On Wednesday 16 January 2013 15:43:10 Olof Johansson wrote:
> > On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> > > Hi Olof, Hi Arnd,
> > > 
> > > I have some complex dependencies for mach-shmobile for v3.9 and as such I
> > > am sending this email outline the dependencies of branches on each other.
> > > I have also included the multiple pull requests below though I am happy to
> > > post them individually including the patches they comprise if you have no
> > > objections to the way the branch dependencies are arranged.
> > > 
> > > I would also be happy to supply a single branch with all changes with or
> > > without merge commits.
> > 
> > Hmm, complex indeed.
> > 
> > Is there any way to avoid this sequence of ARM -> sh/pinctrl -> ARM ->
> > sh/pinctrl dependencies? That's what really makes things look complicated
> > here. If you could move the final cleanup/code removal pieces out of
> > the sh/pinctrl branches such that you have a less iterative chain of:
> > 
> > sh/pinctrl -> ARM -> final sh/pinctrl cleanup (removal of struct members,
> > etc)
> > 
> > ... but I haven't looked in detail at the per-patch dependencies to see how
> > tough that would be to arrange.
> > 
> > > All branches are present in the renesas tree
> > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> > > 
> > > 1. Branch: sh-soc
> > > 
> > >    Description: Pre-requisites for pfc changes for SH SoCs
> > >    Based on: v3.8-rc1
> > > 
> > > 2. Branch: clocksource
> > > 
> > >    Description: Pre-requisite clocksource change for soc branch
> > >    Based on: v3.8-rc1
> > > 
> > > 3. Branch: pfc
> > > 
> > >    Description: PFC Updates
> > >    Based on: sh-soc
> > > 
> > > 4. Branch: sh-soc2
> > > 
> > >    Description: Further PFC changes for SH SoCs
> > >    Based on: pfc
> > > 
> > > 5. Branch: soc
> > > 
> > >    Description: shmobile (ARM) SoCs updates, including PFC changes.
> > >    Based on: a merge of clocksource and pfc
> > > 
> > > 6. Branch: boards
> > > 
> > >    Description: Board changes, including PFC changes.
> > >    Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> > >    soc
> > > 
> > > 7. Branch: pfc2
> > > 
> > >    Description: Further PFC changes which depend on SoC changes
> > >    Based on: A merge of sh-soc2 and soc
> > > 
> > > 8. Branch: sh-soc3
> > > 
> > >    Description: Further PFC changes for SH SoCs
> > >    Based on: pfc2
> > > 
> > > 9. Branch: soc2
> > > 
> > >    Description: Further PFC changes for shmobile (ARM) SoCs
> > >    Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> > >    pfc2
> > > 
> > > 10. Branch: pfc3
> > > 
> > >     Description: Description: Further PFC changes which depend on SoC
> > >     changes
> > >     Based on: A merge of sh-soc3 and soc2
> > 
> > Looking at it from the end here, 10 contains only arch/sh and global
> > changes, and depends on 8 and 9. 8 also contains only sh changes. So it
> > looks like 8 and 10 could be pruned from this pull request and go through
> > either SH or pinctrl.
> > 
> > What pieces from branch 7 are stronly needed? A couple of the added pinctrl
> > modules are used by mach-shmobile boards, it seems. And the structure rename
> > might also be needed.
> 
> 7 prepares for the move of PFC data from board code to drivers/. The branch 
> mostly adds a pinctrl module for each of the supported SoCs, to allow later 
> removal of PFC data from board code (in branches 8 and 9).
> 
> > Not having to pull in the bulk of 7, 8 and 10 would make a pretty big
> > difference.
> 
> One way or the other all patches will need to be pulled. If they go through 
> multiple trees we'll have to synchronize the multiple pull requests during the 
> merge window, which looks pretty error-prone to me (but I might be wrong on 
> this).
> 
> Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline, 
> then push 7 through the pinctrl tree, wait until it reaches mainline, push 8 
> through the SH tree and 9 through the ARM tree, wait until they reach 
> mainline, and finally push 10 through the pinctrl tree again. We could even 
> push each branch through the tree it belongs to, but I doubt we'll be able to 
> push everything during a single merge window.
> 
> I might be able to move 1 after 7, in which case we would have a single branch 
> that would combine both and touch pinctrl only. The other dependencies seem 
> pretty difficult to avoid.
> 
> What are the main issues with merging the branches in their current state (or 
> possibly with 5 and 6 moved aside) through the ARM tree ?

Ah, ok -- you're suggesting bringing it _all_ in through arm-soc. We
can do so, I was of the initial impression from Simon's cover letter
that the arch/sh branches would also go through the SH tree.

This seems to be a particularly hairy conversion, given that it touches two
architectures that need to be updated in lockstep. I guess we might be just as
well off pulling it in as-is (with below exceptions) to get it in.

If you need the same contents in the SH tree due to dependencies and
later development, let me know and we can agree on a stable branch that
we both pick up in either tree that has all contents.

> > For branch 2 (clocksource include order), I'd like to see an ack from John
> > or Thomas. Does it really make sense to base that on an ifdef instead of
> > always initialize early?
> > 
> > Branch 4 seems to be mostly sh-specific updates. With some of the later
> > dependencies avoided, maybe this branch can be dropped too, not sure?
> 
> 4 moves platform device registration from the sh-pfc module to board code. 
> Later pinctrl patches then remove platform device registration from the sh-pfc 
> module completely and continue with the rework of the sh-pfc code. 7 thus 
> strongly depends on 4.

Ok.

> > About half of branch 5 looks like it's generic SoC-updates unrelated
> > to the pinctrl rework, and branch 6 looks like mostly regular
> > patches/updates, is that stronly dependent on all the pinctrl
> > rework? Doesn't look like it should be?
> 
> You're right here. The non-pinctrl patches in 5 could go through a separate 
> branch, they shouldn't depend on the pinctrl rework. 6 also has no dependency 
> on the pinctrl rework.

Simon, based on the above, would you mind splitting off the non-pinctrl updates
to separate branches?

I'll likely pick this up as a standalone branch, and not try to fit it into the
usual arm-soc categories, so feel free to use the pinctrl branch contents as
a base for the other branches if you have to, but maybe you can avoid it
alltogether if there aren't any substantial conflicts between the pinctrl
restructuring and the other patches mentioned above.


-Olof

[GIT PULL] Renesas ARM-based SoC v3.9

[Olof Johansson]

On Mon, Jan 21, 2013 at 04:31:43PM +0100, Laurent Pinchart wrote:
> Hi Olof,
> 
> On Wednesday 16 January 2013 15:43:10 Olof Johansson wrote:
> > On Wed, Jan 16, 2013 at 03:37:53PM +0900, Simon Horman wrote:
> > > Hi Olof, Hi Arnd,
> > > 
> > > I have some complex dependencies for mach-shmobile for v3.9 and as such I
> > > am sending this email outline the dependencies of branches on each other.
> > > I have also included the multiple pull requests below though I am happy to
> > > post them individually including the patches they comprise if you have no
> > > objections to the way the branch dependencies are arranged.
> > > 
> > > I would also be happy to supply a single branch with all changes with or
> > > without merge commits.
> > 
> > Hmm, complex indeed.
> > 
> > Is there any way to avoid this sequence of ARM -> sh/pinctrl -> ARM ->
> > sh/pinctrl dependencies? That's what really makes things look complicated
> > here. If you could move the final cleanup/code removal pieces out of
> > the sh/pinctrl branches such that you have a less iterative chain of:
> > 
> > sh/pinctrl -> ARM -> final sh/pinctrl cleanup (removal of struct members,
> > etc)
> > 
> > ... but I haven't looked in detail at the per-patch dependencies to see how
> > tough that would be to arrange.
> > 
> > > All branches are present in the renesas tree
> > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> > > 
> > > 1. Branch: sh-soc
> > > 
> > >    Description: Pre-requisites for pfc changes for SH SoCs
> > >    Based on: v3.8-rc1
> > > 
> > > 2. Branch: clocksource
> > > 
> > >    Description: Pre-requisite clocksource change for soc branch
> > >    Based on: v3.8-rc1
> > > 
> > > 3. Branch: pfc
> > > 
> > >    Description: PFC Updates
> > >    Based on: sh-soc
> > > 
> > > 4. Branch: sh-soc2
> > > 
> > >    Description: Further PFC changes for SH SoCs
> > >    Based on: pfc
> > > 
> > > 5. Branch: soc
> > > 
> > >    Description: shmobile (ARM) SoCs updates, including PFC changes.
> > >    Based on: a merge of clocksource and pfc
> > > 
> > > 6. Branch: boards
> > > 
> > >    Description: Board changes, including PFC changes.
> > >    Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> > >    soc
> > > 
> > > 7. Branch: pfc2
> > > 
> > >    Description: Further PFC changes which depend on SoC changes
> > >    Based on: A merge of sh-soc2 and soc
> > > 
> > > 8. Branch: sh-soc3
> > > 
> > >    Description: Further PFC changes for SH SoCs
> > >    Based on: pfc2
> > > 
> > > 9. Branch: soc2
> > > 
> > >    Description: Further PFC changes for shmobile (ARM) SoCs
> > >    Based on: A merge of timer/cleanup (present in the arm-soc tree) and
> > >    pfc2
> > > 
> > > 10. Branch: pfc3
> > > 
> > >     Description: Description: Further PFC changes which depend on SoC
> > >     changes
> > >     Based on: A merge of sh-soc3 and soc2
> > 
> > Looking at it from the end here, 10 contains only arch/sh and global
> > changes, and depends on 8 and 9. 8 also contains only sh changes. So it
> > looks like 8 and 10 could be pruned from this pull request and go through
> > either SH or pinctrl.
> > 
> > What pieces from branch 7 are stronly needed? A couple of the added pinctrl
> > modules are used by mach-shmobile boards, it seems. And the structure rename
> > might also be needed.
> 
> 7 prepares for the move of PFC data from board code to drivers/. The branch 
> mostly adds a pinctrl module for each of the supported SoCs, to allow later 
> removal of PFC data from board code (in branches 8 and 9).
> 
> > Not having to pull in the bulk of 7, 8 and 10 would make a pretty big
> > difference.
> 
> One way or the other all patches will need to be pulled. If they go through 
> multiple trees we'll have to synchronize the multiple pull requests during the 
> merge window, which looks pretty error-prone to me (but I might be wrong on 
> this).
> 
> Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline, 
> then push 7 through the pinctrl tree, wait until it reaches mainline, push 8 
> through the SH tree and 9 through the ARM tree, wait until they reach 
> mainline, and finally push 10 through the pinctrl tree again. We could even 
> push each branch through the tree it belongs to, but I doubt we'll be able to 
> push everything during a single merge window.
> 
> I might be able to move 1 after 7, in which case we would have a single branch 
> that would combine both and touch pinctrl only. The other dependencies seem 
> pretty difficult to avoid.
> 
> What are the main issues with merging the branches in their current state (or 
> possibly with 5 and 6 moved aside) through the ARM tree ?

Ah, ok -- you're suggesting bringing it _all_ in through arm-soc. We
can do so, I was of the initial impression from Simon's cover letter
that the arch/sh branches would also go through the SH tree.

This seems to be a particularly hairy conversion, given that it touches two
architectures that need to be updated in lockstep. I guess we might be just as
well off pulling it in as-is (with below exceptions) to get it in.

If you need the same contents in the SH tree due to dependencies and
later development, let me know and we can agree on a stable branch that
we both pick up in either tree that has all contents.

> > For branch 2 (clocksource include order), I'd like to see an ack from John
> > or Thomas. Does it really make sense to base that on an ifdef instead of
> > always initialize early?
> > 
> > Branch 4 seems to be mostly sh-specific updates. With some of the later
> > dependencies avoided, maybe this branch can be dropped too, not sure?
> 
> 4 moves platform device registration from the sh-pfc module to board code. 
> Later pinctrl patches then remove platform device registration from the sh-pfc 
> module completely and continue with the rework of the sh-pfc code. 7 thus 
> strongly depends on 4.

Ok.

> > About half of branch 5 looks like it's generic SoC-updates unrelated
> > to the pinctrl rework, and branch 6 looks like mostly regular
> > patches/updates, is that stronly dependent on all the pinctrl
> > rework? Doesn't look like it should be?
> 
> You're right here. The non-pinctrl patches in 5 could go through a separate 
> branch, they shouldn't depend on the pinctrl rework. 6 also has no dependency 
> on the pinctrl rework.

Simon, based on the above, would you mind splitting off the non-pinctrl updates
to separate branches?

I'll likely pick this up as a standalone branch, and not try to fit it into the
usual arm-soc categories, so feel free to use the pinctrl branch contents as
a base for the other branches if you have to, but maybe you can avoid it
alltogether if there aren't any substantial conflicts between the pinctrl
restructuring and the other patches mentioned above.


-Olof

Re: [GIT PULL] Renesas ARM-based SoC v3.9

[Paul Mundt]

On Tue, Jan 22, 2013 at 12:21:23AM -0800, Olof Johansson wrote:
> On Mon, Jan 21, 2013 at 04:31:43PM +0100, Laurent Pinchart wrote:
> > Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline, 
> > then push 7 through the pinctrl tree, wait until it reaches mainline, push 8 
> > through the SH tree and 9 through the ARM tree, wait until they reach 
> > mainline, and finally push 10 through the pinctrl tree again. We could even 
> > push each branch through the tree it belongs to, but I doubt we'll be able to 
> > push everything during a single merge window.
> 
> Ah, ok -- you're suggesting bringing it _all_ in through arm-soc. We
> can do so, I was of the initial impression from Simon's cover letter
> that the arch/sh branches would also go through the SH tree.
> 
> This seems to be a particularly hairy conversion, given that it touches two
> architectures that need to be updated in lockstep. I guess we might be just as
> well off pulling it in as-is (with below exceptions) to get it in.
> 
> If you need the same contents in the SH tree due to dependencies and
> later development, let me know and we can agree on a stable branch that
> we both pick up in either tree that has all contents.
> 
There isn't anything at the moment pending for the SH tree that cares
about or conflicts with any of this work, so it's ok with me if this all
goes through arm-soc. If there is any fallout we can take care of it
later on in the merge window. This would seem to be a saner option than
attempting to merge half a dozen branches with dependencies on each other
in precise order, which doesn't leave a lot of time for fixing up
any residual merge window damage.

[GIT PULL] Renesas ARM-based SoC v3.9

[Paul Mundt]

On Tue, Jan 22, 2013 at 12:21:23AM -0800, Olof Johansson wrote:
> On Mon, Jan 21, 2013 at 04:31:43PM +0100, Laurent Pinchart wrote:
> > Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline, 
> > then push 7 through the pinctrl tree, wait until it reaches mainline, push 8 
> > through the SH tree and 9 through the ARM tree, wait until they reach 
> > mainline, and finally push 10 through the pinctrl tree again. We could even 
> > push each branch through the tree it belongs to, but I doubt we'll be able to 
> > push everything during a single merge window.
> 
> Ah, ok -- you're suggesting bringing it _all_ in through arm-soc. We
> can do so, I was of the initial impression from Simon's cover letter
> that the arch/sh branches would also go through the SH tree.
> 
> This seems to be a particularly hairy conversion, given that it touches two
> architectures that need to be updated in lockstep. I guess we might be just as
> well off pulling it in as-is (with below exceptions) to get it in.
> 
> If you need the same contents in the SH tree due to dependencies and
> later development, let me know and we can agree on a stable branch that
> we both pick up in either tree that has all contents.
> 
There isn't anything at the moment pending for the SH tree that cares
about or conflicts with any of this work, so it's ok with me if this all
goes through arm-soc. If there is any fallout we can take care of it
later on in the merge window. This would seem to be a saner option than
attempting to merge half a dozen branches with dependencies on each other
in precise order, which doesn't leave a lot of time for fixing up
any residual merge window damage.

Re: [GIT PULL] Renesas ARM-based SoC v3.9

[Olof Johansson]

On Tue, Jan 22, 2013 at 1:19 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Jan 22, 2013 at 12:21:23AM -0800, Olof Johansson wrote:
>> On Mon, Jan 21, 2013 at 04:31:43PM +0100, Laurent Pinchart wrote:
>> > Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline,
>> > then push 7 through the pinctrl tree, wait until it reaches mainline, push 8
>> > through the SH tree and 9 through the ARM tree, wait until they reach
>> > mainline, and finally push 10 through the pinctrl tree again. We could even
>> > push each branch through the tree it belongs to, but I doubt we'll be able to
>> > push everything during a single merge window.
>>
>> Ah, ok -- you're suggesting bringing it _all_ in through arm-soc. We
>> can do so, I was of the initial impression from Simon's cover letter
>> that the arch/sh branches would also go through the SH tree.
>>
>> This seems to be a particularly hairy conversion, given that it touches two
>> architectures that need to be updated in lockstep. I guess we might be just as
>> well off pulling it in as-is (with below exceptions) to get it in.
>>
>> If you need the same contents in the SH tree due to dependencies and
>> later development, let me know and we can agree on a stable branch that
>> we both pick up in either tree that has all contents.
>>
> There isn't anything at the moment pending for the SH tree that cares
> about or conflicts with any of this work, so it's ok with me if this all
> goes through arm-soc. If there is any fallout we can take care of it
> later on in the merge window. This would seem to be a saner option than
> attempting to merge half a dozen branches with dependencies on each other
> in precise order, which doesn't leave a lot of time for fixing up
> any residual merge window damage.

Yup, that sounds good. Let's do it that way.


-Olof

[GIT PULL] Renesas ARM-based SoC v3.9

[Olof Johansson]

On Tue, Jan 22, 2013 at 1:19 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> On Tue, Jan 22, 2013 at 12:21:23AM -0800, Olof Johansson wrote:
>> On Mon, Jan 21, 2013 at 04:31:43PM +0100, Laurent Pinchart wrote:
>> > Sure, we could push 1-6 through the ARM tree, wait until it reaches mainline,
>> > then push 7 through the pinctrl tree, wait until it reaches mainline, push 8
>> > through the SH tree and 9 through the ARM tree, wait until they reach
>> > mainline, and finally push 10 through the pinctrl tree again. We could even
>> > push each branch through the tree it belongs to, but I doubt we'll be able to
>> > push everything during a single merge window.
>>
>> Ah, ok -- you're suggesting bringing it _all_ in through arm-soc. We
>> can do so, I was of the initial impression from Simon's cover letter
>> that the arch/sh branches would also go through the SH tree.
>>
>> This seems to be a particularly hairy conversion, given that it touches two
>> architectures that need to be updated in lockstep. I guess we might be just as
>> well off pulling it in as-is (with below exceptions) to get it in.
>>
>> If you need the same contents in the SH tree due to dependencies and
>> later development, let me know and we can agree on a stable branch that
>> we both pick up in either tree that has all contents.
>>
> There isn't anything at the moment pending for the SH tree that cares
> about or conflicts with any of this work, so it's ok with me if this all
> goes through arm-soc. If there is any fallout we can take care of it
> later on in the merge window. This would seem to be a saner option than
> attempting to merge half a dozen branches with dependencies on each other
> in precise order, which doesn't leave a lot of time for fixing up
> any residual merge window damage.

Yup, that sounds good. Let's do it that way.


-Olof

[GIT PULL] Renesas ARM-based SoC defconfig for v3.9 #2

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following defconfig enhancements for 3.9.

This series is based on the renesas/defconfig branch in the arm-soc tree.

----------------------------------------------------------------
The following changes since commit 8098df15c26b2bf16924df5a134d1a649692ab62:

  ARM: mach-shmobile: kzm9d: update defconfig (2013-01-15 08:57:09 +0900)

are available in the git repository at:

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

for you to fetch changes up to 46bbd43fa44fe083188f3e4846ba5b8d3c89bae6:

  ARM: mach-shmobile: mackerel:  enable VFP in defconfig (2013-01-23 14:59:37 +0900)

----------------------------------------------------------------
Simon Horman (2):
      ARM: mach-shmobile: armadillo: defconfig: Enable CEU
      ARM: mach-shmobile: mackerel:  enable VFP in defconfig

 arch/arm/configs/armadillo800eva_defconfig |    5 +----
 arch/arm/configs/mackerel_defconfig        |    1 +
 2 files changed, 2 insertions(+), 4 deletions(-)

[GIT PULL] Renesas ARM-based SoC defconfig for v3.9 #2

[Simon Horman]

Hi Olof, Hi Arnd,

please consider the following defconfig enhancements for 3.9.

This series is based on the renesas/defconfig branch in the arm-soc tree.

----------------------------------------------------------------
The following changes since commit 8098df15c26b2bf16924df5a134d1a649692ab62:

  ARM: mach-shmobile: kzm9d: update defconfig (2013-01-15 08:57:09 +0900)

are available in the git repository at:

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

for you to fetch changes up to 46bbd43fa44fe083188f3e4846ba5b8d3c89bae6:

  ARM: mach-shmobile: mackerel:  enable VFP in defconfig (2013-01-23 14:59:37 +0900)

----------------------------------------------------------------
Simon Horman (2):
      ARM: mach-shmobile: armadillo: defconfig: Enable CEU
      ARM: mach-shmobile: mackerel:  enable VFP in defconfig

 arch/arm/configs/armadillo800eva_defconfig |    5 +----
 arch/arm/configs/mackerel_defconfig        |    1 +
 2 files changed, 2 insertions(+), 4 deletions(-)

[PATCH 1/2] ARM: mach-shmobile: armadillo: defconfig: Enable CEU

[Simon Horman]

Update the defconfig to enable the CEU camera.

It appears that it was previously enabled but an
update is required for Kconfig changes.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index f9e2701..0b98100 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -90,14 +90,11 @@ CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_VIDEO_DEV=y
-# CONFIG_RC_CORE is not set
-# CONFIG_VIDEO_HELPER_CHIPS_AUTO is not set
-# CONFIG_V4L_USB_DRIVERS is not set
+CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_SOC_CAMERA=y
 CONFIG_SOC_CAMERA_MT9T112=y
 CONFIG_VIDEO_SH_MOBILE_CEU=y
-# CONFIG_RADIO_ADAPTERS is not set
 CONFIG_FB=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FB_SH_MOBILE_HDMI=y
-- 
1.7.10.4

[PATCH 1/2] ARM: mach-shmobile: armadillo: defconfig: Enable CEU

[Simon Horman]

Update the defconfig to enable the CEU camera.

It appears that it was previously enabled but an
update is required for Kconfig changes.

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index f9e2701..0b98100 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -90,14 +90,11 @@ CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_VIDEO_DEV=y
-# CONFIG_RC_CORE is not set
-# CONFIG_VIDEO_HELPER_CHIPS_AUTO is not set
-# CONFIG_V4L_USB_DRIVERS is not set
+CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_SOC_CAMERA=y
 CONFIG_SOC_CAMERA_MT9T112=y
 CONFIG_VIDEO_SH_MOBILE_CEU=y
-# CONFIG_RADIO_ADAPTERS is not set
 CONFIG_FB=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FB_SH_MOBILE_HDMI=y
-- 
1.7.10.4

[PATCH 2/2] ARM: mach-shmobile: mackerel: enable VFP in defconfig

[Simon Horman]

CONFIG_VFP appears to be required to use the
Debian armhf userspace. Enabling this is consistent
with many other shmobile boards.

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

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index e6881ac..7594b3a 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -25,6 +25,7 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_KEXEC=y
+CONFIG_VFP=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_PM=y
 CONFIG_PM_RUNTIME=y
-- 
1.7.10.4

[PATCH 2/2] ARM: mach-shmobile: mackerel: enable VFP in defconfig

[Simon Horman]

CONFIG_VFP appears to be required to use the
Debian armhf userspace. Enabling this is consistent
with many other shmobile boards.

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

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index e6881ac..7594b3a 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -25,6 +25,7 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_KEXEC=y
+CONFIG_VFP=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_PM=y
 CONFIG_PM_RUNTIME=y
-- 
1.7.10.4

Re: [GIT PULL] Renesas ARM-based SoC defconfig for v3.9 #2

[Olof Johansson]

On Fri, Jan 25, 2013 at 11:02:52AM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> please consider the following defconfig enhancements for 3.9.
> 
> This series is based on the renesas/defconfig branch in the arm-soc tree.
> 
> ----------------------------------------------------------------
> The following changes since commit 8098df15c26b2bf16924df5a134d1a649692ab62:
> 
>   ARM: mach-shmobile: kzm9d: update defconfig (2013-01-15 08:57:09 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git defconfig2

Thanks, pulled on top of previous defconfig branch.


-Olof

[GIT PULL] Renesas ARM-based SoC defconfig for v3.9 #2

[Olof Johansson]

On Fri, Jan 25, 2013 at 11:02:52AM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
> 
> please consider the following defconfig enhancements for 3.9.
> 
> This series is based on the renesas/defconfig branch in the arm-soc tree.
> 
> ----------------------------------------------------------------
> The following changes since commit 8098df15c26b2bf16924df5a134d1a649692ab62:
> 
>   ARM: mach-shmobile: kzm9d: update defconfig (2013-01-15 08:57:09 +0900)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git defconfig2

Thanks, pulled on top of previous defconfig branch.


-Olof

[GIT PULL] Renesas ARM-based SoC defconfig updates for v3.10

[Simon Horman]

Hi Olof, Hi Arnd,

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig-for-v3.10

for you to fetch changes up to db30abdf3c07c564d4af0f991bb7f38b728f9035:

  ARM: mach-shmobile: marzen: add SATA support (2013-03-14 10:28:07 +0100)

----------------------------------------------------------------
Renesas ARM-based SoC defconfig updates for v3.10

----------------------------------------------------------------
Kuninori Morimoto (3):
      ARM: shmobile: armadillo800eva: enable branch prediction on defconfig
      ARM: shmobile: armadillo800eva: enable NEON on defconfig
      ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

Simon Horman (5):
      ARM: mach-shmobile: mackerel: enable MMCIF and SDHI in defconfig
      ARM: mach-shmobile: mackerel: enable REGULATOR in defconfig
      ARM: mach-shmobile: armadillo800eva: enable REGULATOR in defconfig
      ARM: shmobile: kzm9g: defconfig: do not enable PREEMPT
      ARM: mach-shmobile: kzm9g: do not enable REGULATOR_DUMMY in defconfig

Vladimir Barinov (1):
      ARM: mach-shmobile: marzen: add SATA support

 arch/arm/configs/armadillo800eva_defconfig |    8 +++++++-
 arch/arm/configs/kzm9g_defconfig           |    2 --
 arch/arm/configs/mackerel_defconfig        |    4 ++++
 arch/arm/configs/marzen_defconfig          |    4 ++++
 4 files changed, 15 insertions(+), 3 deletions(-)

[GIT PULL] Renesas ARM-based SoC defconfig updates for v3.10

[Simon Horman]

Hi Olof, Hi Arnd,

The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:

  Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig-for-v3.10

for you to fetch changes up to db30abdf3c07c564d4af0f991bb7f38b728f9035:

  ARM: mach-shmobile: marzen: add SATA support (2013-03-14 10:28:07 +0100)

----------------------------------------------------------------
Renesas ARM-based SoC defconfig updates for v3.10

----------------------------------------------------------------
Kuninori Morimoto (3):
      ARM: shmobile: armadillo800eva: enable branch prediction on defconfig
      ARM: shmobile: armadillo800eva: enable NEON on defconfig
      ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

Simon Horman (5):
      ARM: mach-shmobile: mackerel: enable MMCIF and SDHI in defconfig
      ARM: mach-shmobile: mackerel: enable REGULATOR in defconfig
      ARM: mach-shmobile: armadillo800eva: enable REGULATOR in defconfig
      ARM: shmobile: kzm9g: defconfig: do not enable PREEMPT
      ARM: mach-shmobile: kzm9g: do not enable REGULATOR_DUMMY in defconfig

Vladimir Barinov (1):
      ARM: mach-shmobile: marzen: add SATA support

 arch/arm/configs/armadillo800eva_defconfig |    8 +++++++-
 arch/arm/configs/kzm9g_defconfig           |    2 --
 arch/arm/configs/mackerel_defconfig        |    4 ++++
 arch/arm/configs/marzen_defconfig          |    4 ++++
 4 files changed, 15 insertions(+), 3 deletions(-)

[PATCH 1/9] ARM: mach-shmobile: mackerel: enable MMCIF and SDHI in defconfig

[Simon Horman]

I'm unsure why this isn't already the case.

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

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index 7594b3a..ec8e605 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -94,6 +94,9 @@ CONFIG_USB_RENESAS_USBHS=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_RENESAS_USBHS_UDC=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHI=y
+CONFIG_MMC_SH_MMCIF=y
 CONFIG_DMADEVICES=y
 CONFIG_SH_DMAE=y
 CONFIG_EXT2_FS=y
-- 
1.7.10.4

[PATCH 1/9] ARM: mach-shmobile: mackerel: enable MMCIF and SDHI in defconfig

[Simon Horman]

I'm unsure why this isn't already the case.

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

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index 7594b3a..ec8e605 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -94,6 +94,9 @@ CONFIG_USB_RENESAS_USBHS=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_RENESAS_USBHS_UDC=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHI=y
+CONFIG_MMC_SH_MMCIF=y
 CONFIG_DMADEVICES=y
 CONFIG_SH_DMAE=y
 CONFIG_EXT2_FS=y
-- 
1.7.10.4

[PATCH 2/9] ARM: mach-shmobile: mackerel: enable REGULATOR in defconfig

[Simon Horman]

As well as being a generally sane thing to do this
is required for MMCIF to function in conjunction with
" ARM: shmobile: streamline mackerel SD and MMC devices".

Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/mackerel_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index ec8e605..9fb1189 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -75,6 +75,7 @@ CONFIG_I2C=y
 CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
 # CONFIG_MFD_SUPPORT is not set
+CONFIG_REGULATOR=y
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_SH_MOBILE_LCDC=y
-- 
1.7.10.4

[PATCH 2/9] ARM: mach-shmobile: mackerel: enable REGULATOR in defconfig

[Simon Horman]

As well as being a generally sane thing to do this
is required for MMCIF to function in conjunction with
" ARM: shmobile: streamline mackerel SD and MMC devices".

Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/mackerel_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mackerel_defconfig b/arch/arm/configs/mackerel_defconfig
index ec8e605..9fb1189 100644
--- a/arch/arm/configs/mackerel_defconfig
+++ b/arch/arm/configs/mackerel_defconfig
@@ -75,6 +75,7 @@ CONFIG_I2C=y
 CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
 # CONFIG_MFD_SUPPORT is not set
+CONFIG_REGULATOR=y
 CONFIG_FB=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_SH_MOBILE_LCDC=y
-- 
1.7.10.4

[PATCH 3/9] ARM: mach-shmobile: armadillo800eva: enable REGULATOR in defconfig

[Simon Horman]

As well as being a generally sane thing to do this
is required for MMCIF to function in conjunction with
"ARM: shmobile: switch SDHI0 to GPIO regulator on armadillo800eva".

Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 0b98100..0cc8014 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -88,6 +88,7 @@ CONFIG_I2C=y
 CONFIG_I2C_GPIO=y
 CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
+CONFIG_REGULATOR=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_VIDEO_DEV=y
 CONFIG_MEDIA_CAMERA_SUPPORT=y
-- 
1.7.10.4

[PATCH 3/9] ARM: mach-shmobile: armadillo800eva: enable REGULATOR in defconfig

[Simon Horman]

As well as being a generally sane thing to do this
is required for MMCIF to function in conjunction with
"ARM: shmobile: switch SDHI0 to GPIO regulator on armadillo800eva".

Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 0b98100..0cc8014 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -88,6 +88,7 @@ CONFIG_I2C=y
 CONFIG_I2C_GPIO=y
 CONFIG_I2C_SH_MOBILE=y
 # CONFIG_HWMON is not set
+CONFIG_REGULATOR=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_VIDEO_DEV=y
 CONFIG_MEDIA_CAMERA_SUPPORT=y
-- 
1.7.10.4

[PATCH 4/9] ARM: shmobile: kzm9g: defconfig: do not enable PREEMPT

[Simon Horman]

The motivation for this change is:

* It is consistent with all other shmobile boards and;
* Allows the kzm9g-reference code to work with CONFIG_SMP
  and thus the new defconfig

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/kzm9g_defconfig |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index 670c3b6..84ac68c 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -33,7 +33,6 @@ CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_SMP=y
 CONFIG_SCHED_MC=y
-CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 # CONFIG_OABI_COMPAT is not set
 CONFIG_HIGHMEM=y
-- 
1.7.10.4

[PATCH 4/9] ARM: shmobile: kzm9g: defconfig: do not enable PREEMPT

[Simon Horman]

The motivation for this change is:

* It is consistent with all other shmobile boards and;
* Allows the kzm9g-reference code to work with CONFIG_SMP
  and thus the new defconfig

Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/kzm9g_defconfig |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index 670c3b6..84ac68c 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -33,7 +33,6 @@ CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_SMP=y
 CONFIG_SCHED_MC=y
-CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 # CONFIG_OABI_COMPAT is not set
 CONFIG_HIGHMEM=y
-- 
1.7.10.4

[PATCH 5/9] ARM: shmobile: armadillo800eva: enable branch prediction on defconfig

[Simon Horman]

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

Because defconfig disabled ARM branch prediction
by CONFIG_CPU_BPREDICT_DISABLE,
Armadillo800eva's Bogomips and Loop were not good performance.
This patch enabled Arm branch prediction.
Special thanks to Ishiyama-san

Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 0cc8014..c402294 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -20,7 +20,6 @@ CONFIG_ARCH_R8A7740=y
 CONFIG_MACH_ARMADILLO800EVA=y
 # CONFIG_SH_TIMER_TMU is not set
 CONFIG_ARM_THUMB=y
-CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_CACHE_L2X0=y
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
-- 
1.7.10.4

[PATCH 5/9] ARM: shmobile: armadillo800eva: enable branch prediction on defconfig

[Simon Horman]

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

Because defconfig disabled ARM branch prediction
by CONFIG_CPU_BPREDICT_DISABLE,
Armadillo800eva's Bogomips and Loop were not good performance.
This patch enabled Arm branch prediction.
Special thanks to Ishiyama-san

Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 0cc8014..c402294 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -20,7 +20,6 @@ CONFIG_ARCH_R8A7740=y
 CONFIG_MACH_ARMADILLO800EVA=y
 # CONFIG_SH_TIMER_TMU is not set
 CONFIG_ARM_THUMB=y
-CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_CACHE_L2X0=y
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
-- 
1.7.10.4

[PATCH 6/9] ARM: shmobile: armadillo800eva: enable NEON on defconfig

[Simon Horman]

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

The application / library will be stopped by illegal instruction
on current Armaddilo800eva board,
since defconfig doesn't have CONFIG_NEON.
This patch enabled it.
Special thanks to Ishiyama-san

Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index c402294..468c616 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -36,6 +36,7 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_KEXEC=y
 CONFIG_VFP=y
+CONFIG_NEON=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_PM_RUNTIME=y
 CONFIG_NET=y
-- 
1.7.10.4

[PATCH 6/9] ARM: shmobile: armadillo800eva: enable NEON on defconfig

[Simon Horman]

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

The application / library will be stopped by illegal instruction
on current Armaddilo800eva board,
since defconfig doesn't have CONFIG_NEON.
This patch enabled it.
Special thanks to Ishiyama-san

Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index c402294..468c616 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -36,6 +36,7 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_KEXEC=y
 CONFIG_VFP=y
+CONFIG_NEON=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_PM_RUNTIME=y
 CONFIG_NET=y
-- 
1.7.10.4

[PATCH 7/9] ARM: mach-shmobile: kzm9g: do not enable REGULATOR_DUMMY in defconfig

[Simon Horman]

Don't enable REGULATOR_DUMMY, it is only intended for development / testing.
There doesn't seem to be any value in setting it here and doing
so was an error on my part.

Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/kzm9g_defconfig |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index 84ac68c..f6e585b 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -85,7 +85,6 @@ CONFIG_I2C_SH_MOBILE=y
 CONFIG_GPIO_PCF857X=y
 # CONFIG_HWMON is not set
 CONFIG_REGULATOR=y
-CONFIG_REGULATOR_DUMMY=y
 CONFIG_FB=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-- 
1.7.10.4

[PATCH 7/9] ARM: mach-shmobile: kzm9g: do not enable REGULATOR_DUMMY in defconfig

[Simon Horman]

Don't enable REGULATOR_DUMMY, it is only intended for development / testing.
There doesn't seem to be any value in setting it here and doing
so was an error on my part.

Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/kzm9g_defconfig |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/kzm9g_defconfig b/arch/arm/configs/kzm9g_defconfig
index 84ac68c..f6e585b 100644
--- a/arch/arm/configs/kzm9g_defconfig
+++ b/arch/arm/configs/kzm9g_defconfig
@@ -85,7 +85,6 @@ CONFIG_I2C_SH_MOBILE=y
 CONFIG_GPIO_PCF857X=y
 # CONFIG_HWMON is not set
 CONFIG_REGULATOR=y
-CONFIG_REGULATOR_DUMMY=y
 CONFIG_FB=y
 CONFIG_FB_SH_MOBILE_LCDC=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-- 
1.7.10.4

[PATCH 8/9] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Simon Horman]

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

Some errata for cache had not enabled on current
Armadillo800eva defconfig.
This patch enables these.
Special thanks to Ishiyama-san

Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 468c616..0f2d80d 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -24,10 +24,15 @@ CONFIG_CACHE_L2X0=y
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
 CONFIG_ARM_ERRATA_460075=y
+CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_720789=y
+CONFIG_PL310_ERRATA_727915=y
 CONFIG_ARM_ERRATA_743622=y
 CONFIG_ARM_ERRATA_751472=y
+CONFIG_PL310_ERRATA_753970=y
 CONFIG_ARM_ERRATA_754322=y
+CONFIG_PL310_ERRATA_769419=y
+CONFIG_ARM_ERRATA_775420=y
 CONFIG_AEABI=y
 # CONFIG_OABI_COMPAT is not set
 CONFIG_FORCE_MAX_ZONEORDER\x13
-- 
1.7.10.4

[PATCH 8/9] ARM: shmobile: armadillo800eva: enable all errata for cache on defconfig

[Simon Horman]

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

Some errata for cache had not enabled on current
Armadillo800eva defconfig.
This patch enables these.
Special thanks to Ishiyama-san

Reported-by: Kiyoshi Ishiyama <kiyoshi.ishiyama.wg@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/armadillo800eva_defconfig |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/armadillo800eva_defconfig b/arch/arm/configs/armadillo800eva_defconfig
index 468c616..0f2d80d 100644
--- a/arch/arm/configs/armadillo800eva_defconfig
+++ b/arch/arm/configs/armadillo800eva_defconfig
@@ -24,10 +24,15 @@ CONFIG_CACHE_L2X0=y
 CONFIG_ARM_ERRATA_430973=y
 CONFIG_ARM_ERRATA_458693=y
 CONFIG_ARM_ERRATA_460075=y
+CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_720789=y
+CONFIG_PL310_ERRATA_727915=y
 CONFIG_ARM_ERRATA_743622=y
 CONFIG_ARM_ERRATA_751472=y
+CONFIG_PL310_ERRATA_753970=y
 CONFIG_ARM_ERRATA_754322=y
+CONFIG_PL310_ERRATA_769419=y
+CONFIG_ARM_ERRATA_775420=y
 CONFIG_AEABI=y
 # CONFIG_OABI_COMPAT is not set
 CONFIG_FORCE_MAX_ZONEORDER=13
-- 
1.7.10.4

[PATCH 9/9] ARM: mach-shmobile: marzen: add SATA support

[Simon Horman]

From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>

Add SATA support to marzen_defconfig.

Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/marzen_defconfig |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index afb17d6..8e7329b 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -49,6 +49,10 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_ATA_SFF=y
+CONFIG_ATA_BMDMA=y
+CONFIG_SATA_RCAR=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_BROADCOM is not set
 # CONFIG_NET_VENDOR_FARADAY is not set
-- 
1.7.10.4

[PATCH 9/9] ARM: mach-shmobile: marzen: add SATA support

[Simon Horman]

From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>

Add SATA support to marzen_defconfig.

Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/configs/marzen_defconfig |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/marzen_defconfig b/arch/arm/configs/marzen_defconfig
index afb17d6..8e7329b 100644
--- a/arch/arm/configs/marzen_defconfig
+++ b/arch/arm/configs/marzen_defconfig
@@ -49,6 +49,10 @@ CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_ATA_SFF=y
+CONFIG_ATA_BMDMA=y
+CONFIG_SATA_RCAR=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_BROADCOM is not set
 # CONFIG_NET_VENDOR_FARADAY is not set
-- 
1.7.10.4

Re: [GIT PULL] Renesas ARM-based SoC defconfig updates for v3.10

[Arnd Bergmann]

On Monday 18 March 2013, Simon Horman wrote:
> The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
> 
>   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig-for-v3.10
> 
> for you to fetch changes up to db30abdf3c07c564d4af0f991bb7f38b728f9035:

Pulled into next/soc, thanks!

I'm combining it with the other soc updates for now, but I still like to receive
the branches separately as you do here. If we get a lot more defconfig pull requests,
we can make that an extra topic branch that we create from all the ones we received.

	Arnd

[GIT PULL] Renesas ARM-based SoC defconfig updates for v3.10

[Arnd Bergmann]

On Monday 18 March 2013, Simon Horman wrote:
> The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
> 
>   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig-for-v3.10
> 
> for you to fetch changes up to db30abdf3c07c564d4af0f991bb7f38b728f9035:

Pulled into next/soc, thanks!

I'm combining it with the other soc updates for now, but I still like to receive
the branches separately as you do here. If we get a lot more defconfig pull requests,
we can make that an extra topic branch that we create from all the ones we received.

	Arnd

Re: [GIT PULL] Renesas ARM-based SoC defconfig updates for v3.10

[Simon Horman]

On Thu, Mar 21, 2013 at 04:56:25PM +0000, Arnd Bergmann wrote:
> On Monday 18 March 2013, Simon Horman wrote:
> > The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
> > 
> >   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig-for-v3.10
> > 
> > for you to fetch changes up to db30abdf3c07c564d4af0f991bb7f38b728f9035:
> 
> Pulled into next/soc, thanks!
> 
> I'm combining it with the other soc updates for now, but I still like to
> receive the branches separately as you do here. If we get a lot more
> defconfig pull requests, we can make that an extra topic branch that we
> create from all the ones we received.

Thanks.

At this point I do not have any more defconfig changes queued up
and I only expect a few more in the v3.10 time-frame - to deal
with new SoCs and corresponding boards.

[GIT PULL] Renesas ARM-based SoC defconfig updates for v3.10

[Simon Horman]

On Thu, Mar 21, 2013 at 04:56:25PM +0000, Arnd Bergmann wrote:
> On Monday 18 March 2013, Simon Horman wrote:
> > The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
> > 
> >   Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig-for-v3.10
> > 
> > for you to fetch changes up to db30abdf3c07c564d4af0f991bb7f38b728f9035:
> 
> Pulled into next/soc, thanks!
> 
> I'm combining it with the other soc updates for now, but I still like to
> receive the branches separately as you do here. If we get a lot more
> defconfig pull requests, we can make that an extra topic branch that we
> create from all the ones we received.

Thanks.

At this point I do not have any more defconfig changes queued up
and I only expect a few more in the v3.10 time-frame - to deal
with new SoCs and corresponding boards.