On Thu, 2 Sep 2010, Tejun Heo wrote: > Hello, > > On 09/02/2010 10:28 PM, Rafael J. Wysocki wrote: > > That would be very nice. In particular, I'd like to get rid of the > > pm_message_t thing if possible. And I'd like to avoid putting the > > controller into D3 before creating hibernation image. :-) Ultimately I don't think it will be possible to get rid of pm_message_t throughout the entire kernel. Not just because it's a legacy thing spread all over the place, but because it sometimes is genuinely useful. In situations where there are only minimal differences between the various suspend/resume paths, it makes a lot of sense to call a single function and tell it which type of operation to perform. > Oh, yeah, things like that can definitely be changed, but I think it > would still need to be piped through EH. That's how the queue gets > quiesced for those special operations and resume is basically probing, > so it doesn't make much sense to split them. Please let me know how > it should work from power management POV and I'll be happy to convert > libata to fit the new behavior. Tejun, I'm planning to make a few changes to the block layer and the SCSI core in order to implement delayed autosuspend. These changes will affect system sleep too, so you may need to know about them. Each request_queue structure will have an rpm_status variable that gets updated as the corresponding device is suspended or resumed. When the status is SUSPENDING or RESUMING, requests will not be sent from the request_queue to the driver unless they have cmd_type set to REQ_TYPE_PM_SUSPEND or REQ_TYPE_PM_RESUME (actually I may combine those two into a single REQ_TYPE_PM type). If other types of request are added to the queue when the status isn't ACTIVE, they will cause a runtime resume to be started. Initially this will affect only drivers using the SCSI layer. Commands sent during error handling won't be affected though, because the SCSI error handler doesn't use requests or queues -- it sends commands directly to the lower-level driver. Does that all sound okay to you? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
