| Message ID | 1321347089.26084.2.camel@minggr |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On Tue, Nov 15, 2011 at 04:51:29PM +0800, Lin Ming wrote: > > This is not the right approach. You should look instead at > > scsi_dev_type_suspend() in scsi_pm.c. If the device is already runtime > > suspended then the routine should return immediately. > > How about below? > > diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c > index d329f8b..94b60bd 100644 > --- a/drivers/scsi/scsi_pm.c > +++ b/drivers/scsi/scsi_pm.c > @@ -20,6 +20,9 @@ static int scsi_dev_type_suspend(struct device *dev, pm_message_t msg) > struct device_driver *drv; > int err; > > + if (pm_runtime_suspended(dev)) > + return 0; > + Something to be careful about is there are different types of suspend states (PMSG_*). IIUC, runtime PM is using PMSG_SUSPEND. Other states may or may not be compatible with PMSG_SUSPEND expectations, so you can skip suspend operation if the newly requested state is PMSG_SUSPEND but otherwise the controller needs to be woken up and told to comply to the new state. Thanks.
On Tue, 15 Nov 2011, Tejun Heo wrote: > On Tue, Nov 15, 2011 at 04:51:29PM +0800, Lin Ming wrote: > > > This is not the right approach. You should look instead at > > > scsi_dev_type_suspend() in scsi_pm.c. If the device is already runtime > > > suspended then the routine should return immediately. > > > > How about below? > > > > diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c > > index d329f8b..94b60bd 100644 > > --- a/drivers/scsi/scsi_pm.c > > +++ b/drivers/scsi/scsi_pm.c > > @@ -20,6 +20,9 @@ static int scsi_dev_type_suspend(struct device *dev, pm_message_t msg) > > struct device_driver *drv; > > int err; > > > > + if (pm_runtime_suspended(dev)) > > + return 0; > > + > > Something to be careful about is there are different types of suspend > states (PMSG_*). IIUC, runtime PM is using PMSG_SUSPEND. Other > states may or may not be compatible with PMSG_SUSPEND expectations, so > you can skip suspend operation if the newly requested state is > PMSG_SUSPEND but otherwise the controller needs to be woken up and > told to comply to the new state. That's right. Surprisingly enough (and contrary to what I wrote earlier), the sd_suspend() routine doesn't spin down a drive for runtime suspend. This probably should be considered a bug. Anyway, it looks like the correct approach would be more like this: static int scsi_bus_suspend_common(struct device *dev, pm_message_t msg) { int err = 0; - if (scsi_is_sdev_device(dev)) + if (scsi_is_sdev_device(dev)) { pm_runtime_resume(dev); err = scsi_dev_type_suspend(dev, msg); + } return err; } Alan Stern -- 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 Wed, 2011-11-16 at 00:08 +0800, Alan Stern wrote: > On Tue, 15 Nov 2011, Tejun Heo wrote: > > > On Tue, Nov 15, 2011 at 04:51:29PM +0800, Lin Ming wrote: > > > > This is not the right approach. You should look instead at > > > > scsi_dev_type_suspend() in scsi_pm.c. If the device is already runtime > > > > suspended then the routine should return immediately. > > > > > > How about below? > > > > > > diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c > > > index d329f8b..94b60bd 100644 > > > --- a/drivers/scsi/scsi_pm.c > > > +++ b/drivers/scsi/scsi_pm.c > > > @@ -20,6 +20,9 @@ static int scsi_dev_type_suspend(struct device *dev, pm_message_t msg) > > > struct device_driver *drv; > > > int err; > > > > > > + if (pm_runtime_suspended(dev)) > > > + return 0; > > > + > > > > Something to be careful about is there are different types of suspend > > states (PMSG_*). IIUC, runtime PM is using PMSG_SUSPEND. Other > > states may or may not be compatible with PMSG_SUSPEND expectations, so > > you can skip suspend operation if the newly requested state is > > PMSG_SUSPEND but otherwise the controller needs to be woken up and > > told to comply to the new state. > > That's right. Surprisingly enough (and contrary to what I wrote > earlier), the sd_suspend() routine doesn't spin down a drive for > runtime suspend. This probably should be considered a bug. > > Anyway, it looks like the correct approach would be more like this: Thanks. I think ata_port_suspend also needs to call pm_runtime_resume, as below. static int ata_port_suspend(struct device *dev) { struct ata_port *ap = to_ata_port(dev); int rc; pm_runtime_resume(dev); rc = ata_port_request_pm(ap, PMSG_SUSPEND, 0, ATA_EHI_QUIET, 1); return rc; } > > static int scsi_bus_suspend_common(struct device *dev, pm_message_t msg) > { > int err = 0; > > - if (scsi_is_sdev_device(dev)) > + if (scsi_is_sdev_device(dev)) { > pm_runtime_resume(dev); > err = scsi_dev_type_suspend(dev, msg); > + } > return err; > } > > Alan Stern > -- 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 Wed, 16 Nov 2011, Lin Ming wrote: > > > Something to be careful about is there are different types of suspend > > > states (PMSG_*). IIUC, runtime PM is using PMSG_SUSPEND. Other > > > states may or may not be compatible with PMSG_SUSPEND expectations, so > > > you can skip suspend operation if the newly requested state is > > > PMSG_SUSPEND but otherwise the controller needs to be woken up and > > > told to comply to the new state. > > > > That's right. Surprisingly enough (and contrary to what I wrote > > earlier), the sd_suspend() routine doesn't spin down a drive for > > runtime suspend. This probably should be considered a bug. > > > > Anyway, it looks like the correct approach would be more like this: > > Thanks. > > I think ata_port_suspend also needs to call pm_runtime_resume, as below. > > static int ata_port_suspend(struct device *dev) > { > struct ata_port *ap = to_ata_port(dev); > int rc; > > pm_runtime_resume(dev); > rc = ata_port_request_pm(ap, PMSG_SUSPEND, 0, ATA_EHI_QUIET, 1); > return rc; > } Maybe not. You know a lot more about the state of the ATA ports than you do about the state of the SCSI devices. If there's no difference in the port states for runtime suspend and system sleep then you don't have to power up the port just in order to power it down again. Alan Stern -- 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 d329f8b..94b60bd 100644 --- a/drivers/scsi/scsi_pm.c +++ b/drivers/scsi/scsi_pm.c @@ -20,6 +20,9 @@ static int scsi_dev_type_suspend(struct device *dev, pm_message_t msg) struct device_driver *drv; int err; + if (pm_runtime_suspended(dev)) + return 0; + err = scsi_device_quiesce(to_scsi_device(dev)); if (err == 0) { drv = dev->driver;