From: broonie@opensource•wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists•infradead.org
Subject: common clock framework
Date: Tue, 8 May 2012 10:01:46 +0100 [thread overview]
Message-ID: <20120508090145.GG15893@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAJOA=zPozuanQFWt10PU4mySQ1kV+YV6iO5+BOfDWGPS2Y0aYg@mail.gmail.com>
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: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120508/d985f537/attachment.sig>
next prev parent reply other threads:[~2012-05-08 9:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 2:02 common clock framework Chao Xie
2012-05-04 8:21 ` Sascha Hauer
2012-05-04 8:45 ` Chao Xie
2012-05-04 9:15 ` Russell King - ARM Linux
2012-05-04 10:20 ` Sascha Hauer
2012-05-04 23:08 ` Turquette, Mike
2012-05-05 8:28 ` Sascha Hauer
2012-05-05 17:44 ` Turquette, Mike
2012-05-08 9:01 ` Mark Brown [this message]
2012-05-08 17:29 ` Turquette, Mike
[not found] ` <CAG9bXv=T7v_MBUOmCsp4n0SNmYY_DOEkhQXAp0rTGpdi6KkXNA@mail.gmail.com>
2012-05-06 23:49 ` Mike Turquette
2012-05-07 3:49 ` Raul Xiong
[not found] ` <AAD1C6EB06EE3649B35B7E026785068D1A74B2C256@SC-VEXCH2.marvell.com>
[not found] ` <A63A0DC671D719488CD1A6CD8BDC16CF1A0F044EB4@SC-VEXCH4.marvell.com>
[not found] ` <53612FE6B944314AAADB181E45A45B6413D3FF9F37@sc-vexch3.marvell.com>
2012-05-18 8:41 ` Chao Xie
2012-05-22 18:57 ` Mike Turquette
2012-05-22 19:11 ` Mike Turquette
2012-06-14 13:09 ` Lei Wen
[not found] <AAD1C6EB06EE3649B35B7E026785068D1A749F0DB6@SC-VEXCH2.marvell.com>
[not found] ` <CAJOA=zPAy3AV6Dg9sE+fro1ZCmbxeCH8aeR5-YqffZphRkUQMQ@mail.gmail.com>
[not found] ` <AAD1C6EB06EE3649B35B7E026785068D1A749F10CC@SC-VEXCH2.marvell.com>
2012-04-25 4:40 ` Turquette, Mike
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120508090145.GG15893@opensource.wolfsonmicro.com \
--to=broonie@opensource$(echo .)wolfsonmicro.com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox