On Mon, 5 Dec 2011, Russell King - ARM Linux wrote:
> On Mon, Dec 05, 2011 at 02:15:56PM -0700, Paul Walmsley wrote:
>
> > But I'd propose that we instead increase the size of struct clk.rate to be
> > s64:
> >
> > s64 clk_round_rate(struct clk *clk, s64 desired_rate);
> > int clk_set_rate(struc
On Mon, 5 Dec 2011, Paul Walmsley wrote:
> For example, here's a trivial implementation for rate recalculation for a
> integer divider clock node (that can't be handled with a right shift):
>
> s64 div(struct clk *clk, u32 div) {
> if (clk->flags & CLK_PARENT_RATE_MAX_U32)
>
On Mon, Dec 05, 2011 at 02:15:56PM -0700, Paul Walmsley wrote:
> The types associated with clock rates in the clock interface
> (include/linux/clk.h) are inconsistent, and we should fix this.
Rubbish. They're different with good reason. Rates are primerily
unsigned quantities - and should be t
On Mon, Nov 21, 2011 at 5:40 PM, Mike Turquette wrote:
> +/**
> + * clk_get_parent - return the parent of a clk
> + * @clk: the clk whose parent gets returned
> + *
> + * Simply returns clk->parent. It is up to the caller to hold the
> + * prepare_lock, if desired. Returns NULL if clk is NULL.
>
Hi
a brief comment concerning clock rates:
On Mon, 21 Nov 2011, Mike Turquette wrote:
> +unsigned long clk_get_rate(struct clk *clk)
...
> +long clk_round_rate(struct clk *clk, unsigned long rate)
...
> +int clk_set_rate(struct clk *clk, unsigned long rate)
...
> +struct clk {
...
> +
Hello,
On Fri, Dec 02, 2011 at 08:23:06PM +, Russell King - ARM Linux wrote:
> On Fri, Dec 02, 2011 at 10:13:10AM -0700, Paul Walmsley wrote:
> > Hi Russell,
> >
> > On Thu, 1 Dec 2011, Russell King - ARM Linux wrote:
> >
> > > On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
>
Hi Russell,
On Thu, 1 Dec 2011, Russell King - ARM Linux wrote:
> On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> > 1. When a clock user calls clk_enable() on a clock, the clock framework
> > should prevent other users of the clock from changing the clock's rate.
> > This shou
On Thu, 1 Dec 2011, Russell King - ARM Linux wrote:
> On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:
> > The intention behind the clk_{allow,block}_rate_change() proposal was to
> > allow the current user of the clock to change its rate without having to
> > call clk_{allow,block
On Fri, Dec 02, 2011 at 10:13:10AM -0700, Paul Walmsley wrote:
> Hi Russell,
>
> On Thu, 1 Dec 2011, Russell King - ARM Linux wrote:
>
> > On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> > > 1. When a clock user calls clk_enable() on a clock, the clock framework
> > > should pre
Hi Mark,
On Thu, 1 Dec 2011, Mark Brown wrote:
> On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:
>
> > Clock rate/parent-change notifiers are requirements for DVFS use-cases,
> > and they must be paired with something like the
> > clk_{allow,block}_rate_change() functions to wor
On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:
> The intention behind the clk_{allow,block}_rate_change() proposal was to
> allow the current user of the clock to change its rate without having to
> call clk_{allow,block}_rate_change(), if that driver was the sole user of
> the c
On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:
> So for example, if you had a driver that did:
> c = clk_get(dev, clk_name);
> clk_enable(c);
> clk_set_rate(c, clk_rate);
> and c was currently not enabled by any other driver on the system, and
> nothing else had called clk_block
On Thu, Dec 1, 2011 at 6:42 AM, Mark Brown
wrote:
> On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:
>
>> Clock rate/parent-change notifiers are requirements for DVFS use-cases,
>> and they must be paired with something like the
>> clk_{allow,block}_rate_change() functions to work ef
On Wed, Nov 30, 2011 at 11:39:59PM -0700, Paul Walmsley wrote:
> Clock rate/parent-change notifiers are requirements for DVFS use-cases,
> and they must be paired with something like the
> clk_{allow,block}_rate_change() functions to work efficiently. I intend
> to comment on this later; it's
Hi Mike
a few brief comments.
On Wed, 30 Nov 2011, Turquette, Mike wrote:
> Likewise when a clk is requested to transition to a new frequency it
> will have to clear it with all of the clks below it, so there is still
> a need to propagate a request throughout the clk tree whenever
> clk_set_rat
Hello,
Here are some initial comments on clk_get_rate().
On Mon, 21 Nov 2011, Mike Turquette wrote:
> +/**
> + * clk_get_rate - return the rate of clk
> + * @clk: the clk whose rate is being returned
> + *
> + * Simply returns the cached rate of the clk. Does not query the hardware.
> If
> +
Hi
a few initial comments on clk_get_parent().
On Mon, 21 Nov 2011, Mike Turquette wrote:
> +/**
> + * clk_get_parent - return the parent of a clk
> + * @clk: the clk whose parent gets returned
> + *
> + * Simply returns clk->parent. It is up to the caller to hold the
> + * prepare_lock, if des
On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> 1. When a clock user calls clk_enable() on a clock, the clock framework
> should prevent other users of the clock from changing the clock's rate.
> This should persist until the clock user calls clk_disable() (but see also
> #2 be
On Wed, Nov 30, 2011 at 5:20 PM, Paul Walmsley wrote:
> This implementation of clk_get_rate() is racy, and is, in general, unsafe.
> The problem is that, in many cases, the clock's rate may change between
> the time that clk_get_rate() is called and the time that the returned
> rate is used. This
On Sat, Nov 26, 2011 at 5:22 AM, Shawn Guo wrote:
> On Mon, Nov 21, 2011 at 05:40:45PM -0800, Mike Turquette wrote:
>> + * To prevent this consider setting the CLK_GATE_SET_RATE flag on any
>> + * clk where you also set the CLK_PARENT_SET_RATE flag
>
> Eh, this is how flag CLK_GATE_SET_RATE is bor
On Mon, Nov 21, 2011 at 05:40:45PM -0800, Mike Turquette wrote:
[...]
> +/**
> + * DOC: Using the CLK_PARENT_SET_RATE flag
> + *
> + * __clk_set_rate changes the child's rate before the parent's to more
> + * easily handle failure conditions.
> + *
> + * This means clk might run out of spec for a s
On Tue, Nov 22, 2011 at 7:12 PM, Saravana Kannan wrote:
> On 11/21/2011 05:40 PM, Mike Turquette wrote:
>> +void __clk_unprepare(struct clk *clk)
>> +{
>> + if (!clk)
>> + return;
>> +
>> + if (WARN_ON(clk->prepare_count == 0))
>> + return;
>> +
>> + i
On 11/21/2011 05:40 PM, Mike Turquette wrote:
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
new file mode 100644
index 000..12c9994
--- /dev/null
+++ b/drivers/clk/clk.c
@@ -0,0 +1,538 @@
+/*
+ * Copyright (C) 2010-2011 Canonical Ltd
+ * Copyright (C) 2011 Linaro Ltd
+ *
+ * This program
23 matches
Mail list logo
