spi/pl022: Activate resourses before deactivate them in suspend

From: Ulf Hansson <[email protected]>

To be able to deactivate resourses in suspend, the resourses must first be surely active. This is done with a pm_runtime_get_sync. Once the resourses are restored to active state again in resume, the runtime pm usage count can be decreased with a pm_runtime_put.

Signed-off-by Ulf Hansson <[email protected]>

---
 drivers/spi/spi-pl022.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/spi/spi-pl022.c +3 -1

index 9194641..c3590e0 100644
@@ -2350,6 +2350,8 @@ static int pl022_suspend(struct device *dev)
                dev_warn(dev, "cannot suspend master\n");
                return ret;
        }
+
+       pm_runtime_get_sync(dev);
        pl022_suspend_resources(pl022);
 
        dev_dbg(dev, "suspended\n");

@@ -2362,6 +2364,7 @@ static int pl022_resume(struct device *dev)
        int ret;
 
        pl022_resume_resources(pl022);
+       pm_runtime_put(dev);
 
        /* Start the queue running */
        ret = spi_master_resume(pl022->master);
--

1.7.10

Hi Mark,

Just a kind remember on this. Do you see any problem merging this?

Kind regards
Ulf Hansson

On 5 October 2012 09:43, Ulf Hansson <[email protected]> wrote:

To be able to deactivate resourses in suspend, the resourses must first be surely active. This is done with a pm_runtime_get_sync. Once the resourses are restored to active state again in resume, the runtime pm usage count can be decreased with a pm_runtime_put.

Quoted 4 lines · Ulf Hansson

To be able to deactivate resourses in suspend, the resourses must first be surely active. This is done with a pm_runtime_get_sync. Once the resourses are restored to active state again in resume, the runtime pm usage count can be decreased with a pm_runtime_put.

The PM core will ensure devices are runtime resumed before we enter suspend precisely due to this sort of issue.

Quoted 9 lines · Mark Brown

Quoted 4 lines · Ulf Hansson

To be able to deactivate resourses in suspend, the resourses must first be surely active. This is done with a pm_runtime_get_sync. Once the resourses are restored to active state again in resume, the runtime pm usage count can be decreased with a pm_runtime_put.

The PM core will ensure devices are runtime resumed before we enter suspend precisely due to this sort of issue.

I asked the very same question to Ulf (in speech, sorry so you couldn't see it...)

So I guess we are talking about drivers/base/main.c

in device_prepare()
pm_runtime_get_noresume() is called

and in device_complete()
pm_runtime_put_sync() is called.

Both put into current for in
commit 88d26136a256576e444db312179e17af6dd0ea87
on sep 19th.

Yes it seems like it will do the job.

Ulf can you comment on this...

Yours,
Linus Walleij

Quoted 15 lines · Linus Walleij

Quoted 9 lines · Mark Brown

Quoted 4 lines · Ulf Hansson

To be able to deactivate resourses in suspend, the resourses must first be surely active. This is done with a pm_runtime_get_sync. Once the resourses are restored to active state again in resume, the runtime pm usage count can be decreased with a pm_runtime_put.

The PM core will ensure devices are runtime resumed before we enter suspend precisely due to this sort of issue.

I asked the very same question to Ulf (in speech, sorry so you couldn't see it...)

Quoted 4 lines

So I guess we are talking about drivers/base/main.c

in device_prepare()
pm_runtime_get_noresume() is called

This will increase the "usage_counter" for the device. It will not "runtime_resume" the device, though it will prevent it from being "runtime_suspended".

Quoted 16 lines · Ulf Hansson

Quoted 15 lines · Linus Walleij

Quoted 9 lines · Mark Brown

Quoted 4 lines · Ulf Hansson

To be able to deactivate resourses in suspend, the resourses must first be surely active. This is done with a pm_runtime_get_sync. Once the resourses are restored to active state again in resume, the runtime pm usage count can be decreased with a pm_runtime_put.

The PM core will ensure devices are runtime resumed before we enter suspend precisely due to this sort of issue.

I asked the very same question to Ulf (in speech, sorry so you couldn't see it...)

Quoted 8 lines

Quoted 4 lines

So I guess we are talking about drivers/base/main.c

in device_prepare()
pm_runtime_get_noresume() is called

This will increase the "usage_counter" for the device. It will not "runtime_resume" the device, though it will prevent it from being "runtime_suspended".

Indeed. The PM core does _not_ insure that devices are runtime resumed before going into system suspend. Some subsystems may do this (the PCI subsystem does, for example -- see drivers/pci/pci-driver.c:pci_pm_prepare()), but the PM core doesn't.

Alan Stern