intel driver suspend/resume failure
jbarnes at virtuousgeek.org
Mon Jun 11 08:24:10 PDT 2007
On Saturday, June 9, 2007 7:19:52 Greg KH wrote:
> On Sat, Jun 09, 2007 at 12:00:31PM -0500, James Bottomley wrote:
> > On Sat, 2007-06-09 at 16:45 +0100, Matthew Garrett wrote:
> > > On Sat, Jun 09, 2007 at 12:21:03AM +0200, Lukas Hejtmanek wrote:
> > > > this should be done by the kernel. what kernel version are you using?
> > >
> > > Linux only saves the first 64 bytes of PCI config space, and even then
> > > only if there's a PCI driver (so not drm) attached to the device.
> > For generic devices that's the best we can do ... a lot map registers
> > into configuration space above 64 (and registers can trigger actions as
> > well as just holding values). It might be possible for the kernel to
> > identify the legacy PCI VGA device and save all 256 of its config space
> > values, but I think even that would be pretty dangerous. As Jesse
> > showed, it seems to be the values at 0xe0-0xff that are needed to be
> > restored ... could the video driver not just save these on suspend and
> > restore them on resume. Or would a script like I already have be
> > better? I think debian already does something like this, so I could
> > probably persuade RH to do the same.
> The drm driver doesn't get called on suspend I think due to it not tying
> into the driver model properly :(
> So the kernel driver has no chance to actually do this properly, which
> is a real shame as that is what it should be doing...
> So, once that is fixed, then we might have a chance. Any ideas when
> David's video framework is going into the kernel? Or should we just
> kick the framebuffer driver off and just use drm instead?
I doubt it'll be ready for 2.6.23 since we'll probably want at least one or
two more drm drivers ported to the interface before pushing, and we'll also
want some more code running on top of the new userspace APIs before we're
comfortable with them (working on the intel ddx driver now), but ultimately
it's up to Dave.
That said, I think having the drm driver do full suspend/resume really is the
way to go. The drm modesetting driver for intel already does this, and it
seems to work ok on my laptop, but it obviously needs more testing and
probably some more state saved/restored (I don't think it'll deal with James'
problem atm for examle).
More information about the xorg