public inbox for linux-snps-arc@lists.infradead.org
 help / color / mirror / Atom feed
From: Vineet.Gupta1@synopsys.com (Vineet Gupta)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] arc: use hardware ARCNUM in smp_processor_id()
Date: Wed, 7 Dec 2016 11:03:39 -0800	[thread overview]
Message-ID: <718dad11-573a-294a-b9df-8ada0d49fcee@synopsys.com> (raw)
In-Reply-To: <1481124922-30942-1-git-send-email-abrodkin@synopsys.com>

On 12/07/2016 07:36 AM, Alexey Brodkin wrote:
> We used to think that ARC cores in SMP SoC start
> consequentially, i.e. core0 -> core1 -> core2 -> core4.
>
> Moreover we treat core0 as a master core which does some
> low-level initialization before allowing other cores to
> start doing real stuff.
>
> In that case everything works as expected - smp_processor_id()
> returns expected values for all cores, i.e.:
>  0 for core0
>  1 for core1 etc.
>
> But what if instead of core0 we want core1 to be the master?
> That might be the case if we want to use only one core out of
> SMP setup and that core is not core0 or for some other reason
> modify core start-up sequence to say: core3 -> core1 > ...
>
> In that case smp_processor_id() returns values that differ
> from real hardware core index. For the first/master core that
> we'l get 0, the next one will be 1 etc.

But then the problem is you are not setting up thread_info->cpu correctly. And
that needs fixing.
Say we already had ur next patch which doesn't assume 0 based masters, then is
this patch still needed.

Essentially this change can be taken as an optimization (mem vz. aux reg read) but
I don't think it is a fix !

> The problem here is we'll use improper cpu indexes in MCIP commands
> and inevitably commands will be sent to unexpected cores causing all
> sorts of unexpected behavior.
>
> But if we use hardware core index out out IDENTITY AUX reg that problem
> won't happen because cpu value will match its hardware index.
>
> Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> Cc: stable at vger.kernel.org
> ---
>  arch/arc/include/asm/smp.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arc/include/asm/smp.h b/arch/arc/include/asm/smp.h
> index 0861007d9ef3..5aad65d3defd 100644
> --- a/arch/arc/include/asm/smp.h
> +++ b/arch/arc/include/asm/smp.h
> @@ -14,8 +14,9 @@
>  #include <linux/types.h>
>  #include <linux/init.h>
>  #include <linux/threads.h>
> +#include <asm/arcregs.h>
>  
> -#define raw_smp_processor_id() (current_thread_info()->cpu)
> +#define raw_smp_processor_id() ((int)(read_aux_reg(AUX_IDENTITY) >> 8) & 0xFF)
>  
>  /* including cpumask.h leads to cyclic deps hence this Forward declaration */
>  struct cpumask;

      parent reply	other threads:[~2016-12-07 19:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-07 15:35 [PATCH] arc: use hardware ARCNUM in smp_processor_id() Alexey Brodkin
2016-12-07 18:58 ` Vineet Gupta
2016-12-07 19:03 ` Vineet Gupta [this message]

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=718dad11-573a-294a-b9df-8ada0d49fcee@synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=linux-snps-arc@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