Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp976699imu; Wed, 23 Jan 2019 08:49:35 -0800 (PST) X-Google-Smtp-Source: ALg8bN7FFkTHu4Kj6wraKbbpJ1LFCHkDvxA8ZChUJn2mg2ikNZcbXJSuzEvCg9zr+1Mzz0MZX4av X-Received: by 2002:a17:902:7c05:: with SMTP id x5mr2844356pll.273.1548262175585; Wed, 23 Jan 2019 08:49:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548262175; cv=none; d=google.com; s=arc-20160816; b=vz4DLshol6voQTlohf6/t6M+2/UFn/+jcIUu3FgOVsrztyRxwgW/qvcKvzpkUWnz0+ KSR7hQHPB71kHa0Is75QIXk6nRYDChgc9O3hhuBvzGkiL7mREofr2TKjrBcxDtg/kTOS y4gGQdrP9b/68dXBf2rQvo0I+gG64AvEwfflM1dHTf9k/Z8EmyK6R25p7VHUb+vmGqoR EX35Gd5MMF1+gQtLkKnUEtJnIfMVZB80fSqil6g1wqyY6jadpUWSpSbEWu+WdvLpIDDx eVFc0pceeLnJ+s7nmPu4gyoD4EBGgBZ78uyNWTcRhUTO1EbjEXymaEW3T95BuP7/uw0Z Dwsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=hB9nUjl0sqV9zN3jlNRqESRWei1+GXjVqdcSr1SJCb8=; b=gF5PkjwPr5FxeyH3WoW9YbrrPJ4CJctqvT+IUGbycWkrJ3GmdIiGasw4MsMLs9AHDL rfYwID+cWUhBphPgYcGCB8Oj3+rW5B3YqHlWzQ7wuyQDrvxPZIKB/LK1I+ToGant+ZQK zponalcypbU/bYFYForuB6zbyVDQ5d4/7s4WqoNAuvukS+V0q5OylF/GbNNRr0vKVS8r /B4RUdIB9w8Rg12zZ+ut5RD0J3w+b/d/7wp+cqSS2gpOXbSC8L/M2N7E1QskOSaP4y/G HLjDVJdmo8GuMft6dkGgE2GW9sn0xa6hcHzR6IlnzVVcL/i90S1zrnkX5kUvc1rXEArw petA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o11si19406465pll.160.2019.01.23.08.49.18; Wed, 23 Jan 2019 08:49:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726154AbfAWQsK (ORCPT + 99 others); Wed, 23 Jan 2019 11:48:10 -0500 Received: from foss.arm.com ([217.140.101.70]:44072 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725862AbfAWQsJ (ORCPT ); Wed, 23 Jan 2019 11:48:09 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 15FBFEBD; Wed, 23 Jan 2019 08:48:09 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F12E33F237; Wed, 23 Jan 2019 08:48:06 -0800 (PST) Date: Wed, 23 Jan 2019 16:48:02 +0000 From: Mark Rutland To: Pramod Kumar Cc: Sudeep Holla , Catalin Marinas , Will Deacon , Suzuki K Poulose , Dave Martin , Rob Herring , Lorenzo Pieralisi , Steve Capper , BCM Kernel Feedback , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 1/1] arm64: Use PSCI calls for CPU stop when hotplug is supported Message-ID: <20190123164801.GA55887@lakrids.cambridge.arm.com> References: <1547790380-6276-1-git-send-email-pramod.kumar@broadcom.com> <20190118113242.GA8928@e107155-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 21, 2019 at 11:30:02AM +0530, Pramod Kumar wrote: > On Mon, Jan 21, 2019 at 11:28 AM Pramod Kumar > wrote: > > Need comes from a specific use case where one Accelerator card(SoC) is > plugged in a sever over a PCIe interface. This Card gets supply from a > battery, which could provide very less power for a very small time, in case > of any power loss. Once Card switches to battery, this has to reduce its > power consumption to its lowest point and back-up the DDR contents asap > before battery gets fully drained off. In this example is Linux running on the server, or on the accelerator? What precisely are you trying to back up from DDR, and why? What is responsible for backing up that contents? > Since battery can provide limited power for a very short time hence need to > transition to lowest power. As per the transition process , CPUs power > domain has to be off but before that it needs to flush out its content to > system memory(L3) so that content could be backed-up by a MCU, a controller > consuming very less power. Since we can not afford plugging-out every > individual CPUs in sequence hence uses ipi_cpu_stop for all other CPUs > which ultimately switch to ATF to flush out all the CPUs caches and comes > out of coherency domain so that its power rails could be switched-off. If you're stopping CPUs from completely arbitrary states, what is the benefit of saving the RAM contents? CPUs might be running with IRQs disabled for an arbitrarily long time, so there's no guarantee that all of them will be turned off before power is lost. I'm very confused as to what you're trying to achieve here. Thanks, Mark.