From owner-freebsd-current@FreeBSD.ORG Sat Oct 9 00:33:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C66416A4CE; Sat, 9 Oct 2004 00:33:18 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD57743D1D; Sat, 9 Oct 2004 00:33:17 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i990Wd1d032304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Oct 2004 17:32:40 -0700 Message-ID: <416731A3.50807@root.org> Date: Fri, 08 Oct 2004 17:32:35 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <5ad23a300410071928791fa9c@mail.gmail.com> <20041008030317.GV664@empiric.icir.org> <5ad23a3004100720467646e1ea@mail.gmail.com> <20041008102758.GH718@empiric.icir.org> <20041008223600.GL718@empiric.icir.org> In-Reply-To: <20041008223600.GL718@empiric.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: anholt@freebsd.org cc: freebsd-current@freebsd.org cc: imp@freebsd.org cc: Jordan Sissel Subject: Re: Radeon AGP suspend/resume support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Oct 2004 00:33:18 -0000 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