From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org, e1000-devel@lists.sourceforge.net,
linux-pci@vger.kernel.org, Dave Airlie <airlied@redhat.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH 3/5] PCI: revert preparing for wakeup in runtime-suspend finalization
Date: Tue, 29 Jan 2013 11:04:57 +0400 [thread overview]
Message-ID: <51077499.90602@openvz.org> (raw)
In-Reply-To: <1821500.CRlxLgYU5r@vostro.rjw.lan>
Rafael J. Wysocki wrote:
> On Monday, January 28, 2013 04:17:42 PM Bjorn Helgaas wrote:
>> [+cc Rafael]
>>
>> On Fri, Jan 18, 2013 at 4:42 AM, Konstantin Khlebnikov
>> <khlebnikov@openvz.org> wrote:
>>> This patch effectively reverts commit 42eca2302146fed51335b95128e949ee6f54478f
>>> ("PCI: Don't touch card regs after runtime suspend D3")
>>>
>>> | This patch checks whether the pci state is saved and doesn't attempt to hit
>>> | any registers after that point if it is.
>>>
>>> This seems completely wrong. Yes, PCI configuration space has been saved by
>>> driver, but this doesn't means that all job is done and device has been
>>> suspended and ready for waking up in the future.
>>>
>>> For example driver e1000e for ethernet in my thinkpad x220 saves pci-state
>>> but device cannot wakeup after that, because it needs some ACPI callbacks
>>> which usually called from pci_finish_runtime_suspend().
>>>
>>> | Optimus (dual-gpu) laptops seem to have their own form of D3cold, but
>>> | unfortunately enter it on normal D3 transitions via the ACPI callback.
>>>
>>> Hardware which disappears from the bus unexpectedly is exception, so let's
>>> handle it as an exception. Its driver should set device state to D3cold and
>>> the rest code will handle it properly.
>>
>> Functions in D3cold don't have power, so it's completely expected that
>> they would disappear from the bus and not respond to config accesses.
>> Maybe Dave was referring to D3hot, where functions *should* respond to
>> config accesses. I dunno.
>>
>> Just to be clear, it sounds like 42eca230 caused a regression on your
>> e1000e device? If so, I guess we should revert it unless you and Dave
>> can figure out a better patch that fixes both your e1000e device and
>> the Optimus issue.
>
> Yes, if there's a regression, let's revert it, but I'd like the regression
> to be described clearly.
Yep, this is regression.
commit 42eca2302146fed51335b95128e949ee6f54478f ("PCI: Don't touch
card regs after runtime suspend D3") changes state convention during
runtime-suspend transaction too much. If PCI configuration space
has been saved by driver that does not means that all job is done
and device has been suspended and ready for waking up in the future.
e1000e saves pci-config space itself, but it requires operations which
pci_finish_runtime_suspend() does: preparing for wake (calling particular
platform pm-callbacks) and switching to proper sleep state.
>
> Thanks,
> Rafael
>
>
next prev parent reply other threads:[~2013-01-29 7:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-18 11:42 [PATCH 0/5] pci/e1000e: return runtime-pm back to work Konstantin Khlebnikov
2013-01-18 11:42 ` [PATCH 1/5] e1000e: fix resuming from runtime-suspend Konstantin Khlebnikov
2013-01-28 23:05 ` Bjorn Helgaas
2013-01-29 1:11 ` Rafael J. Wysocki
2013-01-29 6:32 ` Konstantin Khlebnikov
2013-01-29 12:00 ` Rafael J. Wysocki
2013-01-31 1:18 ` Rafael J. Wysocki
2013-01-31 7:05 ` Konstantin Khlebnikov
2013-01-31 1:23 ` Rafael J. Wysocki
2013-01-18 11:42 ` [PATCH 2/5] e1000e: fix pci device enable counter balance Konstantin Khlebnikov
2013-01-28 23:09 ` Bjorn Helgaas
2013-01-29 0:31 ` Bjorn Helgaas
2013-01-29 6:45 ` Konstantin Khlebnikov
2013-01-31 1:07 ` Rafael J. Wysocki
2013-01-18 11:42 ` [PATCH 3/5] PCI: revert preparing for wakeup in runtime-suspend finalization Konstantin Khlebnikov
2013-01-28 23:17 ` Bjorn Helgaas
2013-01-29 1:15 ` Rafael J. Wysocki
2013-01-29 7:04 ` Konstantin Khlebnikov [this message]
2013-01-29 11:55 ` Rafael J. Wysocki
2013-01-31 1:13 ` Rafael J. Wysocki
2013-02-02 12:12 ` Konstantin Khlebnikov
2013-02-02 20:58 ` Rafael J. Wysocki
2013-02-02 22:59 ` Rafael J. Wysocki
2013-02-03 10:14 ` Konstantin Khlebnikov
2013-02-03 12:57 ` Rafael J. Wysocki
2013-02-03 23:03 ` David Airlie
2013-02-03 23:19 ` David Airlie
2013-02-03 23:31 ` Rafael J. Wysocki
2013-01-18 11:42 ` [PATCH 4/5] PCI: don't touch enable_cnt in pci_device_shutdown() Konstantin Khlebnikov
2013-01-18 16:16 ` Don Dutile
2013-01-28 23:40 ` Bjorn Helgaas
2013-01-28 23:44 ` Bjorn Helgaas
2013-01-29 2:47 ` Khalid Aziz
2013-01-18 11:42 ` [PATCH 5/5] PCI: catch enable-counter underflows Konstantin Khlebnikov
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=51077499.90602@openvz.org \
--to=khlebnikov@openvz.org \
--cc=airlied@redhat.com \
--cc=bhelgaas@google.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rjw@sisk.pl \
/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;
as well as URLs for NNTP newsgroup(s).