linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: elder@linaro.org (Alex Elder)
To: linux-arm-kernel@lists.infradead.org
Subject: mach-spear SMP questions
Date: Thu, 27 Mar 2014 11:56:44 -0500	[thread overview]
Message-ID: <5334584C.1090708@linaro.org> (raw)
In-Reply-To: <20140327143933.GD7528@n2100.arm.linux.org.uk>

On 03/27/2014 09:39 AM, Russell King - ARM Linux wrote:
> On Thu, Mar 27, 2014 at 08:33:38AM -0500, Alex Elder wrote:
>> I'm doing some code cleanup and have a question about
>> something related to SMP in mach-spear.  Can anyone
>> help me with these questions?
> 
> I think you're working in a similar area to that which I have been - but
> with different ends in mind.  Have a look for my L2 cache series on LAKML.

By "different ends in mind," do you mean conflicting
goals, or simply for different reasons?

>> My question has to do with how secondary cores start for
>> SMP.  Most machines need to send a wakeup event from the
>> boot core to each secondary core as it is told to start.
>> But mach-spear does not do this.  I'd like to know if this
>> is an oversight, or confirm that this is simply not necessary
>> for this machine.
> 
> It could be that the "BootMonitor" waits for spear13xx_smp_prepare_cpus()
> to write the address of the function to jump to into SYS_LOCATION - I can't
> see any other way this code would work (there's nothing else there to tell
> the secondary CPUs where to start executing from or when to start executing
> from that point.)

That could be.

My next question is whether sending a wakeup event would
be *harmful*.  If it's not, this machine can use the
common pen-release code I'm consolidating things to use.

>> Also, while most machines touch a memory location and then
>> do a targeted cache involving only that location, mach-spear
>> does a full flush.  Is the full flush really required for
>> some reason?
> 
> It's not required.  As part of the L2 cache cleanup, I have this
> change:

That's perfect.  Just like all other implementations
(so I can factor it out).  Now I just need to know
whether I can use the shared the smp_boot_secondary
method.

Thanks.

					-Alex

> Author: Russell King <rmk+kernel@arm.linux.org.uk>
> Date:   Sat Mar 15 16:47:47 2014 +0000
> 
>     ARM: l2c: avoid calling outer_flush_all() unnecessarily (Spear)
> 
>     Spear calls outer_flush_all() from it's SMP bringup function.  This
>     is potentially dangerous as the L2C set/way operations which implement
>     this don't take kindly to concurrent operations.  Besides, there's
>     better solutions to this, as implemented on other platforms.
> 
>     Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> @@ -20,6 +20,18 @@
> +/*
> + * Write pen_release in a way that is guaranteed to be visible to all
> + * observers, irrespective of whether they're taking part in coherency
> + * or not.  This is necessary for the hotplug code to work reliably.
> + */
> +static void write_pen_release(int val)
> +{
> +       pen_release = val;
> +       smp_wmb();
> +       sync_cache_w(&pen_release);
> +}
> +
> ...
> @@ -30,8 +42,7 @@ static void spear13xx_secondary_init(unsigned int cpu)
> -       pen_release = -1;
> -       smp_wmb();
> +       write_pen_release(-1);
> ...
> @@ -58,9 +69,7 @@ static int spear13xx_boot_secondary(unsigned int cpu, struct t
> -       pen_release = cpu;
> -       flush_cache_all();
> -       outer_flush_all();
> +       write_pen_release(cpu);
> 
> for Spear, which makes it behave like every other platform we have using
> this pen release method.
> 

  reply	other threads:[~2014-03-27 16:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 13:33 mach-spear SMP questions Alex Elder
2014-03-27 14:39 ` Russell King - ARM Linux
2014-03-27 16:56   ` Alex Elder [this message]
2014-03-27 17:19     ` Russell King - ARM Linux
2014-03-27 19:08       ` Alex Elder
2014-03-27 14:40 ` Viresh Kumar

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=5334584C.1090708@linaro.org \
    --to=elder@linaro.org \
    --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).