Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 09 Oct 2004 14:15:34 +0100
From:      Pete Carss <itinerant@mac.com>
To:        freebsd-current@freebsd.org
Subject:   Re: Radeon AGP suspend/resume support
Message-ID:  <4167E476.4050505@mac.com>
In-Reply-To: <416731A3.50807@root.org>
References:  <5ad23a300410071928791fa9c@mail.gmail.com> <416731A3.50807@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson wrote:

> 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.
> 

This make me wonder how Apple do it in their implementation of X - 
anything that could be ported back to FreeBSD?

Pete



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4167E476.4050505>