On Thu, 16 Jan 2014, Todd E Brandt wrote:
> On Thu, Jan 16, 2014 at 03:05:40PM -0500, Alan Stern wrote:
> > On Thu, 16 Jan 2014, Todd E Brandt wrote:
> >
> > > > Does this plan sound reasonable to everyone? Are there important
> > > > aspects I haven't considered (such as interactions between the SCSI and
> > > > ATA layers)?
> > > >
> > > > Alan Stern
> > > >
> > >
> > > Both approaches employ non-blocking resume of the scsi disks so why don't
> > > we treat these two patch sets as parts one and two. My patch just spins
> > > everything up but sets everything to non-blocking, so it will take care
> > > of the most common use cases. Your patch will then fine-tune that behavior
> > > to only spin up those disks that are actually needed. I don't think there
> > > are any serious conflicts between the two patch sets.
> >
> > Hmmm. In your 2/2 patch, sd_resume_complete() gets called in atomic
> > context. I would need a process context in order to carry out a
> > runtime resume. Any suggestions?
>
> The complete call is really just there to printk any errors and free
> the sense buffer. Why would you want to carry out a runtime resume in
> it?
>From my earlier message:
Otherwise, check to see whether the disk is spinning up all
by itself. This presumably will involve issuing a TEST UNIT
READY command and checking the sense data. Maybe something
different will be needed for ATA disks; I don't know.
If the disk is spinning, or if you can't tell, call
pm_runtime_resume() to put the disk back into the
RPM_ACTIVE state (and spin it up in the case where you
couldn't tell what it was doing).
As you can see, the runtime resume is carried out in the completion
routine for the TEST UNIT READY command. Since the command is likely
to take a long time (Phillip said it can take up to 10 seconds for ATA
disks), we want it to be asynchronous, like the START-STOP command.
> > Also, I don't understand the point of your 1/2 patch. If the whole
> > point of that patch was to carry out the ATA port resume asynchronously
> > ("thus allowing the next device in the pm queue to resume"), doesn't
> > device_enable_async_suspend() already do that for you?
> >
> > Alan Stern
> >
>
> The device_enable_async_suspend call is used to set a pm flag which lets
> the power manager know that this device can be added to the async suspend
> queue. Basically that means that it can be suspended/resumed in parallel
> with all the other async devices, but resume still waits for all those
> devices to finish before completing system resume.
Correct.
> My patch makes ata port and scsi disk resume 'non-blocking' (asynchronous
> with respect to system resume). Which means once they're called the power
> manager pays no more attention to them and will complete system resume
> whenever. Both the power manager and the ata subsystems call these
> features 'asynchronous' so it can be confusing.
I see. That's not explained very well in the patch description -- it
talks about going on to resume the next device on the list, but not
about waiting for the overall system resume to finish.
Alan Stern
--
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
