[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 at cogentembedded.com> wrote:
> On 06/27/2016 12:41 PM, Geert Uytterhoeven wrote:
>>>>>> From: Magnus Damm <damm+renesas at 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 at opensource.se>
>>>>>> [geert: Fix CONFIG_SMP=n build]
>>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas at 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