On Thursday 06 September 2012 13:08:18 Alan Stern wrote:
> On Thu, 6 Sep 2012, Oliver Neukum wrote:
> 
> > On Thursday 06 September 2012 11:06:49 Alan Stern wrote:
> > > On Thu, 6 Sep 2012, Aaron Lu wrote:
> > > 
> > > > > That's why we have an autosuspend delay.  Although for some reason 
> > > > > the 
> > > > > SCSI subsystem doesn't use it currently...  We need to add a call to 
> > > > > pm_runtime_use_autosuspend() in scsi_sysfs_add_sdev().  Likewise, the 
> > > > > pm_schedule_suspend() call in scsi_runtime_idle() should be changed 
> > > > > to 
> > > > > pm_runtime_autosuspend().  And there should be calls to 
> > > > > pm_runtime_set_autosuspend_delay() in the sd and sr drivers.
> > > > 
> > > > I tried to use autosuspend when preparing the patch, but the fact that
> > > > the devices will be polled every 2 seconds make it impossible to enter
> > > > suspend state if the autosuspend delay is larger than that.
> > > 
> > > You can always increase the polling interval.
> > > 
> > > But in the long run that wouldn't be a good solution.  What I'd really 
> > > like is a way to do the status polling without having it reset the 
> > > idle timer.
> > > 
> > > Oliver, what do you think?  Would that be a good solution?
> > 
> > Well, we could introduce a flag into the requests for the polls.
> > But best would be to simply declare a device immediately idle
> > as soon as we learn that it has no medium. No special casing
> > would be needed.
> 
> We could do that, but what about idle drives that do have media?

Then we do have a problem. To handle this optimally we'd have to make
a difference between the first time a new medium is noticed and later
polls.

        Regards
                Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to