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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
