All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Linux PCI <linux-pci@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Andreas Noever <andreas.noever@gmail.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH v2 10/13] PCI: Avoid going from D3cold to D3hot for system sleep
Date: Thu, 4 Aug 2016 01:50:39 +0200	[thread overview]
Message-ID: <CAJZ5v0jxQHM=uuvFrpPw0vLbVjF0EQsm=XEZNdtQeYsO0ZobtQ@mail.gmail.com> (raw)
In-Reply-To: <20160803122848.GA4415@wunner.de>

On Wed, Aug 3, 2016 at 2:28 PM, Lukas Wunner <lukas@wunner.de> wrote:
> On Mon, Jul 18, 2016 at 03:39:15PM +0200, Rafael J. Wysocki wrote:
>> On Saturday, June 18, 2016 12:14:07 AM Lukas Wunner wrote:
>> > On Fri, Jun 17, 2016 at 04:09:24PM -0500, Bjorn Helgaas wrote:
>> > > On Fri, May 13, 2016 at 01:15:31PM +0200, Lukas Wunner wrote:
>> > > > There are devices wich are not power-managed by the platform, yet can be
>> > > > runtime suspended to D3cold with some other mechanism.  When putting the
>> > > > system to sleep, we currently handle such devices improperly by trying
>> > > > to transition them from D3cold to D3hot (the default power state defined
>> > > > at the beginning of pci_target_state()).  Avoid that.
>> > > >
>> > > > An example for devices affected by this are Thunderbolt controllers
>> > > > built into Macs which can be put into D3cold with nonstandard ACPI
>> > > > methods.
>> > > >
>> > > > Signed-off-by: Lukas Wunner <lukas@wunner.de>
>> > >
>> > > This needs an ack from Rafael.
>> > >
>> > > > ---
>> > > >  drivers/pci/pci.c | 2 ++
>> > > >  1 file changed, 2 insertions(+)
>> > > >
>> > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> > > > index 791dfe7..6af9911 100644
>> > > > --- a/drivers/pci/pci.c
>> > > > +++ b/drivers/pci/pci.c
>> > > > @@ -1943,6 +1943,8 @@ static pci_power_t pci_target_state(struct pci_dev *dev)
>> > > >                               && !(dev->pme_support & (1 << target_state)))
>> > > >                                 target_state--;
>> > > >                 }
>> > > > +       } else if (dev->current_state == PCI_D3cold) {
>> > > > +               target_state = PCI_D3cold;
>> > > >         }
>> > >
>> > > This only covers the case of !device_may_wakeup().  So I guess
>> > > device_may_wakeup() is false for these Thunderbolt controllers.
>> > > Is there a reason you don't want to do this check for devices that
>> > > may wakeup?
>> >
>> > Fear of breaking things. It would mean that a device would be left in
>> > D3cold even though it may not be able to signal wakeup from that power
>> > state.
>>
>> Then it should not be put into D3_cold at run time too if it is wakeup-
>> capable.
>>
>> > That's a change of behaviour the consequences of which I cannot
>> > estimate. Intuitively, I would expect breakage from such a change.
>>
>> That would have been the case if the device had been capable of signaling
>> wakeup from D3_cold at run time, but not from system sleep.  However, that
>> can only happen when platform_pci_power_manageable() is true AFAICS.
>>
>> So I'd change the switch () under the platform_pci_power_manageable() check
>> to return "state" in the default case and then do
>>
>>       return dev->current_state < target_state ? target_state : dev->current_state;
>>
>> at the end of the function.
>
> That suggestion doesn't seem to be correct because there's another
> value besides PCI_D3cold which is also greater than PCI_D3hot,
> namely PCI_UNKNOWN. (If the device is in that state, e.g. after
> pci_device_remove() has been called, and the system goes to sleep,
> we'd leave the device as is and not put it into D3hot as we do now.)

Right, I obviously forgot about PCI_UNKNOWN.

> I will update this patch with Bjorn's suggestion to also leave the
> device in D3cold if it is wakeup-capable. The idea is to just change
> the default state in the first line of the function like this:
>
> -       pci_power_t target_state = PCI_D3hot;
> +       pci_power_t target_state =
> +               dev->current_state == PCI_D3cold ? PCI_D3cold : PCI_D3hot;

That should work (even though it is a little clumsy IMO).

Thanks,
Rafael

  reply	other threads:[~2016-08-03 23:50 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-13 11:15 [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs Lukas Wunner
2016-05-13 11:15 ` [PATCH v2 01/13] PCI: Recognize Thunderbolt devices Lukas Wunner
2016-05-13 11:15 ` [PATCH v2 11/13] PM / sleep: Allow opt-out from runtime resume after direct-complete Lukas Wunner
2016-07-18 13:18   ` Rafael J. Wysocki
2016-08-07  9:56     ` Lukas Wunner
2016-08-07 15:33       ` Alan Stern
2016-08-07 15:33         ` Alan Stern
2016-08-12 16:39         ` Lukas Wunner
2016-08-12 17:30           ` Alan Stern
2016-08-12 17:30             ` Alan Stern
2016-08-12 22:40             ` Rafael J. Wysocki
2016-05-13 11:15 ` [PATCH v2 03/13] PCI: Add Thunderbolt portdrv service type Lukas Wunner
2016-06-17 22:51   ` Bjorn Helgaas
2016-07-20  0:30     ` Rafael J. Wysocki
2016-07-20  6:59     ` Lukas Wunner
2016-05-13 11:15 ` [PATCH v2 09/13] PCI: Do not write to PM control register while in D3cold Lukas Wunner
2016-06-17 21:18   ` Bjorn Helgaas
2016-07-18 13:55   ` Rafael J. Wysocki
2016-05-13 11:15 ` [PATCH v2 13/13] thunderbolt: Support runtime pm on NHI Lukas Wunner
2016-05-13 11:15 ` [PATCH v2 04/13] PCI: Generalize portdrv pm iterator Lukas Wunner
2016-05-13 11:15 ` [PATCH v2 08/13] PCI: Allow runtime PM for Thunderbolt hotplug ports on Macs Lukas Wunner
2016-06-14  9:08   ` [PATCH v2 08/13 REBASED] " Lukas Wunner
2016-06-17 21:53   ` [PATCH v2 08/13] " Bjorn Helgaas
2016-05-13 11:15 ` [PATCH v2 10/13] PCI: Avoid going from D3cold to D3hot for system sleep Lukas Wunner
2016-06-17 21:09   ` Bjorn Helgaas
2016-06-17 22:14     ` Lukas Wunner
2016-07-18 13:39       ` Rafael J. Wysocki
2016-08-03 12:28         ` Lukas Wunner
2016-08-03 23:50           ` Rafael J. Wysocki [this message]
2016-08-04  0:45             ` Lukas Wunner
2016-08-04  1:07               ` Rafael J. Wysocki
2016-08-04  8:14                 ` Lukas Wunner
2016-08-04 15:30                   ` Rafael J. Wysocki
2016-08-07  9:03                     ` Lukas Wunner
2016-08-07 23:32                       ` Rafael J. Wysocki
2016-08-11 13:20                         ` Lukas Wunner
2016-08-12  0:50                           ` Rafael J. Wysocki
2016-08-12 16:16                             ` Lukas Wunner
2016-08-12 22:18                               ` Rafael J. Wysocki
2016-08-12 22:37                                 ` Rafael J. Wysocki
2016-08-14 10:27                                 ` Lukas Wunner
2016-08-15 23:05                                   ` Rafael J. Wysocki
2016-05-13 11:15 ` [PATCH v2 06/13] PCI: pciehp: Support runtime pm Lukas Wunner
2016-05-13 11:15 ` [PATCH v2 05/13] PCI: Use portdrv pm iterator on further callbacks Lukas Wunner
2016-05-13 11:15 ` [PATCH v2 02/13] PCI: Allow D3 for Thunderbolt ports Lukas Wunner
2016-05-13 11:15 ` [PATCH v2 12/13] thunderbolt: Support runtime pm on upstream bridge Lukas Wunner
2016-05-13 11:15 ` [PATCH v2 07/13] PCI: pciehp: Ignore interrupts during D3cold Lukas Wunner
2016-06-17 22:52   ` Bjorn Helgaas
2016-08-02 16:27     ` Lukas Wunner
2016-08-05  0:29       ` Rafael J. Wysocki
2016-05-21  9:48 ` [PATCH v2 00/13] Runtime PM for Thunderbolt on Macs Andreas Noever
2016-06-14 16:37   ` Bjorn Helgaas
2016-06-14 19:14     ` Andreas Noever
2016-06-14 20:22       ` Bjorn Helgaas
2016-06-15 18:40         ` Lukas Wunner
2016-06-16  1:55           ` Linus Torvalds
2016-07-07 17:39         ` Andreas Noever
2016-07-09  5:23           ` Greg KH
2016-07-12 21:46             ` Andreas Noever
2016-06-13 20:58 ` Bjorn Helgaas
2016-06-14  9:27   ` Lukas Wunner
2016-07-07 15:02 ` Lukas Wunner
2016-07-08  1:28   ` Rafael J. Wysocki
2016-07-20  7:23     ` Lukas Wunner
2016-07-20 12:48       ` Rafael J. Wysocki

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='CAJZ5v0jxQHM=uuvFrpPw0vLbVjF0EQsm=XEZNdtQeYsO0ZobtQ@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=andreas.noever@gmail.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.