[PATCH 01/11] usb: chipidea: Add power management support

[peter.chen@freescale.com (Peter Chen)]

On Mon, Oct 14, 2013 at 12:01:08PM +0100, Russell King - ARM Linux wrote:
> On Sat, Oct 12, 2013 at 05:35:03PM +0800, Peter Chen wrote:
> > This commit adds runtime and system power management support for
> > chipidea core. The runtime pm support is controlled by glue
> > layer, it can be enabled by flag CI_HDRC_SUPPORTS_RUNTIME_PM.
> 
> Let's look at the locking.
> 
> 1. Runtime PM.  These callbacks are locked with a spinlock, which holds
>    dev->power.lock.  This lock is taken either with or without disabling
>    IRQs depending on whether runtime PM is IRQ safe or not.
> 
> 2. Normal PM.  These callbacks are locked by holding dev->mutex.
> 
> Now, there's a little bit of protection between these two operations -
> when normal PM places a device into a low power state, it 'gets' a
> reference on the runtime PM to ensure no runtime PM transitions occur
> while normal PM is active.  (See pm_runtime_get_noresume() in
> device_prepare().)  This is only dropped when the normal PM resumes the
> device.
> 
> Moreover, all runtime PM events are flushed before the suspend callback
> occurs (see the pm_runtime_barrier() in __device_suspend()).
> 
> What that means is that you can't receive any runtime PM events while
> you are in your suspend/resume callbacks.  So, each call is mutually
> exclusive.
> 
> So, runtime PM callbacks vs normal PM callbacks for any single device
> are all called with mutual exclusion - you won't have two running at
> any time.
> 
> Hence, for the reasons stated previously about the non-atomic nature of
> atomic_read()/atomic_set(), there's even more reasons that their use
> here is just mere obfuscation: the accesses to this state tracking
> variable is already guaranteed to be single-threaded by core code, so
> the use of atomic_read()/atomic_set() just adds additional needless
> confusion to this code.
> 

Many Thanks, Russell.

So, the lessons for this topic are:

- If one atomic variable's operation only includes one instruction like
atomic_read and atomic_set, it is not meaningful for using atomic
operation, we can just use bool instead of it.

- The runtime pm itself, normal pm itself, runtime pm and normal pm
are all already exclusion, we don't need protection for variables
who are only used at pm situation.

-- 

Best Regards,
Peter Chen