From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] Fixing CPU Hotplug for RealView Platforms
Date: Tue, 7 Dec 2010 17:47:00 -0000 [thread overview]
Message-ID: <007501cb9636$c0a54c90$41efe5b0$@deacon@arm.com> (raw)
In-Reply-To: <20101207171810.GA25839@n2100.arm.linux.org.uk>
Hi Russell,
> On Tue, Dec 07, 2010 at 04:43:10PM -0000, Will Deacon wrote:
> > Hello,
> >
> > Currently, CPU hotplug is broken for RealView platforms. I posted some
> > patches previously to try and address this, but they didn't solve the
> > problems fully:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/026157.html
> >
> > I'm now revisiting the code and it looks like the main problem is when
> > we wish to *leave* the lowpower state. The enter/leave routines look
> > like this:
> >
> ...
> >
> > The problem is that by turning off coherency, the contents of the D-cache
> > becomes stale. If data is prefetched into L1 between the flush_cache_all
> > invocation and disabling the D-cache then this data will still be present
> > when we come out of lowpower. Without coherency, we *must not* use this
> > data and so a D-cache invalidation to the PoC is required in
> > cpu_leave_lowpower().
>
> What if we fixed the cpu_reset functions for v6 and v7, and when a CPU
> is taken offline, we actually go through a proper shutdown of that CPU
> and call the reset vector, re-entering the boot loader?
This will certainly solve our problem, but people might complain that it's
too heavyweight :) That said, for v7 this may be the only solution as the
platform can require an IMPLEMENTATION DEFINED initialisation routine to be
executed before enabling the D-cache out of reset. This should be something
that the bootloader does for us.
> We can only do this for CPUs other than the original boot CPU, because
> the boot loader should be checking which are the secondary CPUs and
> putting those into this simple WFI loop with the GIC appropriately
> programmed.
>
> This means when we re-activate the CPU, we'll be waking it up in
> exactly the same way as we do when the kernel boots - and we have all
> that code around just waiting to be used.
As long as the bootloader doesn't mind, then this should work.
Will
next prev parent reply other threads:[~2010-12-07 17:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-07 16:43 [RFC] Fixing CPU Hotplug for RealView Platforms Will Deacon
2010-12-07 17:18 ` Russell King - ARM Linux
2010-12-07 17:47 ` Will Deacon [this message]
2010-12-08 6:03 ` Santosh Shilimkar
2010-12-08 13:20 ` Will Deacon
2010-12-08 20:20 ` Russell King - ARM Linux
2010-12-18 17:10 ` Russell King - ARM Linux
2010-12-18 17:44 ` Will Deacon
2010-12-18 19:22 ` Russell King - ARM Linux
-- strict thread matches above, loose matches on Subject: below --
2010-12-20 8:16 Vincent Guittot
2011-01-03 10:46 ` Russell King - ARM Linux
2011-01-03 17:39 ` Vincent Guittot
2011-01-03 18:03 ` Russell King - ARM Linux
2011-01-04 8:55 ` Vincent Guittot
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='007501cb9636$c0a54c90$41efe5b0$@deacon@arm.com' \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).