Re: [RFC/PATCH] IDE Power Management try 1

[Alexander Atanasov <alex@ssi.bg>]

		Hello,

Benjamin Herrenschmidt wrote:


> The point is to pipe the power management requests through the request
> queue for proper locking. Since those requests involve several
> operations that have to be tied together with the queue beeing locked
> for further 'user' requests, they are implemented as a state machine
> with specific callbacks in the subdrivers
> 
[cut]
> 
> One thing that should probably be cleaned up is the difference between
> the suspend and the resume request. I didn't want to implement 2
> different request bits to avoid using too much of that bit-space, and
> because most of the core handling is the same. So right now, I carry in
> the special structure attached to the request, 2 fields. An int
> indicating if we are doing a suspend or a resume op, and an int that is
> the actual state machine step.

 > ===== include/linux/blkdev.h 1.100 vs edited =====
 > --- 1.100/include/linux/blkdev.h	Sun Apr 20 18:20:10 2003
 > +++ edited/include/linux/blkdev.h	Thu Apr 24 14:30:50 2003
 > @@ -116,6 +116,7 @@
 >  	__REQ_DRIVE_CMD,
 >  	__REQ_DRIVE_TASK,
 >  	__REQ_DRIVE_TASKFILE,
 > +	__REQ_POWER_MANAGEMENT,
 >  	__REQ_NR_BITS,	/* stops here */
 >  };


		What about this - add __REQ_DRIVE_INTERNAL, and carry args in 
rq->cmd[16] [0] = PM, [1] = SUSPEND/RESUME, [2]= STATE ? IDE can use it 
for power managment, error handling (do not do it from interrupt 
context, but queue it), may be more. This way it would really makes 
things a bit better with the complicated IDE locking. SCSI and probably 
other block devices can benefit from this internal requests too, so the 
bit is not wasted.


--
have fun,
alex