From: khilman@linaro•org (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: Problems booting exynos5420 with >1 CPU
Date: Mon, 09 Jun 2014 13:47:42 -0700 [thread overview]
Message-ID: <7hsindq07l.fsf@paris.lan> (raw)
In-Reply-To: <alpine.LFD.2.11.1406081138070.25775@knanqh.ubzr> (Nicolas Pitre's message of "Sun, 8 Jun 2014 13:53:43 -0400 (EDT)")
Nicolas Pitre <nicolas.pitre@linaro•org> writes:
> On Sun, 8 Jun 2014, Lorenzo Pieralisi wrote:
>
>> On Sun, Jun 08, 2014 at 12:53:34AM +0100, Olof Johansson wrote:
>> > Lorenzo,
>> >
>> > Since you're emailing from @arm.com, some of this is to the wider
>> > recipient and maybe not directly to you:
>>
>> I am glad to reply and take blame since this is a debate definitely worth
>> having.
>
> Great. Because I would like to steer this debate a little towards the
> genuine cause rather than sticking to some particular consequences.
>
>> Guys, do not get me wrong here. There are fixes that can be deemed
>> acceptable in an OS, there are fixes that can't. I just can't help thinking
>> that Nicolas' patch is a nasty hack (and I am far, really really far from
>> blaming him for that, because that's the only patch that can fix that
>> issue in the kernel), and he perfectly knows that.
>
> You know what? The more I think about my patch, the more I consider
> this should be the standard way of setting up things unconditionally on
> _all_ platforms using MCPM. Why? Because that's the most coherent thing
> to do!
I agree.
> I really think the kernel should either be responsible for the CCI or it
> should not at all. And conversely for the bootloader. Right now we
> have an implicit requirement that the bootloader should turn on the CCI,
> but only for cold boot, and only for the boot cluster, and not for CPU
> resuming from idle, and what other case we haven't thought about yet.
> And as noticed this requirement is not documented.
In addition to being a firmware minimalist like Nico, what I find most
objectional to the bootloader approach is that even with CCI enabled by
the firmware, since it's a runtime requirement (for low-power idle or
suspend), the kernel has to handle it anyways. So you end up with a
partial solution in the firwmare (for boot cluster only) *and* a full
solution in the kernel. This doesn't make any sense, expecially because
the kernel might then have to do things differently on cold boot
vs. low-power idle/suspend or differently on the boot cluster vs. other
clusters. From a maintenance PoV, this is a mess and could easily lead
to just as many SoC specific hacks that are different across platforms.
Stated more simply: If the kernel has to manage the resource at runtime
due to low-power idle/suspend. I don't see any reason why it shouldn't
manage it at cold boot time also.
Kevin
next prev parent reply other threads:[~2014-06-09 20:47 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 1:08 Problems booting exynos5420 with >1 CPU Doug Anderson
2014-06-06 4:38 ` Tushar Behera
2014-06-06 17:17 ` Doug Anderson
2014-06-06 17:36 ` Abhilash Kesavan
2014-06-06 18:02 ` Doug Anderson
2014-06-06 18:12 ` Abhilash Kesavan
2014-06-06 18:20 ` Doug Anderson
2014-06-06 18:31 ` Abhilash Kesavan
2014-06-06 18:56 ` Doug Anderson
2014-06-06 19:09 ` Abhilash Kesavan
2014-06-06 19:12 ` Abhilash Kesavan
2014-06-06 20:49 ` Doug Anderson
2014-06-06 21:01 ` Russell King - ARM Linux
2014-06-06 21:12 ` Doug Anderson
2014-06-06 21:44 ` Doug Anderson
2014-06-06 20:37 ` Olof Johansson
2014-06-06 20:46 ` Abhilash Kesavan
2014-06-06 21:01 ` Olof Johansson
2014-06-06 21:06 ` Abhilash Kesavan
2014-06-06 21:34 ` Nicolas Pitre
2014-06-06 21:49 ` Olof Johansson
2014-06-06 21:59 ` Doug Anderson
2014-06-06 22:38 ` Nicolas Pitre
2014-06-06 23:03 ` Doug Anderson
2014-06-06 22:17 ` Nicolas Pitre
2014-06-06 21:48 ` Nicolas Pitre
2014-06-07 3:25 ` Abhilash Kesavan
2014-06-07 16:10 ` Nicolas Pitre
2014-06-07 17:56 ` Lorenzo Pieralisi
2014-06-07 20:06 ` Nicolas Pitre
2014-06-07 22:36 ` Lorenzo Pieralisi
2014-06-07 23:53 ` Olof Johansson
2014-06-08 0:19 ` Russell King - ARM Linux
2014-06-08 2:52 ` Olof Johansson
2014-06-08 18:26 ` Nicolas Pitre
2014-06-08 18:29 ` Russell King - ARM Linux
2014-06-08 18:55 ` Nicolas Pitre
2014-06-08 19:02 ` Russell King - ARM Linux
2014-06-08 12:45 ` Lorenzo Pieralisi
2014-06-08 14:34 ` Russell King - ARM Linux
2014-06-08 17:53 ` Nicolas Pitre
2014-06-09 20:47 ` Kevin Hilman [this message]
2014-06-09 22:26 ` Lorenzo Pieralisi
2014-06-10 4:25 ` Nicolas Pitre
2014-06-10 9:19 ` Lorenzo Pieralisi
2014-06-10 14:14 ` Catalin Marinas
2014-06-10 16:49 ` Nicolas Pitre
2014-06-10 17:42 ` Catalin Marinas
2014-06-10 19:15 ` Nicolas Pitre
2014-06-09 20:27 ` Kevin Hilman
2014-06-09 20:35 ` Doug Anderson
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=7hsindq07l.fsf@paris.lan \
--to=khilman@linaro$(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