From owner-freebsd-acpi@FreeBSD.ORG Sun May 8 20:46:39 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 E676216A4E6 for ; Sun, 8 May 2005 20:46:39 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73D3543D8C for ; Sun, 8 May 2005 20:46:39 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.115] (adsl-64-171-185-67.dsl.snfc21.pacbell.net [64.171.185.67])j48KjpXw004494; Sun, 8 May 2005 16:45:54 -0400 Message-ID: <427E7AA9.6040703@root.org> Date: Sun, 08 May 2005 13:46:33 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050416) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takanori Watanabe References: <200505081157.j48Bva9s043547@sana.init-main.com> In-Reply-To: <200505081157.j48Bva9s043547@sana.init-main.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org 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: Sun, 08 May 2005 20:46:40 -0000 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. -- Nate