Re: Power management for SCSI

[Stefan Richter]

Alan Stern wrote:
> On Wed, 13 Aug 2008, Oliver Neukum wrote:
>> Am Mittwoch 13 August 2008 16:59:23 schrieb Alan Stern:
>> > Is the USB transport unique in its requirement that all the child
>> > devices must be suspended before the link can be powered down?  Maybe
>> 
>> All children that are USB must be powered down. We know in fact that most
>> drives don't care that the device is suspended. The problem was drive
>> enclosures that cut power upon suspension losing cached data.
> 
> You misunderstood my question.  Are there SCSI transports other than
> USB sharing the requirement that all child devices must be suspended
> before the link can be powered down?

Yes in case of FireWire; it's necessary there too (but not sufficient).

(It's a bad example though since I have no good idea whether power
management beyond (a) system suspend and (b) disk spindown is feasible
in reality at all.)

[...]
>> So do we really want to do autosuspend on the device level? Or do we work
>> on hosts and just use the suspend()/resume() support of the sd, sr, ... etc?
> 
> For transports which are like USB, we should do autosuspend at the
> target (not device) level.  This means invoking the suspend/resume 
> routines of the ULDs like sd and sr.  The transport gets notified when 
> all of the targets are suspended.  (Or maybe the host driver gets 
> notified instead; there probably isn't any advantage to using the 
> transport class here.)
> 
> For other transports, we should only do idle-timeout detection.  The
> transport gets notified when any target has been idle for sufficiently 
> long, so that it can power down the link.  The ULDs are not involved.
> 
> Does that sound okay?

Minor correction:  The ULD suspend/resume methods necessarily work on
logical units, not targets.
-- 
Stefan Richter
-=====-==--- =--- -==-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/