From owner-p4-projects@FreeBSD.ORG Fri Oct 3 15:59:50 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id DCB1916A4E4; Fri, 3 Oct 2003 15:59:49 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4A8716A4B3 for ; Fri, 3 Oct 2003 15:59:49 -0700 (PDT) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id F350F43FE3 for ; Fri, 3 Oct 2003 15:59:39 -0700 (PDT) (envelope-from imp@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.12.9/8.12.9) with ESMTP id h93MxdXJ018282 for ; Fri, 3 Oct 2003 15:59:39 -0700 (PDT) (envelope-from imp@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.12.9/8.12.9/Submit) id h93Mxdn5018279 for perforce@freebsd.org; Fri, 3 Oct 2003 15:59:39 -0700 (PDT) (envelope-from imp@freebsd.org) Date: Fri, 3 Oct 2003 15:59:39 -0700 (PDT) Message-Id: <200310032259.h93Mxdn5018279@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to imp@freebsd.org using -f From: Warner Losh To: Perforce Change Reviews Subject: PERFORCE change 39117 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2003 22:59:50 -0000 http://perforce.freebsd.org/chv.cgi?CH=39117 Change 39117 by imp@imp_koguchi on 2003/10/03 15:59:36 Add comments to jhb's latest additions. Affected files ... .. //depot/projects/power/notes#6 edit Differences ... ==== //depot/projects/power/notes#6 (text+ko) ==== @@ -22,10 +22,19 @@ our power shadow tree in the acpi_SetPowerState() function. - define a bus method for powering up/down devices - bus_set_powerstate(parent, child, state) where state is on or off + # actually on/off is insufficient for a power management daemon that + # wants to actively manage the D level of a device. We should make + # this more flexible so that it can be mapped into states that are + # neither on or off. - define either a device or syscall for asking new-bus to dispatch commands to a given device + # devctl is the perfect place for this, in one of my trees I have + # ioctls for doing this already. - The power command would be sent to the parent device using device_get_parent() for the simple case (power off fdc0) + # would also potentially need a method for powering off arbitrary devices + # in the tree that aren't attached for busses whose default policy is + # to not power down unattached devices. - define a bus method to locate a child of a specific device by name using a 'parent:child' syntax where the format of the "child" string is defined by the parent driver. Thus, 'pci0::' might be @@ -34,12 +43,22 @@ - Convert device_power() to use this method to look up the child device if the name contains a colon instead of treating the name as a pure name of the child device + # We have almost what we need now in the location_str stuff. However, + # that's more of a 'long string' rather than the short string that's + # wanted for this. - Perhaps rename device_power() to device_command() to allow for other commands like eject, etc. + # methods should be unique. Command interfaces to userland should dispatch + # the right method. Otherwise we've reinvented ioctl :-) - convert to a model of suspending the device via device_suspend()/resume() rather than detach()/attach() - This may require fixes to drivers so that they continue to function appropriately when their hardware has been suspended + # NO. This cannot be implemented reliably. pccard bridges do not tell + # us that a device has been removed while the system was asleep. That's + # why we detach/reattach on suspend/resume for devices on pccard/cardbus + # bridges. usb bridges can tell about this, and they properly use the + # suspend/resume functions. The second stage will be to make the powering off of devices more automated. This is still in early design stage. It may involve a powerd, it may