From: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
To: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
Dmitry Torokhov
<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v4 1/3] ARM: rockchip: fix the CPU soft reset
Date: Sun, 07 Jun 2015 13:51:24 +0800 [thread overview]
Message-ID: <5573DBDC.2010204@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=VswV+MAgYr084VOxQynHrL1fdwnVb4b_W_bHUZgoW4mg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
在 2015年06月07日 11:43, Doug Anderson 写道:
> Caesar,
>
> On Sat, Jun 6, 2015 at 7:51 PM, Caesar Wang <wxt@rock-chips.com> wrote:
>> @@ -150,13 +159,15 @@ static int __cpuinit rockchip_boot_secondary(unsigned
>> int cpu,
>> * sram_base_addr + 4: 0xdeadbeaf
>> * sram_base_addr + 8: start address for pc
>> * */
>> - udelay(10);
>> + udelay(20);
>>
>> I increased the 'udelay(20)' or 'udelay(50)' in rockchip_boot_secondary().
>> Set#2 also can repro this issue over 22600 cycles with testing scripts.
>> (about 1 hours)
>>
>> log:
>> ================= 226 ============
>> [ 4069.134419] CPU1: shutdown
>> [ 4069.164431] CPU2: shutdown
>> [ 4069.204475] CPU3: shutdown
>> ......
>> [ 4072.454453] CPU1: shutdown
>> [ 4072.504436] CPU2: shutdown
>> [ 4072.554426] CPU3: shutdown
>> [ 4072.577827] CPU1: Booted secondary processor
>> [ 4072.582611] CPU2: Booted secondary processor
>> [ 4072.587426] CPU3: Booted secondary processor
>> <hang>
>>
>> The set #4 will be better work.
> OK, I'm OK with this, but I'd like to get Heiko's opinion.
>
> Also:
> * Just for kicks, does mdelay(1) work? I know that's 100x more than
OK, it should delay more time.
the mdelay(1) can be work over 50000 cycles, so that should be work.
Perhaps, can we use 'usleep_range(500, 1000)' to work.
Heiko, do you agree with it?
> udelay(10), but previously we were actually looping waiting for the
> power domain, right? ...so maybe the old code used to introduce a
> pretty big delay.
>
> * Does anyone from the chip design team have any idea why patch set #4
> works but patch set #2 doesn't? I know it's Sunday morning in China
> right now, but maybe you could ask Monday?
>
>
> Thanks!
>
> -Doug
>
>
>
--
Thanks,
- Caesar
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: wxt@rock-chips.com (Caesar Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/3] ARM: rockchip: fix the CPU soft reset
Date: Sun, 07 Jun 2015 13:51:24 +0800 [thread overview]
Message-ID: <5573DBDC.2010204@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=VswV+MAgYr084VOxQynHrL1fdwnVb4b_W_bHUZgoW4mg@mail.gmail.com>
? 2015?06?07? 11:43, Doug Anderson ??:
> Caesar,
>
> On Sat, Jun 6, 2015 at 7:51 PM, Caesar Wang <wxt@rock-chips.com> wrote:
>> @@ -150,13 +159,15 @@ static int __cpuinit rockchip_boot_secondary(unsigned
>> int cpu,
>> * sram_base_addr + 4: 0xdeadbeaf
>> * sram_base_addr + 8: start address for pc
>> * */
>> - udelay(10);
>> + udelay(20);
>>
>> I increased the 'udelay(20)' or 'udelay(50)' in rockchip_boot_secondary().
>> Set#2 also can repro this issue over 22600 cycles with testing scripts.
>> (about 1 hours)
>>
>> log:
>> ================= 226 ============
>> [ 4069.134419] CPU1: shutdown
>> [ 4069.164431] CPU2: shutdown
>> [ 4069.204475] CPU3: shutdown
>> ......
>> [ 4072.454453] CPU1: shutdown
>> [ 4072.504436] CPU2: shutdown
>> [ 4072.554426] CPU3: shutdown
>> [ 4072.577827] CPU1: Booted secondary processor
>> [ 4072.582611] CPU2: Booted secondary processor
>> [ 4072.587426] CPU3: Booted secondary processor
>> <hang>
>>
>> The set #4 will be better work.
> OK, I'm OK with this, but I'd like to get Heiko's opinion.
>
> Also:
> * Just for kicks, does mdelay(1) work? I know that's 100x more than
OK, it should delay more time.
the mdelay(1) can be work over 50000 cycles, so that should be work.
Perhaps, can we use 'usleep_range(500, 1000)' to work.
Heiko, do you agree with it?
> udelay(10), but previously we were actually looping waiting for the
> power domain, right? ...so maybe the old code used to introduce a
> pretty big delay.
>
> * Does anyone from the chip design team have any idea why patch set #4
> works but patch set #2 doesn't? I know it's Sunday morning in China
> right now, but maybe you could ask Monday?
>
>
> Thanks!
>
> -Doug
>
>
>
--
Thanks,
- Caesar
WARNING: multiple messages have this Message-ID (diff)
From: Caesar Wang <wxt@rock-chips.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Heiko Stuebner <heiko@sntech.de>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
"open list:ARM/Rockchip SoC..."
<linux-rockchip@lists.infradead.org>,
Russell King <linux@arm.linux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/3] ARM: rockchip: fix the CPU soft reset
Date: Sun, 07 Jun 2015 13:51:24 +0800 [thread overview]
Message-ID: <5573DBDC.2010204@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=VswV+MAgYr084VOxQynHrL1fdwnVb4b_W_bHUZgoW4mg@mail.gmail.com>
在 2015年06月07日 11:43, Doug Anderson 写道:
> Caesar,
>
> On Sat, Jun 6, 2015 at 7:51 PM, Caesar Wang <wxt@rock-chips.com> wrote:
>> @@ -150,13 +159,15 @@ static int __cpuinit rockchip_boot_secondary(unsigned
>> int cpu,
>> * sram_base_addr + 4: 0xdeadbeaf
>> * sram_base_addr + 8: start address for pc
>> * */
>> - udelay(10);
>> + udelay(20);
>>
>> I increased the 'udelay(20)' or 'udelay(50)' in rockchip_boot_secondary().
>> Set#2 also can repro this issue over 22600 cycles with testing scripts.
>> (about 1 hours)
>>
>> log:
>> ================= 226 ============
>> [ 4069.134419] CPU1: shutdown
>> [ 4069.164431] CPU2: shutdown
>> [ 4069.204475] CPU3: shutdown
>> ......
>> [ 4072.454453] CPU1: shutdown
>> [ 4072.504436] CPU2: shutdown
>> [ 4072.554426] CPU3: shutdown
>> [ 4072.577827] CPU1: Booted secondary processor
>> [ 4072.582611] CPU2: Booted secondary processor
>> [ 4072.587426] CPU3: Booted secondary processor
>> <hang>
>>
>> The set #4 will be better work.
> OK, I'm OK with this, but I'd like to get Heiko's opinion.
>
> Also:
> * Just for kicks, does mdelay(1) work? I know that's 100x more than
OK, it should delay more time.
the mdelay(1) can be work over 50000 cycles, so that should be work.
Perhaps, can we use 'usleep_range(500, 1000)' to work.
Heiko, do you agree with it?
> udelay(10), but previously we were actually looping waiting for the
> power domain, right? ...so maybe the old code used to introduce a
> pretty big delay.
>
> * Does anyone from the chip design team have any idea why patch set #4
> works but patch set #2 doesn't? I know it's Sunday morning in China
> right now, but maybe you could ask Monday?
>
>
> Thanks!
>
> -Doug
>
>
>
--
Thanks,
- Caesar
next prev parent reply other threads:[~2015-06-07 5:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-05 17:05 [PATCH v4 0/3] ARM: rockchip: fix the SMP Caesar Wang
2015-06-05 17:05 ` Caesar Wang
2015-06-05 17:05 ` [PATCH v4 1/3] ARM: rockchip: fix the CPU soft reset Caesar Wang
2015-06-05 17:05 ` Caesar Wang
2015-06-05 20:55 ` Doug Anderson
2015-06-05 20:55 ` Doug Anderson
2015-06-07 2:51 ` Caesar Wang
2015-06-07 2:51 ` Caesar Wang
2015-06-07 3:43 ` Doug Anderson
2015-06-07 3:43 ` Doug Anderson
[not found] ` <CAD=FV=VswV+MAgYr084VOxQynHrL1fdwnVb4b_W_bHUZgoW4mg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-07 5:51 ` Caesar Wang [this message]
2015-06-07 5:51 ` Caesar Wang
2015-06-07 5:51 ` Caesar Wang
[not found] ` <5573DBDC.2010204-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2015-06-07 9:02 ` Heiko Stübner
2015-06-07 9:02 ` Heiko Stübner
2015-06-07 9:02 ` Heiko Stübner
2015-06-05 17:05 ` [PATCH v4 2/3] ARM: rockchip: ensure CPU to enter WFI/WFE state Caesar Wang
2015-06-05 17:05 ` Caesar Wang
2015-06-05 17:05 ` [PATCH v4 3/3] ARM: rockchip: fix the SMP code style Caesar Wang
2015-06-05 17:05 ` Caesar Wang
2015-06-05 20:58 ` Doug Anderson
2015-06-05 20:58 ` Doug Anderson
-- strict thread matches above, loose matches on Subject: below --
2015-06-05 17:03 [PATCH v4 0/3] ARM: rockchip: fix the SMP Caesar Wang
2015-06-05 17:03 ` [PATCH v4 1/3] ARM: rockchip: fix the CPU soft reset Caesar Wang
2015-06-05 17:03 ` Caesar Wang
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=5573DBDC.2010204@rock-chips.com \
--to=wxt-tnx95d0mmh7dzftrwevzcw@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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.