From mboxrd@z Thu Jan 1 00:00:00 1970 From: broonie@opensource.wolfsonmicro.com (Mark Brown) Date: Tue, 8 May 2012 10:01:46 +0100 Subject: common clock framework In-Reply-To: References: <20120504082110.GB16535@pengutronix.de> <20120505082840.GQ4141@pengutronix.de> Message-ID: <20120508090145.GG15893@opensource.wolfsonmicro.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: