Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932208AbbFHUwd (ORCPT ); Mon, 8 Jun 2015 16:52:33 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:33680 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753541AbbFHUwQ (ORCPT ); Mon, 8 Jun 2015 16:52:16 -0400 MIME-Version: 1.0 In-Reply-To: <55752067.2040108@rock-chips.com> References: <1433517104-7595-1-git-send-email-wxt@rock-chips.com> <1433517104-7595-3-git-send-email-wxt@rock-chips.com> <20150605182947.GN7557@n2100.arm.linux.org.uk> <55752067.2040108@rock-chips.com> Date: Mon, 8 Jun 2015 13:52:15 -0700 X-Google-Sender-Auth: 3BwLr0IpQKCryPSTohKUfsGSknE Message-ID: Subject: Re: [PATCH v3 2/3] ARM: rockchip: ensure CPU to enter WFI/WFE state From: Doug Anderson To: Caesar Wang Cc: Russell King - ARM Linux , Heiko Stuebner , Dmitry Torokhov , "open list:ARM/Rockchip SoC..." , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2867 Lines: 82 Caesar, On Sun, Jun 7, 2015 at 9:56 PM, Caesar Wang wrote: > 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 assume you meant the _above_ test. So it sometimes works and sometimes doesn't? Strange... > I'm no sure what's happen, That maybe abnormal won't to enter the WFI state. Good test. I think I understood what you said above: basically if you don't get to the WFI state then the system will sometimes restart. I guess that seems a little strange to me since I would have thought that since you assert "reset" to the CPU before you power it off it wouldn't matter a whole lot what state the system was in. The processor has exited concurrency and isn't touching any memory, so nothing it does should be hurting anyone. ...but I also am only guessing about how all this works / trying to use common sense. If we really need to be in WFI/WFE then I guess that's what we need to do. It still makes me nervous to say both that we "need to be in WFI" and that we have a loop around cpu_do_idle(). The loop implies that cpu_do_idle() might return sometimes. That would be OK, except now we've learned that if we happen to kill the CPU while we're executing the loop that it might crash the system. That's pretty non-ideal. I know the chances are incredibly unlikely, but still something that worries me... -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/