[PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

[Abhilash Kesavan]

Hi Kevin,

On Thu, Nov 27, 2014 at 12:11 AM, Nicolas Pitre
<nicolas.pitre at linaro.org> wrote:
> On Wed, 26 Nov 2014, Kevin Hilman wrote:
>
>> Abhilash Kesavan <kesavan.abhilash at gmail.com> writes:
>>
>> > Hi Kevin,
>> >
>> > On Wed, Nov 26, 2014 at 6:30 AM, Kevin Hilman <khilman at kernel.org> wrote:
>> >> [...]
>> >>
>> >> More specifically, with only the loopback call to turn off CCI commented
>> >> out, the imprecise aborts go away.
>> >
>> > I can't see how enabling snoops for the boot cluster is causing these
>> > aborts. Perhaps as Krzysztof commented it has something to do with the
>> > secure firmware/tz software on these boards ? Other than there does
>> > not appear to be any difference between the working/non-working
>> > setups.
>>
>> Perhaps the secure firmware is preventing the CCI to be enabled by the
>> kernel, and that is causing the imprecise abort?
>
> That is well possible.
>
> Now...... if the bootloader/firmware does not let Linux deal with both
> the CCI and caches then MCPM simply has no more purpose for this board.
> The whole point of MCPM is actually to handle the CCI properly and the
> most efficient way despite all the possible races and opportunities for
> memory corruptions. And yes, this is a complex task.
>
> So there is actually two choices: the firmware let Linux take care of it
> via the MCPM layer (easy), or the firmware has to implement it all
> _properly_ (hard) behind an interface such as PSCI, at which point MCPM
> should be configured out.
>
> If the firmware does not let Linux interact with the CCI _and_ does not
> implement full MCPM-like services then the platform is broken and only a
> firmware upgrade could fix that.  It might still be possible to boot all
> CPUs through other means, but power management would then be severely
> limited.

How about restricting the mcpm initialization to only known working
boards like chromebooks and smdk. This would be better than disabling
the config altogether from exynos_defconfig. The non-working boards
would then default to platsmp. Assuming that the firmware handles all
CCI/cache activities then platsmp may work for secondary core boot-up
?

Can you please apply the below diff and test the non-working boards
with CONFIG_EXYNOS5420_MCPM enabled.

diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index b0d3c2e..34d77bb 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -316,8 +316,9 @@ static void __init exynos_cache_off(void)
 }

 static const struct of_device_id exynos_dt_mcpm_match[] = {
-       { .compatible = "samsung,exynos5420" },
-       { .compatible = "samsung,exynos5800" },
+       { .compatible = "samsung,smdk5420" },
+       { .compatible = "google,pi" },
+       { .compatible = "google,pit" },
        {},
 };

On a different note, I did not see any mainline support for Odroid
Xu3, are you testing this board with a non-mainline kernel ?

Regards,
Abhilash
>
>
>
> Nicolas