Hi On Wed, 12 Dec 2012, Jean Pihet wrote:
> On Sun, Dec 9, 2012 at 2:23 AM, Paul Walmsley <p...@pwsan.com> wrote: > > > Add a per-powerdomain spinlock. Use that instead of the clockdomain > > spinlock. Add pwrdm_lock()/pwrdm_unlock() functions to allow other > > code to acquire or release the powerdomain spinlock without reaching > > directly into the struct powerdomain. > > > Since clockdomains are part of powerdomains it seems weird for the > clockdomain code to take a powerdoamin lock. Why? > Is there a reason why the powerdomain could not take the lock before > calling the clockdomain functions? Do you mean "is there a reason why the powerdomain _code_ could not take the lock"? If so, the reason is that code other than the powerdomain code calls the clkdm_* functions directly, without calling any powerdomain functions first. So there's really no other place to take the lock unless the callers are updated to take the powerdomain lock themselves. That seems like something to avoid if the caller doesn't have any other relationship to the powerdomain code. > Also, are the lock and nolock version the clockdomain function needed? Did you have a different solution in mind? The two versions are used for code that needs to be called from two contexts: the first with the powerdomain's lock already held; the second needing to acquire the powerdomain's lock to avoid racing against other PRCM code. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
