On Monday 01 November 2004, Alan Stern wrote: > It might be a good idea to add a generic PM state for devices that are in > a low-performance mode but will automatically transfer (or be transferred) > back to full-performance when the next request arrives. I don't think the PM framework should know about "low performance" modes. This particular case I see as a kind of "ondemand" policy for managing the device power consumption ... just like the cpufreq policy of the same name, though the switching time is much higher. (Measured in milliseconds across USB, not microseconds for changing voltage and frequencies for on-chip cores including CPUs.) In both cases, key state is internal to the driver. It's not clear to me whether there should be something analagous to cpufreq for managing driver policies ... the hardware variability seems to be greater, and updating thousands of drivers would be tricky! All the "System PM" framework needs to know about any device is that its PM state is compatible with any upcoming sleep state transition. Otherwise, "Device PM" must be mostly orthogonal to "System PM". That's part of why there seems to be agreement that "power_state" should vanish. > In any case, yes, you are right; these layers do not and should not know > about auto-suspend. My reason for bringing it up is because it seems to > contradicts this paragraph from David's recent write-up: > > + Devices generally can't enter low power modes before their children, > or leave them before their parents. At least some of that logic might > need to live in the bridge or hub drivers managing those > relationships. > > And yes, he wrote "generally", so this is an exception to the rule. It > might end up being a wide-spread exception. Of course in this case the child devices -- logical SCSI hosts and disks -- really seem like they're different kinds of animal than the physical USB devices. It's not at all clear to me that the SCSI layer needs to know when requests might take a bit longer to complete, or that it even makes sense to talk of them as having any power consumption managed through SCSI. (Except maybe for SCSI commands to spin down idle disks...) But this also highlights one of the reasons for that last sentence. The usb-storage driver is literally a bridge between two different frameworks. It can know things about how that bridging works, things that no generic PM layer can reasonably know. In this case, that there's a low power mode for the bridge that doesn't need to be visible to SCSI. - Dave
