Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 08 Oct 2004 17:32:35 -0700
From:      Nate Lawson <nate@root.org>
To:        Bruce M Simpson <bms@spc.org>
Cc:        Jordan Sissel <psionic@gmail.com>
Subject:   Re: Radeon AGP suspend/resume support
Message-ID:  <416731A3.50807@root.org>
In-Reply-To: <20041008223600.GL718@empiric.icir.org>
References:  <5ad23a300410071928791fa9c@mail.gmail.com> <20041008030317.GV664@empiric.icir.org> <5ad23a3004100720467646e1ea@mail.gmail.com> <20041008102758.GH718@empiric.icir.org> <20041008223600.GL718@empiric.icir.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M Simpson wrote:
> Hello,
> 
> 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:
>>	http://www.spinics.net/lists/xf-xpert/msg04368.html
> 
> 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.

-- 
Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416731A3.50807>