From: k.kozlowski@samsung•com (Krzysztof Kozlowski)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv2] ARM: EXYNOS: reset Little cores when cpu is up
Date: Wed, 02 Sep 2015 16:59:19 +0900 [thread overview]
Message-ID: <55E6AC57.4020208@samsung.com> (raw)
In-Reply-To: <55E6A8F6.5020301@osg.samsung.com>
On 02.09.2015 16:44, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On 09/02/2015 02:39 AM, Krzysztof Kozlowski wrote:
>> On 02.09.2015 09:32, Javier Martinez Canillas wrote:
>>> Hello Krzysztof,
>>>
>>> On 09/02/2015 02:15 AM, Krzysztof Kozlowski wrote:
>>>> On 01.09.2015 23:17, Chanho Park wrote:
>>>>> The cpu booting of exynos5422 has been still broken since we discussed
>>>>> it in last year[1]. This patch is inspired from Odroid XU3
>>>>> code (Actually, it was from samsung exynos vendor kernel)[2]. This weird
>>>>> reset code was founded exynos5420 octa cores series SoCs and only
>>>>> required for the first boot core is the Little core (Cortex A7).
>>>>> Some of the exynos5420 boards and all of the exynos5422 boards will require
>>>>> this code.
>>>>>
>>>>> There is two ways to check the little core is the first cpu. One is
>>>>> checking GPG2CON[1] GPIO value and the other is checking the cluster
>>>>> number of the first cpu. I selected the latter because it's more easier
>>>>> than the former.
>>>>>
>>>>> [1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/350632.html
>>>>> [2]:https://patchwork.kernel.org/patch/6782891/
>>>>>
>>>>> Cc: Kevin Hilman <khilman@kernel•org>
>>>>> Cc: Javier Martinez Canillas <javier@osg•samsung.com>
>>>>> Cc: Krzysztof Kozlowski <k.kozlowski@samsung•com>
>>>>> Tested-by: Kevin Hilman <khilman@linaro•org>
>>>>> Signed-off-by: Chanho Park <parkch98@gmail•com>
>>>>> ---
>>>>> Changes from v1:
>>>>> .kfc to Little (Cortex A7) and eagle to big (Cortex A15)
>>>>> .append comments about waiting SPARE2 register
>>>>>
>>>>> Changes since RFC:
>>>>> .drop checking soc_is_exynos5800 to extend this codes to
>>>>> exynos5420/5422 boards.
>>>>> .kfc cores will be reset only if the cpu0 is kfc core.
>>>>> .Rebase top of the kukjin's for-next branch
>>>>>
>>>>> arch/arm/mach-exynos/mcpm-exynos.c | 25 ++++++++++++++++++++++++-
>>>>> arch/arm/mach-exynos/regs-pmu.h | 6 ++++++
>>>>> 2 files changed, 30 insertions(+), 1 deletion(-)
>>>>
>>>> Thanks for updating the patch. Remaining minor nit about comment style
>>>> (/* on first line) can be fixed while applying.
>>>>
>>>> The patch works good, after disabling bL switcher I have 8 cores running:
>>>>
>>>> Tested on Odroid XU4:
>>>> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung•com>
>>>> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung•com>
>>>>
>>>> It's 4.3 merge window so the patch will go probably to v4.4.
>>>>
>>>
>>> Isn't this material for the v4.3 -rc cycle since it's fixing a bug
>>> (CPUs not booting)? So I don't think that's necessary to wait for v4.4.
>>
>> It is a bug fix but:
>> 1. Not a fix for regression introduced in current merge window,
>
> I thought the -rc cycle was for stabilization and fix not only regressions
> introduced during the merge window but also long standing issues.
It's all subtle. Sometimes it also depends on the mood of maintainer...
A lot of fixes for different issues are merged in -rc and in the same
time they are rejected because they are too late and they don't fix
regression from merge window. Anyway I used the argument #1 in
combination with #2.
Best regards,
Krzysztof
>
>> 2. There may be more subtle issues like the one mentioned below, not
>> found yet (probably no one tested it with all possible configurations),
>>
>
> Right, this is indeed a better reason to wait for v4.4.
>
>> so I don't think rushing with the patch to mainline is good idea.
>>
>
> Yes, agreed.
>
>> However your comment reminds me about stable. This actually looks like a
>> candidate for stable.
>>
>>>
>>> But I was expecting another re-spin as from Abhilash's latest comments [0],
>>> it seems the same workaround is needed in arch/arm/mach-exynos/platsmp.c
>>> to avoid the CPU's not booting issue when CCI is disabled in DT and the
>>> MCPM backend is bypassed.
>>>
>>> Although I guess that could be also made as a follow up patch.
>>
>> Chanho patch fixes only MCPM path. Regular path (platsmp, firmware) is
>> not affected so I would expect a following patch.
>>
>
> Ok, hopefully the non MCPM path can also be fixed before v4.4.
>
>> Best regards,
>> Krzysztof
>>
>>>
>
> Best regards,
>
next prev parent reply other threads:[~2015-09-02 7:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-01 14:17 [PATCHv2] ARM: EXYNOS: reset Little cores when cpu is up Chanho Park
2015-09-01 14:47 ` Anand Moon
2015-09-02 0:15 ` Krzysztof Kozlowski
2015-09-02 0:32 ` Javier Martinez Canillas
2015-09-02 0:39 ` Krzysztof Kozlowski
2015-09-02 7:44 ` Javier Martinez Canillas
2015-09-02 7:59 ` Krzysztof Kozlowski [this message]
2015-09-14 1:24 ` Krzysztof Kozlowski
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=55E6AC57.4020208@samsung.com \
--to=k.kozlowski@samsung$(echo .)com \
--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