From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jesse Barnes <jesse.barnes@intel.com>,
Andreas Schwab <schwab@suse.de>, Len Brown <lenb@kernel.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: PCI PM: Restore standard config registers of all devices early
Date: Mon, 2 Feb 2009 15:18:41 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0902021508340.3247@localhost.localdomain> (raw)
In-Reply-To: <200902022331.49131.rjw@sisk.pl>
On Mon, 2 Feb 2009, Rafael J. Wysocki wrote:
> >
> > b) disable_device_irq()'s: things are live, but device interrupts
> > are turned off by essentially looping over the irq_desc_ptr[]
> > table.
>
> Well, do we actually need to turn off all device interrupts?
>
> Shared interrupts are the source of the problem, so perhaps we can
> only disable interrupts of devices that use interrupt pins at this point
> (MSI/MSI-X need not be disabled, for example, and the timer interrupts most
> probably too)?
We could try that, yes.
> > d) disable CPU interrupts.
>
> At what point do we disable the other CPUs?
I left it out, because I don't much care or think it matters. So take your
pick. I'd suggest keeping the current setup, and literally just insert the
new point between "device_power_off()" and "sysdev_suspend()", with _zero_
other changes.
> Well, it means reworking the entire suspend sequence (again) or we will
> break assumptions made by some existing drivers (interrupts off during
> suspend_late and resume_early). And that affects all drivers, not only PCI.
No it doesn't.
No changes AT ALL to the suspend sequence. We do everything in the same
order: look at my patch. The only difference is that instead of doing that
"cli" we do the "for_each_irq(disable_irq)" instead (and do the 'cli' a
bit later).
ZERO effect on drivers. The calling convention is 100% the same as far as
the driver is concerned: ->suspend() is called with interrupts on and a
fully working machine, and ->suspend_late() called with interrupts off.
The only difference is the _mechanism_ of turning interrupts off. NOTHING
else.
> I first would like to understand what _exactly_ breaks on the iBook reported to
> have problems.
I bet it's code like the USB one:
int usb_hcd_pci_resume(struct pci_dev *dev)
{
#ifdef CONFIG_PPC_PMAC
/* Reenable ASIC clocks for USB */
if (machine_is(powermac)) {
struct device_node *of_node;
of_node = pci_device_to_OF_node(dev);
if (of_node)
pmac_call_feature(PMAC_FTR_USB_ENABLE,
of_node, 0, 1);
}
#endif
..
retval = pci_enable_device(dev);
and now pci_enable_device() calls pci_raw_set_power_state(), which does:
if (dev->current_state == state) {
/* we're already there */
return 0;
} else ..
which means that it doesn't actually _do_ anything, because it thinks that
'current_state' was already PCI_D0. But if the device was totally turned
off, that's wrong.
(background: pci_restore_standard_config() will have done
pci_raw_set_power_state(PCI_D0) with the device clocks off, which wouldn't
actualyl have _done_ anythign to the device, but then it does
dev->current_state = PCI_D0;
Maybe the simplest thing to do migth be to replace that with a
pci_update_current_state(dev, PCI_D0);
instead, to try to read back the state explicitly in
pci_restore_standard_config()).
Best test:
Ben, does this trivial patch make any difference for those powermacs?
Linus
---
drivers/pci/pci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 17bd932..97e1c38 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1419,7 +1419,7 @@ int pci_restore_standard_config(struct pci_dev *dev)
}
}
- dev->current_state = PCI_D0;
+ pci_update_current_state(dev, PCI_D0);
return 0;
}
next prev parent reply other threads:[~2009-02-02 23:19 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200901261904.n0QJ4Q9c016709@hera.kernel.org>
2009-02-02 9:54 ` Benjamin Herrenschmidt
2009-02-02 17:06 ` Linus Torvalds
2009-02-02 20:29 ` Benjamin Herrenschmidt
2009-02-02 20:41 ` Linus Torvalds
2009-02-02 21:00 ` Benjamin Herrenschmidt
2009-02-02 21:32 ` Rafael J. Wysocki
2009-02-02 20:33 ` Benjamin Herrenschmidt
2009-02-02 20:50 ` Linus Torvalds
2009-02-02 20:55 ` Linus Torvalds
2009-02-02 21:19 ` Benjamin Herrenschmidt
2009-02-02 21:39 ` Rafael J. Wysocki
2009-02-02 22:05 ` Linus Torvalds
2009-02-02 22:09 ` Linus Torvalds
2009-02-02 22:31 ` Rafael J. Wysocki
2009-02-02 23:18 ` Linus Torvalds [this message]
2009-02-02 23:45 ` Rafael J. Wysocki
2009-02-02 23:59 ` Linus Torvalds
2009-02-03 0:15 ` Rafael J. Wysocki
2009-02-03 0:28 ` Linus Torvalds
2009-02-03 1:12 ` Benjamin Herrenschmidt
2009-02-03 1:32 ` Linus Torvalds
2009-02-03 1:46 ` Benjamin Herrenschmidt
2009-02-03 3:30 ` Benjamin Herrenschmidt
2009-02-03 3:47 ` Linus Torvalds
2009-02-03 4:03 ` Benjamin Herrenschmidt
2009-02-03 6:07 ` Benjamin Herrenschmidt
2009-02-03 15:48 ` Linus Torvalds
2009-02-03 22:59 ` Benjamin Herrenschmidt
2009-02-03 23:23 ` Rafael J. Wysocki
2009-02-03 16:33 ` Jesse Barnes
2009-02-03 0:15 ` Linus Torvalds
2009-02-03 0:58 ` Benjamin Herrenschmidt
2009-02-03 3:51 ` Benjamin Herrenschmidt
2009-02-03 3:55 ` Benjamin Herrenschmidt
2009-02-03 4:09 ` Linus Torvalds
2009-02-03 4:21 ` Benjamin Herrenschmidt
2009-02-03 9:26 ` Rafael J. Wysocki
2009-02-03 17:04 ` Reworking suspend-resume sequence (was: Re: PCI PM: Restore standard config registers of all devices early) Rafael J. Wysocki
2009-02-03 17:59 ` Linus Torvalds
2009-02-03 18:31 ` Linus Torvalds
2009-02-03 18:41 ` Ingo Molnar
2009-02-03 18:32 ` Jesse Barnes
2009-02-03 18:46 ` Linus Torvalds
2009-02-03 19:03 ` Linus Torvalds
2009-02-03 19:13 ` Ingo Molnar
2009-02-03 19:38 ` Linus Torvalds
2009-02-03 19:53 ` Ingo Molnar
2009-02-03 20:04 ` Ingo Molnar
2009-02-03 20:18 ` Linus Torvalds
2009-02-03 20:57 ` Ingo Molnar
2009-02-03 21:04 ` Ingo Molnar
2009-02-03 21:12 ` Thomas Gleixner
2009-02-04 10:07 ` Russell King
2009-02-03 21:18 ` Linus Torvalds
2009-02-03 19:19 ` Linus Torvalds
2009-02-03 21:11 ` Benjamin Herrenschmidt
2009-02-03 21:53 ` Rafael J. Wysocki
2009-02-03 22:33 ` Benjamin Herrenschmidt
2009-02-03 22:44 ` Rafael J. Wysocki
2009-02-03 23:05 ` Benjamin Herrenschmidt
2009-02-03 23:18 ` Linus Torvalds
2009-02-04 0:27 ` Benjamin Herrenschmidt
2009-03-04 8:02 ` Pavel Machek
2009-03-04 23:25 ` Benjamin Herrenschmidt
2009-03-05 8:19 ` Pavel Machek
2009-03-05 19:09 ` Rafael J. Wysocki
2009-02-03 23:25 ` Rafael J. Wysocki
2009-02-04 0:46 ` Linus Torvalds
2009-02-03 21:02 ` Benjamin Herrenschmidt
2009-02-03 21:56 ` Rafael J. Wysocki
2009-02-03 17:53 ` PCI PM: Restore standard config registers of all devices early Linus Torvalds
2009-02-03 21:57 ` Rafael J. Wysocki
2009-02-02 22:48 ` Benjamin Herrenschmidt
2009-02-02 23:00 ` Rafael J. Wysocki
2009-02-03 0:23 ` Benjamin Herrenschmidt
2009-02-03 0:29 ` Rafael J. Wysocki
2009-02-03 0:44 ` Linus Torvalds
2009-02-03 1:32 ` Benjamin Herrenschmidt
2009-02-03 5:06 ` Ingo Molnar
2009-02-03 11:06 ` Peter Zijlstra
2009-02-03 12:09 ` Ingo Molnar
2009-02-02 23:49 ` Ingo Molnar
2009-02-03 22:09 ` Rafael J. Wysocki
2009-02-03 23:13 ` Linus Torvalds
2009-02-02 22:28 ` Benjamin Herrenschmidt
2009-02-02 21:07 ` Benjamin Herrenschmidt
2009-02-02 21:49 ` Rafael J. Wysocki
2009-02-02 22:15 ` Linus Torvalds
2009-02-02 22:33 ` Rafael J. Wysocki
2009-02-02 22:56 ` Rafael J. Wysocki
2009-02-03 0:11 ` Benjamin Herrenschmidt
2009-02-03 0:21 ` Linus Torvalds
2009-02-10 20:25 ` Pavel Machek
2009-02-02 22:57 ` Benjamin Herrenschmidt
2009-02-02 23:22 ` Rafael J. Wysocki
2009-02-03 1:03 ` Benjamin Herrenschmidt
2009-02-10 20:25 ` kmalloc during suspend, was " Pavel Machek
2009-02-02 17:20 ` 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=alpine.LFD.2.00.0902021508340.3247@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=jesse.barnes@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--cc=schwab@suse.de \
/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
Powered by JetHome