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;
Subject: Re: [PATCH RFC 1/1] arm64: Use PSCI calls for CPU stop when hotplug
 is supported
To:     Mark Rutland <mark.rutland@arm.com>,
        Pramod Kumar <pramod.kumar@broadcom.com>
Cc:     Sudeep Holla <sudeep.holla@arm.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>,
        BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
References: <1547790380-6276-1-git-send-email-pramod.kumar@broadcom.com>
 <20190118113242.GA8928@e107155-lin>
 <CAJ+tv6+6yqT1xkmkY3x6SNQ83K+J6zqKZr7PV5A_ffvyEzceqg@mail.gmail.com>
 <CAJ+tv6KqynSf5t_VwLqpdM4BF+wLWcJ0wPTD4nWqL4ej1Yih4g@mail.gmail.com>
 <20190123164801.GA55887@lakrids.cambridge.arm.com>
From:   Scott Branden <scott.branden@broadcom.com>
Message-ID: <f1851a76-8078-b8e7-6a54-b038b47f9214@broadcom.com>
Date:   Wed, 23 Jan 2019 09:05:26 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20190123164801.GA55887@lakrids.cambridge.arm.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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).

>
>>      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.

>
> CPUs might be running with IRQs disabled for an arbitrarily long time,

In an embedded linux system we control everything running.

But good point - we'll need to ensure interrupts are not disabled for 
too long.

> 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.

Regards,

  Scott