From: khilman@kernel•org (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
Date: Wed, 26 Nov 2014 09:56:22 -0800 [thread overview]
Message-ID: <7hmw7dg81l.fsf@deeprootsystems.com> (raw)
In-Reply-To: <CAM4voa=budowQ+vnCAQhWj95Hx+yBnRAaDrFrjkQa2ubjrRwUQ@mail.gmail.com> (Abhilash Kesavan's message of "Wed, 26 Nov 2014 22:28:57 +0530")
Abhilash Kesavan <kesavan.abhilash@gmail•com> writes:
> Hi Kevin,
>
> On Wed, Nov 26, 2014 at 6:30 AM, Kevin Hilman <khilman@kernel•org> wrote:
>> Hi Abhilash,
>>
>> Abhilash Kesavan <kesavan.abhilash@gmail•com> writes:
>>
>> [...]
>>
>>>>> To be honest, since I don't have the exynos5420 arndale, chromebook...but smdk
>>>>> which has different bootloader, I couldn't test it...I'll try to make a test
>>>>> farm like you guys...
>>>>
>>>> Do you have some colleagues with any other 542x hardware? I had
>>>> assumed that linux-next was being better tested on the publicaly
>>>> available, and widely available boards like odroid-xu3 and
>>>> Chromebook2, but I've come to realize the hard way that that is not
>>>
>>> Are you seeing this on Chromebook2 (Peach-Pi 5800) too ?
>>
>> No, it seems that my exynos5800-peach-pi is not having this problem,
>> which suggests it's a bootloader setup issue.
>>
>>>> the case. You mention your board has a different bootloader. Do you
>>>> suspect there's a bootloader issue on these other platforms? If so,
>>>> could you elaborate on possible fixes? I'm more than willing to test
>>>> any proposed fixes, but I'm not familiar enough yet with these SoCs to
>>>> figure out the underlying issues alone.
>>>>
>>>> Until you have a working board farm, you could start having a closer
>>>> look at the boot logs we're already producing. Admittedly linux-next
>>>> broken in many ways besides this one for exynos currently, but it has
>>>> been having these imprecise aborts well before the other recent
>>>> issues.
>>>>
>>>> Also, It's very possible that this issue is not even MCPM related at
>>>> all, and MCPM is just uncovering a previously hidden bug. It would be
>>>> very helpful if people more familiar with this hardware and SoC would
>>>> investigate bug reports like these.
>>>
>>> The 3 boards I have access to (SMDK5420, Chromebook Peach-Pi and
>>> Chromebook Peach-Pit) work fine with MCPM enabled.
>>
>> Thanks for helping look into this.
>>
>>> I am not sure why
>>> it is failing only on the above mentioned boards as there is nothing
>>> specific to them in the MCPM back-end.
>>>
>>> I assume that when you default to platsmp (on disabling MCPM), the
>>> non-working boards boot all cores upto userspace without any issues ?
>>
>> Nope. With MCPM disabled:
>>
>> - 5420/arndale-octa: CPU0-3 come up (A15s)
>> - 5422/odroid-xu3: only CPU0 (A7)
>> - 5800/peach-pi: only CPU0 (A15)
>>
>> Note that with MCPM enabled, the arndale-octa gets the same result.
>> Peach-pi on the other hand gets all 8 CPUs, and the odroid-xu3 only gets
>> 6/8 CPUs (see other thread on that topic.)
>>
>>> Based on the timeline (problems started about 2.5 months back), there
>>> have only been a couple of changes in the 5420 MCPM back-end. Could
>>> you revert the following commits and check if things improve.
>>>
>>> 20fe6f9 ARM: EXYNOS: Support cluster power off on exynos5420/5800
>>> fbb0499 ARM: 8083/1: exynos: activate the CCI on boot CPU/cluster
>>> using the MCPM loopback
>>>
>>> These might not revert cleanly, so instead of the above you could also
>>> comment the following 2 lines:
>>>
>>>
>>> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
>>> b/arch/arm/mach-exynos/mcpm-exynos.c
>>> index dc9a764..9a07188 100644
>>> --- a/arch/arm/mach-exynos/mcpm-exynos.c
>>> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>>> @@ -152,7 +152,7 @@ static void exynos_power_down(void)
>>> exynos_cpu_power_down(cpunr);
>>>
>>> if (exynos_cluster_unused(cluster)) {
>>> - exynos_cluster_power_down(cluster);
>>> + //exynos_cluster_power_down(cluster);
>>> last_man = true;
>>> }
>> 2> } else if (cpu_use_count[cpu][cluster] == 1) {
>>> @@ -356,8 +356,8 @@ static int __init exynos_mcpm_init(void)
>>> ret = mcpm_platform_register(&exynos_power_ops);
>>> if (!ret)
>>> ret = mcpm_sync_init(exynos_pm_power_up_setup);
>>> - if (!ret)
>>> - ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */
>>> + //if (!ret)
>>> + //ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */
>>> if (ret) {
>>> iounmap(ns_sram_base_addr);
>>> return ret;
>>>
>>>
>>>
>>> If you still get aborts then I suspect that the problem is with the
>>> bootloader configuration but am not sure.
>>
>> Nice. With those lines commented out, the arndale-octa is not geting
>> imprecise aborts anymore, and this is the platform where those aborts
>> seem to prevent booting into a full userspace (as originally reported by
>> Tyler.)
>>
>> 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?
Is there a way to update/replace the BL1/BL2/TZ firmware blobs with
something that is known to be working better?
Kevin
next prev parent reply other threads:[~2014-11-26 17:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-31 22:59 [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable Kevin Hilman
2014-11-08 9:50 ` Kukjin Kim
2014-11-10 19:35 ` Kevin Hilman
2014-11-24 19:51 ` Kevin Hilman
2014-11-25 0:25 ` Olof Johansson
2014-11-25 1:35 ` Kevin Hilman
2014-11-25 1:37 ` Olof Johansson
2014-11-25 1:38 ` Olof Johansson
2014-11-25 1:50 ` Kukjin Kim
2014-11-25 3:20 ` Kevin Hilman
2014-11-25 6:01 ` Abhilash Kesavan
2014-11-26 1:00 ` Kevin Hilman
2014-11-26 16:58 ` Abhilash Kesavan
2014-11-26 17:56 ` Kevin Hilman [this message]
2014-11-26 18:11 ` Kukjin Kim
2014-11-26 18:41 ` Nicolas Pitre
2014-11-27 16:51 ` Abhilash Kesavan
2014-11-27 17:06 ` Nicolas Pitre
2014-11-28 14:41 ` Abhilash Kesavan
2014-11-27 18:57 ` Sudeep Holla
2014-11-25 8:47 ` Krzysztof Kozlowski
2014-11-25 9:07 ` Krzysztof Kozlowski
2014-11-25 2:13 ` Kevin Hilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7hmw7dg81l.fsf@deeprootsystems.com \
--to=khilman@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox