From: Sudeep Holla <sudeep.holla@arm.com>
To: Scott Branden <scott.branden@broadcom.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Pramod Kumar <pramod.kumar@broadcom.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Suzuki K Poulose <Suzuki.Poulose@arm.com>,
Dave Martin <dave.martin@arm.com>, Rob Herring <robh@kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Steve Capper <steve.capper@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
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
Date: Wed, 23 Jan 2019 17:21:15 +0000 [thread overview]
Message-ID: <20190123172115.GA31694@e107155-lin> (raw)
In-Reply-To: <f1851a76-8078-b8e7-6a54-b038b47f9214@broadcom.com>
On Wed, Jan 23, 2019 at 09:05:26AM -0800, Scott Branden wrote:
> Hi Mark,
>
> Hopefully I can shed some light on the use case inline.
>
> On 2019-01-23 8:48 a.m., Mark Rutland wrote:
> > On Mon, Jan 21, 2019 at 11:30:02AM +0530, Pramod Kumar wrote:
> > > On Mon, Jan 21, 2019 at 11:28 AM Pramod Kumar <pramod.kumar@broadcom.com>
> > > 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?
> Accelerator
> >
> > What precisely are you trying to back up from DDR, and why?
> Data in DDR is being written to disk at this time (disk is connected to
> accelerator)
> >
> > What is responsible for backing up that contents?
>
> A low power M-class processor and DMA engine which continues necessary
> operations to transfer DDR memory to disk.
>
> The high power processors on the accelerator running linux needed to be
> halted ASAP on this power loss event and M0 take over. Graceful shutdown of
> linux and other peripherals is unnecessary (and we don't have the power
> necessary to do so).
>
It may be unnecessary for your use-case, but not recommended.
> >
> > > 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?
>
> Some of the RAM contains data that was in the process of being written to
> disk by the accelerator.
>
> This data must be saved to disk and the high power CPUs consume too much
> power to continue performing this operation.
>
Why will suspend to ram or idle not work ? It will power off the secondaries
which this patch is trying to achieve, but in more sane way so that no
data/state is lost/corrupted as I stated earlier.
> >
> > CPUs might be running with IRQs disabled for an arbitrarily long time,
>
> In an embedded linux system we control everything running.
>
By which I assume you have patches to do all sorts of things to make this
work and this patch standalone is of no use :)
I don't like this as it's not scalable to big systems as this is in the
same code path as system off/reset.
--
Regards,
Sudeep
next prev parent reply other threads:[~2019-01-23 17:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 5:46 [PATCH RFC 1/1] arm64: Use PSCI calls for CPU stop when hotplug is supported Pramod Kumar
2019-01-18 11:32 ` Sudeep Holla
[not found] ` <CAJ+tv6+6yqT1xkmkY3x6SNQ83K+J6zqKZr7PV5A_ffvyEzceqg@mail.gmail.com>
[not found] ` <CAJ+tv6KqynSf5t_VwLqpdM4BF+wLWcJ0wPTD4nWqL4ej1Yih4g@mail.gmail.com>
2019-01-21 6:06 ` Pramod Kumar
2019-01-23 16:48 ` Mark Rutland
2019-01-23 17:05 ` Scott Branden
2019-01-23 17:21 ` Sudeep Holla [this message]
2019-01-23 17:33 ` Scott Branden
2019-01-23 17:33 ` Mark Rutland
2019-01-23 17:46 ` Scott Branden
2019-01-23 18:07 ` Sudeep Holla
2019-01-25 7:03 ` Pramod Kumar
2019-01-25 15:56 ` Robin Murphy
2019-01-25 16:52 ` Sudeep Holla
2019-01-21 11:22 ` Sudeep Holla
2019-01-23 4:51 ` Pramod Kumar
2019-01-23 16:27 ` Sudeep Holla
2019-01-23 16:56 ` Mark Rutland
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=20190123172115.GA31694@e107155-lin \
--to=sudeep.holla@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=catalin.marinas@arm.com \
--cc=dave.martin@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=pramod.kumar@broadcom.com \
--cc=robh@kernel.org \
--cc=scott.branden@broadcom.com \
--cc=steve.capper@arm.com \
--cc=will.deacon@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).