From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 17 19:11:09 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D58416A400 for ; Tue, 17 Jul 2007 19:11:09 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7388313C4A6 for ; Tue, 17 Jul 2007 19:11:09 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 61461 invoked from network); 17 Jul 2007 19:11:10 -0000 Received: from ppp-71-139-42-13.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.42.13) by root.org with ESMTPA; 17 Jul 2007 19:11:10 -0000 Message-ID: <469D1447.2060904@root.org> Date: Tue, 17 Jul 2007 12:11:03 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.4 (X11/20070620) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <20070717030137.GQ57123@obelix.dsto.defence.gov.au> In-Reply-To: <20070717030137.GQ57123@obelix.dsto.defence.gov.au> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Brown, Len" Subject: Re: "ACPI in Linux . Myths vs. Reality" ... Paper - 27th June 2007 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 19:11:09 -0000 Wilkinson, Alex wrote: > By Len.Brown@intel.com > > [https://ols2006.108.redhat.com/2007/Reprints/brown_1-Reprint.pdf] Thanks for the forward. This is a good summary. My perspective from the FreeBSD side: * We don't have suspend-to-disk yet except for the couple systems that supported S4BIOS. If it was implemented, it would be a much more reliable than suspend-to-ram. This is a major project, hence it hasn't been done yet. * I agree most suspend-to-ram issues are devices/drivers, not ACPI. Often, it's the case that our drivers are incomplete or lacking quirks for particular buggy devices, not bugs in the drivers themselves. However, issues like with video are awaiting more help from DRM and the modesetting project. * Hotkeys are solved by loading the acpi_ibm/panasonic/asus/whatever driver. We do still need a central way of adapting the device-specific keys to general key events. Not a hard project, but one that needs a lot of research into Gnome, KDE, HAL, etc. to see what users expect and how to link it to common UIs. * We should investigate using the RTC for the timer interrupt. Also, the HPET has an interrupt mode that might be useful. * I've submitted errata to the ACPI standards effort, cc'd to the Linux list and Intel developers. No changes have been made in that area over 3 revs of the spec. I disagree that the ACPI spec incorporates much, if any, community input. Perhaps there is now a new contact but I'm not aware of them. * Linux Firmware kit (http://www.linuxfirmwarekit.org/) Great stuff if people use it. We benefit from the acpi-ca compliance. * ACPI-CA is still changing a lot in fundamental ways, i.e. locking. The APIs have to be reworked every 3rd revision or so. Unfortunately since we have a lot of support code Linux does not, we end up hostage to the least common denominator (i.e semaphores vs. mutexes, hard-coded lock order in ACPI-CA itself vs. WITNESS). * Native MSR access for the acpi cpufreq module. Hey, nice. I didn't see this revision before. Chapter 3 is new and will help us make SpeedStep work on newer systems. * Your help -- still needed! -Nate