Hi Paul,

On 6/26/2011 11:34 PM, Paul Walmsley wrote:

Hi Rajendra, Todd,

On Fri, 10 Jun 2011, Rajendra Nayak wrote:

quoted

Paul/Benoit any thoughts on if a per-clkdm lock seems reasonable?

Sounds okay to me.

The experimental patch that you sent didn't add the locking to the *wkdep,
*sleepdep functions; I guess we'd better add it there at the same time,
since some of the register access there does a read-modify-write.

My initial idea was to just guard the functions which program the
target clockdomain state, since that's something which had a possibility
of racing.
For the sleepdep/wkupdep programming, I thought they are all done from
within frameworks and during pm-core init at boot and might not run into
concurrency issues. But maybe it makes sense to guard those as well.

It should be possible to get rid of the atomic_t usage in the clockdomain
code as part of the same series.

Sure, I'll get rid of those.

Thanks,
Rajendra

Todd, thanks for pointing this out.


- Paul