Re: common clock framework

[Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, May 05, 2012 at 10:44:17AM -0700, Turquette, Mike wrote:
> + Mark & Graeme (for audio/pmic perspective)

> >> Having clk_set_rate and clk_prepare both hold the same prepare_lock
> >> mutex seems suboptimal, but it is easy.  Having reentrant accesses to
> >> the clock tree is going to be hard...  I've spent some time thinking
> >> of ways to solve this, but I would appreciate suggestions.  I suspect
> >> the exact same case I'm describing above will affect many SoCs.

> > That's interesting. Here's another one: What will happen when Mark
> > attaches one of his i2c wolfson chips to a omap core and wants to test
> > his new clock driver? a clk_prepare on some clock on the wolfson chip
> > will trigger another clk_prepare inside the i2c driver.
> > So the reentrancy problem is not limited to prepare vs. set_rate.

This sounds pretty much expected - you'll also see similar things on
some SoCs where IPs for clocks might get clock gated when not in use and
reentrancy could crop up while exiting low power modes.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel