[PATCH V3] AMBA: Put devices into low-power state in suspend_noirq

[Russell King - ARM Linux]

On Wed, Nov 02, 2011 at 02:50:51PM +0100, Ulf Hansson wrote:
> Just some thinking, you may comment if you like....
>
> When using a power_domain this will then mean that the power domain  
> callbacks for suspend|resume should take similar actions as they do in  
> their runtime_suspend|resume callbacks to put the devices into low power  
> state. This should be in line of what you prefer?

If it is appropriate to cut the vcore for the device when in runtime
suspend state, then a driver itself has to explicitly do that.  vcore
handling is different from pclk handling because loss of vcore requires
the device to be reinitialized, whereas pclk does not.

> This will mean some duplicated code but at the same time give the device  
> driver full control and responsibility of putting its device in  
> low-power state.

It should not mean any duplicated code - if a driver itself wishes to call
its runtime suspend and resume handlers from its normal suspend/resume
handlers, that's a choice it can make (and it alone can make).  Again,
take a moment to think a little more about your original proposal of
pushing that into the bus layer.

And consider the case of a non-runtime PM system (where the runtime PM
callbacks are NULL) yet you have system suspend enabled, and you trigger
a system suspend.  Do you really want the suspend of the devices to be
skipped because the runtime PM callbacks were NULL because of system
configuration?

With them being explicit calls in the driver, this doesn't happen because
if you omit those functions for non-runtime PM, you'll get a link error.

> In parallel it would then also make sense to remove the pm_runtime  
> handling completely from the amba bus and let the pclk be fully runtime  
> handled from the device driver instead. Since it must handle it from  
> suspend anyway...

We know that it's safe to handle the pclk at the bus layer for normal
runtime PM as it causes no state loss.  We also know that throwing the
vcore handling in there is the wrong thing to do because it does cause
state loss and therefore needs proper handling at the driver level.

Hence, the bus code can take care of the pclk but not for vcore.

So, I don't see any reason to change the bus code.