[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dd557897-f2e0-4347-ae67-27cd45920159@oss.qualcomm.com>
Date: Fri, 20 Dec 2024 16:15:21 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>, Christoph Hellwig <hch@....de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
"Rafael J. Wysocki"
<rjw@...ysocki.net>,
Bjorn Helgaas <helgaas@...nel.org>, kbusch@...nel.org, axboe@...nel.dk,
sagi@...mberg.me, linux-nvme@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
andersson@...nel.org, konradybcio@...nel.org,
Len Brown
<len.brown@...el.com>, linux-pm@...r.kernel.org
Subject: Re: [PATCH] nvme-pci: Shutdown the device if D3Cold is allowed by the
user
On 16.12.2024 5:42 PM, Rafael J. Wysocki wrote:
> On Mon, Dec 16, 2024 at 5:23 PM Christoph Hellwig <hch@....de> wrote:
>>
>> On Sat, Dec 14, 2024 at 12:00:23PM +0530, Manivannan Sadhasivam wrote:
>>> We need a PM core API that tells the device drivers when it is safe to powerdown
>>> the devices. The usecase here is with PCIe based NVMe devices but the problem is
>>> applicable to other devices as well.
>>
>> Maybe I'm misunderstanding things, but I think the important part is
>> to indicate when a suspend actually MUST put the device into D3. Because
>> doing that should always be safe, but not always optimal.
>
> I'm not aware of any cases when a device must be put into D3cold
> (which I think is what you mean) during system-wide suspend.
>
> Suspend-to-idle on x86 doesn't require this, at least not for
> correctness. I don't think any platforms using DT require it either.
That would be correct.
The Qualcomm platform (or class of platforms) we're looking at with this
specific issue requires PCIe (implying NVMe) shutdown for S2RAM.
The S2RAM entry mechanism is unfortunately misrepresented as an S2Idle
state by Linux as of today, and I'm trying really hard to convince some
folks to let me describe it correctly, with little success so far..
That is the real underlying issue and once/if it's solved, this patch
will not be necessary.
> In theory, ACPI S3 or hibernation may request that, but I've never
> seen it happen in practice.
>
> Suspend-to-idle on x86 may want devices to end up in specific power
> states in order to be able to switch the entire platform into a deep
> energy-saving mode, but that's never been D3cold so far.
In our case the plug is only pulled in S2RAM, otherwise the best we can
do is just turn off the devices individually to decrease the overall
power draw
(simplifying some small edge cases here, but that's mostly the story)
Konrad
Powered by blists - more mailing lists