[PATCH v4 03/13] soc: renesas: rcar-sysc: Make rcar_sysc_init() init the PM domains

[PATCH v4 03/13] soc: renesas: rcar-sysc: Make rcar_sysc_init() init the PM domains

[Ulrich Hecht]

Thanks for the patch.

On Thu, Jun 16, 2016 at 12:27 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Let rcar_sysc_init() trigger initialization of the SYSC PM domains from
> DT if called before the early_initcall.
> On failure, it falls back to mapping the passed register block, as
> before.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v4:
>   - New.
> ---
>  drivers/soc/renesas/rcar-sysc.c | 20 +++++++++++---------
>  1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
> index 59a8152681a59a5c..68d6856c9d3cd192 100644
> --- a/drivers/soc/renesas/rcar-sysc.c
> +++ b/drivers/soc/renesas/rcar-sysc.c
> @@ -164,15 +164,6 @@ static bool rcar_sysc_power_is_off(const struct rcar_sysc_ch *sysc_ch)
>         return false;
>  }
>
> -void __iomem *rcar_sysc_init(phys_addr_t base)
> -{
> -       rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
> -       if (!rcar_sysc_base)
> -               panic("unable to ioremap R-Car SYSC hardware block\n");

Is this check no longer necessary?

> -
> -       return rcar_sysc_base;
> -}
> -
>  struct rcar_sysc_pd {
>         struct generic_pm_domain genpd;
>         struct rcar_sysc_ch ch;
> @@ -328,6 +319,9 @@ static int __init rcar_sysc_pd_init(void)
>         unsigned int i;
>         int error;
>
> +       if (rcar_sysc_base)
> +               return 0;
> +
>         np = of_find_matching_node_and_match(NULL, rcar_sysc_matches, &match);
>         if (!np)
>                 return -ENODEV;
> @@ -405,3 +399,11 @@ out_put:
>         return error;
>  }
>  early_initcall(rcar_sysc_pd_init);
> +
> +void __iomem * __init rcar_sysc_init(phys_addr_t base)
> +{
> +       if (rcar_sysc_pd_init())
> +               rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
> +
> +       return rcar_sysc_base;
> +}
> --
> 1.9.1
>

CU
Uli

[PATCH v4 03/13] soc: renesas: rcar-sysc: Make rcar_sysc_init() init the PM domains

[Geert Uytterhoeven]

Hi Ulrich,

On Fri, Jun 17, 2016 at 5:57 PM, Ulrich Hecht <ulrich.hecht@gmail.com> wrote:
>> --- a/drivers/soc/renesas/rcar-sysc.c
>> +++ b/drivers/soc/renesas/rcar-sysc.c
>> @@ -164,15 +164,6 @@ static bool rcar_sysc_power_is_off(const struct rcar_sysc_ch *sysc_ch)
>>         return false;
>>  }
>>
>> -void __iomem *rcar_sysc_init(phys_addr_t base)
>> -{
>> -       rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
>> -       if (!rcar_sysc_base)
>> -               panic("unable to ioremap R-Car SYSC hardware block\n");
>
> Is this check no longer necessary?

If this failed (out of memory) this early in the boot process, we're gonna die
anyway.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH v4 04/13] soc: renesas: rcar-sysc: Move SYSC interrupt config to rcar-sysc driver

[Ulrich Hecht]

On Thu, Jun 16, 2016 at 12:27 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> On R-Car H1 and Gen2, the SYSC interrupt registers are always configured
> using hardcoded values in platform code. For R-Car Gen2, values are
> provided for H2 and M2-W only, other SoCs are not yet supported, and
> never will be.
>
> Move this configuration from SoC-specific platform code to the
> rcar_sysc_init() wrapper, so it can be skipped if the SYSC is configured
> from DT. This would be the case not only for H1, H2, and M2-W using a
> modern DTS, but also for other R-Car Gen2 SoCs not supported by the
> platform code, relying purely on DT.
>
> There is no longer a need to return the mapped register block, hence
> make the function return void.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v4:
>   - New.
> ---
>  arch/arm/mach-shmobile/pm-r8a7779.c   |  6 +-----
>  arch/arm/mach-shmobile/pm-rcar-gen2.c |  6 +-----
>  drivers/soc/renesas/rcar-sysc.c       | 12 ++++++++----
>  include/linux/soc/renesas/rcar-sysc.h |  2 +-
>  4 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-shmobile/pm-r8a7779.c b/arch/arm/mach-shmobile/pm-r8a7779.c
> index 4174cbcbc467d047..5c9a93f5e650181a 100644
> --- a/arch/arm/mach-shmobile/pm-r8a7779.c
> +++ b/arch/arm/mach-shmobile/pm-r8a7779.c
> @@ -23,11 +23,7 @@
>
>  static void __init r8a7779_sysc_init(void)
>  {
> -       void __iomem *base = rcar_sysc_init(0xffd85000);
> -
> -       /* enable all interrupt sources, but do not use interrupt handler */
> -       iowrite32(0x0131000e, base + SYSCIER);
> -       iowrite32(0, base + SYSCIMR);
> +       rcar_sysc_init(0xffd85000, 0x0131000e);
>  }
>
>  #else /* CONFIG_PM || CONFIG_SMP */
> diff --git a/arch/arm/mach-shmobile/pm-rcar-gen2.c b/arch/arm/mach-shmobile/pm-rcar-gen2.c
> index 61361dac6068210a..dd9ac366868f4336 100644
> --- a/arch/arm/mach-shmobile/pm-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/pm-rcar-gen2.c
> @@ -36,11 +36,7 @@
>
>  static void __init rcar_gen2_sysc_init(u32 syscier)
>  {
> -       void __iomem *base = rcar_sysc_init(0xe6180000);
> -
> -       /* enable all interrupt sources, but do not use interrupt handler */
> -       iowrite32(syscier, base + SYSCIER);
> -       iowrite32(0, base + SYSCIMR);
> +       rcar_sysc_init(0xe6180000, syscier);
>  }
>
>  #else /* CONFIG_SMP */
> diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
> index 68d6856c9d3cd192..22f0d646225c444e 100644
> --- a/drivers/soc/renesas/rcar-sysc.c
> +++ b/drivers/soc/renesas/rcar-sysc.c
> @@ -400,10 +400,14 @@ out_put:
>  }
>  early_initcall(rcar_sysc_pd_init);
>
> -void __iomem * __init rcar_sysc_init(phys_addr_t base)
> +void __init rcar_sysc_init(phys_addr_t base, u32 syscier)
>  {
> -       if (rcar_sysc_pd_init())
> -               rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
> +       if (!rcar_sysc_pd_init())
> +               return;
>
> -       return rcar_sysc_base;
> +       rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
> +
> +       /* enable all interrupt sources, but do not use interrupt handler */
> +       iowrite32(syscier, rcar_sysc_base + SYSCIER);
> +       iowrite32(0, rcar_sysc_base + SYSCIMR);
>  }
> diff --git a/include/linux/soc/renesas/rcar-sysc.h b/include/linux/soc/renesas/rcar-sysc.h
> index 92fc613ab23db091..7b8b280c181b8389 100644
> --- a/include/linux/soc/renesas/rcar-sysc.h
> +++ b/include/linux/soc/renesas/rcar-sysc.h
> @@ -11,6 +11,6 @@ struct rcar_sysc_ch {
>
>  int rcar_sysc_power_down(const struct rcar_sysc_ch *sysc_ch);
>  int rcar_sysc_power_up(const struct rcar_sysc_ch *sysc_ch);
> -void __iomem *rcar_sysc_init(phys_addr_t base);
> +void rcar_sysc_init(phys_addr_t base, u32 syscier);
>
>  #endif /* __LINUX_SOC_RENESAS_RCAR_SYSC_H__ */
> --
> 1.9.1
>

Reviewed-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>

CU
Uli

[PATCH v4 05/13] soc: renesas: rcar-sysc: Improve SYSC interrupt config in legacy wrapper

[Ulrich Hecht]

On Thu, Jun 16, 2016 at 12:27 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Align SYSC interrupt configuration in the legacy wrapper with the DT
> version:
>   - Mask SYSC interrupt sources before enabling them (doesn't matter
>     much as they're disabled at the GIC level anyway),
>   - Make sure not to clear reserved SYSCIMR bits that were set before.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v4:
>   - New.
> ---
>  drivers/soc/renesas/rcar-sysc.c | 17 +++++++++++++++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
> index 22f0d646225c444e..65c8e1eb90c09bb3 100644
> --- a/drivers/soc/renesas/rcar-sysc.c
> +++ b/drivers/soc/renesas/rcar-sysc.c
> @@ -402,12 +402,25 @@ early_initcall(rcar_sysc_pd_init);
>
>  void __init rcar_sysc_init(phys_addr_t base, u32 syscier)
>  {
> +       u32 syscimr;
> +
>         if (!rcar_sysc_pd_init())
>                 return;
>
>         rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
>
> -       /* enable all interrupt sources, but do not use interrupt handler */
> +       /*
> +        * Mask all interrupt sources to prevent the CPU from receiving them.
> +        * Make sure not to clear reserved bits that were set before.
> +        */
> +       syscimr = ioread32(rcar_sysc_base + SYSCIMR);
> +       syscimr |= syscier;
> +       pr_debug("%s: syscimr = 0x%08x\n", __func__, syscimr);
> +       iowrite32(syscimr, rcar_sysc_base + SYSCIMR);
> +
> +       /*
> +        * SYSC needs all interrupt sources enabled to control power.
> +        */
> +       pr_debug("%s: syscier = 0x%08x\n", __func__, syscier);
>         iowrite32(syscier, rcar_sysc_base + SYSCIER);
> -       iowrite32(0, rcar_sysc_base + SYSCIMR);
>  }
> --
> 1.9.1
>

Reviewed-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>

CU
Uli

[PATCH v4 06/13] ARM: shmobile: apmu: Move #ifdef CONFIG_SMP to cover more functions

[Ulrich Hecht]

On Thu, Jun 16, 2016 at 12:27 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> shmobile_smp_apmu_prepare_cpus() is used only if CONFIG_SMP=y.
>
> Hence move the #ifdef to cover shmobile_smp_apmu_prepare_cpus() and all
> functions only called by it (apmu_init_cpu() and apmu_parse_cfg()).
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v4:
>   - New.
> ---
>  arch/arm/mach-shmobile/platsmp-apmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c b/arch/arm/mach-shmobile/platsmp-apmu.c
> index aba75c89f9c1c5eb..c1558ef0c590dd3e 100644
> --- a/arch/arm/mach-shmobile/platsmp-apmu.c
> +++ b/arch/arm/mach-shmobile/platsmp-apmu.c
> @@ -74,6 +74,7 @@ static int __maybe_unused apmu_wrap(int cpu, int (*fn)(void __iomem *p, int cpu)
>         return p ? fn(p, apmu_cpus[cpu].bit) : -EINVAL;
>  }
>
> +#ifdef CONFIG_SMP
>  static void apmu_init_cpu(struct resource *res, int cpu, int bit)
>  {
>         if ((cpu >= ARRAY_SIZE(apmu_cpus)) || apmu_cpus[cpu].iomem)
> @@ -128,7 +129,6 @@ void __init shmobile_smp_apmu_prepare_cpus(unsigned int max_cpus,
>         apmu_parse_cfg(apmu_init_cpu, apmu_config, num);
>  }
>
> -#ifdef CONFIG_SMP
>  int shmobile_smp_apmu_boot_secondary(unsigned int cpu, struct task_struct *idle)
>  {
>         /* For this particular CPU register boot vector */
> --
> 1.9.1
>

Reviewed-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>

CU
Uli

[PATCH v4 13/13] ARM: dts: r8a7793: Add APMU node and second CPU core

[Sergei Shtylyov]

On 06/16/2016 01:27 PM, Geert Uytterhoeven wrote:

> From: Magnus Damm <damm+renesas@opensource.se>
>
> Add DT nodes for the Advanced Power Management Unit (APMU) and the
> second CPU core.  Use the enable-method to point out that the APMU
> should be used for SMP support.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> v4:
>   - Improve patch description,
>   - Use "renesas,<soctype>-apmu" instead of "renesas,apmu-<soctype>",
>
> v3:
>   - New.
> ---
>  arch/arm/boot/dts/r8a7793.dtsi | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
> index 9b55c1c6ee31a49d..fce310c54efa88eb 100644
> --- a/arch/arm/boot/dts/r8a7793.dtsi
> +++ b/arch/arm/boot/dts/r8a7793.dtsi
[...]
> @@ -56,6 +57,13 @@
>  			next-level-cache = <&L2_CA15>;
>  		};
>
> +		cpu1: cpu at 1 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a15";
> +			reg = <1>;
> +			clock-frequency = <1500000000>;

    Why no "power-domains??

[...]

MBR, Sergei

[PATCH v4 13/13] ARM: dts: r8a7793: Add APMU node and second CPU core

[Geert Uytterhoeven]

Hi Sergei,

On Mon, Jun 20, 2016 at 11:05 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
>> diff --git a/arch/arm/boot/dts/r8a7793.dtsi
>> b/arch/arm/boot/dts/r8a7793.dtsi
>> index 9b55c1c6ee31a49d..fce310c54efa88eb 100644
>> --- a/arch/arm/boot/dts/r8a7793.dtsi
>> +++ b/arch/arm/boot/dts/r8a7793.dtsi
>
> [...]
>>
>> @@ -56,6 +57,13 @@
>>                         next-level-cache = <&L2_CA15>;
>>                 };
>>
>> +               cpu1: cpu at 1 {
>> +                       device_type = "cpu";
>> +                       compatible = "arm,cortex-a15";
>> +                       reg = <1>;
>> +                       clock-frequency = <1500000000>;
>
>    Why no "power-domains??

Because the original patch predates that, and I forgot to update it...

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH v4 07/13] ARM: shmobile: apmu: Add APMU DT support via Enable method

[Sergei Shtylyov]

On 06/16/2016 01:27 PM, Geert Uytterhoeven wrote:

> From: Magnus Damm <damm+renesas@opensource.se>
>
> Allow DT configuration of the APMU hardware in the case when the APMU is
> pointed out in the DTB via the enable-method. The ability to configure
> the APMU via C code is still kept intact to prevent DTB breakage for older
> SoCs that do not rely on the enable-method for SMP support.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> [geert: Fix CONFIG_SMP=n build]
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[...]

> diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c b/arch/arm/mach-shmobile/platsmp-apmu.c
> index c1558ef0c590dd3e..0c6bb458b7a45128 100644
> --- a/arch/arm/mach-shmobile/platsmp-apmu.c
> +++ b/arch/arm/mach-shmobile/platsmp-apmu.c
[...]
> +static int shmobile_smp_apmu_boot_secondary_md21(unsigned int cpu,
> +						 struct task_struct *idle)
> +{
> +	/* Error out when hardware debug mode is enabled */
> +	if (rcar_gen2_read_mode_pins() & BIT(21)) {
> +		pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
> +		return -ENOTSUPP;
> +	}
> +
> +	return shmobile_smp_apmu_boot_secondary(cpu, idle);
> +}
> +
> +static struct smp_operations apmu_smp_ops __initdata = {
> +	.smp_prepare_cpus	= shmobile_smp_apmu_prepare_cpus_dt,
> +	.smp_boot_secondary	= shmobile_smp_apmu_boot_secondary_md21,
> +#ifdef CONFIG_HOTPLUG_CPU
> +	.cpu_can_disable	= shmobile_smp_cpu_can_disable,
> +	.cpu_die		= shmobile_smp_apmu_cpu_die,
> +	.cpu_kill		= shmobile_smp_apmu_cpu_kill,
>  #endif

    For the record: it turned out that I tested my non-DT SMP on 
R8A7792/Blanche with MD21 bit set. And I've just made sure it still works with 
this implementation (by commenting out the check above.
    Also, I was going to try the workaround for MD21 I saw in the BSP tree -- 
perhaps it'll help get R8A7791 working w/MD21 set...

MBR, Sergei

[PATCH v4 07/13] ARM: shmobile: apmu: Add APMU DT support via Enable method

[Geert Uytterhoeven]

Hi Sergei,

On Tue, Jun 21, 2016 at 7:49 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 06/16/2016 01:27 PM, Geert Uytterhoeven wrote:
>> From: Magnus Damm <damm+renesas@opensource.se>
>> Allow DT configuration of the APMU hardware in the case when the APMU is
>> pointed out in the DTB via the enable-method. The ability to configure
>> the APMU via C code is still kept intact to prevent DTB breakage for older
>> SoCs that do not rely on the enable-method for SMP support.
>>
>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>> [geert: Fix CONFIG_SMP=n build]
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> [...]
>
>> diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c
>> b/arch/arm/mach-shmobile/platsmp-apmu.c
>> index c1558ef0c590dd3e..0c6bb458b7a45128 100644
>> --- a/arch/arm/mach-shmobile/platsmp-apmu.c
>> +++ b/arch/arm/mach-shmobile/platsmp-apmu.c
>
> [...]
>>
>> +static int shmobile_smp_apmu_boot_secondary_md21(unsigned int cpu,
>> +                                                struct task_struct *idle)
>> +{
>> +       /* Error out when hardware debug mode is enabled */
>> +       if (rcar_gen2_read_mode_pins() & BIT(21)) {
>> +               pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
>> +               return -ENOTSUPP;
>> +       }
>> +
>> +       return shmobile_smp_apmu_boot_secondary(cpu, idle);
>> +}
>> +
>> +static struct smp_operations apmu_smp_ops __initdata = {
>> +       .smp_prepare_cpus       = shmobile_smp_apmu_prepare_cpus_dt,
>> +       .smp_boot_secondary     = shmobile_smp_apmu_boot_secondary_md21,
>> +#ifdef CONFIG_HOTPLUG_CPU
>> +       .cpu_can_disable        = shmobile_smp_cpu_can_disable,
>> +       .cpu_die                = shmobile_smp_apmu_cpu_die,
>> +       .cpu_kill               = shmobile_smp_apmu_cpu_kill,
>>  #endif
>
>
>    For the record: it turned out that I tested my non-DT SMP on
> R8A7792/Blanche with MD21 bit set. And I've just made sure it still works
> with this implementation (by commenting out the check above.
>    Also, I was going to try the workaround for MD21 I saw in the BSP tree --

Which workaround? I only saw the BSP removed the check, but it didn't mention
why (because E2 and V2H don't need it, or...?).

> perhaps it'll help get R8A7791 working w/MD21 set...

Does your Porter work with the other MD21 setting (and the check commented
out, of coutse)?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH v4 07/13] ARM: shmobile: apmu: Add APMU DT support via Enable method

[Sergei Shtylyov]

Hello.

On 06/24/2016 10:44 AM, Geert Uytterhoeven wrote:

>>> From: Magnus Damm <damm+renesas@opensource.se>
>>> Allow DT configuration of the APMU hardware in the case when the APMU is
>>> pointed out in the DTB via the enable-method. The ability to configure
>>> the APMU via C code is still kept intact to prevent DTB breakage for older
>>> SoCs that do not rely on the enable-method for SMP support.
>>>
>>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>>> [geert: Fix CONFIG_SMP=n build]
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>
>> [...]
>>
>>> diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c
>>> b/arch/arm/mach-shmobile/platsmp-apmu.c
>>> index c1558ef0c590dd3e..0c6bb458b7a45128 100644
>>> --- a/arch/arm/mach-shmobile/platsmp-apmu.c
>>> +++ b/arch/arm/mach-shmobile/platsmp-apmu.c
>>
>> [...]
>>>
>>> +static int shmobile_smp_apmu_boot_secondary_md21(unsigned int cpu,
>>> +                                                struct task_struct *idle)
>>> +{
>>> +       /* Error out when hardware debug mode is enabled */
>>> +       if (rcar_gen2_read_mode_pins() & BIT(21)) {
>>> +               pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
>>> +               return -ENOTSUPP;
>>> +       }
>>> +
>>> +       return shmobile_smp_apmu_boot_secondary(cpu, idle);
>>> +}
>>> +
>>> +static struct smp_operations apmu_smp_ops __initdata = {
>>> +       .smp_prepare_cpus       = shmobile_smp_apmu_prepare_cpus_dt,
>>> +       .smp_boot_secondary     = shmobile_smp_apmu_boot_secondary_md21,
>>> +#ifdef CONFIG_HOTPLUG_CPU
>>> +       .cpu_can_disable        = shmobile_smp_cpu_can_disable,
>>> +       .cpu_die                = shmobile_smp_apmu_cpu_die,
>>> +       .cpu_kill               = shmobile_smp_apmu_cpu_kill,
>>>  #endif
>>
>>
>>    For the record: it turned out that I tested my non-DT SMP on
>> R8A7792/Blanche with MD21 bit set. And I've just made sure it still works
>> with this implementation (by commenting out the check above.
>>    Also, I was going to try the workaround for MD21 I saw in the BSP tree --

> Which workaround? I only saw the BSP removed the check, but it didn't mention
> why (because E2 and V2H don't need it, or...?).

    I'm looking at the <soc>_smp_prepare_cpus() in 
arch/arm/mach-shmobile/setup-<soc>.c in the 
'bsp/v3.10.31-ltsi/rcar-gen2-1.9.6' branch of Simon's renesas-backport.git. 
The all have the code to handle MD21 bit set (by setting some bits in 
CA{7,15}DBGRCR.

>> perhaps it'll help get R8A7791 working w/MD21 set...
>
> Does your Porter work with the other MD21 setting (and the check commented
> out, of coutse)?

    Yes, I've made sure it works now.

> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

[PATCH v4 07/13] ARM: shmobile: apmu: Add APMU DT support via Enable method

[Geert Uytterhoeven]

Hi Sergei,

On Sun, Jun 26, 2016 at 6:36 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 06/24/2016 10:44 AM, Geert Uytterhoeven wrote:
>>>> From: Magnus Damm <damm+renesas@opensource.se>
>>>> Allow DT configuration of the APMU hardware in the case when the APMU is
>>>> pointed out in the DTB via the enable-method. The ability to configure
>>>> the APMU via C code is still kept intact to prevent DTB breakage for
>>>> older
>>>> SoCs that do not rely on the enable-method for SMP support.
>>>>
>>>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>>>> [geert: Fix CONFIG_SMP=n build]
>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>
>>> [...]
>>>
>>>> diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c
>>>> b/arch/arm/mach-shmobile/platsmp-apmu.c
>>>> index c1558ef0c590dd3e..0c6bb458b7a45128 100644
>>>> --- a/arch/arm/mach-shmobile/platsmp-apmu.c
>>>> +++ b/arch/arm/mach-shmobile/platsmp-apmu.c
>>>
>>> [...]
>>>>
>>>>
>>>> +static int shmobile_smp_apmu_boot_secondary_md21(unsigned int cpu,
>>>> +                                                struct task_struct
>>>> *idle)
>>>> +{
>>>> +       /* Error out when hardware debug mode is enabled */
>>>> +       if (rcar_gen2_read_mode_pins() & BIT(21)) {
>>>> +               pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
>>>> +               return -ENOTSUPP;
>>>> +       }
>>>> +
>>>> +       return shmobile_smp_apmu_boot_secondary(cpu, idle);
>>>> +}
>>>> +
>>>> +static struct smp_operations apmu_smp_ops __initdata = {
>>>> +       .smp_prepare_cpus       = shmobile_smp_apmu_prepare_cpus_dt,
>>>> +       .smp_boot_secondary     = shmobile_smp_apmu_boot_secondary_md21,
>>>> +#ifdef CONFIG_HOTPLUG_CPU
>>>> +       .cpu_can_disable        = shmobile_smp_cpu_can_disable,
>>>> +       .cpu_die                = shmobile_smp_apmu_cpu_die,
>>>> +       .cpu_kill               = shmobile_smp_apmu_cpu_kill,
>>>>  #endif
>>>
>>>    For the record: it turned out that I tested my non-DT SMP on
>>> R8A7792/Blanche with MD21 bit set. And I've just made sure it still works
>>> with this implementation (by commenting out the check above.
>>>    Also, I was going to try the workaround for MD21 I saw in the BSP tree
>>> --
>
>> Which workaround? I only saw the BSP removed the check, but it didn't
>> mention
>> why (because E2 and V2H don't need it, or...?).
>
>    I'm looking at the <soc>_smp_prepare_cpus() in
> arch/arm/mach-shmobile/setup-<soc>.c in the

.../smp-<soc>.c

> 'bsp/v3.10.31-ltsi/rcar-gen2-1.9.6' branch of Simon's renesas-backport.git.
> The all have the code to handle MD21 bit set (by setting some bits in
> CA{7,15}DBGRCR.
>
>>> perhaps it'll help get R8A7791 working w/MD21 set...

Thanks! I'll give that a try...

Note that for SoCs with CA7 cores, it sets undocumented bits (the 0x3330 part)?

For now we can keep the check, as the behavior is the same as on H2/M2-W
before, so it doesn't introduce a regression.

>> Does your Porter work with the other MD21 setting (and the check commented
>> out, of coutse)?
>
>    Yes, I've made sure it works now.

With or without the DBGRCR code from the BSP?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH v4 07/13] ARM: shmobile: apmu: Add APMU DT support via Enable method

[Sergei Shtylyov]

Hello.

On 06/27/2016 12:41 PM, Geert Uytterhoeven wrote:

>>>>> From: Magnus Damm <damm+renesas@opensource.se>
>>>>> Allow DT configuration of the APMU hardware in the case when the APMU is
>>>>> pointed out in the DTB via the enable-method. The ability to configure
>>>>> the APMU via C code is still kept intact to prevent DTB breakage for
>>>>> older
>>>>> SoCs that do not rely on the enable-method for SMP support.
>>>>>
>>>>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>>>>> [geert: Fix CONFIG_SMP=n build]
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>
>>>> [...]
>>>>
>>>>> diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c
>>>>> b/arch/arm/mach-shmobile/platsmp-apmu.c
>>>>> index c1558ef0c590dd3e..0c6bb458b7a45128 100644
>>>>> --- a/arch/arm/mach-shmobile/platsmp-apmu.c
>>>>> +++ b/arch/arm/mach-shmobile/platsmp-apmu.c
>>>>
>>>> [...]
>>>>>
>>>>>
>>>>> +static int shmobile_smp_apmu_boot_secondary_md21(unsigned int cpu,
>>>>> +                                                struct task_struct
>>>>> *idle)
>>>>> +{
>>>>> +       /* Error out when hardware debug mode is enabled */
>>>>> +       if (rcar_gen2_read_mode_pins() & BIT(21)) {
>>>>> +               pr_warn("Unable to boot CPU%u when MD21 is set\n", cpu);
>>>>> +               return -ENOTSUPP;
>>>>> +       }
>>>>> +
>>>>> +       return shmobile_smp_apmu_boot_secondary(cpu, idle);
>>>>> +}
>>>>> +
>>>>> +static struct smp_operations apmu_smp_ops __initdata = {
>>>>> +       .smp_prepare_cpus       = shmobile_smp_apmu_prepare_cpus_dt,
>>>>> +       .smp_boot_secondary     = shmobile_smp_apmu_boot_secondary_md21,
>>>>> +#ifdef CONFIG_HOTPLUG_CPU
>>>>> +       .cpu_can_disable        = shmobile_smp_cpu_can_disable,
>>>>> +       .cpu_die                = shmobile_smp_apmu_cpu_die,
>>>>> +       .cpu_kill               = shmobile_smp_apmu_cpu_kill,
>>>>>  #endif
>>>>
>>>>    For the record: it turned out that I tested my non-DT SMP on
>>>> R8A7792/Blanche with MD21 bit set. And I've just made sure it still works
>>>> with this implementation (by commenting out the check above.
>>>>    Also, I was going to try the workaround for MD21 I saw in the BSP tree
>>>> --
>>
>>> Which workaround? I only saw the BSP removed the check, but it didn't
>>> mention
>>> why (because E2 and V2H don't need it, or...?).
>>
>>    I'm looking at the <soc>_smp_prepare_cpus() in
>> arch/arm/mach-shmobile/setup-<soc>.c in the
>
> .../smp-<soc>.c

    Yes, sorry. :-)

>> 'bsp/v3.10.31-ltsi/rcar-gen2-1.9.6' branch of Simon's renesas-backport.git.
>> The all have the code to handle MD21 bit set (by setting some bits in
>> CA{7,15}DBGRCR.
>>
>>>> perhaps it'll help get R8A7791 working w/MD21 set...
>
> Thanks! I'll give that a try...
>
> Note that for SoCs with CA7 cores, it sets undocumented bits (the 0x3330 part)?

    Yes, looks like they're undocumented.

> For now we can keep the check, as the behavior is the same as on H2/M2-W
> before, so it doesn't introduce a regression.

    Wait, H2 SMP code doesn't have this check.

>>> Does your Porter work with the other MD21 setting (and the check commented
>>> out, of coutse)?
>>
>>    Yes, I've made sure it works now.
>
> With or without the DBGRCR code from the BSP?

    Without.

> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert

MBR, Sergei

[PATCH v4 07/13] ARM: shmobile: apmu: Add APMU DT support via Enable method

[Geert Uytterhoeven]

Hi Sergei,

On Mon, Jun 27, 2016 at 2:59 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 06/27/2016 12:41 PM, Geert Uytterhoeven wrote:
>>>>>> From: Magnus Damm <damm+renesas@opensource.se>
>>>>>> Allow DT configuration of the APMU hardware in the case when the APMU
>>>>>> is
>>>>>> pointed out in the DTB via the enable-method. The ability to configure
>>>>>> the APMU via C code is still kept intact to prevent DTB breakage for
>>>>>> older
>>>>>> SoCs that do not rely on the enable-method for SMP support.
>>>>>>
>>>>>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>>>>>> [geert: Fix CONFIG_SMP=n build]
>>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>>
>>>>> [...]
>>>>>
>>>>>> diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c
>>>>>> b/arch/arm/mach-shmobile/platsmp-apmu.c
>>>>>> index c1558ef0c590dd3e..0c6bb458b7a45128 100644
>>>>>> --- a/arch/arm/mach-shmobile/platsmp-apmu.c
>>>>>> +++ b/arch/arm/mach-shmobile/platsmp-apmu.c
>>>>>
>>>>> [...]
>>>>>>
>>>>>> +static int shmobile_smp_apmu_boot_secondary_md21(unsigned int cpu,
>>>>>> +                                                struct task_struct
>>>>>> *idle)
>>>>>> +{
>>>>>> +       /* Error out when hardware debug mode is enabled */
>>>>>> +       if (rcar_gen2_read_mode_pins() & BIT(21)) {
>>>>>> +               pr_warn("Unable to boot CPU%u when MD21 is set\n",
>>>>>> cpu);
>>>>>> +               return -ENOTSUPP;
>>>>>> +       }
>>>>>> +
>>>>>> +       return shmobile_smp_apmu_boot_secondary(cpu, idle);
>>>>>> +}
>>>>>> +
>>>>>> +static struct smp_operations apmu_smp_ops __initdata = {
>>>>>> +       .smp_prepare_cpus       = shmobile_smp_apmu_prepare_cpus_dt,
>>>>>> +       .smp_boot_secondary     =
>>>>>> shmobile_smp_apmu_boot_secondary_md21,
>>>>>> +#ifdef CONFIG_HOTPLUG_CPU
>>>>>> +       .cpu_can_disable        = shmobile_smp_cpu_can_disable,
>>>>>> +       .cpu_die                = shmobile_smp_apmu_cpu_die,
>>>>>> +       .cpu_kill               = shmobile_smp_apmu_cpu_kill,
>>>>>>  #endif
>>>>>
>>>>>    For the record: it turned out that I tested my non-DT SMP on
>>>>> R8A7792/Blanche with MD21 bit set. And I've just made sure it still
>>>>> works
>>>>> with this implementation (by commenting out the check above.
>>>>>    Also, I was going to try the workaround for MD21 I saw in the BSP
>>>>> tree
>>>>> --
>>>
>>>> Which workaround? I only saw the BSP removed the check, but it didn't
>>>> mention
>>>> why (because E2 and V2H don't need it, or...?).
>>>
>>>    I'm looking at the <soc>_smp_prepare_cpus() in
>>> arch/arm/mach-shmobile/setup-<soc>.c in the
>>
>> .../smp-<soc>.c
>
>    Yes, sorry. :-)
>
>>> 'bsp/v3.10.31-ltsi/rcar-gen2-1.9.6' branch of Simon's
>>> renesas-backport.git.
>>> The all have the code to handle MD21 bit set (by setting some bits in
>>> CA{7,15}DBGRCR.
>>>
>>>>> perhaps it'll help get R8A7791 working w/MD21 set...

>>
>> Thanks! I'll give that a try...
>>
>> Note that for SoCs with CA7 cores, it sets undocumented bits (the 0x3330
>> part)?
>
>    Yes, looks like they're undocumented.
>
>> For now we can keep the check, as the behavior is the same as on H2/M2-W
>> before, so it doesn't introduce a regression.
>
>    Wait, H2 SMP code doesn't have this check.

You're right. While Magnus did send out a patch that added the check for both,
in the end a newer revision touching r8a7791 only was applied.
Whether r8a7790 is really not affected is not clear to me...

>>>> Does your Porter work with the other MD21 setting (and the check
>>>> commented
>>>> out, of coutse)?
>>>
>>>    Yes, I've made sure it works now.
>>
>> With or without the DBGRCR code from the BSP?
>
>    Without.

That's interesting. So there may be different firmware/boot loader on Koelsch
and Porter.

Or perhaps it's just random: on Koelsch, I only had the issue after a Real Cold
Boot (in the morning). During the day, it used to work with MD21=1, too.

Now, we're getting closer to the moment Simon will close his tree for v4.8.
Can we apply my series as-is, or do we need the DBGRCR handling first,
probably postponing all of this to v4.9?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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

[PATCH v4 01/13] devicetree: bindings: Renesas APMU and SMP Enable method

[Rob Herring]

On Thu, Jun 16, 2016 at 12:27:30PM +0200, Geert Uytterhoeven wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Add DT binding documentation for the APMU hardware and add "renesas,apmu"
> to the list of enable methods for the ARM cpus.
> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree at vger.kernel.org
> ---
> v4:
>   - s/reigsters/registers/,
>   - Use "renesas,<soctype>-apmu" instead of "renesas,apmu-<soctype>",
> 
> v3:
>   - s/Until/Unit/g,
> 
> v2:
>   - No changes.
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt     |  1 +
>  .../devicetree/bindings/power/renesas,apmu.txt     | 31 ++++++++++++++++++++++
>  2 files changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/renesas,apmu.txt

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v4 01/13] devicetree: bindings: Renesas APMU and SMP Enable method

[Geert Uytterhoeven]

On Thu, Jun 16, 2016 at 12:27 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Add DT binding documentation for the APMU hardware and add "renesas,apmu"
> to the list of enable methods for the ARM cpus.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree at vger.kernel.org
> ---
> v4:
>   - s/reigsters/registers/,
>   - Use "renesas,<soctype>-apmu" instead of "renesas,apmu-<soctype>",
>
> v3:
>   - s/Until/Unit/g,
>
> v2:
>   - No changes.
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt     |  1 +
>  .../devicetree/bindings/power/renesas,apmu.txt     | 31 ++++++++++++++++++++++
>  2 files changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/renesas,apmu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index 3f0cbbb8395f84ef..fa7520eb6387edbe 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -204,6 +204,7 @@ nodes to be present and contain the properties described below.
>                             "qcom,gcc-msm8660"
>                             "qcom,kpss-acc-v1"
>                             "qcom,kpss-acc-v2"
> +                           "renesas,apmu"

Any Acked-by from the ARM people?
Thanks!

>                             "rockchip,rk3036-smp"
>                             "rockchip,rk3066-smp"
>                             "ste,dbx500-smp"
> diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.txt b/Documentation/devicetree/bindings/power/renesas,apmu.txt
> new file mode 100644
> index 0000000000000000..84404c9edff73d97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/renesas,apmu.txt
> @@ -0,0 +1,31 @@
> +DT bindings for the Renesas Advanced Power Management Unit
> +
> +Renesas R-Car line of SoCs utilize one or more APMU hardware units
> +for CPU core power domain control including SMP boot and CPU Hotplug.
> +
> +Required properties:
> +
> +- compatible: Should be "renesas,<soctype>-apmu", "renesas,apmu" as fallback.
> +             Examples with soctypes are:
> +               - "renesas,r8a7790-apmu" (R-Car H2)
> +               - "renesas,r8a7791-apmu" (R-Car M2-W)
> +               - "renesas,r8a7792-apmu" (R-Car V2H)
> +               - "renesas,r8a7793-apmu" (R-Car M2-N)
> +               - "renesas,r8a7794-apmu" (R-Car E2)
> +
> +- reg: Base address and length of the I/O registers used by the APMU.
> +
> +- cpus: This node contains a list of CPU cores, which should match the order
> +  of CPU cores used by the WUPCR and PSTR registers in the Advanced Power
> +  Management Unit section of the device's datasheet.
> +
> +
> +Example:
> +
> +This shows the r8a7791 APMU that can control CPU0 and CPU1.
> +
> +       apmu at e6152000 {
> +               compatible = "renesas,r8a7791-apmu", "renesas,apmu";
> +               reg = <0 0xe6152000 0 0x188>;
> +               cpus = <&cpu0 &cpu1>;
> +       };
> --
> 1.9.1

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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