Patchwork [v2,4/4] ata: add ata port runtime PM callbacks

login
register
mail settings
Submitter Lin Ming
Date Nov. 15, 2011, 8:51 a.m.
Message ID <1321347089.26084.2.camel@minggr>
Download mbox | patch
Permalink /patch/125707/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

Lin Ming - Nov. 15, 2011, 8:51 a.m.
On Mon, 2011-11-14 at 23:31 +0800, Alan Stern wrote:
> On Mon, 14 Nov 2011, Lin Ming wrote:
> 
> > Current patches has a bug that system suspend fails if ata port was
> > runtime suspended.
> > 
> > disk suspend issues sync cache and stop device commands that obviously
> > need ata port to be active. So we need to runtime resume ata port first.
> 
> This is wrong.  If the port is already suspended then so are all the 
> drives below the port.  Hence there is no need to sync the cache or 
> stop the device.

Ah, got it now!

> 
> > Alan, Tejun
> > 
> > How about below fix?
> > 
> > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> > index fa3a591..ebb87fbf 100644
> > --- a/drivers/scsi/sd.c
> > +++ b/drivers/scsi/sd.c
> > @@ -50,6 +50,7 @@
> >  #include <linux/string_helpers.h>
> >  #include <linux/async.h>
> >  #include <linux/slab.h>
> > +#include <linux/pm_runtime.h>
> >  #include <asm/uaccess.h>
> >  #include <asm/unaligned.h>
> >  
> > @@ -2762,6 +2763,14 @@ static int sd_suspend(struct device *dev, pm_message_t mesg)
> >  	if (!sdkp)
> >  		return 0;	/* this can happen */
> >  
> > +	/*
> > +	 * Resume parent device to handle sync cache and
> > +	 * stop device commands
> > +	 */
> > +	ret = pm_runtime_get_sync(dev->parent);
> > +	if (ret)
> > +		goto exit;
> > +
> >  	if (sdkp->WCE) {
> >  		sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
> >  		ret = sd_sync_cache(sdkp);
> 
> 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?



> 
> 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
Tejun Heo - Nov. 15, 2011, 2:54 p.m.
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.
Alan Stern - Nov. 15, 2011, 4:08 p.m.
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
Lin Ming - Nov. 16, 2011, 1:14 p.m.
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
Alan Stern - Nov. 16, 2011, 3:42 p.m.
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

Patch

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;