Messages in this thread | | | Date | Thu, 14 Aug 2008 15:08:12 +0200 | From | Pavel Machek <> | Subject | Re: Power management for SCSI |
| |
Hi!
> > Add support for autosuspend/autoresume. Lowlevel driver can use it to > > spin the disk down and power down its SATA link, to turn off the USB > > interface, etc. > > > > Spinning down the disk is useful - saves ~0.5W here. Powering down > > SATA controller is even better -- should save ~1W. > > > > Now, I guess the patch will need to be split to small pieces for > > merge... I tried to rearrange it so that the documentation and hooks > > go before stuff that needs the hooks, and before Kconfig enabler. If > > it looks reasonably good, I'll split it into smaller pieces. > > James had a number of objections to my original patch; you can read > them here: > > https://lists.linux-foundation.org/pipermail/linux-pm/2008-March/016849.html > > I haven't had time yet to work on an improved version.
Ok, I see, "its done at the wrong level" sounds pretty serious.
First the general comments/questions:
# #1. It's done at the wrong level: suspend "device" is actually a target #function. There's no way on a multi-lun device we want to keep the #flags and last_busy anywhere but in the target
So... if there's one device with Lun0==cdrom1 and Lun1==cdrom2, it is a single target, and we want to keep flags/last busy common to all that?
What is good data structure to add? I see scsi_tgt*.h, but it is very short, and there does not seem to be good structure to hook into.
#2. As you say in the comment, the thing we're trying to power down is #the link. In most SCSI implementations, the link has a rather complex #relationship to the target, what we want to do in #periodic_autosuspend_scan() is run over the devices on each link, and #if #they're not busy suspend the link? What's probably needed is a set of #adjunct helpers for the transport classes to do this.
So the host suspend/resume stuff should go into struct scsi_transport_template?
#3. The link power down is much faster than device spin down ... in #your #patch these two things seem to be coupled ... we really need to keep #them separate. #
ACK.
#4. The entanglement with error handling is incredibly problematic #(since #eh is a nastily complex state machine in its own right). What do #transports that use eh_strategy_handler do about all of this?
/me scared... Pavel
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |