Radeon AGP suspend/resume support
nate at root.org
Fri Oct 8 17:33:18 PDT 2004
Bruce M Simpson wrote:
> I should be most grateful if someone else could confirm my findings here.
> This is based purely on my reading of the code; I haven't tried watching
> debug messages yet to see what happens.
This is interesting and I agree work is needed here.
> On Fri, Oct 08, 2004 at 03:27:58AM -0700, Bruce M Simpson wrote:
>>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:
> Actually the problem is worse than that, from what I can see. There is a
> module in the xorg/Xfree86 tree called bsd_apm.c. This is meant to poll
> the /dev/apm device on the BSDs for suspend/resume event notifications
> coming from the APM BIOS.
> There are two problems with this:
> 1) This uses a NetBSD specific interface, which, whilst broadly similar
> to FreeBSD's apm support, is not ABI compatible with ours.
> 2) The ACPI apm shim does not dispatch such events. They are only
> dispatched within the system if 'real' BIOS APM support is in the
> kernel. This cannot co-exist with ACPI. Furthermore they are only
> announced on the /dev/apmctl device; there are some comments in the
> code to this effect.
> So *no* suspend/resume support ever actually gets called, for any userland
> driver in the X tree, on FreeBSD. It seems X needs to be re-educated about
> how FreeBSD suspends and resumes. It may well be more appropriate to rewrite
> this module entirely from scratch for use with ACPI.
> This would seem to boil down to two components being needed:
> a) AGP suspend/resume support.
> b) X.org/XF86 support for suspend/resume with ACPI.
I agree. Here's some more detail of what I think is needed in these areas.
a) PCI/AGP video driver
John has some initial support for a real PCI/AGP video driver. This
would implement the suspend/resume functionality for VGA and also do
DPMS calls to turn off/on the display as appropriate. This needs to
interface with acpi_video in some way since they are both attaching to
the same actual device.
b) X notification of suspend/resume on FreeBSD
This is easy in one sense but tricky in another. The easy approach is
to just add support for the APM_IOC_NEXTEVENT ioctl and a no-op for
APM_IOC_STANDBY (or the FreeBSD equivalents if this is NetBSD-specific.)
Then X gets the notify and has the chance to suspend. The catch is
that the current model doesn't support userland being in the blocking
path for any ACPI events. So currently if X took a while to suspend, it
might not complete before the actual suspend.
The tough thing about putting usermode in the driver seat is how to know
if it has crashed. I suspect we can do this with a timeout() and just
give the usermode a max of 10 seconds or so to complete suspending
before the system unconditionally suspends. I'm curious if anyone else
has thoughts on this model.
More information about the freebsd-current