RE: [PATCH] SCSI midlayer power management

[James . Smart]

Glad to see where this thread ended up...

Suspend, for scsi hosts, essentially has to end up being an unattach. You can't make assumptions on DMA use, etc based on just quiescing host i/o flow or no target for multi-initiators. There's too much variance in adapters design that depend on adapter-pull functionality - rings, ring pointers, host-based contexts, host-based firmware (scripts), and so on. There's also lots of potential asynchronous traffic that can occur outside of just host-requested io : for FC, there's ELS/BLS's; for iSCSI there's non-io PDU's (NOPs, AENs). Posted buffers to the adapter must be killed, and so on.  Ultimately, the scsi class drivers must quiesce the devices, then the LLDD's must "suspend", essentially saving software state and resetting hardware.

For Resume, given that the MMIO state isn't restored, and given the above argument of "detach" on suspend - the LLDD must essentially restart the hardware, reprogramming dma addresses, reposting buffers, reinstantiating contexts, etc.  As indicated, easier on some hardware, harder on others.

So, as Pavel indicates - powermanagement for the LLDD should look very similar to rmmod/insmod. The question usually comes down to whether the overhead of a suspend/resume, where the driver has to participate to save/restore software state, is worth the extra complexity vs. whether you are better off just having the LLDD fully detach/reattach. Latter usually wins as it supports hot-plug well, and moves the complexities out of each driver and into the infrastructure.

-- James S


> -----Original Message-----
> From: linux-scsi-owner@xxxxxxxxxxxxxxx
> [mailto:linux-scsi-owner@xxxxxxxxxxxxxxx]On Behalf Of Pavel Machek
> Sent: Thursday, August 12, 2004 4:49 PM
> To: James Bottomley
> Cc: Benjamin Herrenschmidt; Nathan Bryant; Linux SCSI Reflector; Linux
> Kernel list; Jeff Garzik
> Subject: Re: [PATCH] SCSI midlayer power management
> 
> 
> Hi!
> 
> > > Can't you simply reuse bootup code? It will no longer be __init,
> > > but it should make suspend/resume functions quite simple.
> > 
> > Unfortunately, no that simply.
> > 
> > Bootup is all about allocating these areas and initialising 
> the card. 
> > Resume will be about initialising the card knowing the 
> existing areas
> > (and the data about the existing areas will have to be part of our
> > persistent data on suspend).
> 
> You can simply free those areas during suspend, so that resume will be
> same as powerup....
> 
> Essentially if you can do insmod and rmmod, you can "simply" emulate
> rmmod during suspend and emulate "insmod" during resume...
> 
> > > > to pick three drivers to do this for, that would be 
> aic7xxx, aic79xx and
> > > > sym_2?
> > > 
> > > No idea, only SCSI host I owned was some 8-bit isa thing....
> > 
> > Well, someone who's interested needs to pick a driver.  It's usually
> > easier to persuade everyone to add the feature if there's 
> an example to
> > copy...
> 
> Make it aic7xxx then... Someone already worked on that one.
> 
> 								
> 	Pavel
> -- 
> People were complaining that M$ turns users into beta-testers...
> ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
-
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/