Re: intel-agp PM experiences (was: 2.6.20-rc5: usb mouse breaks suspend to ram)

[Andreas Mohr <andi@rhlx01.fht-esslingen.de>]

Hi,

On Tue, Jan 30, 2007 at 08:36:32PM +0800, Wang Zhenyu wrote:
> On 2007.01.29 22:30:53 +0000, 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_APSIZE    0xb4
> #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