On Thu, 2005-03-10 at 11:38 -0500, Alan Stern wrote: > On Wed, 9 Mar 2005, Adam Belay wrote: > > > On Wed, 2005-03-09 at 11:11 -0500, Alan Stern wrote: > > > On Tue, 8 Mar 2005, Adam Belay wrote: > > > > > > > The idea here is that if a device could be put into a lower state in which > > > > it isn't operational, but still maintains configuration, then we could just > > > > use "close" and "open". For complete poweroffs we could do: > > > > > > > > "close" -> "stop" and... "start" -> "open". > > > > > > > > A power state has the following characteristics: > > > > Is the device operational? > > > > Is the context of the device maintained? > > > > Is the configuration of the device maintained? > > I'm not clear on the distinction you draw here between context and > configuration. These terms are used in the ACPI specs. Basically, if context is maintained, it's possible to start where you left off (e.g. continuing an actual operation). In this case, *close might not ever need to be called. If configuration is maintained, then you don't have to re-setup the device, but may have to restore the context before continuing. Configuration is associated only with the physical device. Device context plays a role in both physical and logical layers. A loss of configuration is like starting from when the device was first detected. A loss of context is like starting right after the device was configured by the driver. These can mean a lot of things for different buses and classes of devices, but they tend to apply to all of them. > > Also you should note that some drivers have to keep track of much finer > levels of functionality than just "is it operational". For instance: > which parts are operational, which clocks are running, what is the speed, > and so on. Yes, but those characteristics are class specific, and will be managed by policy for that class, generally after the "*open" phase. > > > > > "start" and "stop" handle configuration, "open" and "close" handle context. > > > Not at all, these layers correspond to the existing driver model design, > > which, to date, has been adequate for every type of device. Class > > devices are optional. If the driver registers many class devices, then > > the driver model could automatically manage "*start" and "*stop" for all > > of them. If none are registered, then there is no extra overhead, and > > no extra layer. > > > > If you're referring to "start" and "open" as "layers", then I don't > > think they're imposing anything unreasonable. Every driver needs to > > detect and setup the hardware (*start) and most drivers need to make > > that device available to the user or other kernel components (*open). > > More fine grained layers would be class specific and happen after *open, > > which essential prepares the device for use by the class. > > Let's not worry about class devices for now. Are your start/stop and > close/open significantly different from probe/remove and suspend/resume? These new functions are primarily to better support class devices. Class devices play a critical role in power management. They're virtual, and must operate regardless of what is going on at the physical level. *start and *open are different because they draw a clear line between context and configuration, and physical and logical. As an example we could consider a modem. *attach allocates structures, and handles initialization. *start reads resource configuration, and does any necessary setup stuff. *open would prepare the device to receive commands. The class device could be ttyS0. When the user opens /dev/ttyS0, the kernel might do the following: dev->open class->start and when /dev/ttyS0 is closed: class->stop dev->close and then the device might be powered off for idling: dev->stop and then when it's powered back up, it lost configuration, so: dev->start Also these changes allow us to stop the operation of hardware in a manner independent of power management, but without unloading the driver. The user may decide to stop the operation of a device. Also a device may need to be stopped to rebalance resources (a situation that may be more common with PCI express). With resource rebalancing, we may only want to stop the physical layer, but keep the logical layer operating. Thanks, Adam
