Re: [PATCH 3/5] PCI: revert preparing for wakeup in runtime-suspend finalization

[Rafael J. Wysocki]

On Tuesday, January 29, 2013 11:04:57 AM Konstantin Khlebnikov wrote:
> 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@xxxxxxxxxx>  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.

Well, I'd argue this is a bug in e1000e.  Why does it need to save the PCI
config space even though pci_pm_runtime_suspend() will do that anyway?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/