[GIT,PULL,v2] Renesas ARM-based SoC boards for v3.8

Hi Olof, Hi Arnd,

please consider the following board 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 boards

for you to fetch changes up to 39fe22dd9b60c26a6e1a5279abfb6473d67723e6:

  ARM: mach-shmobile: Use DT_MACHINE for mackerel (2012-10-24 17:06:15 +0900)

----------------------------------------------------------------
Bastian Hecht (1):
      ARM: mach-shmobile: add FLCTL DMA slave definitions for sh7372

Kuninori Morimoto (6):
      ARM: shmobile: armadillo800eva: enable restart
      ARM: shmobile: r8a7779: add HSPI clock support
      ARM: shmobile: r8a7779: add I2C clock support
      ARM: shmobile: r8a7779: add I2C driver support
      ARM: shmobile: marzen: add HSPI support
      ARM: shmobile: r8a7740: fixup DT machine desc name typo

Nobuhiro Iwamatsu (2):
      ARM: shmobile: r8a7740: Enable PMU
      ARM: mach-shmobile: Use DT_MACHINE for mackerel

Tetsuyuki Kobayashi (3):
      ARM: shmobile: kzm9g: enable magnetometer ak8975.
      ARM: shmobile: kzm9g: enable three-axis digital accelerometer ADXL345
      ARM: shmobile: kzm9g: enable DMAEngine on SHDI0 and SDHI2

 arch/arm/boot/dts/Makefile                     |    3 +-
 arch/arm/boot/dts/sh7372-mackerel.dts          |   22 +++++++
 arch/arm/configs/armadillo800eva_defconfig     |    1 +
 arch/arm/configs/kzm9g_defconfig               |    4 ++
 arch/arm/configs/marzen_defconfig              |    4 ++
 arch/arm/mach-shmobile/Kconfig                 |    1 +
 arch/arm/mach-shmobile/board-armadillo800eva.c |    8 +++
 arch/arm/mach-shmobile/board-kzm9g.c           |   14 ++++-
 arch/arm/mach-shmobile/board-mackerel.c        |    8 ++-
 arch/arm/mach-shmobile/board-marzen.c          |   25 ++++++++
 arch/arm/mach-shmobile/clock-r8a7779.c         |   16 ++++-
 arch/arm/mach-shmobile/include/mach/sh7372.h   |    4 ++
 arch/arm/mach-shmobile/setup-r8a7740.c         |   18 +++++-
 arch/arm/mach-shmobile/setup-r8a7779.c         |   77 ++++++++++++++++++++++++
 arch/arm/mach-shmobile/setup-sh7372.c          |   20 ++++++
 15 files changed, 220 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/sh7372-mackerel.dts

Dear Simon Horman,

On Sun, 28 Oct 2012 11:26:13 +0900, Simon Horman wrote:

> -MACHINE_START(MACKEREL, "mackerel")
> +static const char *mackerel_boards_compat_dt[] __initdata = {
> +	"renesas,mackerel",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(MACKEREL_DT, "mackerel")
>  	.map_io		= sh7372_map_io,
>  	.init_early	= sh7372_add_early_devices,
>  	.init_irq	= sh7372_init_irq,
> @@ -1659,4 +1664,5 @@ MACHINE_START(MACKEREL, "mackerel")
>  	.init_machine	= mackerel_init,
>  	.init_late	= sh7372_pm_init_late,
>  	.timer		= &shmobile_timer,
> +	.dt_compat  = mackerel_boards_compat_dt,
>  MACHINE_END

Not sure what is the status of mach-shmobile with regard to the device
tree, but one of the idea of the device tree is to avoid having one .c
file per board, and therefore one DT_MACHINE_START definition per
board. There should be only only DT_MACHINE_START definition per SoC or
SoC family, with the DT giving the detailed hardware description.

Of course, during a transition period, not all your drivers may have DT
bindings, and therefore some devices may need to be probed in the "old"
way (manual registration of platform_device). In that case, your
->init_machine() hook can call initialization function on a per-board
basis by testing if the machine is such or such board.

See arch/arm/mach-kirkwood/board-dt.c for an example. The advantage is
that with this solution, the board specific C files are progressively
reducing in size as more and more devices get registered through the
Device Tree, until the point where they become empty and can be removed.

Best regards,

Thomas

On Sun, Oct 28, 2012 at 10:37:11AM +0100, Thomas Petazzoni wrote:
> Dear Simon Horman,
> 
> On Sun, 28 Oct 2012 11:26:13 +0900, Simon Horman wrote:
> 
> > -MACHINE_START(MACKEREL, "mackerel")
> > +static const char *mackerel_boards_compat_dt[] __initdata = {
> > +	"renesas,mackerel",
> > +	NULL,
> > +};
> > +
> > +DT_MACHINE_START(MACKEREL_DT, "mackerel")
> >  	.map_io		= sh7372_map_io,
> >  	.init_early	= sh7372_add_early_devices,
> >  	.init_irq	= sh7372_init_irq,
> > @@ -1659,4 +1664,5 @@ MACHINE_START(MACKEREL, "mackerel")
> >  	.init_machine	= mackerel_init,
> >  	.init_late	= sh7372_pm_init_late,
> >  	.timer		= &shmobile_timer,
> > +	.dt_compat  = mackerel_boards_compat_dt,
> >  MACHINE_END
> 
> Not sure what is the status of mach-shmobile with regard to the device
> tree, but one of the idea of the device tree is to avoid having one .c
> file per board, and therefore one DT_MACHINE_START definition per
> board. There should be only only DT_MACHINE_START definition per SoC or
> SoC family, with the DT giving the detailed hardware description.
> 
> Of course, during a transition period, not all your drivers may have DT
> bindings, and therefore some devices may need to be probed in the "old"
> way (manual registration of platform_device). In that case, your
> ->init_machine() hook can call initialization function on a per-board
> basis by testing if the machine is such or such board.
> 
> See arch/arm/mach-kirkwood/board-dt.c for an example. The advantage is
> that with this solution, the board specific C files are progressively
> reducing in size as more and more devices get registered through the
> Device Tree, until the point where they become empty and can be removed.

Hi Thomas,

shmobile is very much in the transition phase and we are, patch by patch,
working towards full(er) DT support for boards, SoCs and drivers. I am not
sure that now is the right time to jump to a approach similar to that taken
by mach-kirkwood/board-dt.c.

Simon,

On Sun, 28 Oct 2012 19:44:38 +0900, Simon Horman wrote:

> shmobile is very much in the transition phase and we are, patch by patch,
> working towards full(er) DT support for boards, SoCs and drivers. I am not
> sure that now is the right time to jump to a approach similar to that taken
> by mach-kirkwood/board-dt.c.

Ok, I understand that for transition needs, each SoC family may need a
different method. My comment was more a general comment to make sure
that the right final direction is being taken. For sure the
intermediate steps may be different.

Best regards,

Thomas

Hello.

On 28-10-2012 6:26, Simon Horman wrote:

> From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>

> This patch enables PMU for r8a7740.

    And enables performance events on the Armadillo board. Perhaps the 
defconfig part was worth a separate patch...

> Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> Signed-off-by: Simon Horman <horms@verge.net.au>
[...]

> diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
> index 11bb1d9..1e032cb 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7740.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7740.c
> @@ -590,6 +590,21 @@ static struct platform_device i2c1_device = {
>   	.num_resources	= ARRAY_SIZE(i2c1_resources),
>   };
>
> +static struct resource pmu_resources[] = {
> +	[0] = {
> +		.start	= evt2irq(0x19a0),
> +		.end	= evt2irq(0x19a0),
> +		.flags  = IORESOURCE_IRQ,
> +	},
> +};
> +
> +static struct platform_device pmu_device = {
> +	.name	= "arm-pmu",
> +	.id		= -1,

    I think you should either align '=' with tabs, or not bother doing this, 
not both. :-)

> +	.num_resources = ARRAY_SIZE(pmu_resources),
> +	.resource = pmu_resources,
> +};
> +
>   static struct platform_device *r8a7740_late_devices[] __initdata = {
>   	&i2c0_device,
>   	&i2c1_device,

WBR, Sergei

On Sun, Oct 28, 2012 at 03:28:47PM +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 28-10-2012 6:26, Simon Horman wrote:
> 
> >From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> 
> >This patch enables PMU for r8a7740.
> 
>    And enables performance events on the Armadillo board. Perhaps
> the defconfig part was worth a separate patch...

As I understand things, the Armadillo is currently the only
board in-tree that uses the r8a7740 SoC and it seems
reasonable to enable performance events to activate the
code that comprises the rest of the patch.

So while I don't feel strongly about this I do have a slight preference
for the current single-patch approach.

> >Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> >Signed-off-by: Simon Horman <horms@verge.net.au>
> [...]
> 
> >diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
> >index 11bb1d9..1e032cb 100644
> >--- a/arch/arm/mach-shmobile/setup-r8a7740.c
> >+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
> >@@ -590,6 +590,21 @@ static struct platform_device i2c1_device = {
> >  	.num_resources	= ARRAY_SIZE(i2c1_resources),
> >  };
> >
> >+static struct resource pmu_resources[] = {
> >+	[0] = {
> >+		.start	= evt2irq(0x19a0),
> >+		.end	= evt2irq(0x19a0),
> >+		.flags  = IORESOURCE_IRQ,
> >+	},
> >+};
> >+
> >+static struct platform_device pmu_device = {
> >+	.name	= "arm-pmu",
> >+	.id		= -1,
> 
>    I think you should either align '=' with tabs, or not bother
> doing this, not both. :-)

Thanks, there seems to be an extra tab there.

I'll roll this into an updated patch and series once
we come to a consensus about the defconfig change.

> >+	.num_resources = ARRAY_SIZE(pmu_resources),
> >+	.resource = pmu_resources,
> >+};
> >+
> >  static struct platform_device *r8a7740_late_devices[] __initdata = {
> >  	&i2c0_device,
> >  	&i2c1_device,
> 
> WBR, Sergei
>