ACPI Sleep on Thinkpad R40, wakeup fails for X11/radeon

[Eric Kjeldergaard]

On 7/1/05, Tobias Roth <roth at iam.unibe.ch> wrote:
> On Thu, Jun 30, 2005 at 12:01:48PM -0400, Martin Cracauer wrote:
> > Any ideas how I could fix suspend/resume on this Thinkpad?
> > 
> > 
> > I have a Thinkpad R40 running 6.0-current.  It has a Radeon 7500 with
> > 32 MB.
> > 
> > When I suspend it with zzz (ACPI actice), the machine sleeps and wakes
> > up fine except the X11 server is unhappy.
> > 
> > The X11 server has some graphical corruption, never updates graphics
> > and does not take keyboard input (Control-Alt-F2 etc are also disabled
> > and just beep).
> 
> please make sure that you don't have dri in your x.org / xfree config

I guess this is a commonly known problem.  In fact last October Bruce
Simpson wrote:


Hello,

On Thu, Oct 07, 2004 at 11:46:19PM -0400, Jordan Sissel wrote:
> Absolutely, I'll help in any way I can. I'm currently content without
> drm, however I would like to see it fixed for those who can't stop
> playing crack attack (me!). I presently have zero knowlwedge about
> kernel modules or drm, but I'm willing to learn and help with
> whatever's going on with this.

What this boils down to is that we have some of the pieces to do it,
but not all of them.

Those who are interested in the technical specifics (written up herein so
as to benefit from mailing list archiving) may wish to read on.

Ok. Well some initial research suggests that many of the userland pieces are
already there in xorg 6.7.0, after some rummaging around in the source:
        http://www.spinics.net/lists/xf-xpert/msg04368.html

And most of what we need in the DRM driver is already there, and is
presumably called by the DRI framework in the X server:
        http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/drm/radeon_cp.c
        (Revision 1.7 in particular)

What I'm not clear about is if the device gets cleanly stopped before
FreeBSD actually suspends the machine (with acpi or without). I think
Eric may be able to help clarify some of this as he's more familiar
with the code in question than I (Cc:'d).

One of the things the original author of the Radeon resume patch raised
was that it needed the AGP GART driver to reinitialize correctly after
a resume, and submitted an additional patch for Linux. From the failure
modes of this combination I've observed in the past, it amounts to: 2D
graphics work fine after an ACPI resume, but 3D graphics no longer work.

The patch in question for Linux is here:
        http://cpbotha.net/files/dri_reinit/agpgart-i845-resume.patch
        http://www.ussg.iu.edu/hypermail/linux/kernel/0408.1/0089.html
        http://fxr.watson.org/fxr/source/drivers/char/agp/intel-agp.c?v=linux-2.6.1#L1427

The Radeon chip sits on the AGP bus, which hangs off a Host-to-AGP bridge
(a PCI function in the northbridge of the chipset). Whilst AGP looks like
PCI in terms of hardware configuration, it is quite different. The T41
uses the Odem chipset; this in turn uses the agp_intel.c driver. Observe:

agp0 at pci0:0:0:  class=0x060000 card=0x05291014 chip=0x33408086 rev=0x03 hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82855PM Odem Host-Hub Interface Bridge'
    class    = bridge
    subclass = HOST-PCI

pcib1 at pci0:1:0: class=0x060400 card=0x00000000 chip=0x33418086 rev=0x03 hdr=0x01
    vendor   = 'Intel Corporation'
    device   = '82855PM Odem AGP Bridge'
    class    = bridge
    subclass = PCI-PCI

The PCI bus code was recently updated to save the configuration space of
all PCI child devices on a suspend/resume. This however does *not*
apply to bridge devices, because they're totally different in their
operation to child devices.

We don't currently implement suspend/resume support for agp. I suspect
this is on several people's TODO or WISHLISTS judging from previous
list traffic.  I suspect this is where the problem lies. My main machine
is an IBM T40, which has near identical hardware, so I will try to hack
on this when I can.

This could be as simple as refactoring some of the code in agp_intel.c
from attach into init functions and calling them on resume.

Really going to sleep now.

Regards,
BMS


I guess what I'd really like to know is is there any active work on
this, any interest in getting this fixed, etc.    I would very much
like to see it fixed and would be fully willing to help out in any way
I can.  Hoping someone has information on this,

Eric Kjeldergaard

-- 
If I write a signature, my emails will appear more personalised.