From owner-freebsd-acpi@FreeBSD.ORG Mon May 9 03:26:46 2005 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C72516A4E6 for ; Mon, 9 May 2005 03:26:46 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 252FF43D48 for ; Mon, 9 May 2005 03:26:46 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Sun, 08 May 2005 20:26:45 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4F8135D07; Sun, 8 May 2005 20:26:45 -0700 (PDT) To: Nate Lawson In-reply-to: Your message of "Sun, 08 May 2005 13:46:33 PDT." <427E7AA9.6040703@root.org> Date: Sun, 08 May 2005 20:26:45 -0700 From: "Kevin Oberman" Message-Id: <20050509032645.4F8135D07@ptavv.es.net> cc: freebsd-acpi@freebsd.org cc: Takanori Watanabe Subject: Re: Porting code from the Linux ibm-acpi sourceforge package X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2005 03:26:46 -0000 > Date: Sun, 08 May 2005 13:46:33 -0700 > From: Nate Lawson > Sender: owner-freebsd-acpi@freebsd.org > > Takanori Watanabe wrote: > > In message <20050508024448.A943@cons.org>, Martin Cracauer さんいわく: > > > >>Hi, > >> > >>I reinstalled my Thinkpad R40 with FreeBSD-5-stable. Works very well > >>except for video corruption on sleep and that I miss some ACPI > >>functionality I had with the ibm-acpi package under Linux. > > > > > > Some functionalies are implimented in acpi_ibm. > > In particular, sys/dev/acpi_support/acpi_ibm.c > If you want to update that, it would be good since Linux appears to have > reverse engineered more capabilities recently. > > >>More specifically, I would like to port or reimplement some parts of > >>it, and I would like to start with the code to eject and re-mount the > >>ultrabay devices. > >> > >>I have the Linux code in front of me which is showing, for the example > >>of the basic bay identifier and the eject code: > >> > >>IBM_HANDLE(bay, root, > >> "\\_SB.PCI.IDE.SECN.MAST", /* 570 */ > >> "\\_SB.PCI0.IDE0.IDES.IDSM", /* 600e/x, 770e, 770x */ > >> "\\_SB.PCI0.IDE0.SCND.MSTR", /* all others */ > >>); /* A21e, R30, R31 */ > >>IBM_HANDLE(bay_ej, bay, > >> "_EJ3", /* 600e/x, A2xm/p, A3x */ > >> "_EJ0", /* all others */ > >>); /* 570,A21e,G4x,R30,R31,R32,R40e,R50e */ > > > > But eject handling is not supported . > > There is a lot of work to do here and not much of it has to do with > ACPI. I have a patch for ACPI eject support that I'll post again some > time. But it is not usable since many device drivers don't support > eject. For instance, our ATA driver did not support detach until the > recent mkIII import. I'm not sure if it supports forced detach yet. > Going up a level, I'm not sure how our filesystem drivers would support > a drive disappearing out from under them. If you want to contribute, I > think a good first step is adding a testing SYSCTL_PROC that calls > device_detach(devclass_get_device(devclass_find("acd"), 0)) and then > running it to see if it works. > > Linux doesn't yet implement a proper device tree (although they're > getting better). So they have to have lots of hacks like these handle > arrays to figure out what to eject. In FreeBSD, the ACPI side is very > simple -- you get a notify, take the passed in handle, and call the > associated device_t's detach routine. That's what my patch does. No > hardcoded paths. FreeBSD ATA has supported bus detach since ATAng (whenever that was). I have had no problem detaching ATA bus 1 and removing the drive (CD or HD) in the bay and replacing it with another or with a battery. Of course, it MUST be dismounted before the detach or a panic is to be expected. Also, if you use a second battery, you must have it in the system at boot time or it won't be seen, used, or even charged. If you boot with the battery, you can: atacontrol detach 1 remove the battery insert a disk drive atacontrol attach 1 use the disk and dismount it. atacontrol detach 1 remove the disk insert the battery Battery will be seen and used This should work in V5.3, -stable, or -current, although I have not run v5 on my T30 for some time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634