From: Zhenyu Wang <zhenyuw@linux.intel.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>, Zhenyu Wang <zhenyuw@linux.intel.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Dave Airlie <airlied@redhat.com>,
Linux-pm mailing list <linux-pm@lists.linux-foundation.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Suspend problems in 2.6.31-rc6
Date: Wed, 19 Aug 2009 10:01:56 +0800 [thread overview]
Message-ID: <20090819020156.GA22638@zhen-devel.sh.intel.com> (raw)
In-Reply-To: <200908190122.17015.rjw@sisk.pl>
[-- Attachment #1.1: Type: text/plain, Size: 2819 bytes --]
On 2009.08.19 01:22:16 +0200, Rafael J. Wysocki wrote:
> >
> > I have narrowed this down. The problem occurs in agp_intel_resume()
> > in drivers/char/agp/intel-agp.c. Here's the beginning of the routine:
> >
> >
> > static int agp_intel_resume(struct pci_dev *pdev)
> > {
> > struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
> > int ret_val;
> >
> > pci_restore_state(pdev);
> >
> > /* We should restore our graphics device's config space,
> > * as host bridge (00:00) resumes before graphics device (02:00),
> > * then our access to its pci space can work right.
> > */
> > if (intel_private.pcidev)
> > pci_restore_state(intel_private.pcidev);
> >
> >
> > As the comment says, pdev is 0000:00:00.0 and intel_private.pcidev is
> > 0000:00:02.0. So this is the resume routine for 00:00.0, and it calls
> > pci_restore_state() for 00:02.0 before that device has been resumed.
> >
> > Note that there is no corresponding agp_intel_suspend() function.
> >
> > Stuff stops appearing on the screen in the middle of the second
> > pci_restore_state() call. That is, I see messages about "restoring
> > config space at offset..." for each of the two devices, but a
> > debugging message added at the end of pci_restore_state() doesn't
> > appear for the second call.
> >
> > (Should these config space changes occur at all, given that I'm
> > testing with "echo devices >pm_test"?)
> >
> > It's also worth noting that a debugging message added to the start of
> > pci_restore_state() shows that for both of these calls,
> > pdev->state_saved is false. It's not clear whether that matters,
> > though, because the suspend and resume routines in the PCI core do so
> > many calls to pci_save_state() and pci_restore_state() on their own.
> >
> > Commenting out the second call to pci_restore_state() apparently fixes
> > the problem. I have no idea whether it's the right thing to do,
> > though.
>
> It is. The PCI core have restored the PCI config already anyway at the early
> resume stage.
>
> I think the first pci_restore_state() could be dropped from there as well.
>
Rafael, as I added this restore long time ago, pci core has changed in some way?
We had problem when reconfigure agp GTT space in resume, as we must be sure
gfx device's config space has been restored properly, and as 02:00 gfx device
restored later than host bridge 00:00 device, that came to my origin patch to
restore it earlier. So do you mean this order issue is gone now?
We also do proper pci save/restore in drm/i915 driver, which is the real pci
driver for our gfx device. I'm not sure if there could any conflict between them...
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2009-08-19 2:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-17 15:11 Suspend problems in 2.6.31-rc6 Alan Stern
2009-08-17 18:28 ` Rafael J. Wysocki
2009-08-17 20:53 ` Alan Stern
2009-08-17 21:14 ` Greg KH
2009-08-17 21:15 ` Greg KH
2009-08-17 21:31 ` Jiri Slaby
2009-08-17 21:33 ` Jiri Slaby
2009-08-17 21:21 ` Rafael J. Wysocki
2009-08-17 21:50 ` Alan Stern
2009-08-18 16:07 ` Alan Stern
2009-08-18 23:22 ` Rafael J. Wysocki
2009-08-19 2:01 ` Zhenyu Wang [this message]
2009-08-19 14:42 ` Alan Stern
2009-08-20 1:05 ` Zhenyu Wang
2009-08-20 14:03 ` Alan Stern
2009-08-21 1:17 ` Zhenyu Wang
2009-08-20 15:34 ` Rafael J. Wysocki
2009-08-19 14:26 ` Alan Stern
2009-08-19 21:22 ` Rafael J. Wysocki
2009-08-20 15:17 ` Alan Stern
2009-08-20 16:17 ` Rafael J. Wysocki
2009-08-21 1:21 ` Zhenyu Wang
2009-08-21 3:13 ` Zhenyu Wang
2009-08-21 14:32 ` Alan Stern
2009-08-21 17:01 ` Rafael J. Wysocki
2009-08-24 2:34 ` Zhenyu Wang
2009-08-24 18:55 ` Rafael J. Wysocki
2009-08-25 0:59 ` Alan Stern
2009-08-27 14:51 ` Alan Stern
2009-08-27 16:18 ` Jesse Barnes
2009-08-24 1:30 ` Zhenyu Wang
2009-08-20 15:41 ` Rafael J. Wysocki
2009-08-20 16:05 ` Jesse Barnes
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=20090819020156.GA22638@zhen-devel.sh.intel.com \
--to=zhenyuw@linux.intel.com \
--cc=airlied@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=greg@kroah.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-pm@lists.linux-foundation.org \
--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