Re: common clock framework
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.
Description: Digital signature
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[Linux ARM (vger)] [Linux ARM MSM] [Linux Omap] [Linux Arm] [Linux Tegra] [Fedora ARM] [eCos] [Linux Fastboot] [Gcc Help] [Git] [DCCP] [IETF Announce] [Security] [PDAs] [Linux] [Linux MIPS] [Yosemite Campsites] [Photos]