ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

From: Kevin Hilman <khilman@linaro.org>

The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts
during boot testing, causing various userspace startup failures.

Disable until it has gotten more testing.

Cc: Kukjin Kim <kgene.kim@samsung.com>,
Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
Cc: Sachin Kamat <sachin.kamat@samsung.com>,
Cc: Doug Anderson <dianders@chromium.org>,
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
Cc: Tushar Behera <tushar.behera@linaro.org>,
Cc: stable@vger.kernel.org # v3.17+
Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
This has been reported by a few people[1], but not investigated or fixed, so it's
time to disable this feature until it can be fixed.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288344.html

 arch/arm/configs/exynos_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Kevin Hilman wrote:
> 
> From: Kevin Hilman <khilman@linaro.org>
> 
> The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts
> during boot testing, causing various userspace startup failures.
> 
> Disable until it has gotten more testing.
> 
> Cc: Kukjin Kim <kgene.kim@samsung.com>,
> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
> Cc: Sachin Kamat <sachin.kamat@samsung.com>,
> Cc: Doug Anderson <dianders@chromium.org>,
> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
> Cc: Tushar Behera <tushar.behera@linaro.org>,
> Cc: stable@vger.kernel.org # v3.17+
> Signed-off-by: Kevin Hilman <khilman@linaro.org>
> ---
> This has been reported by a few people[1], but not investigated or fixed, so it's
> time to disable this feature until it can be fixed.
> 
Hi Kevin,

Yeah I agree with your opinion.

But as you can see my tree, I've queued regarding mcpm patches for 3.19 will
be shown in -next in this weekend. Anyway let me apply this into -fixes and
then let's enable after test its functionality in -next in a couple of days.

Thanks,
Kukjin


> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288344.html
> 
>  arch/arm/configs/exynos_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index 72058b8a6f4d..a250dcbf34cd 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -10,7 +10,7 @@ CONFIG_MODULE_UNLOAD=y
>  CONFIG_PARTITION_ADVANCED=y
>  CONFIG_ARCH_EXYNOS=y
>  CONFIG_ARCH_EXYNOS3=y
> -CONFIG_EXYNOS5420_MCPM=y
> +CONFIG_EXYNOS5420_MCPM=n
>  CONFIG_SMP=y
>  CONFIG_BIG_LITTLE=y
>  CONFIG_BL_SWITCHER=y
> --
> 2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Kukjin Kim <kgene@kernel.org> writes:

> Kevin Hilman wrote:
>> 
>> From: Kevin Hilman <khilman@linaro.org>
>> 
>> The option CONFIG_EXYNOS5420_MCPM is causing imprecise external aborts
>> during boot testing, causing various userspace startup failures.
>> 
>> Disable until it has gotten more testing.
>> 
>> Cc: Kukjin Kim <kgene.kim@samsung.com>,
>> Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
>> Cc: Sachin Kamat <sachin.kamat@samsung.com>,
>> Cc: Doug Anderson <dianders@chromium.org>,
>> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
>> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
>> Cc: Tushar Behera <tushar.behera@linaro.org>,
>> Cc: stable@vger.kernel.org # v3.17+
>> Signed-off-by: Kevin Hilman <khilman@linaro.org>
>> ---
>> This has been reported by a few people[1], but not investigated or fixed, so it's
>> time to disable this feature until it can be fixed.
>> 
> Hi Kevin,
>
> Yeah I agree with your opinion.
>
> But as you can see my tree, I've queued regarding mcpm patches for 3.19 will
> be shown in -next in this weekend. 

Which of the recently queued patches are expected to address the
imprecise abort issue?  I'd be happy to test them out.  

> Anyway let me apply this into -fixes and
> then let's enable after test its functionality in -next in a couple of days.

Yes, I think this needs to be applied until these aborts are understood
and fixed.

Thanks,

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, 26 Nov 2014, Kevin Hilman wrote:

> Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:
> 
> > Hi Kevin,
> >
> > On Wed, Nov 26, 2014 at 6:30 AM, Kevin Hilman <khilman@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.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, 27 Nov 2014, Abhilash Kesavan wrote:

> Hi Kevin,
> 
> On Thu, Nov 27, 2014 at 12:11 AM, Nicolas Pitre
> <nicolas.pitre@linaro.org> wrote:
> > On Wed, 26 Nov 2014, Kevin Hilman wrote:
> >
> >> Abhilash Kesavan <kesavan.abhilash@gmail.com> writes:
> >>
> >> > Hi Kevin,
> >> >
> >> > On Wed, Nov 26, 2014 at 6:30 AM, Kevin Hilman <khilman@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.

I'd much prefer if the CCI is non accessible on some board that the 
device tree file for that board be modified instead by marking the CCI 
as unavailable.


> 
> 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
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html