From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA856C282DD for ; Thu, 9 Jan 2020 15:03:35 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 77EA02067D for ; Thu, 9 Jan 2020 15:03:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KSj8gc4f"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="oDNhfyut" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77EA02067D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LvIEH86GVa7GjcM9n574oDYdfmLXkae3YzQIFybxIRc=; b=KSj8gc4fa38q4z DsV+F6meczyFXVDmjOKpgvP1QZIdaNelixCRoDK4NAu82t5AVYuifBWS3DKc+Tv8pQTbUjFqBXaYn Bhl22rG5pdH4BcYQx9DjvmmqbWropw8nnsqddIylyJabrmq5bhPS4B3sBSkYSzwGscVmjdBJVqUfa TF25KRiI2a/XhXfpCIZ8OmD7MrJ5iImCTbccieUzCAgmg5suWr41gftPKqDG5PyLq0GaGjvMIXD4z 5wuyFgzjEKQcyFGIwTLt22eqjqYWBAzTq04uvDPbHhTX4v367qE1i63Njmg1M/eGjwDRO53a3WNsm 36Dd4QOLGRDip+V8u3vQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ipZLL-0001Bk-JW; Thu, 09 Jan 2020 15:03:27 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ipZLI-0001BF-42 for linux-arm-kernel@lists.infradead.org; Thu, 09 Jan 2020 15:03:25 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 571ED2067D; Thu, 9 Jan 2020 15:03:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578582203; bh=OQZ2YdOpS1y/7pFJQtE5FBNHy1UBhwGIboxLjUnOO04=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oDNhfyutSYDKCzDauZlMYQG3iP7+gsLXdX6hSIAoqPCma9GK2zK5T7QIAsJPISTlg xuy/f1mQS31Erz3szwch7ZiaMYioFi1RS7DsEJC7XMlwwjyaDfoaKa2QfBef0KUfhJ WOiu28zXW6M3oS9Dxg2lUO7i/juT4isXOh0i3FHU= Date: Thu, 9 Jan 2020 15:03:19 +0000 From: Will Deacon To: Xiongfeng Wang Subject: Re: [Question] About handling PMU context loss in the deepest idle state where the core is powered down Message-ID: <20200109150318.GF12236@willie-the-truck> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200109_070324_195402_521FEC47 X-CRM114-Status: GOOD ( 15.36 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, wangzhe59@huawei.com, lorenzo.pieralisi@arm.com, Catalin Marinas , huawei.libin@huawei.com, guohanjun@huawei.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org [+Lorenzo] On Thu, Jan 09, 2020 at 10:43:40AM +0800, Xiongfeng Wang wrote: > Sorry to bother you. It's just that we have come across some problems > about PMU recently. No bother, and thanks for including the mailing list. > We are working on deep power state on CPU cores. In the deepest idle state, the core will be > powered down. In our implementation, the PMU and the core are in the same power domain, > so the PMU will also be powered down. But I didn't find where we saved the PMU context > in kernel before entering the deepest idle state. > > Before we enter the system sleep state, we update the kernel PMU counter and stop the PMU > in 'cpu_pm_pmu_notify()'. But we didn't do that before we enter idle state. > I only find some system registers saving in 'psci_cpu_suspend_enter()->cpu_susend()->cpu_do_suspend()' I'm not sure what you mean by "system sleep state", but if you're putting the CPU into a state where register contents is lost, then I think you need those PM notifiers to run. My understanding was that CPUidle took care of this. Why is that not sufficient for you? > Do you have some suggestion about how we can handle this problem ? > Should we save and restore the PMU context before and after the deepest idle state . I don't know > if we can take care of the PMU counters and interrupts properly by saving and restoring > the PMU registers. > Or we should update the kernel counter and stop the PMU, like what we did in system sleep situation. > Or we should let the firmware to handle the saving and restoring problem. If the idle state is somehow autonomous (i.e. the kernel is not aware of it), then I suppose firmware has to save/restore the register state that is not otherwise preserved. However, I'd like to understand if this is really what's happening and why CPUidle isn't just doing the right thing. Thanks, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel