Thread (80 messages) 80 messages, 20 authors, 2011-01-28

Re: Locking in the clk API

From: Ben Dooks <ben-linux@fluff.org>
Date: 2011-01-20 16:57:54
Also in: linux-arm-kernel, lkml

On 12/01/11 02:25, Paul Mundt wrote:
On Tue, Jan 11, 2011 at 05:54:42PM -0800, Saravana Kannan wrote:
quoted
On 01/11/2011 04:18 AM, Paul Mundt wrote:
quoted
Again, you are approaching it from the angle that an atomic clock is a
special requirement rather than the default behaviour. Sleeping for
lookup, addition, and deletion are all quite acceptable, but
enable/disable pairs have always been intended to be usable from atomic
context. Anyone that doesn't count on that fact is either dealing with
special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
implementing any sort of fine grained runtime power management for their
platform.
Paul,

I see you repeating this point a couple of times and I'm a bit confused 
how you handle the clock tree/dependencies.

Does your clock driver NOT hide the details of what root clock/PLL a 
branch clock is sourced from? If you do hide the details of the root/PLL 
source, how do you get the branch clk_enable() to be done atomically if 
the root/PLL enables are not possible in atomic context?

Is it simply a matter of your hardware having PLLs and root clocks that 
can be turned on/off quickly?
There are a few cases where PLL clocks would benefit from a clk_enable()
that can sleep, but for us these are almost all in the device space. Most
of the SoCs however have fairly straightforward clock topologies where
the root clock in question is an external oscillator that can't be
disabled, and anything chained below that sits behind a PLL divider or
multiplier bank that can likewise be adjusted atomically. The vast
majority of the clocks below that can likewise be trivially
enabled/disabled from atomic context.
All the Samsung SoCs have multiple PLLs as the root of their clock
trees, with some muxing options to feed in oscillator inputs. Many
of the systems I've seen have a 48MHz source for the USB, 12MHz
as a PLL source and then generate a pile of different frequencies for
various peripherals via the PLLs...

this is especially important for the cases where you need very specific
frequencies such as audio playback of tv encoding.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help