All of lore.kernel.org
 help / color / mirror / Atom feed
From: Caesar Wang <wxt@rock-chips.com>
To: Doug Anderson <dianders@chromium.org>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Heiko Stuebner <heiko@sntech.de>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"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 v3 2/3] ARM: rockchip: ensure CPU to enter WFI/WFE state
Date: Mon, 08 Jun 2015 12:56:07 +0800	[thread overview]
Message-ID: <55752067.2040108@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=UamkH+RHmHHVzGKZda_w0teGBdfcH-LbCKqyp2q1OVqA@mail.gmail.com>



在 2015年06月06日 04:24, Doug Anderson 写道:
> Russell,
>
> On Fri, Jun 5, 2015 at 11:29 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> 1) v7_coherency_exit() is specific to v7 CPUs and can't be used by
>>     generic code.
> Oh, I see.  So (I think) you're saying that perhaps the reason that
> Caesar needed his patch was that he needed the dying processor to
> execute v7_exit_coherency_flush(), NOT that he needed the dying
> processor to be in WFI/WFE.  That actually makes a lot more sense to
> me!  :)  Thanks a lot for pointing that out, it's very helpful.
>
>
>> So, we're actually in a very sticky position over taking CPUs offline.
>> It seems to be something that the ARM architecture and kernel
>> architecture doesn't actually allow to be done safely.  So much so,
>> that in a similar way to the original Keystone 2 physical address
>> switch, I'm tempted to make taking a CPU offline taint the kernel!
> Wow, that's going to suck.  So if you want to suspend / resume you
> need to taint your kernel.  So much for saving the planet by going
> into suspend...  ...or are you thinking that it won't taint the kernel
> when the kernel takes CPUs offline for suspend/resume purposes?  ...or
> are you thinking you've some solution that works for suspend/resume
> that doesn't work for the general cpu offlining problem?  I'd be very
> interested to hear...
>
>
> I know I'm not a maintainer, but if I were and I knew that lots of
> smart people had thought about the problem of CPU offlining and they
> didn't have a solution and I could make my platform 99.99999999%
> reliable by allowing a very safe mdelay(1) where I had a pretty strong
> guarantee that the 1ms was enough time, I would probably accept that
> code...
>
>
> So since I'm not a maintainer and I certainly couldn't ack such code,
> I would certainly be happy to add my Reviewed-by to Caesar's patch if
> he changed it mention that he needed to make sure that
> v7_exit_coherency_flush() in rockchip_cpu_die() executed in time.

OK.
The dying processor to execute v7_exit_coherency_flush(),not that the 
dying processor to be in WFI/WFE.

It's needed to enter WFI/WFE state from the ARM refer document when CPU 
down.

But......

Here is my test: (won't to enter the WFI state)
@@ -331,8 +331,8 @@ static int rockchip_cpu_kill(unsigned int cpu)
  static void rockchip_cpu_die(unsigned int cpu)
  {
         v7_exit_coherency_flush(louis);
-       while (1)
-               cpu_do_idle();
+       while (1);
+               //cpu_do_idle();
  }

echo 0 > /sys/module/printk/parameters/console_suspend
echo 1 > /sys/power/pm_print_times
echo mem > sys/power/state

You can play anything
or do some test for CPU up/down:

cd /sys/devices/system/cpu/
for i in $(seq 10000); do
   echo "================= $i ============"
   for j in $(seq 100); do
     while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" 
!= "000" ]]; do

       echo 0 > cpu1/online
       echo 0 > cpu2/online
       echo 0 > cpu3/online
     done
     while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" 
!= "111" ]]; do
       echo 1 > cpu1/online
       echo 1 > cpu2/online
       echo 1 > cpu3/online
     done
   done
done
Sometimes,the system will be restart when do the about test.
I'm no sure what's happen, That maybe abnormal won't to enter the WFI 
state.

>
> -Doug
>
>
>

-- 
Thanks,
- Caesar

WARNING: multiple messages have this Message-ID (diff)
From: wxt@rock-chips.com (Caesar Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/3] ARM: rockchip: ensure CPU to enter WFI/WFE state
Date: Mon, 08 Jun 2015 12:56:07 +0800	[thread overview]
Message-ID: <55752067.2040108@rock-chips.com> (raw)
In-Reply-To: <CAD=FV=UamkH+RHmHHVzGKZda_w0teGBdfcH-LbCKqyp2q1OVqA@mail.gmail.com>



? 2015?06?06? 04:24, Doug Anderson ??:
> Russell,
>
> On Fri, Jun 5, 2015 at 11:29 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> 1) v7_coherency_exit() is specific to v7 CPUs and can't be used by
>>     generic code.
> Oh, I see.  So (I think) you're saying that perhaps the reason that
> Caesar needed his patch was that he needed the dying processor to
> execute v7_exit_coherency_flush(), NOT that he needed the dying
> processor to be in WFI/WFE.  That actually makes a lot more sense to
> me!  :)  Thanks a lot for pointing that out, it's very helpful.
>
>
>> So, we're actually in a very sticky position over taking CPUs offline.
>> It seems to be something that the ARM architecture and kernel
>> architecture doesn't actually allow to be done safely.  So much so,
>> that in a similar way to the original Keystone 2 physical address
>> switch, I'm tempted to make taking a CPU offline taint the kernel!
> Wow, that's going to suck.  So if you want to suspend / resume you
> need to taint your kernel.  So much for saving the planet by going
> into suspend...  ...or are you thinking that it won't taint the kernel
> when the kernel takes CPUs offline for suspend/resume purposes?  ...or
> are you thinking you've some solution that works for suspend/resume
> that doesn't work for the general cpu offlining problem?  I'd be very
> interested to hear...
>
>
> I know I'm not a maintainer, but if I were and I knew that lots of
> smart people had thought about the problem of CPU offlining and they
> didn't have a solution and I could make my platform 99.99999999%
> reliable by allowing a very safe mdelay(1) where I had a pretty strong
> guarantee that the 1ms was enough time, I would probably accept that
> code...
>
>
> So since I'm not a maintainer and I certainly couldn't ack such code,
> I would certainly be happy to add my Reviewed-by to Caesar's patch if
> he changed it mention that he needed to make sure that
> v7_exit_coherency_flush() in rockchip_cpu_die() executed in time.

OK.
The dying processor to execute v7_exit_coherency_flush(),not that the 
dying processor to be in WFI/WFE.

It's needed to enter WFI/WFE state from the ARM refer document when CPU 
down.

But......

Here is my test: (won't to enter the WFI state)
@@ -331,8 +331,8 @@ static int rockchip_cpu_kill(unsigned int cpu)
  static void rockchip_cpu_die(unsigned int cpu)
  {
         v7_exit_coherency_flush(louis);
-       while (1)
-               cpu_do_idle();
+       while (1);
+               //cpu_do_idle();
  }

echo 0 > /sys/module/printk/parameters/console_suspend
echo 1 > /sys/power/pm_print_times
echo mem > sys/power/state

You can play anything
or do some test for CPU up/down:

cd /sys/devices/system/cpu/
for i in $(seq 10000); do
   echo "================= $i ============"
   for j in $(seq 100); do
     while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" 
!= "000" ]]; do

       echo 0 > cpu1/online
       echo 0 > cpu2/online
       echo 0 > cpu3/online
     done
     while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" 
!= "111" ]]; do
       echo 1 > cpu1/online
       echo 1 > cpu2/online
       echo 1 > cpu3/online
     done
   done
done
Sometimes,the system will be restart when do the about test.
I'm no sure what's happen, That maybe abnormal won't to enter the WFI 
state.

>
> -Doug
>
>
>

-- 
Thanks,
- Caesar

  reply	other threads:[~2015-06-08  4:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-05 15:11 [PATCH v3 0/3] ARM: rockchip: fix the SMP Caesar Wang
2015-06-05 15:11 ` Caesar Wang
2015-06-05 15:11 ` [PATCH v3 1/3] ARM: rockchip: fix the CPU soft reset Caesar Wang
2015-06-05 15:11   ` Caesar Wang
     [not found]   ` <1433517104-7595-2-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2015-06-05 15:52     ` Heiko Stübner
2015-06-05 15:52       ` Heiko Stübner
2015-06-05 15:52       ` Heiko Stübner
2015-06-05 16:17       ` Heiko Stübner
2015-06-05 16:17         ` Heiko Stübner
2015-06-05 16:28   ` Doug Anderson
2015-06-05 16:28     ` Doug Anderson
2015-06-05 15:11 ` [PATCH v3 2/3] ARM: rockchip: ensure CPU to enter WFI/WFE state Caesar Wang
2015-06-05 15:11   ` Caesar Wang
2015-06-05 17:49   ` Doug Anderson
2015-06-05 17:49     ` Doug Anderson
2015-06-05 18:29     ` Russell King - ARM Linux
2015-06-05 18:29       ` Russell King - ARM Linux
2015-06-05 20:24       ` Doug Anderson
2015-06-05 20:24         ` Doug Anderson
2015-06-08  4:56         ` Caesar Wang [this message]
2015-06-08  4:56           ` Caesar Wang
2015-06-08 20:52           ` Doug Anderson
2015-06-08 20:52             ` Doug Anderson
2015-06-05 15:11 ` [PATCH v3 3/3] ARM: rockchip: fix the SMP code style Caesar Wang
2015-06-05 15:11   ` 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=55752067.2040108@rock-chips.com \
    --to=wxt@rock-chips.com \
    --cc=dianders@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    /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.