On Tue, Jan 21, 2014 at 7:44 AM, Alan Stern <st...@rowland.harvard.edu> wrote: > On Tue, 21 Jan 2014, Dan Williams wrote: > >> On Sat, Jan 18, 2014 at 6:08 AM, Alan Stern <st...@rowland.harvard.edu> >> wrote: >> > On Fri, 17 Jan 2014, Dan Williams wrote: >> > >> >> I think it's a bit of an interface surprise to have pm_runtime disable >> >> have side effects only for scsi_disk devices. I think lazy_resume >> >> needs to be an explicit attribute of the disk. For ata devices any >> >> command wakes up the drive. Perhaps we could simply do the same for >> >> scsi devices. In lazy_resume mode flag the device as "needs spinup" >> >> at sd_resume time and schedule it when a command arrives. >> > >> > What you have just described is essentially what runtime PM does. >> >> Deliberately so... >> >> > There's no need to implement it any other way. And this explains why >> > disabling runtime PM would also disable lazy resume. >> >> The need is to avoid tying rpm and dpm ops together in surprising new >> ways that require userspace to change if it wants to keep the default >> behavior of hiding resume latency as much as possible. A lazy_resume >> knob vs changing the default let's the few setups that care set the >> power-up in standby mode. > > That's why I proposed it. What are you getting at?
? Yes, earlier in the thread you propose a lazy_resume knob and then later say "there's no need to implement it any other way" referring to runtime PM. I took that to mean there's no need to consider any other solution besides disabling runtime PM. >> It should also "perform" better given it >> does not require the disk to be runtime suspended prior to system >> suspend, it will unconditionally resume on demand. > > None of my posts in this email thread have required the disk to be in > runtime suspend prior to the system suspend. Apologies, I was recalling one of the earlier patches. -- Dan -- 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
