Re: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
Hi, On Tue, Jan 30, 2007 at 08:36:32PM +0800, Wang Zhenyu wrote: > ok, just see the AGP tables bits definition for intel_i815_driver, > /* Intel registers */ > #define INTEL_APSIZE0xb4 > #define INTEL_ATTBASE 0xb8 > #define INTEL_AGPCTRL 0xb0 > ... > And this could explain why your patch can make X come back to live on > i815, as default suspend saves 64bytes. We need suspend func to handle > this, but for now mainline intel integrated gfx, this's not needed. > Would you send out a cleanup patch later? OK, I just spent an entire evening on this tiresome procedure of trying, not quite successful, machine killed, rebooting, adapting, trying, hang, ... My conclusions: - never forget about [EMAIL PROTECTED]@#$% PCI posting! (hours wasted due to register values NOT restored after resume...) - those 3 registers above are not sufficient, since AGP status is completely broken, not even such basic things as 4x mode or sideband addressing bits get restored, so these need proper care as well. - backing up about 10 registers properly (all those that have different state after resume) makes it work fine without going over the whole extended PCI register range needlessly I'm going to spend more time on this, so...: Questions (in order of fine-grainedness): - is intel-agp the right place to reinit such things, or should something be changed in a more global way? Would other drivers be responsible for that instead? x.org? - should we have infrastructure available which records AGP state in all its nicety in various variables, with chipset-specific access functions (AGP mode, memory setup, ...)? That way we'd be able to implement one chipset-agnostic suspend/resume, which could be a heavenly thing considering the amount of different chipsets... (IOW, we should perhaps focus on maintaining an abstract device state tracking, not blindly push those I/O instructions out to the device and forget about actual device state) - should we just implement a plain'n stupid I/O register array for each chipset which denotes the registers that need resume maintenance and also records their pre-suspend values? (DUMB) - or even (shudder) simply always recover the entire PCI I/O space no matter which chipset it is? I really want to get this improved, so any ideas how it should best be updated to get a nice clean generic suspend/resume functionality for all chipsets? (at least Intel, or even better for all types) And it would be very useful to add a generic function for those repeated agp_bridge->dev->device == PCI_DEVICE_... checks which takes a PCI ID array input... (inline or real function, doesn't matter). Thanks! Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
Hi,
On Tue, Jan 30, 2007 at 08:36:32PM +0800, Wang Zhenyu wrote:
> On 2007.01.29 22:30:53 +, Andreas Mohr wrote:
> Sorry I don't have 815G board nowadays, this board seems has two
> pci devs, one for AGP bridge, another for integrated gfx card if no add-in
> card.
> So have you tried both cases?
Does this mean that it has builtin i815 video, too?
How would I be able to "try both cases", then?
I somehow would have to configure it to boot with builtin graphics and
thus show 0x1130 and 0x1132 PCI IDs, right? Help, I'm confused...
> ok, just see the AGP tables bits definition for intel_i815_driver,
> /* Intel registers */
> #define INTEL_APSIZE0xb4
> #define INTEL_ATTBASE 0xb8
> #define INTEL_AGPCTRL 0xb0
> ...
> And this could explain why your patch can make X come back to live on
> i815, as default suspend saves 64bytes. We need suspend func to handle
> this, but for now mainline intel integrated gfx, this's not needed.
> Would you send out a cleanup patch later?
OK, I'll keep working on this (trying a backup specific to those registers
above).
I suspect that your patch might actually additionally help in my case, too,
but of course I first need my enhanced PCI space backup to prevent it
from locking up.
IOW, your patch might then enable me to skip vbetool hackery entirely
since graphics mode appearance would already be correct.
I'll verify this.
How to transform all this newly-gained knowledge into a *clean* generic
intel-agp driver layer is a different question, though.
Specifically, I'm unsure about all those xxx_configure() calls in the resume
function, this sounds rather unclean to me...
("let's just yank it all back into a clean default state, that will somehow
magically make everything work again after resume")
Andreas Mohr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
On 2007.01.29 22:30:53 +, Andreas Mohr wrote: > > I've post a patch which trys to resolve pci config restore issue, see > > http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G > > machine, > > that my X can come back to live after s3, but I wasn't aware of the issues > > Andreas > > has noted. It'll be good if more people could try this out. > > [sorry, somewhat late, had complete and utter heating failure at home] > > I employed a variant of your patch (added a static i815_dev > to support my i815 chipset). It didn't help, X hung on resume. > PCI IDs of i815 are 0x1130, 0x1131, 0x1132. > I'm having 0x1130 and 0x1131, IOW an i815 system in > "external AGP graphics" mode: > 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and > Memory Controller Hub (rev 02) > 00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 02) > > so I need to query 0x1131 instead of PCI_DEVICE_ID_INTEL_82815_CGC > (0x1132) for resume of the proper device, right?? > Or am I supposed to restore the PCI space of my *non-builtin* > 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M4 AGP > card instead? Sorry I don't have 815G board nowadays, this board seems has two pci devs, one for AGP bridge, another for integrated gfx card if no add-in card. So have you tried both cases? > > The diff below (against 2.6.19-ck2 or in fact plain 2.6.19) > shows what I changed from my (working!) version to what I think I > had to do to be compatible with your intentions. OK, not quite, > I now merely disabled the suspend/restore of the full PCI space, > several other parts remained the same. > > IOW, suspending/restoring the *full* PCI space of my Host Bridge > helped, whereas restoring the standard PCI space of my Host Bridge > plus restoring the PCI space of the AGP bridge as you suggested > did NOT. > > Can we conclude from that that I'm having rather different issues > than you? > > I think this means that we are required/supposed to backup > the entire PCI space of host bridges, right? How to actually implement > this cleanly? Oh, and of course my patch manages to fix the X11 > lockup only, actual video is still garbled and requires > vbetool magic to get it fixed, too... ok, just see the AGP tables bits definition for intel_i815_driver, /* Intel registers */ #define INTEL_APSIZE0xb4 #define INTEL_ATTBASE 0xb8 #define INTEL_AGPCTRL 0xb0 ... And this could explain why your patch can make X come back to live on i815, as default suspend saves 64bytes. We need suspend func to handle this, but for now mainline intel integrated gfx, this's not needed. Would you send out a cleanup patch later? Thanks. -zhen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
Hi,
On Mon, Jan 22, 2007 at 12:45:19PM +0800, Wang Zhenyu wrote:
> I've post a patch which trys to resolve pci config restore issue, see
> http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine,
> that my X can come back to live after s3, but I wasn't aware of the issues
> Andreas
> has noted. It'll be good if more people could try this out.
[sorry, somewhat late, had complete and utter heating failure at home]
I employed a variant of your patch (added a static i815_dev
to support my i815 chipset). It didn't help, X hung on resume.
PCI IDs of i815 are 0x1130, 0x1131, 0x1132.
I'm having 0x1130 and 0x1131, IOW an i815 system in
"external AGP graphics" mode:
00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory
Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82815 815 Chipset AGP Bridge (rev 02)
so I need to query 0x1131 instead of PCI_DEVICE_ID_INTEL_82815_CGC
(0x1132) for resume of the proper device, right??
Or am I supposed to restore the PCI space of my *non-builtin*
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M4 AGP
card instead?
The diff below (against 2.6.19-ck2 or in fact plain 2.6.19)
shows what I changed from my (working!) version to what I think I
had to do to be compatible with your intentions. OK, not quite,
I now merely disabled the suspend/restore of the full PCI space,
several other parts remained the same.
IOW, suspending/restoring the *full* PCI space of my Host Bridge
helped, whereas restoring the standard PCI space of my Host Bridge
plus restoring the PCI space of the AGP bridge as you suggested
did NOT.
Can we conclude from that that I'm having rather different issues
than you?
I think this means that we are required/supposed to backup
the entire PCI space of host bridges, right? How to actually implement
this cleanly? Oh, and of course my patch manages to fix the X11
lockup only, actual video is still garbled and requires
vbetool magic to get it fixed, too...
Thanks,
Andreas Mohr
--- intel-agp.c 2007-02-07 21:50:49.0 +0100
+++ intel-agp.c.2619ck2.patched 2007-02-07 21:50:04.0 +0100
@@ -1666,6 +1666,9 @@
return 1;
}
+static struct pci_dev *i815_dev;
+
+
static int __devinit agp_intel_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -1719,7 +1722,10 @@
if (find_i810(PCI_DEVICE_ID_INTEL_82815_CGC))
bridge->driver = &intel_810_driver;
else
+ {
+ i815_dev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x1131,
NULL);
bridge->driver = &intel_815_driver;
+ }
name = "i815";
break;
case PCI_DEVICE_ID_INTEL_82820_HB:
@@ -1921,12 +1927,62 @@
}
#ifdef CONFIG_PM
+
+#if 0
+static u32 pci_cfg_space[64];
+
+static int agp_intel_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ int i;
+ for (i = 0; i <= 63; i++)
+ pci_read_config_dword(pdev, i * 4, &pci_cfg_space[i]);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+
+ printk(KERN_INFO "agp_intel_suspend\n");
+
+ return 0;
+}
+#endif
+
static int agp_intel_resume(struct pci_dev *pdev)
{
struct agp_bridge_data *bridge = pci_get_drvdata(pdev);
+ int i;
+ int val;
+ pci_set_power_state (pdev, PCI_D0);
pci_restore_state(pdev);
+ if (i815_dev)
+ pci_restore_state(i815_dev);
+
+#if 0
+ for (i = 15; i >= 0; i--) {
+ pci_read_config_dword(pdev, i * 4, &val);
+ if (val != pci_cfg_space[i]) {
+ printk(KERN_DEBUG "AGP: Writing back config space on "
+ "device %s at offset %x (was %x, writing %x)\n",
+ pci_name(pdev), i,
+ val, pci_cfg_space[i]);
+ pci_write_config_dword(pdev, i * 4,
+ pci_cfg_space[i]);
+ }
+ }
+ for (i = 63; i >= 16; i--) {
+ pci_read_config_dword(pdev, i * 4, &val);
+ if (val != pci_cfg_space[i]) {
+ printk(KERN_DEBUG "AGP: Writing back config space on "
+ "device %s at offset %x (was %x, writing %x)\n",
+ pci_name(pdev), i,
+ val, pci_cfg_space[i]);
+ pci_write_config_dword(pdev, i * 4,
+ pci_cfg_space[i]);
+ }
+ }
+#endif
+
+ printk(KERN_INFO "agp bridge is %04x\n", agp_bridge->dev->device);
+
if (bridge->driver == &intel_generic_driver)
intel_configure();
else if (bridge->driver == &intel_850_driver)
@@ -1939,6 +1995,8 @@
intel_i915_configure();
else if (bridge->driver == &intel_830_driver)
Re: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
On 2007.01.18 23:16:51 +, Pavel Machek wrote: > Hi! > > > > > Especially the PCI video_state trick finally got me a working resume on > > > > 2.6.19-ck2 r128 Rage Mobility M4 AGP *WITH*(!) fully enabled and working > > > > (and keeping working!) DRI (3D). > > > > > > Can we get whitelist entry for suspend.sf.net? s2ram from there can do > > > all the tricks you described, one letter per trick :-). We even got > > > PCI saving lately. > > > > Whitelist? Let me blacklist it all the way to Timbuktu instead! > > > I've been doing more testing, and X never managed to come back to working > > state without some of my couple intel-agp changes: > > - a proper suspend method, doing a proper pci_save_state() > > or improved equivalent > > - a missing resume check for my i815 chipset > > - global cache flush in _configure > > - restoring AGP bridge PCI config space > > Can you post a patch? I've post a patch which trys to resolve pci config restore issue, see http://lkml.org/lkml/2007/1/16/297. It resolves s3 issue with my 965G machine, that my X can come back to live after s3, but I wasn't aware of the issues Andreas has noted. It'll be good if more people could try this out. > Whitelist entry would still be welcome. > > > All in all intel-agp code semi-shattered my universe. > > I didn't expect to find all these issues in rather important core code > ... > > Given the myriads of resume issues we experience in general, > > it may be wise to do something as simple as a code review of *all* > > Any volunteers? > Pavel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
Hi! > > > Especially the PCI video_state trick finally got me a working resume on > > > 2.6.19-ck2 r128 Rage Mobility M4 AGP *WITH*(!) fully enabled and working > > > (and keeping working!) DRI (3D). > > > > Can we get whitelist entry for suspend.sf.net? s2ram from there can do > > all the tricks you described, one letter per trick :-). We even got > > PCI saving lately. > > Whitelist? Let me blacklist it all the way to Timbuktu instead! > I've been doing more testing, and X never managed to come back to working > state without some of my couple intel-agp changes: > - a proper suspend method, doing a proper pci_save_state() > or improved equivalent > - a missing resume check for my i815 chipset > - global cache flush in _configure > - restoring AGP bridge PCI config space Can you post a patch? Whitelist entry would still be welcome. > All in all intel-agp code semi-shattered my universe. > I didn't expect to find all these issues in rather important core code ... > Given the myriads of resume issues we experience in general, > it may be wise to do something as simple as a code review of *all* Any volunteers? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
Hi. On Thu, 2007-01-18 at 12:51 +0100, Andreas Mohr wrote: [...] > All in all intel-agp code semi-shattered my universe. > I didn't expect to find all these issues in rather important core code > for a wide-spread chipset vendor - it doesn't even log an > "unhandled chipset: resuming may fail, please report!" message > in the resume handler in case of a missing chipset check > (although it may be debatable whether people are able to see this message > at all). Now that's a really good idea, and simple to do too. For some time I've been thinking of a sysfs entry that could list for you all the drivers in the tree. Perhaps that, combined with your idea (as well as implementing your idea separately) would be helpful? > However since the new AGP code was a heroic refactoring effort > it's understandable that there are some remaining issues. > > Given the myriads of resume issues we experience in general, > it may be wise to do something as simple as a code review of *all* > relevant code no matter how "complete" we expect each driver to be... > (one could e.g. start with reviewing all other AGP chipset drivers). Yes, we really need to get around to checking what drivers do suspend and resume properly for both S3 and S4, and prodding the authors where necessary. Regards, Nigel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)
Hi, On Wed, Jan 17, 2007 at 01:57:55AM +0100, Pavel Machek wrote: > > Especially the PCI video_state trick finally got me a working resume on > > 2.6.19-ck2 r128 Rage Mobility M4 AGP *WITH*(!) fully enabled and working > > (and keeping working!) DRI (3D). > > Can we get whitelist entry for suspend.sf.net? s2ram from there can do > all the tricks you described, one letter per trick :-). We even got > PCI saving lately. Whitelist? Let me blacklist it all the way to Timbuktu instead! I've been doing more testing, and X never managed to come back to working state without some of my couple intel-agp changes: - a proper suspend method, doing a proper pci_save_state() or improved equivalent - a missing resume check for my i815 chipset - global cache flush in _configure - restoring AGP bridge PCI config space The remaining suspects (the other hacks alone didn't recover it) are global cache flush and restoring of the *entire* AGP bridge PCI config space (no, a 64-bytes-only pci_restore_state() alone doesn't help, and it didn't help either that intel-agp doesn't do pci_save_state() anywhere - unless that's now done by default by PCI layer). I'll do more testing today to isolate which change exactly fixed it. All in all intel-agp code semi-shattered my universe. I didn't expect to find all these issues in rather important core code for a wide-spread chipset vendor - it doesn't even log an "unhandled chipset: resuming may fail, please report!" message in the resume handler in case of a missing chipset check (although it may be debatable whether people are able to see this message at all). However since the new AGP code was a heroic refactoring effort it's understandable that there are some remaining issues. Given the myriads of resume issues we experience in general, it may be wise to do something as simple as a code review of *all* relevant code no matter how "complete" we expect each driver to be... (one could e.g. start with reviewing all other AGP chipset drivers). Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
