On Monday 01 November 2004 17:26, you wrote: > > > What should what -- and why? :) > > > > The cost to resume would be on the order of a few seeks. > > If the drive were busy, that'd matter; but in that case > > nothing would be suspending, the drive's not idle! I'd > > be interested in knowing more what the SCSI folk think. > > > > You later said: > > > > > But whatever subsystem you are providing a service for (fs, networking, > > > etc...) aren't to be part of the bus hierarchy and aren't to be > > > suspended or resumed. > > > > But that's exactly this case. USB is the bus hierarchy; > > SCSI is just a functional layer on top, it doesn't have > > anything particular to do with *this* hardware. Unless > > someone added power switching to SCSI when I wasn't > > watching (entirely possible). > > Hrm... ok, that isn't trivial, but here's how I see it. The actual PM > scenario goes down to the disk (sd in our case). Not below. The SCSI > is a bus in that case, it's a transport, like USB. We are basically > stacking 2 layers of transport but SCSI is part of the bus hierarchy. It's certainly implemented that way, except for iSCSI and so on where the "hierarchy" is sort of multipath/abstract... But also, what I was talking about was a bit different. Yes, SCSI does need to be able to quiesce queues. But that doesn't mean that one of the other transports in that hierarchy can't do so independently ... such as for example USB-storage, or drive firmware. > What I do on IDE is this: > > The disk itself is the leaf of the PM tree. Actually, the callback goes > to the ide_bus structure, since busses are what get the callbacks. > ide_bus (but that could really be the disk struct device, it was just > simple to put it there because it's generic for all IDE devices). > > That callbacks are then turned into a special request that I send down > the queue on suspend (and wait for it to complete) and that I inject at > the head of the queue (and wait for it to complete eventually, that is > optional, completion of resume can be asynchronous in some carefully > chosen cases). USB_SUSPEND just quiesces the whole queue. All the drivers are told to suspend, and if they do so then the queue will be empty. If they don't, the root hub will just disable the schedules when it's told to suspend; it'll resume them later. (Something I'd rather discourage from happening, since disabling active schedules can mean spinning with irqs blocked for several msecs. But for now, that'll be typical if CONFIG_PM without USB_SUSPEND.) > The core IDE queue management will then make sure it accepts no other > request after processing the PM suspend one, and will make sure all > pending ones have been flushed out before processing it (it acts like a > barrier). Once processing it, it then calls back a subdriver specific > callback that processes the PM request in a state machine model (that's > best suited for IDE: send taskfiles, gets called again on completion, > maybe that's fine for SCSI too). Once the state machine at the subdriver > level is complete, the PM request is "completed". For suspend, that > means the queue stays blocked, which is why the resume request is > directly injected at the head of the queue, triggering a special case in > the IDE code to start the resume process. > > This sounds complicated, but it's not very in practice (the > implementation is simple). Ditto for USB, though few drivers will try to handle suspend/resume yet. So the HCD has more to do with making it be correct than I'd prefer. > For scsi, the idea would be the same. The disk gets suspended (the leaf > of the PM tree, provider of the request queue). sd() (or the core SCSI > like I do on IDE to simplify) would get the callback, would then forge & > send a PM request down the queue for the device. sd, st, etc... > subdrivers would then have their own handling of it once the request > reach them and the PM request would be treated as a barrier making sure > previous pending stuff is completed. > > I'll probably give a try at implementing that one of these day if I can > find my cardbus adaptec scsi card :) You could just do it with a usb-storage device. Don't you have a Swiss Army Knife with USB? ;) Oh -- that won't address the "ub" driver. Hmm... - Dave > Ben. > > >
