Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Lukas Wunner <lukas@wunner.de>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Bjorn Helgaas <bhelgaas@google.com>, Len Brown <lenb@kernel.org>,
	Keith Busch <keith.busch@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Alexandru Gagniuc <mr.nuke.me@gmail.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux PCI <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 3/3] PCI / ACPI: Handle sibling devices sharing power resources
Date: Mon, 10 Jun 2019 12:57:45 +0200
Message-ID: <3235484.ejFT65BlB1@kreacher> (raw)
In-Reply-To: <20190609185835.cqjbgzfwajbg4kks@wunner.de>

On Sunday, June 9, 2019 8:58:35 PM CEST Lukas Wunner wrote:
> On Thu, Jun 06, 2019 at 04:27:21PM +0200, Rafael J. Wysocki wrote:
> > On Thu, Jun 6, 2019 at 4:17 PM Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
> > > On Thu, Jun 06, 2019 at 04:08:11PM +0200, Rafael J. Wysocki wrote:
> > > > That isn't necessary IMO as long as the device are not accessed.  If
> > > > the kernel thinks that a given device is in D3cold and doesn't access
> > > > it, then it really doesn't matter too much what state the device is in
> > > > physically.  On the first access the device should be reinitialized
> > > > anyway.
> > >
> > > But if the device is configured to wake. For example when it detects a
> > > hotplug that state is gone when it goes to D0unitialized.
> > 
> > For this we'll need a pm_runtime_resume() of the dependent device on
> > the resource going "on".
> > 
> > That means we need a list of devices to resume when the resource goes
> > "on" after being taken "off".
> 
> An idea would be to model every ACPI power resource as a struct device
> and automatically set up a device link from the devices using that
> power resource (consumers).  After all dependent devices runtime suspend,
> the power resource "device" runtime suspends by turning itself off
> (and updating the PCI current_state of dependent devices to D3cold).
> When the power resource runtime resumes, it schedules a runtime resume
> of all dependent devices.

The sharing of power resources is covered already.  That's not the problem here.

The missing part is the runtime resume of dependent devices and I'm not even sure
if it needs to be done in general or for PCI devices only.  At least it doesn't need to be
done for devices that are not configured for wakeup, even on a PCI bus.

Thanks,
Rafael




      reply index

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 14:58 [PATCH 0/3] PCI: Power management improvements Mika Westerberg
2019-06-05 14:58 ` [PATCH 1/3] PCI: Add missing link delays required by the PCIe spec Mika Westerberg
2019-06-06  8:40   ` Rafael J. Wysocki
2019-06-06 11:24     ` Mika Westerberg
2019-06-05 14:58 ` [PATCH 2/3] PCI: Do not poll for PME if the device is in D3cold Mika Westerberg
2019-06-05 19:05   ` Lukas Wunner
2019-06-06 11:21     ` Mika Westerberg
2019-06-09 18:38   ` Lukas Wunner
2019-06-10 11:35   ` Rafael J. Wysocki
2019-06-05 14:58 ` [PATCH 3/3] PCI / ACPI: Handle sibling devices sharing power resources Mika Westerberg
2019-06-06  8:54   ` Rafael J. Wysocki
2019-06-06 11:26     ` Mika Westerberg
2019-06-06 13:44       ` Mika Westerberg
2019-06-06 14:08         ` Rafael J. Wysocki
2019-06-06 14:17           ` Mika Westerberg
2019-06-06 14:27             ` Rafael J. Wysocki
2019-06-06 14:36               ` Mika Westerberg
2019-06-12 22:38                 ` Rafael J. Wysocki
2019-06-13 12:52                   ` Mika Westerberg
2019-06-13 13:51                     ` Rafael J. Wysocki
2019-06-13 14:27                       ` Mika Westerberg
2019-06-09 18:58               ` Lukas Wunner
2019-06-10 10:57                 ` Rafael J. Wysocki [this message]

Reply instructions:

You may reply publically 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=3235484.ejFT65BlB1@kreacher \
    --to=rjw@rjwysocki.net \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=keith.busch@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mr.nuke.me@gmail.com \
    --cc=rafael@kernel.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

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org linux-acpi@archiver.kernel.org
	public-inbox-index linux-acpi


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/ public-inbox