On Tue, 2 Nov 2004, Benjamin Herrenschmidt wrote: > 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). > > 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). It sounds more complicated than necessary, for system PM changes at least. Isn't it true that whenever a system PM request is received that all the user processes are in the refrigerator and hence no new block requests can be generated? If so, wouldn't it be sufficient for IDE suspend simply to wait until the request queue is empty? Alan Stern
