All of lore.kernel.org
 help / color / mirror / Atom feed
From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RESEND 1/2] arm: berlin: use non-self-cleared reset register to reset cpu
Date: Mon, 21 Sep 2015 10:18:25 +0800	[thread overview]
Message-ID: <20150921101825.099b304f@xhacker> (raw)
In-Reply-To: <55FEF511.2050600@gmail.com>

Dear Sebastian,

On Sun, 20 Sep 2015 20:04:01 +0200
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:

> On 14.09.2015 08:47, Jisheng Zhang wrote:
> > In Berlin SoCs, there are two kinds of cpu reset control registers: the
> > first one's corresponding bits will be self-cleared after some cycles,
> > while the second one's bits won't. Previously the first kind of reset
> > control register is used, this patch uses the second kind one to prepare
> > for the next hotplug commit.
> >
> > Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> > ---
> >   arch/arm/mach-berlin/platsmp.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
> > index 34a3753..bde327b 100644
> > --- a/arch/arm/mach-berlin/platsmp.c
> > +++ b/arch/arm/mach-berlin/platsmp.c
> > @@ -17,7 +17,7 @@
> >   #include <asm/smp_plat.h>
> >   #include <asm/smp_scu.h>
> >
> > -#define CPU_RESET		0x00
> > +#define CPU_RESET		0x20
> 
> Jisheng,
> 
> I am fine with the patch itself, except that I'd like to rather
> rename the 0x00-register to CPU_RESET_SC with a comment about
> the self-clearing nature. The 0x20-register would then be named
> CPU_RESET_NON_SC and used the way you propose.

Good idea. And such comment would let people understand why do we change
as that.

> 
> Are you fine with me naming the registers accordingly while
> applying the patches?

Sure, I'm fine. Thank you very much.

> 
> Sebastian
> 
> >   #define RESET_VECT		0x00
> >   #define SW_RESET_ADDR		0x94
> > @@ -31,6 +31,8 @@ static inline void berlin_perform_reset_cpu(unsigned int cpu)
> >   	u32 val;
> >
> >   	val = readl(cpu_ctrl + CPU_RESET);
> > +	val &= ~BIT(cpu_logical_map(cpu));
> > +	writel(val, cpu_ctrl + CPU_RESET);
> >   	val |= BIT(cpu_logical_map(cpu));
> >   	writel(val, cpu_ctrl + CPU_RESET);
> >   }
> >
> 

WARNING: multiple messages have this Message-ID (diff)
From: Jisheng Zhang <jszhang@marvell.com>
To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: <linux@arm.linux.org.uk>, <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND 1/2] arm: berlin: use non-self-cleared reset register to reset cpu
Date: Mon, 21 Sep 2015 10:18:25 +0800	[thread overview]
Message-ID: <20150921101825.099b304f@xhacker> (raw)
In-Reply-To: <55FEF511.2050600@gmail.com>

Dear Sebastian,

On Sun, 20 Sep 2015 20:04:01 +0200
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:

> On 14.09.2015 08:47, Jisheng Zhang wrote:
> > In Berlin SoCs, there are two kinds of cpu reset control registers: the
> > first one's corresponding bits will be self-cleared after some cycles,
> > while the second one's bits won't. Previously the first kind of reset
> > control register is used, this patch uses the second kind one to prepare
> > for the next hotplug commit.
> >
> > Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> > ---
> >   arch/arm/mach-berlin/platsmp.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-berlin/platsmp.c b/arch/arm/mach-berlin/platsmp.c
> > index 34a3753..bde327b 100644
> > --- a/arch/arm/mach-berlin/platsmp.c
> > +++ b/arch/arm/mach-berlin/platsmp.c
> > @@ -17,7 +17,7 @@
> >   #include <asm/smp_plat.h>
> >   #include <asm/smp_scu.h>
> >
> > -#define CPU_RESET		0x00
> > +#define CPU_RESET		0x20
> 
> Jisheng,
> 
> I am fine with the patch itself, except that I'd like to rather
> rename the 0x00-register to CPU_RESET_SC with a comment about
> the self-clearing nature. The 0x20-register would then be named
> CPU_RESET_NON_SC and used the way you propose.

Good idea. And such comment would let people understand why do we change
as that.

> 
> Are you fine with me naming the registers accordingly while
> applying the patches?

Sure, I'm fine. Thank you very much.

> 
> Sebastian
> 
> >   #define RESET_VECT		0x00
> >   #define SW_RESET_ADDR		0x94
> > @@ -31,6 +31,8 @@ static inline void berlin_perform_reset_cpu(unsigned int cpu)
> >   	u32 val;
> >
> >   	val = readl(cpu_ctrl + CPU_RESET);
> > +	val &= ~BIT(cpu_logical_map(cpu));
> > +	writel(val, cpu_ctrl + CPU_RESET);
> >   	val |= BIT(cpu_logical_map(cpu));
> >   	writel(val, cpu_ctrl + CPU_RESET);
> >   }
> >
> 


  reply	other threads:[~2015-09-21  2:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-14  6:47 [PATCH RESEND 0/2] arm: berlin: add cpu hotplug support Jisheng Zhang
2015-09-14  6:47 ` Jisheng Zhang
2015-09-14  6:47 ` [PATCH RESEND 1/2] arm: berlin: use non-self-cleared reset register to reset cpu Jisheng Zhang
2015-09-14  6:47   ` Jisheng Zhang
2015-09-20 18:04   ` Sebastian Hesselbarth
2015-09-20 18:04     ` Sebastian Hesselbarth
2015-09-21  2:18     ` Jisheng Zhang [this message]
2015-09-21  2:18       ` Jisheng Zhang
2015-10-12  5:53       ` Jisheng Zhang
2015-10-12  5:53         ` Jisheng Zhang
2015-09-14  6:47 ` [PATCH RESEND 2/2] arm: berlin: add CPU hotplug support Jisheng Zhang
2015-09-14  6:47   ` Jisheng Zhang

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=20150921101825.099b304f@xhacker \
    --to=jszhang@marvell.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.