On Mon, 1 Nov 2004, David Brownell wrote: > 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! Well, the key state isn't _completely_ internal to the driver. The fact that the USB device has been suspended is available to the entire USB subsystem, and through sysfs, to all of userspace. > 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...) The SCSI layer doesn't need to know these things. (That is, in principle it does need to know that requests will take a little longer to complete, but if the difference is only milliseconds while the SCSI timeouts are measured in seconds then it doesn't matter). This raises the question: Does the SCSI layer need to know about any other kinds of suspend, so that it can (for example) block the input queue? I don't know what the SCSI people think about this... Alan Stern
