| Message ID | 1343297129-28174-3-git-send-email-aaron.lu@amd.com |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On Thursday 26 July 2012 18:05:24 Aaron Lu wrote: > If the device is using autosuspend, when scsi_autopm_put_device is > called for it, use autosuspend runtime pm calls instead of the sync > call. What is the purpose of this approach? You need a very good reason to have an API do two different things based on this. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 26, 2012 at 12:44:24PM +0200, Oliver Neukum wrote: > On Thursday 26 July 2012 18:05:24 Aaron Lu wrote: > > If the device is using autosuspend, when scsi_autopm_put_device is > > called for it, use autosuspend runtime pm calls instead of the sync > > call. > > What is the purpose of this approach? The purpose is to let scsi layer driver(sd, sr, etc.) use the same pm api(scsi_autopm_put_device) to put the device to runtime suspended state. When the device is ready to be suspended, if it does not make use of autosuspend, call pm_runtime_put_sync for it; if it makes use of autosuspend, call the autosuspend runtime pm apis for it. > You need a very good reason to have an API do two different things > based on this. If you see the above reason not good, I'll prepare an updated version to create a new api to cover the autosuspend case, something like: void scsi_autopm_put_device_autosuspend(struct scsi_device *sdev) { pm_runtime_mark_last_busy(&sdev->sdev_gendev); pm_runtime_put_autosuspend(&sdev->sdev_gendev); } Does this look right? Thanks, Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 26 July 2012 20:43:32 Aaron Lu wrote: > > What is the purpose of this approach? > > The purpose is to let scsi layer driver(sd, sr, etc.) use the same pm > api(scsi_autopm_put_device) to put the device to runtime suspended > state. > When the device is ready to be suspended, if it does not make use of > autosuspend, call pm_runtime_put_sync for it; if it makes use of > autosuspend, call the autosuspend runtime pm apis for it. > > > You need a very good reason to have an API do two different things > > based on this. > > If you see the above reason not good, I'll prepare an updated version > to create a new api to cover the autosuspend case, something like: > void scsi_autopm_put_device_autosuspend(struct scsi_device *sdev) > { > pm_runtime_mark_last_busy(&sdev->sdev_gendev); > pm_runtime_put_autosuspend(&sdev->sdev_gendev); > } > Does this look right? Much better :-) Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c index dc0ad85..7c93723 100644 --- a/drivers/scsi/scsi_pm.c +++ b/drivers/scsi/scsi_pm.c @@ -197,7 +197,13 @@ EXPORT_SYMBOL_GPL(scsi_autopm_get_device); void scsi_autopm_put_device(struct scsi_device *sdev) { - pm_runtime_put_sync(&sdev->sdev_gendev); + if (sdev->sdev_gendev.power.use_autosuspend) { + pm_runtime_mark_last_busy(&sdev->sdev_gendev); + pm_runtime_put_autosuspend(&sdev->sdev_gendev); + } else { + pm_runtime_put_sync(&sdev->sdev_gendev); + } + } EXPORT_SYMBOL_GPL(scsi_autopm_put_device);
If the device is using autosuspend, when scsi_autopm_put_device is called for it, use autosuspend runtime pm calls instead of the sync call. Signed-off-by: Aaron Lu <aaron.lu@amd.com> --- drivers/scsi/scsi_pm.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)