lkml.org 
[lkml]   [2018]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] PCI / ACPI / PM: Resume bridges w/o drivers on suspend-to-RAM
On Tue, Jun 26, 2018 at 10:32 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, Jun 26, 2018 at 07:19:29PM +0200, Rafael J. Wysocki wrote:
>> On Tue, Jun 26, 2018 at 7:14 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > On Tue, Jun 26, 2018 at 04:22:00PM +0200, Rafael J. Wysocki wrote:
>> >> On Tue, Jun 26, 2018 at 4:01 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> >> > On Tue, Jun 26, 2018 at 12:06:01PM +0200, Rafael J. Wysocki wrote:
>> >> >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>> >
>> >> >> + /*
>> >> >> + * In some cases (eg. Samsung 305V4A) leaving a bridge in suspend
>> >> >> + * confuses the platform firmware, so avoid doing that, unless the
>> >> >> + * bridge has a driver that should take care of PM handling.
>> >> >> + */
>> >> >> + if (pci_is_bridge(dev) && !dev->driver)
>> >> >> + return true;
>> >> >
>> >> > It sounds like the question of whether leaving a bridge in D3 confuses
>> >> > the firmware has a platform-specific answer.
>> >>
>> >> Well, it may confuse the platform firmware in general.
>> >>
>> >> > How does the driver PM handling know how to do the right thing?
>> >>
>> >> For endpoints this is not an issue as they always have been expected
>> >> to be in D3 before passing control to the platform firmware on S3
>> >> entry, but we've never done that for bridges by default, except for
>> >> PCIe ports with PM enabled (in which case the driver decides whether
>> >> or not to enable it).
>> >
>> > If there's any spec reference for the expected power states of devices
>> > when entering S3, that would be useful here. I can't tell if there's
>> > any guidance for this or if it's just figured out experimentally.
>>
>> It is not direct, but Section 16.1.6 of ACPI 6.2 says this in step 4
>> of the system suspend outline:
>>
>> OSPM places all device drivers into their respective Dx state. If the
>> device is enabled for wake,
>> it enters the Dx state associated with the wake capability. If the
>> device is not enabled to wake
>> the system, it enters the D3 state.
>
> Thanks, that's a very useful citation!

You're welcome! :-)

I actually need to withdraw the $subject patch as it doesn't help (I
misread the reporters response) and the one that does work is a bit
too intrusive IMO, so I'll investigate this a bit more.

\
 
 \ /
  Last update: 2018-06-27 09:17    [W:0.042 / U:2.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site