public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Linux PCI <linux-pci@vger.kernel.org>, Greg KH <gregkh@suse.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	pm list <linux-pm@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Matthew Garrett <mjg@redhat.com>
Subject: Re: [RFD] Asynchronous suspend/resume of PCI devices
Date: Tue, 22 Dec 2009 20:10:27 +0100	[thread overview]
Message-ID: <200912222010.28046.rjw@sisk.pl> (raw)
In-Reply-To: <20091222083001.10ce3948@jbarnes-x200>

On Tuesday 22 December 2009, Jesse Barnes wrote:
> On Sun, 20 Dec 2009 00:31:38 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > Hi,
> > 
> > I'd like to know your opinions about the viability of suspending and
> > resuming PCI devices asynchronously during system-wide PM transitions
> > (suspend to RAM and hibernation).
> > 
> > Linus says it's generally dangerous, because some PCI devices may
> > indirectly depend on the others, but if that's the case, I wonder if
> > we really can power manage PCI devices at run time.
> > 
> > It follows from my experiments that suspending and resuming PCI
> > devices asynchronously doesn't lead to problems as long as we make
> > sure that every PCI device is suspended before and resumed after its
> > ACPI "shadow" partner. However, I'm not sure if this is generally
> > correct.
> > 
> > What are possible problems we can run into while doing asynchronous
> > suspend and resume of PCI devices?  What do we need to do in general
> > to avoid that problems?
> > 
> > Please tell me what you think.
> 
> AFAIK it should be *mostly* safe.  Individual drivers are generally
> independent of one another.  However, there are quite a few
> multifunction devices (some exposed as such, some exposed as multiple
> busses and devices on the same device) where interdependencies are
> possible.  In some cases, we just won't see power savings until the
> whole chip is powered down (which may require extra code in the form of
> a "bus" driver of some sort), in other cases a driver may inadvertently
> power down a piece of a device needed by another driver.
> 
> That said, the best practice for those sorts of devices is to create a
> bus driver anyway, that binds to the master device and has a few
> child drivers, so maybe even that case won't be much trouble...

My current idea is to mark all PCI devices as async and introduce mutexes
for the devices that shouldn't be suspended/resumed at the same time.
Perhaps we can start with just one mutex to be acquired in ->suspend() and
->resume() by the drivers that have to be serialized with respect to one
another.

What do you think?

Rafael

      reply	other threads:[~2009-12-22 19:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-19 23:31 [RFD] Asynchronous suspend/resume of PCI devices Rafael J. Wysocki
2009-12-22 16:30 ` Jesse Barnes
2009-12-22 19:10   ` Rafael J. Wysocki [this message]

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=200912222010.28046.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=gregkh@suse.de \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mjg@redhat.com \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@linux-foundation.org \
    /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