[GIT PULL] Renesas SoC updates for v3.4

[GIT PULL] Renesas SoC updates for v3.4

[Rafael J. Wysocki]

Hi,

Please pull Renesas SoC updates for v3.4 since commit
ce8fea7aa4ad9e3b40999a08622ef27c77159659:

    mmap: EINVAL not ENOMEM when rejecting VM_GROWS

with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef

    ARM: mach-shmobile: default to no earlytimer

from the git repository at:

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

They include:

* The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
  possible future name space collision with common struct clk code.

  This also affects drivers that are shared with the sh architecture,
  so the branch containing this part of the material, clk_ops-rename,
  will be merged into the Paul Mundt's sh tree if necessary.

* Introduction of L2 Cache support for r8a7779.

* Conversion of the mach-shmobile subarch to properly use a per-SoC
  map_io and separate init_early callback for early serial console
  support on platforms where that is possible.

Magnus Damm is the author of all the changes.


 arch/arm/mach-shmobile/board-ag5evm.c        |   39 +---------------
 arch/arm/mach-shmobile/board-ap4evb.c        |   44 +++----------------
 arch/arm/mach-shmobile/board-bonito.c        |   44 +++++-------------
 arch/arm/mach-shmobile/board-g3evm.c         |   38 +--------------
 arch/arm/mach-shmobile/board-g4evm.c         |   38 +--------------
 arch/arm/mach-shmobile/board-kota2.c         |   38 +--------------
 arch/arm/mach-shmobile/board-mackerel.c      |   44 +++----------------
 arch/arm/mach-shmobile/board-marzen.c        |   62 +------------------------
 arch/arm/mach-shmobile/clock-r8a7740.c       |    8 ++--
 arch/arm/mach-shmobile/clock-r8a7779.c       |    4 +-
 arch/arm/mach-shmobile/clock-sh7367.c        |    8 ++--
 arch/arm/mach-shmobile/clock-sh7372.c        |   10 ++--
 arch/arm/mach-shmobile/clock-sh7377.c        |    8 ++--
 arch/arm/mach-shmobile/clock-sh73a0.c        |   14 +++---
 arch/arm/mach-shmobile/clock.c               |    2 +-
 arch/arm/mach-shmobile/include/mach/common.h |    9 +++-
 arch/arm/mach-shmobile/setup-r8a7740.c       |   45 +++++++++++++++++++
 arch/arm/mach-shmobile/setup-r8a7779.c       |   54 ++++++++++++++++++++++
 arch/arm/mach-shmobile/setup-sh7367.c        |   32 +++++++++++++
 arch/arm/mach-shmobile/setup-sh7372.c        |   32 +++++++++++++
 arch/arm/mach-shmobile/setup-sh7377.c        |   32 +++++++++++++
 arch/arm/mach-shmobile/setup-sh73a0.c        |   32 +++++++++++++
 arch/arm/mach-shmobile/timer.c               |    6 ++-
 arch/sh/boards/mach-highlander/setup.c       |    2 +-
 arch/sh/boards/mach-sdk7786/setup.c          |    2 +-
 arch/sh/include/asm/clock.h                  |    2 +-
 arch/sh/kernel/cpu/sh2/clock-sh7619.c        |   12 +++---
 arch/sh/kernel/cpu/sh2a/clock-sh7201.c       |   12 +++---
 arch/sh/kernel/cpu/sh2a/clock-sh7203.c       |   12 +++---
 arch/sh/kernel/cpu/sh2a/clock-sh7206.c       |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh3.c           |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7705.c        |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7706.c        |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7709.c        |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7710.c        |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7712.c        |   10 ++--
 arch/sh/kernel/cpu/sh4/clock-sh4-202.c       |    6 +-
 arch/sh/kernel/cpu/sh4/clock-sh4.c           |   12 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7343.c       |    4 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7366.c       |    4 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c       |    4 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7723.c       |    4 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7724.c       |    6 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7757.c       |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7763.c       |   14 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7770.c       |   12 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7780.c       |   14 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7785.c       |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7786.c       |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-shx3.c         |    2 +-
 arch/sh/kernel/cpu/sh5/clock-sh5.c           |   12 +++---
 drivers/sh/clk/cpg.c                         |   16 +++---
 include/linux/sh_clk.h                       |    5 +-
 53 files changed, 429 insertions(+), 459 deletions(-)

---------------

Magnus Damm (35):
      sh: introduce sh_clk_ops in parallel with clk_ops
      sh: convert cpg code to sh_clk_ops
      ARM: mach-shmobile: sh7367 sh_clk_ops rename
      ARM: mach-shmobile: sh7377 sh_clk_ops rename
      ARM: mach-shmobile: sh7372 sh_clk_ops rename
      ARM: mach-shmobile: sh73a0 sh_clk_ops rename
      ARM: mach-shmobile: r8a7740 sh_clk_ops rename
      ARM: mach-shmobile: r8a7779 sh_clk_ops rename
      sh: sh header sh_clk_ops rename
      sh: sh2 sh_clk_ops rename
      sh: sh2a sh_clk_ops rename
      sh: sh3 sh_clk_ops rename
      sh: sh4 sh_clk_ops rename
      sh: sh4a sh_clk_ops rename
      sh: sh5 sh_clk_ops rename
      sh: board sh_clk_ops rename
      sh: remove clk_ops
      ARM: mach-shmobile: sh7367 map_io and init_early update
      ARM: mach-shmobile: sh7377 map_io and init_early update
      ARM: mach-shmobile: sh7372 map_io and init_early update
      ARM: mach-shmobile: sh73a0 map_io and init_early update
      ARM: mach-shmobile: r8a7740 map_io and init_early update
      ARM: mach-shmobile: r8a7779 map_io and init_early update
      ARM: mach-shmobile: r8a7779 L2 cache support
      ARM: mach-shmobile: rename clk_init() to shmobile_clk_init()
      ARM: mach-shmobile: Move sh7372 Mackerel external clk setup
      ARM: mach-shmobile: Move sh7372 AP4EVB external clk setup
      ARM: mach-shmobile: add shmobile_earlytimer_init()
      ARM: mach-shmobile: sh7367 and G3EVM timer rework
      ARM: mach-shmobile: sh7377 and G4EVM timer rework
      ARM: mach-shmobile: sh7372, AP4EVB and Mackerel timer rework
      ARM: mach-shmobile: sh73a0, AG5EVM and Kota2 timer rework
      ARM: mach-shmobile: r8a7740 and Bonito timer rework
      ARM: mach-shmobile: r8a7779 and Marzen timer rework
      ARM: mach-shmobile: default to no earlytimer

Re: [GIT PULL] Renesas SoC updates for v3.4

[Arnd Bergmann]

On Friday 09 March 2012, Rafael J. Wysocki wrote:
> Hi,
> 
> Please pull Renesas SoC updates for v3.4 since commit
> ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> 
>     mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> 
> with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef

Hi Rafael,

Please rebase this on an -rc release, otherwise we get a rather
messy history in the arm-soc tree.

>     ARM: mach-shmobile: default to no earlytimer
> 
> from the git repository at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
> 
> They include:
> 
> * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
>   possible future name space collision with common struct clk code.
> 
>   This also affects drivers that are shared with the sh architecture,
>   so the branch containing this part of the material, clk_ops-rename,
>   will be merged into the Paul Mundt's sh tree if necessary.
> 
> * Introduction of L2 Cache support for r8a7779.
> 
> * Conversion of the mach-shmobile subarch to properly use a per-SoC
>   map_io and separate init_early callback for early serial console
>   support on platforms where that is possible.
> 
> Magnus Damm is the author of all the changes.

For next time, I think it would be good to make those things separate pull
requests, since they are all rather big. In particular, the clk rework
could be a series by itself.

One thing I noticed while browsing through the patches was this hunk
that Rob should know about:

@@ -242,6 +243,10 @@ static struct platform_device *r8a7779_late_devices[] __initdata = {
 
 void __init r8a7779_add_standard_devices(void)
 {
+#ifdef CONFIG_CACHE_L2X0
+       /* Early BRESP enable, Shared attribute override enable, 64K*16way */
+       l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
+#endif
        r8a7779_pm_init();
 
        r8a7779_init_pm_domain(&r8a7779_sh4a);

Here you are abusing the __io() macro rather badly as a typecast. This breaks
with Rob's series to turn __io(foo) into a NULL pointer for the case where
PCI is disabled. I found a few more of these, mostly in mach-shmobile but
also some others:

arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
arch/arm/mach-cns3xxx/core.c:   gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
arch/arm/mach-cns3xxx/core.c:            __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
arch/arm/mach-cns3xxx/core.c:   u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
arch/arm/mach-cns3xxx/core.c:   cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
arch/arm/mach-cns3xxx/devices.c:        u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
arch/arm/mach-netx/generic.c:   vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs)            __io(NETX_VA_SYSTEM + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs)                     __io(NETX_VA_GPIO + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs)        __io(NETX_VA_PIO + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU           __io(NETX_VA_MIIMU)
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs)               __io(NETX_VA_PFIFO + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs)               __io(NETX_VA_MEMCR + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs)               __io(NETX_VA_DPMAS + (ofs))
arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs)   __io(NETX_VA_I2C, (ofs))
arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n)          __io(IO_ADDRESS(n))
arch/arm/mach-shmobile/board-ag5evm.c:  l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
arch/arm/mach-shmobile/board-bonito.c:  l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
arch/arm/mach-shmobile/board-kota2.c:   l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
arch/arm/mach-shmobile/include/mach/io.h:#define __io(a)                        ((void __iomem *)(a))
arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_dist_base = __io(0xf0001000);
arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_cpu_base = __io(0xf0000100);
arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_dist_base = __io(0xf0001000);
arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_cpu_base = __io(0xf0000100);
arch/arm/mach-shmobile/smp-r8a7779.c:   __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
arch/arm/mach-shmobile/smp-sh73a0.c:    if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(WUPCR));    /* wake up */
arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(SRESCR));   /* reset */
arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(0, __io(APARMBAREA));      /* 4k */
arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n)             __io(IO_ADDRESS(n))

These are all broken and need to be changed to something else before we add the
global definition for __io.

	Arnd

Re: [GIT PULL] Renesas SoC updates for v3.4

[Rob Herring]

On 03/09/2012 03:34 PM, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
>> Hi,
>>
>> Please pull Renesas SoC updates for v3.4 since commit
>> ce8fea7aa4ad9e3b40999a08622ef27c77159659:
>>
>>     mmap: EINVAL not ENOMEM when rejecting VM_GROWS
>>
>> with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> 
> Hi Rafael,
> 
> Please rebase this on an -rc release, otherwise we get a rather
> messy history in the arm-soc tree.
> 
>>     ARM: mach-shmobile: default to no earlytimer
>>
>> from the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
>>
>> They include:
>>
>> * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
>>   possible future name space collision with common struct clk code.
>>
>>   This also affects drivers that are shared with the sh architecture,
>>   so the branch containing this part of the material, clk_ops-rename,
>>   will be merged into the Paul Mundt's sh tree if necessary.
>>
>> * Introduction of L2 Cache support for r8a7779.
>>
>> * Conversion of the mach-shmobile subarch to properly use a per-SoC
>>   map_io and separate init_early callback for early serial console
>>   support on platforms where that is possible.
>>
>> Magnus Damm is the author of all the changes.
> 
> For next time, I think it would be good to make those things separate pull
> requests, since they are all rather big. In particular, the clk rework
> could be a series by itself.
> 
> One thing I noticed while browsing through the patches was this hunk
> that Rob should know about:
> 
> @@ -242,6 +243,10 @@ static struct platform_device *r8a7779_late_devices[] __initdata = {
>  
>  void __init r8a7779_add_standard_devices(void)
>  {
> +#ifdef CONFIG_CACHE_L2X0
> +       /* Early BRESP enable, Shared attribute override enable, 64K*16way */
> +       l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
> +#endif
>         r8a7779_pm_init();
>  
>         r8a7779_init_pm_domain(&r8a7779_sh4a);
> 
> Here you are abusing the __io() macro rather badly as a typecast. This breaks
> with Rob's series to turn __io(foo) into a NULL pointer for the case where
> PCI is disabled. I found a few more of these, mostly in mach-shmobile but
> also some others:
> 
> arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> arch/arm/mach-cns3xxx/core.c:   gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> arch/arm/mach-cns3xxx/core.c:            __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> arch/arm/mach-cns3xxx/core.c:   u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> arch/arm/mach-cns3xxx/core.c:   cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> arch/arm/mach-cns3xxx/devices.c:        u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> arch/arm/mach-netx/generic.c:   vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs)            __io(NETX_VA_SYSTEM + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs)                     __io(NETX_VA_GPIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs)        __io(NETX_VA_PIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU           __io(NETX_VA_MIIMU)
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs)               __io(NETX_VA_PFIFO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs)               __io(NETX_VA_MEMCR + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs)               __io(NETX_VA_DPMAS + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs)   __io(NETX_VA_I2C, (ofs))
> arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n)          __io(IO_ADDRESS(n))
> arch/arm/mach-shmobile/board-ag5evm.c:  l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> arch/arm/mach-shmobile/board-bonito.c:  l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> arch/arm/mach-shmobile/board-kota2.c:   l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> arch/arm/mach-shmobile/include/mach/io.h:#define __io(a)                        ((void __iomem *)(a))
> arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/smp-r8a7779.c:   __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> arch/arm/mach-shmobile/smp-sh73a0.c:    if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
> arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(WUPCR));    /* wake up */
> arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(SRESCR));   /* reset */
> arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(0, __io(APARMBAREA));      /* 4k */
> arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n)             __io(IO_ADDRESS(n))
> 
> These are all broken and need to be changed to something else before we add the
> global definition for __io.

Several platforms define IO_MEM for the purpose of casting the defines
to void __iomem *, so I'll make that common unless you have better
suggestion. I'd guess that changing the defines themselves will cause
lots of warnings in other places.

Rob

Re: [GIT PULL] Renesas SoC updates for v3.4

[Rafael J. Wysocki]

Hi,

On Friday, March 09, 2012, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > Please pull Renesas SoC updates for v3.4 since commit
> > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > 
> >     mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > 
> > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> 
> Hi Rafael,
> 
> Please rebase this on an -rc release, otherwise we get a rather
> messy history in the arm-soc tree.

Well, OK, I can rebase it on -rc7 if there is one, unless Paul
has already pulled from clk_ops-rename.  Paul?

> >     ARM: mach-shmobile: default to no earlytimer
> > 
> > from the git repository at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
> > 
> > They include:
> > 
> > * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
> >   possible future name space collision with common struct clk code.
> > 
> >   This also affects drivers that are shared with the sh architecture,
> >   so the branch containing this part of the material, clk_ops-rename,
> >   will be merged into the Paul Mundt's sh tree if necessary.
> > 
> > * Introduction of L2 Cache support for r8a7779.
> > 
> > * Conversion of the mach-shmobile subarch to properly use a per-SoC
> >   map_io and separate init_early callback for early serial console
> >   support on platforms where that is possible.
> > 
> > Magnus Damm is the author of all the changes.
> 
> For next time, I think it would be good to make those things separate pull
> requests, since they are all rather big. In particular, the clk rework
> could be a series by itself.

It is a series by itself.  You can readily pull it from clk_ops-rename even. :-)

I'm not sure, though, what exactly the point of this would be.

> One thing I noticed while browsing through the patches was this hunk
> that Rob should know about:
> 
> @@ -242,6 +243,10 @@ static struct platform_device *r8a7779_late_devices[] __initdata = {
>  
>  void __init r8a7779_add_standard_devices(void)
>  {
> +#ifdef CONFIG_CACHE_L2X0
> +       /* Early BRESP enable, Shared attribute override enable, 64K*16way */
> +       l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
> +#endif
>         r8a7779_pm_init();
>  
>         r8a7779_init_pm_domain(&r8a7779_sh4a);
> 
> Here you are abusing the __io() macro rather badly as a typecast. This breaks
> with Rob's series to turn __io(foo) into a NULL pointer for the case where
> PCI is disabled. I found a few more of these, mostly in mach-shmobile but
> also some others:
> 
> arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> arch/arm/mach-cns3xxx/core.c:   gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> arch/arm/mach-cns3xxx/core.c:            __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> arch/arm/mach-cns3xxx/core.c:   u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> arch/arm/mach-cns3xxx/core.c:   cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> arch/arm/mach-cns3xxx/devices.c:        u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> arch/arm/mach-netx/generic.c:   vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs)            __io(NETX_VA_SYSTEM + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs)                     __io(NETX_VA_GPIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs)        __io(NETX_VA_PIO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU           __io(NETX_VA_MIIMU)
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs)               __io(NETX_VA_PFIFO + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs)               __io(NETX_VA_MEMCR + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs)               __io(NETX_VA_DPMAS + (ofs))
> arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs)   __io(NETX_VA_I2C, (ofs))
> arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n)          __io(IO_ADDRESS(n))
> arch/arm/mach-shmobile/board-ag5evm.c:  l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> arch/arm/mach-shmobile/board-bonito.c:  l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> arch/arm/mach-shmobile/board-kota2.c:   l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> arch/arm/mach-shmobile/include/mach/io.h:#define __io(a)                        ((void __iomem *)(a))
> arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_dist_base = __io(0xf0001000);
> arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_cpu_base = __io(0xf0000100);
> arch/arm/mach-shmobile/smp-r8a7779.c:   __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> arch/arm/mach-shmobile/smp-sh73a0.c:    if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
> arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(WUPCR));    /* wake up */
> arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(SRESCR));   /* reset */
> arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(0, __io(APARMBAREA));      /* 4k */
> arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n)             __io(IO_ADDRESS(n))
> 
> These are all broken and need to be changed to something else before we add the
> global definition for __io.

While I generally agree with that, I think it's not super-urgent, is it?

Rafael

Re: [GIT PULL] Renesas SoC updates for v3.4

[Arnd Bergmann]

On Friday 09 March 2012, Rafael J. Wysocki wrote:
> Hi,
> 
> On Friday, March 09, 2012, Arnd Bergmann wrote:
> > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > Hi,
> > > 
> > > Please pull Renesas SoC updates for v3.4 since commit
> > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > 
> > >     mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > 
> > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > 
> > Hi Rafael,
> > 
> > Please rebase this on an -rc release, otherwise we get a rather
> > messy history in the arm-soc tree.
> 
> Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> has already pulled from clk_ops-rename.  Paul?

Why not rebase back to -rc6?

> > 
> > For next time, I think it would be good to make those things separate pull
> > requests, since they are all rather big. In particular, the clk rework
> > could be a series by itself.
> 
> It is a series by itself.  You can readily pull it from clk_ops-rename even. :-)
> 
> I'm not sure, though, what exactly the point of this would be.

Mostly it helps make obvious which things are logically connected.
Another reason is that when one of the branches has a problem, we
can still pull all the other ones. 
Finally, we sometimes make new topic branches in the arm-soc tree
when a lot of maintainers send similar things, e.g. we had a 
'next/clk' branch in the past that half of your patches would
have applied to (this time we don't have one of those). By having
more branches for logically separate things, it allows us to group
them in more flexible ways across platforms.

It's not very important this time, so I didn't ask you to rebase
them just for that.

> > arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> > arch/arm/mach-cns3xxx/core.c:   gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> > arch/arm/mach-cns3xxx/core.c:            __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> > arch/arm/mach-cns3xxx/core.c:   u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> > arch/arm/mach-cns3xxx/core.c:   cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> > arch/arm/mach-cns3xxx/devices.c:        u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> > arch/arm/mach-netx/generic.c:   vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs)            __io(NETX_VA_SYSTEM + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs)                     __io(NETX_VA_GPIO + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs)        __io(NETX_VA_PIO + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU           __io(NETX_VA_MIIMU)
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs)               __io(NETX_VA_PFIFO + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs)               __io(NETX_VA_MEMCR + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs)               __io(NETX_VA_DPMAS + (ofs))
> > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs)   __io(NETX_VA_I2C, (ofs))
> > arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n)          __io(IO_ADDRESS(n))
> > arch/arm/mach-shmobile/board-ag5evm.c:  l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> > arch/arm/mach-shmobile/board-bonito.c:  l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> > arch/arm/mach-shmobile/board-kota2.c:   l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> > arch/arm/mach-shmobile/include/mach/io.h:#define __io(a)                        ((void __iomem *)(a))
> > arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_dist_base = __io(0xf0001000);
> > arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_cpu_base = __io(0xf0000100);
> > arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_dist_base = __io(0xf0001000);
> > arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_cpu_base = __io(0xf0000100);
> > arch/arm/mach-shmobile/smp-r8a7779.c:   __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> > arch/arm/mach-shmobile/smp-sh73a0.c:    if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
> > arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(WUPCR));    /* wake up */
> > arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(SRESCR));   /* reset */
> > arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(0, __io(APARMBAREA));      /* 4k */
> > arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> > arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n)             __io(IO_ADDRESS(n))
> > 
> > These are all broken and need to be changed to something else before we add the
> > global definition for __io.
> 
> While I generally agree with that, I think it's not super-urgent, is it?

No, it's not. I just wanted to let you all know now so we don't forget it.

	Arnd

Re: [GIT PULL] Renesas SoC updates for v3.4

[Rafael J. Wysocki]

Hi,

On Friday, March 09, 2012, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > Hi,
> > > > 
> > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > > 
> > > >     mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > > 
> > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > > 
> > > Hi Rafael,
> > > 
> > > Please rebase this on an -rc release, otherwise we get a rather
> > > messy history in the arm-soc tree.
> > 
> > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > has already pulled from clk_ops-rename.  Paul?
> 
> Why not rebase back to -rc6?

Well, I can do that too, if I have to, but still I'd like to be sure that
Paul hasn't pulled from the clk_ops-rename branch yet.
 
> > > For next time, I think it would be good to make those things separate pull
> > > requests, since they are all rather big. In particular, the clk rework
> > > could be a series by itself.
> > 
> > It is a series by itself.  You can readily pull it from clk_ops-rename even. :-)
> > 
> > I'm not sure, though, what exactly the point of this would be.
> 
> Mostly it helps make obvious which things are logically connected.
> Another reason is that when one of the branches has a problem, we
> can still pull all the other ones. 
> Finally, we sometimes make new topic branches in the arm-soc tree
> when a lot of maintainers send similar things, e.g. we had a 
> 'next/clk' branch in the past that half of your patches would
> have applied to (this time we don't have one of those). By having
> more branches for logically separate things, it allows us to group
> them in more flexible ways across platforms.

OK

> It's not very important this time, so I didn't ask you to rebase
> them just for that.

OK, thanks!

> > > arnd@klappe2:~/linux-arm$ git grep -w __io arch/arm/mach-* | grep -v __typesafe
> > > arch/arm/mach-cns3xxx/core.c:   gic_init(0, 29, __io(CNS3XXX_TC11MP_GIC_DIST_BASE_VIRT),
> > > arch/arm/mach-cns3xxx/core.c:            __io(CNS3XXX_TC11MP_GIC_CPU_BASE_VIRT));
> > > arch/arm/mach-cns3xxx/core.c:   u32 __iomem *pm_base = __io(CNS3XXX_PM_BASE_VIRT);
> > > arch/arm/mach-cns3xxx/core.c:   cns3xxx_tmr1 = __io(CNS3XXX_TIMER1_2_3_BASE_VIRT);
> > > arch/arm/mach-cns3xxx/devices.c:        u32 __iomem *gpioa = __io(CNS3XXX_MISC_BASE_VIRT + 0x0014);
> > > arch/arm/mach-netx/generic.c:   vic_init(__io(io_p2v(NETX_PA_VIC)), 0, ~0, 0);
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_SYSTEM_REG(ofs)            __io(NETX_VA_SYSTEM + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_GPIO_REG(ofs)                     __io(NETX_VA_GPIO + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PIO_REG(ofs)        __io(NETX_VA_PIO + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MIIMU           __io(NETX_VA_MIIMU)
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_PFIFO_REG(ofs)               __io(NETX_VA_PFIFO + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_MEMCR_REG(ofs)               __io(NETX_VA_MEMCR + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_DPMAS_REG(ofs)               __io(NETX_VA_DPMAS + (ofs))
> > > arch/arm/mach-netx/include/mach/netx-regs.h:#define NETX_I2C_REG(ofs)   __io(NETX_VA_I2C, (ofs))
> > > arch/arm/mach-realview/include/mach/hardware.h:#define __io_address(n)          __io(IO_ADDRESS(n))
> > > arch/arm/mach-shmobile/board-ag5evm.c:  l2x0_init(__io(0xf0100000), 0x00460000, 0xc2000fff);
> > > arch/arm/mach-shmobile/board-bonito.c:  l2x0_init(__io(0xf0002000), 0x40440000, 0x82000fff);
> > > arch/arm/mach-shmobile/board-kota2.c:   l2x0_init(__io(0xf0100000), 0x40460000, 0x82000fff);
> > > arch/arm/mach-shmobile/include/mach/io.h:#define __io(a)                        ((void __iomem *)(a))
> > > arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_dist_base = __io(0xf0001000);
> > > arch/arm/mach-shmobile/intc-r8a7779.c:  void __iomem *gic_cpu_base = __io(0xf0000100);
> > > arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_dist_base = __io(0xf0001000);
> > > arch/arm/mach-shmobile/intc-sh73a0.c:   void __iomem *gic_cpu_base = __io(0xf0000100);
> > > arch/arm/mach-shmobile/smp-r8a7779.c:   __raw_writel(__pa(shmobile_secondary_vector), __io(AVECR));
> > > arch/arm/mach-shmobile/smp-sh73a0.c:    if (((__raw_readl(__io(PSTR)) >> (4 * cpu)) & 3) == 3)
> > > arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(WUPCR));    /* wake up */
> > > arch/arm/mach-shmobile/smp-sh73a0.c:            __raw_writel(1 << cpu, __io(SRESCR));   /* reset */
> > > arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(0, __io(APARMBAREA));      /* 4k */
> > > arch/arm/mach-shmobile/smp-sh73a0.c:    __raw_writel(__pa(shmobile_secondary_vector), __io(SBAR));
> > > arch/arm/mach-ux500/include/mach/hardware.h:#define __io_address(n)             __io(IO_ADDRESS(n))
> > > 
> > > These are all broken and need to be changed to something else before we add the
> > > global definition for __io.
> > 
> > While I generally agree with that, I think it's not super-urgent, is it?
> 
> No, it's not. I just wanted to let you all know now so we don't forget it.

OK

Thanks,
Rafael

Re: [GIT PULL] Renesas SoC updates for v3.4

[Arnd Bergmann]

On Friday 09 March 2012, Rafael J. Wysocki wrote:
> On Friday, March 09, 2012, Arnd Bergmann wrote:
> > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > Hi,
> > > 
> > > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > > Hi,
> > > > > 
> > > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > > > 
> > > > >     mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > > > 
> > > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > > > 
> > > > Hi Rafael,
> > > > 
> > > > Please rebase this on an -rc release, otherwise we get a rather
> > > > messy history in the arm-soc tree.
> > > 
> > > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > > has already pulled from clk_ops-rename.  Paul?
> > 
> > Why not rebase back to -rc6?
> 
> Well, I can do that too, if I have to, but still I'd like to be sure that
> Paul hasn't pulled from the clk_ops-rename branch yet.

The point is that there might not be an -rc7 any more. I'd suggest that
you rebase on -rc6 if Paul has not yet pulled them, otherwise we will
merge them in the current state and put an explanation into the merge
changeset.

	Arnd

Re: [GIT PULL] Renesas SoC updates for v3.4

[Rafael J. Wysocki]

On Saturday, March 10, 2012, Arnd Bergmann wrote:
> On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > Hi,
> > > > 
> > > > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > > > > 
> > > > > >     mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > > > > 
> > > > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > > > > 
> > > > > Hi Rafael,
> > > > > 
> > > > > Please rebase this on an -rc release, otherwise we get a rather
> > > > > messy history in the arm-soc tree.
> > > > 
> > > > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > > > has already pulled from clk_ops-rename.  Paul?
> > > 
> > > Why not rebase back to -rc6?
> > 
> > Well, I can do that too, if I have to, but still I'd like to be sure that
> > Paul hasn't pulled from the clk_ops-rename branch yet.
> 
> The point is that there might not be an -rc7 any more.

Yes, I'm aware of that. :-)

> I'd suggest that you rebase on -rc6 if Paul has not yet pulled them,

I'm still waiting for a word from Paul.

> otherwise we will merge them in the current state and put an explanation
> into the merge changeset.

Well, if there's no -rc7 (which means that the final v3.3 is released tomorrow)
or there's no information from Paul within the next few days, I'm afraid
rebasing won't be very safe.

Thanks a lot and sorry for the trouble (I think I didn't understand you
correctly when you said you wanted things to be based on -rc, I thought you
meant the Linus' tree in general and not specific commits).

Rafael

Re: [GIT PULL] Renesas SoC updates for v3.4

[Geert Uytterhoeven]

On Sat, Mar 10, 2012 at 22:26, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> The point is that there might not be an -rc7 any more.
>
> Yes, I'm aware of that. :-)

It seems there is.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] Renesas SoC updates for v3.4

[Paul Mundt]

On Fri, Mar 09, 2012 at 10:52:47PM +0100, Rafael J. Wysocki wrote:
> On Friday, March 09, 2012, Arnd Bergmann wrote:
> > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > Please pull Renesas SoC updates for v3.4 since commit
> > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > 
> > >     mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > 
> > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > 
> > Hi Rafael,
> > 
> > Please rebase this on an -rc release, otherwise we get a rather
> > messy history in the arm-soc tree.
> 
> Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> has already pulled from clk_ops-rename.  Paul?
> 
Nope, I haven't had a chance yet. Feel free to rebase as necessary and
I'll grab them afterwards.

Re: [GIT PULL] Renesas SoC updates for v3.4

[Rafael J. Wysocki]

On Monday, March 12, 2012, Paul Mundt wrote:
> On Fri, Mar 09, 2012 at 10:52:47PM +0100, Rafael J. Wysocki wrote:
> > On Friday, March 09, 2012, Arnd Bergmann wrote:
> > > On Friday 09 March 2012, Rafael J. Wysocki wrote:
> > > > Please pull Renesas SoC updates for v3.4 since commit
> > > > ce8fea7aa4ad9e3b40999a08622ef27c77159659:
> > > > 
> > > >     mmap: EINVAL not ENOMEM when rejecting VM_GROWS
> > > > 
> > > > with top-most commit f57fd2100e8273af3a9d2ff67714903d2dfd1eef
> > > 
> > > Hi Rafael,
> > > 
> > > Please rebase this on an -rc release, otherwise we get a rather
> > > messy history in the arm-soc tree.
> > 
> > Well, OK, I can rebase it on -rc7 if there is one, unless Paul
> > has already pulled from clk_ops-rename.  Paul?
> > 
> Nope, I haven't had a chance yet. Feel free to rebase as necessary and
> I'll grab them afterwards.

Thanks, I've just rebased clk_ops-rename on top of -rc7.

Rafael

[GIT PULL] Renesas SoC updates for v3.4, take 2

[Rafael J. Wysocki]

Hi,

Please pull Renesas SoC updates for v3.4 since commit
fde7d9049e55ab85a390be7f415d74c9f62dd0f9

    Linux 3.3-rc7

with top-most commit 2854903ad1329d09d7ec35639fff0949e45d496d

    ARM: mach-shmobile: default to no earlytimer

from the git repository at:

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

They include:

* The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
  possible future name space collision with common struct clk code.

  This also affects drivers that are shared with the sh architecture,
  so the branch containing this part of the material, clk_ops-rename,
  will be merged into the Paul Mundt's sh tree if necessary.

* Introduction of L2 Cache support for r8a7779.

* Conversion of the mach-shmobile subarch to properly use a per-SoC
  map_io and separate init_early callback for early serial console
  support on platforms where that is possible.

Magnus Damm is the author of all the changes.


 arch/arm/mach-shmobile/board-ag5evm.c        |   39 +---------------
 arch/arm/mach-shmobile/board-ap4evb.c        |   44 +++----------------
 arch/arm/mach-shmobile/board-bonito.c        |   44 +++++-------------
 arch/arm/mach-shmobile/board-g3evm.c         |   38 +--------------
 arch/arm/mach-shmobile/board-g4evm.c         |   38 +--------------
 arch/arm/mach-shmobile/board-kota2.c         |   38 +--------------
 arch/arm/mach-shmobile/board-mackerel.c      |   44 +++----------------
 arch/arm/mach-shmobile/board-marzen.c        |   62 +------------------------
 arch/arm/mach-shmobile/clock-r8a7740.c       |    8 ++--
 arch/arm/mach-shmobile/clock-r8a7779.c       |    4 +-
 arch/arm/mach-shmobile/clock-sh7367.c        |    8 ++--
 arch/arm/mach-shmobile/clock-sh7372.c        |   10 ++--
 arch/arm/mach-shmobile/clock-sh7377.c        |    8 ++--
 arch/arm/mach-shmobile/clock-sh73a0.c        |   14 +++---
 arch/arm/mach-shmobile/clock.c               |    2 +-
 arch/arm/mach-shmobile/include/mach/common.h |    9 +++-
 arch/arm/mach-shmobile/setup-r8a7740.c       |   45 +++++++++++++++++++
 arch/arm/mach-shmobile/setup-r8a7779.c       |   54 ++++++++++++++++++++++
 arch/arm/mach-shmobile/setup-sh7367.c        |   32 +++++++++++++
 arch/arm/mach-shmobile/setup-sh7372.c        |   32 +++++++++++++
 arch/arm/mach-shmobile/setup-sh7377.c        |   32 +++++++++++++
 arch/arm/mach-shmobile/setup-sh73a0.c        |   32 +++++++++++++
 arch/arm/mach-shmobile/timer.c               |    6 ++-
 arch/sh/boards/mach-highlander/setup.c       |    2 +-
 arch/sh/boards/mach-sdk7786/setup.c          |    2 +-
 arch/sh/include/asm/clock.h                  |    2 +-
 arch/sh/kernel/cpu/sh2/clock-sh7619.c        |   12 +++---
 arch/sh/kernel/cpu/sh2a/clock-sh7201.c       |   12 +++---
 arch/sh/kernel/cpu/sh2a/clock-sh7203.c       |   12 +++---
 arch/sh/kernel/cpu/sh2a/clock-sh7206.c       |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh3.c           |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7705.c        |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7706.c        |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7709.c        |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7710.c        |   12 +++---
 arch/sh/kernel/cpu/sh3/clock-sh7712.c        |   10 ++--
 arch/sh/kernel/cpu/sh4/clock-sh4-202.c       |    6 +-
 arch/sh/kernel/cpu/sh4/clock-sh4.c           |   12 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7343.c       |    4 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7366.c       |    4 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7722.c       |    4 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7723.c       |    4 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7724.c       |    6 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7757.c       |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7763.c       |   14 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7770.c       |   12 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7780.c       |   14 +++---
 arch/sh/kernel/cpu/sh4a/clock-sh7785.c       |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-sh7786.c       |    2 +-
 arch/sh/kernel/cpu/sh4a/clock-shx3.c         |    2 +-
 arch/sh/kernel/cpu/sh5/clock-sh5.c           |   12 +++---
 drivers/sh/clk/cpg.c                         |   16 +++---
 include/linux/sh_clk.h                       |    5 +-
 53 files changed, 429 insertions(+), 459 deletions(-)

---------------

Magnus Damm (35):
      sh: introduce sh_clk_ops in parallel with clk_ops
      sh: convert cpg code to sh_clk_ops
      ARM: mach-shmobile: sh7367 sh_clk_ops rename
      ARM: mach-shmobile: sh7377 sh_clk_ops rename
      ARM: mach-shmobile: sh7372 sh_clk_ops rename
      ARM: mach-shmobile: sh73a0 sh_clk_ops rename
      ARM: mach-shmobile: r8a7740 sh_clk_ops rename
      ARM: mach-shmobile: r8a7779 sh_clk_ops rename
      sh: sh header sh_clk_ops rename
      sh: sh2 sh_clk_ops rename
      sh: sh2a sh_clk_ops rename
      sh: sh3 sh_clk_ops rename
      sh: sh4 sh_clk_ops rename
      sh: sh4a sh_clk_ops rename
      sh: sh5 sh_clk_ops rename
      sh: board sh_clk_ops rename
      sh: remove clk_ops
      ARM: mach-shmobile: sh7367 map_io and init_early update
      ARM: mach-shmobile: sh7377 map_io and init_early update
      ARM: mach-shmobile: sh7372 map_io and init_early update
      ARM: mach-shmobile: sh73a0 map_io and init_early update
      ARM: mach-shmobile: r8a7740 map_io and init_early update
      ARM: mach-shmobile: r8a7779 map_io and init_early update
      ARM: mach-shmobile: r8a7779 L2 cache support
      ARM: mach-shmobile: rename clk_init() to shmobile_clk_init()
      ARM: mach-shmobile: Move sh7372 Mackerel external clk setup
      ARM: mach-shmobile: Move sh7372 AP4EVB external clk setup
      ARM: mach-shmobile: add shmobile_earlytimer_init()
      ARM: mach-shmobile: sh7367 and G3EVM timer rework
      ARM: mach-shmobile: sh7377 and G4EVM timer rework
      ARM: mach-shmobile: sh7372, AP4EVB and Mackerel timer rework
      ARM: mach-shmobile: sh73a0, AG5EVM and Kota2 timer rework
      ARM: mach-shmobile: r8a7740 and Bonito timer rework
      ARM: mach-shmobile: r8a7779 and Marzen timer rework
      ARM: mach-shmobile: default to no earlytimer

Re: [GIT PULL] Renesas SoC updates for v3.4, take 2

[Arnd Bergmann]

On Monday 12 March 2012, Rafael J. Wysocki wrote:
> Please pull Renesas SoC updates for v3.4 since commit
> fde7d9049e55ab85a390be7f415d74c9f62dd0f9
> 
>     Linux 3.3-rc7
> 
> with top-most commit 2854903ad1329d09d7ec35639fff0949e45d496d
> 
>     ARM: mach-shmobile: default to no earlytimer
> 
> from the git repository at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
> 
> They include:
> 
> * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
>   possible future name space collision with common struct clk code.
> 
>   This also affects drivers that are shared with the sh architecture,
>   so the branch containing this part of the material, clk_ops-rename,
>   will be merged into the Paul Mundt's sh tree if necessary.
> 
> * Introduction of L2 Cache support for r8a7779.
> 
> * Conversion of the mach-shmobile subarch to properly use a per-SoC
>   map_io and separate init_early callback for early serial console
>   support on platforms where that is possible.
> 
> Magnus Damm is the author of all the changes.
> 

Thanks for rebasing this, Olof will merge this soon. Note that the
__io() issue has turned out to be more urgent than I first thought
when we discussed it, so it would be good to apply the patch below
on top of your series.

	Arnd

8<-----
ARM: shmobile: remove additional __io() macro use

setup-r8a7779.c has grown a new user of the __io() macro. Rob Herring's
PIO cleanup series already gets rid of all other uses in shmobile, so
we should ensure that this one gets removed as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
index ce57d90..9545d82 100644
--- a/arch/arm/mach-shmobile/setup-r8a7779.c
+++ b/arch/arm/mach-shmobile/setup-r8a7779.c
@@ -246,7 +246,7 @@ void __init r8a7779_add_standard_devices(void)
 {
 #ifdef CONFIG_CACHE_L2X0
 	/* Early BRESP enable, Shared attribute override enable, 64K*16way */
-	l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
+	l2x0_init((void __iomem __force *)(0xf0100000), 0x40470000, 0x82000fff);
 #endif
 	r8a7779_pm_init();
 

Re: [GIT PULL] Renesas SoC updates for v3.4, take 2

[Rafael J. Wysocki]

On Tuesday, March 13, 2012, Arnd Bergmann wrote:
> On Monday 12 March 2012, Rafael J. Wysocki wrote:
> > Please pull Renesas SoC updates for v3.4 since commit
> > fde7d9049e55ab85a390be7f415d74c9f62dd0f9
> > 
> >     Linux 3.3-rc7
> > 
> > with top-most commit 2854903ad1329d09d7ec35639fff0949e45d496d
> > 
> >     ARM: mach-shmobile: default to no earlytimer
> > 
> > from the git repository at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/renesas.git soc
> > 
> > They include:
> > 
> > * The rename of shmobile struct clk_ops to struct sh_clk_ops to avoid
> >   possible future name space collision with common struct clk code.
> > 
> >   This also affects drivers that are shared with the sh architecture,
> >   so the branch containing this part of the material, clk_ops-rename,
> >   will be merged into the Paul Mundt's sh tree if necessary.
> > 
> > * Introduction of L2 Cache support for r8a7779.
> > 
> > * Conversion of the mach-shmobile subarch to properly use a per-SoC
> >   map_io and separate init_early callback for early serial console
> >   support on platforms where that is possible.
> > 
> > Magnus Damm is the author of all the changes.
> > 
> 
> Thanks for rebasing this, Olof will merge this soon.

Thanks!

> Note that the __io() issue has turned out to be more urgent than I first
> thought when we discussed it, so it would be good to apply the patch below
> on top of your series.

Do you want me to apply it now or will you do that in your tree?

Rafael


> 8<-----
> ARM: shmobile: remove additional __io() macro use
> 
> setup-r8a7779.c has grown a new user of the __io() macro. Rob Herring's
> PIO cleanup series already gets rid of all other uses in shmobile, so
> we should ensure that this one gets removed as well.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> diff --git a/arch/arm/mach-shmobile/setup-r8a7779.c b/arch/arm/mach-shmobile/setup-r8a7779.c
> index ce57d90..9545d82 100644
> --- a/arch/arm/mach-shmobile/setup-r8a7779.c
> +++ b/arch/arm/mach-shmobile/setup-r8a7779.c
> @@ -246,7 +246,7 @@ void __init r8a7779_add_standard_devices(void)
>  {
>  #ifdef CONFIG_CACHE_L2X0
>  	/* Early BRESP enable, Shared attribute override enable, 64K*16way */
> -	l2x0_init(__io(0xf0100000), 0x40470000, 0x82000fff);
> +	l2x0_init((void __iomem __force *)(0xf0100000), 0x40470000, 0x82000fff);
>  #endif
>  	r8a7779_pm_init();
>  
> 
> 

Re: [GIT PULL] Renesas SoC updates for v3.4, take 2

[Arnd Bergmann]

On Tuesday 13 March 2012, Rafael J. Wysocki wrote:
> > Note that the __io() issue has turned out to be more urgent than I first
> > thought when we discussed it, so it would be good to apply the patch below
> > on top of your series.
> 
> Do you want me to apply it now or will you do that in your tree?

Doesn't matter to me, as long as one of you applies it ;-)

	Arnd

Re: [GIT PULL] Renesas SoC updates for v3.4, take 2

[Rafael J. Wysocki]

On Tuesday, March 13, 2012, Arnd Bergmann wrote:
> On Tuesday 13 March 2012, Rafael J. Wysocki wrote:
> > > Note that the __io() issue has turned out to be more urgent than I first
> > > thought when we discussed it, so it would be good to apply the patch below
> > > on top of your series.
> > 
> > Do you want me to apply it now or will you do that in your tree?
> 
> Doesn't matter to me, as long as one of you applies it ;-)

OK, so I will add it to the soc branch in the Renesas tree.

Thanks,
Rafael

Re: [GIT PULL] Renesas SoC updates for v3.4, take 2

[Rafael J. Wysocki]

On Tuesday, March 13, 2012, Rafael J. Wysocki wrote:
> On Tuesday, March 13, 2012, Arnd Bergmann wrote:
> > On Tuesday 13 March 2012, Rafael J. Wysocki wrote:
> > > > Note that the __io() issue has turned out to be more urgent than I first
> > > > thought when we discussed it, so it would be good to apply the patch below
> > > > on top of your series.
> > > 
> > > Do you want me to apply it now or will you do that in your tree?
> > 
> > Doesn't matter to me, as long as one of you applies it ;-)
> 
> OK, so I will add it to the soc branch in the Renesas tree.

Applied and pushed back the updated tree.

Thanks,
Rafael

Re: [GIT PULL] Renesas SoC updates for v3.4, take 2

[Olof Johansson]

On Tue, Mar 13, 2012 at 2:42 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Tuesday, March 13, 2012, Rafael J. Wysocki wrote:
>> On Tuesday, March 13, 2012, Arnd Bergmann wrote:
>> > On Tuesday 13 March 2012, Rafael J. Wysocki wrote:
>> > > > Note that the __io() issue has turned out to be more urgent than I first
>> > > > thought when we discussed it, so it would be good to apply the patch below
>> > > > on top of your series.
>> > >
>> > > Do you want me to apply it now or will you do that in your tree?
>> >
>> > Doesn't matter to me, as long as one of you applies it ;-)
>>
>> OK, so I will add it to the soc branch in the Renesas tree.
>
> Applied and pushed back the updated tree.

Seems like you applied the patch but without the subject line, so now
git thinks the whole first paragraph is the patch subject. That's a
bit messy and I'd prefer if you could fix it up.

Do you have downstream users of your tree that you'll mess up if you
rebase the last commit though? Alternatively I can take everything on
the branch but the last patch and apply it myself, but that will still
cause trouble for your downstream developers once things go upstream
and come down.


-Olof

Re: [GIT PULL] Renesas SoC updates for v3.4, take 2

[Rafael J. Wysocki]

On Wednesday, March 14, 2012, Olof Johansson wrote:
> On Tue, Mar 13, 2012 at 2:42 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Tuesday, March 13, 2012, Rafael J. Wysocki wrote:
> >> On Tuesday, March 13, 2012, Arnd Bergmann wrote:
> >> > On Tuesday 13 March 2012, Rafael J. Wysocki wrote:
> >> > > > Note that the __io() issue has turned out to be more urgent than I first
> >> > > > thought when we discussed it, so it would be good to apply the patch below
> >> > > > on top of your series.
> >> > >
> >> > > Do you want me to apply it now or will you do that in your tree?
> >> >
> >> > Doesn't matter to me, as long as one of you applies it ;-)
> >>
> >> OK, so I will add it to the soc branch in the Renesas tree.
> >
> > Applied and pushed back the updated tree.
> 
> Seems like you applied the patch but without the subject line,

I didn't notice that, sorry.

> so now git thinks the whole first paragraph is the patch subject. That's a
> bit messy and I'd prefer if you could fix it up.

I've just replaced the broken commit with a new fixed one.

> Do you have downstream users of your tree that you'll mess up if you
> rebase the last commit though? Alternatively I can take everything on
> the branch but the last patch and apply it myself, but that will still
> cause trouble for your downstream developers once things go upstream
> and come down.

Hopefully, no one has pulled from the tree yet. :-)

Thanks,
Rafael

Re: [GIT PULL] Renesas SoC updates for v3.4, take 2

[Olof Johansson]

On Tue, Mar 13, 2012 at 5:16 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Wednesday, March 14, 2012, Olof Johansson wrote:
>> On Tue, Mar 13, 2012 at 2:42 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > On Tuesday, March 13, 2012, Rafael J. Wysocki wrote:
>> >> On Tuesday, March 13, 2012, Arnd Bergmann wrote:
>> >> > On Tuesday 13 March 2012, Rafael J. Wysocki wrote:
>> >> > > > Note that the __io() issue has turned out to be more urgent than I first
>> >> > > > thought when we discussed it, so it would be good to apply the patch below
>> >> > > > on top of your series.
>> >> > >
>> >> > > Do you want me to apply it now or will you do that in your tree?
>> >> >
>> >> > Doesn't matter to me, as long as one of you applies it ;-)
>> >>
>> >> OK, so I will add it to the soc branch in the Renesas tree.
>> >
>> > Applied and pushed back the updated tree.
>>
>> Seems like you applied the patch but without the subject line,
>
> I didn't notice that, sorry.
>
>> so now git thinks the whole first paragraph is the patch subject. That's a
>> bit messy and I'd prefer if you could fix it up.
>
> I've just replaced the broken commit with a new fixed one.
>
>> Do you have downstream users of your tree that you'll mess up if you
>> rebase the last commit though? Alternatively I can take everything on
>> the branch but the last patch and apply it myself, but that will still
>> cause trouble for your downstream developers once things go upstream
>> and come down.
>
> Hopefully, no one has pulled from the tree yet. :-)

Cool. Pulled into next/soc. Thanks!!

-Olof

Re: [GIT PULL] Renesas SoC updates for v3.4, take 2

[Rafael J. Wysocki]

On Wednesday, March 14, 2012, Olof Johansson wrote:
> On Tue, Mar 13, 2012 at 5:16 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Wednesday, March 14, 2012, Olof Johansson wrote:
> >> On Tue, Mar 13, 2012 at 2:42 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > On Tuesday, March 13, 2012, Rafael J. Wysocki wrote:
> >> >> On Tuesday, March 13, 2012, Arnd Bergmann wrote:
> >> >> > On Tuesday 13 March 2012, Rafael J. Wysocki wrote:
> >> >> > > > Note that the __io() issue has turned out to be more urgent than I first
> >> >> > > > thought when we discussed it, so it would be good to apply the patch below
> >> >> > > > on top of your series.
> >> >> > >
> >> >> > > Do you want me to apply it now or will you do that in your tree?
> >> >> >
> >> >> > Doesn't matter to me, as long as one of you applies it ;-)
> >> >>
> >> >> OK, so I will add it to the soc branch in the Renesas tree.
> >> >
> >> > Applied and pushed back the updated tree.
> >>
> >> Seems like you applied the patch but without the subject line,
> >
> > I didn't notice that, sorry.
> >
> >> so now git thinks the whole first paragraph is the patch subject. That's a
> >> bit messy and I'd prefer if you could fix it up.
> >
> > I've just replaced the broken commit with a new fixed one.
> >
> >> Do you have downstream users of your tree that you'll mess up if you
> >> rebase the last commit though? Alternatively I can take everything on
> >> the branch but the last patch and apply it myself, but that will still
> >> cause trouble for your downstream developers once things go upstream
> >> and come down.
> >
> > Hopefully, no one has pulled from the tree yet. :-)
> 
> Cool. Pulled into next/soc. Thanks!!

Great, thanks a lot!

Rafael