On 20120506-22:08, Mike Turquette wrote:
> Hi all,
>
> These five patches are hopefully the final set of core framework changes
> for 3.5. There is the obligatory MAINTAINERS file change, three new
> fixes and the fixed-factor clock patch. That last patch is being
> reposted since three bugs were
On Tue, May 8, 2012 at 9:12 AM, Shawn Guo wrote:
> On Sun, May 06, 2012 at 10:08:25PM -0700, Mike Turquette wrote:
>> If no one complains about these then I'll commit them to clk-next and
>> (finally) send my pull request to Arnd.
>>
> On mach-mxs:
>
> Tested-by: Shawn Guo
>
> Mike,
>
> I haven't
On Mon, May 7, 2012 at 12:54 PM, Saravana Kannan wrote:
> On 05/06/2012 10:08 PM, Mike Turquette wrote:
>> From: Sascha Hauer
>> +struct clk *clk_register_fixed_factor(struct device *dev, const char
>> *name,
>> + const char *parent_name, unsigned long flags,
>> + unsig
On Mon, May 7, 2012 at 12:58 AM, Sascha Hauer wrote:
> On Sun, May 06, 2012 at 10:08:27PM -0700, Mike Turquette wrote:
>> Patch 'clk: always pass parent_rate into .round_rate' made a subtle
>> change to the semantics of .round_rate. It is now expected for the
>> parent's rate to always be passed
On Mon, Apr 16, 2012 at 6:46 PM, Shawn Guo wrote:
> On 17 April 2012 07:10, Turquette, Mike wrote:
> ...
>> Yes, this was a braindead change on my part. I'll remove the kstrdup
>> in my next series (the rest of this patch will stay in).
>>
> Do you have an ETA
On Mon, Apr 16, 2012 at 1:52 PM, Sascha Hauer wrote:
> On Wed, Apr 11, 2012 at 06:02:51PM -0700, Mike Turquette wrote:
>> This patch is the basic clk version of 'clk: core: copy parent_names &
>> return error codes'.
>>
>> The registration functions are changed to allow the core code to copy
>> th
On Wed, Apr 11, 2012 at 11:49 PM, Shawn Guo wrote:
> On Wed, Apr 11, 2012 at 06:02:51PM -0700, Mike Turquette wrote:
> ...
>> @@ -175,23 +188,32 @@ struct clk *clk_register_divider(struct device *dev,
>> const char *name,
>> div->flags = clk_divider_flags;
>> div->lock = lock;
>>
>> +
On Mon, Apr 16, 2012 at 1:30 PM, Sascha Hauer wrote:
> On Wed, Apr 11, 2012 at 06:02:50PM -0700, Mike Turquette wrote:
>> struct clk *clk_register(struct device *dev, const char *name,
>> const struct clk_ops *ops, struct clk_hw *hw,
>> const char **parent_names, u8 nu
On Wed, Apr 11, 2012 at 11:14 PM, Viresh Kumar wrote:
> On 4/12/2012 6:32 AM, Mike Turquette wrote:
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 3ed36d3..4daacf5 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -194,7 +194,7 @@ static int __init clk_debug_init(v
On Wed, Apr 11, 2012 at 9:28 PM, Viresh Kumar wrote:
> On 4/12/2012 6:32 AM, Mike Turquette wrote:
>> - * If clk has the CLK_SET_RATE_GATE flag set and it is enabled this call
>> - * will fail; only when the clk is disabled will it be able to change
>> - * its rate.
>
> Why is CLK_SET_RATE_GATE re
On Fri, Apr 13, 2012 at 2:21 AM, Mark Brown
wrote:
> On Wed, Apr 11, 2012 at 06:02:38PM -0700, Mike Turquette wrote:
>> This series collects many of the fixes posted for the recently merged
>> common clock framework as well as some general clean-up. Most of the
>> code classifies as a clean-up mo
On Wed, Mar 28, 2012 at 3:25 PM, Saravana Kannan wrote:
> On 03/28/2012 10:08 AM, Turquette, Mike wrote:
>> On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannan
>> wrote:
>>> I think there is still a problem with not being able to differentiate
>>> between pre-cha
On Tue, Mar 27, 2012 at 8:06 PM, Saravana Kannan wrote:
> On 03/23/2012 04:28 PM, Turquette, Mike wrote:
>> On Fri, Mar 23, 2012 at 4:04 PM, Saravana Kannan
>> wrote:
>>> On 03/23/2012 03:32 PM, Turquette, Mike wrote:
>>> How does a child (or grand child) cl
On Fri, Mar 23, 2012 at 4:04 PM, Saravana Kannan wrote:
> On 03/23/2012 03:32 PM, Turquette, Mike wrote:
>> .recalc_rate serves two purposes: first it recalculates the rate after
>> the rate has changed and you pass in a new parent_rate argument. The
>> second purpose is
On Fri, Mar 23, 2012 at 3:12 PM, Saravana Kannan wrote:
> On 03/23/2012 02:39 PM, Turquette, Mike wrote:
>> __clk_recalc_rates is called by __clk_reparent which is called by
>> clk_set_parent. __clk_recalc_rates is also called by clk_set_rate.
>>
>> Does this not hand
On Fri, Mar 23, 2012 at 2:33 PM, Saravana Kannan wrote:
> On 03/20/2012 08:10 PM, Saravana Kannan wrote:
>>
>> On 03/20/2012 04:53 PM, Turquette, Mike wrote:
>>>
>>> It does make me
>>> wonder if it would be a good idea to pass in the parent rate
On Tue, Mar 20, 2012 at 10:46 AM, Saravana Kannan
wrote:
> On Tue, March 20, 2012 7:02 am, Shawn Guo wrote:
>> On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote:
>> ...
>>> +struct clk_ops {
>>> + int (*prepare)(struct clk_hw *hw);
>>> + void (*unprepare)(
On Tue, Mar 20, 2012 at 7:02 AM, Shawn Guo wrote:
> On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote:
> ...
>> +struct clk_ops {
>> + int (*prepare)(struct clk_hw *hw);
>> + void (*unprepare)(struct clk_hw *hw);
>> + int (*enable)(struct
On Mon, Mar 19, 2012 at 4:22 AM, Rajendra Nayak wrote:
> On Friday 16 March 2012 11:41 AM, Mike Turquette wrote:
>> +/*
>> + * calculate the new rates returning the topmost clock that has to be
>> + * changed.
>> + */
>> +static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long
>> rate
On Mon, Mar 19, 2012 at 12:13 PM, Saravana Kannan
wrote:
> I saw some responses from you over the weekend but not to mine. So, I
> assumed you were busy with other stuff and I started working on a patch on
> top of v7.
I only answer trivial emails on the weekend ;-)
> I will send that out if I g
On Mon, Mar 19, 2012 at 4:28 AM, Sascha Hauer wrote:
> On Mon, Mar 19, 2012 at 04:52:05PM +0530, Rajendra Nayak wrote:
>> Hi Mike,
>>
>> >+/*
>> >+ * calculate the new rates returning the topmost clock that has to be
>> >+ * changed.
>> >+ */
>> >+static struct clk *clk_calc_new_rates(struct clk *
On Sun, Mar 18, 2012 at 7:07 AM, Shawn Guo wrote:
> Another trivial comment. But if there is an incremental patch, maybe
> consider to include it.
>
> On Thu, Mar 15, 2012 at 11:11:19PM -0700, Mike Turquette wrote:
> ...
>> +#ifdef CONFIG_COMMON_CLK_DISABLE_UNUSED
>> +static int clk_disable_unuse
On Sun, Mar 18, 2012 at 6:46 AM, Shawn Guo wrote:
> Reading the documentation of function clk_set_rate(), I'm not sure
> it exactly matches what the code does.
>
> If there is mismatch, it might be worth sending an incremental patch
> to update the documentation and avoid the confusion?
The clk_s
On Fri, Mar 16, 2012 at 8:28 PM, Saravana Kannan wrote:
> On 03/15/2012 11:11 PM, Mike Turquette wrote:
>>
>> The common clock framework defines a common struct clk useful across
>> most platforms as well as an implementation of the clk api that drivers
>> can use safely for managing clocks.
>>
>>
On Sat, Mar 17, 2012 at 2:05 AM, Arnd Bergmann wrote:
> On Friday 16 March 2012, Turquette, Mike wrote:
>> On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley wrote:
>> > From: Paul Walmsley
>> > Date: Fri, 16 Mar 2012 16:06:30 -0600
>> > Subject: [PAT
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley wrote:
> From: Paul Walmsley
> Date: Fri, 16 Mar 2012 16:06:30 -0600
> Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
>
> Mark the common clk code as depending on CONFIG_EXPERIMENTAL. The API
> is not well-defined and both it
On Fri, Mar 16, 2012 at 1:57 PM, Arnd Bergmann wrote:
> On Friday 16 March 2012, Arnd Bergmann wrote:
>> >
>> > Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so
>> > that platform ports can gather speed? Several people are waiting for a
>> > somewhat stable version before startin
On Fri, Mar 16, 2012 at 5:25 AM, Richard Zhao wrote:
> [...]
>> +static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
>> + unsigned long *best_parent_rate)
>> +{
>> + struct clk_divider *divider = to_clk_divider(hw);
>> + int i, bestdiv = 0;
>> + unsigned l
On Thu, Mar 15, 2012 at 2:43 AM, Sascha Hauer wrote:
> On Wed, Mar 14, 2012 at 05:51:48PM -0700, Turquette, Mike wrote:
>> @@ -84,9 +78,9 @@ static int clk_divider_bestdiv(struct clk_hw *hw,
>> unsigned long rate,
>>
>> for (i = 1; i <= maxdiv; i++)
On Tue, Mar 13, 2012 at 5:05 AM, Sascha Hauer wrote:
> On Mon, Mar 12, 2012 at 08:16:36PM -0700, Turquette, Mike wrote:
>> On Mon, Mar 12, 2012 at 4:51 AM, Sascha Hauer wrote:
>> > I tried another
>> > approach on the weekend which basically does not try to do all in
On Wed, Mar 14, 2012 at 2:28 PM, Thomas Gleixner wrote:
> On Wed, 14 Mar 2012, Turquette, Mike wrote:
>
> Could you folks please trim your replies? It's annoying to page down a
> gazillion of lines to find the gist.
Sure. My mailer does this for me so I forget to do it someti
On Wed, Mar 14, 2012 at 1:48 AM, Sascha Hauer wrote:
> On Tue, Mar 13, 2012 at 04:43:57PM -0700, Turquette, Mike wrote:
>> On Tue, Mar 13, 2012 at 4:24 AM, Sascha Hauer wrote:
>> > On Sat, Mar 03, 2012 at 12:29:00AM -0800, Mike Turquette wrote:
>> >> The common cl
On Mon, Mar 5, 2012 at 1:22 AM, Richard Zhao wrote:
> Hi Mike,
Hi Richard,
Sorry for missing this earlier. I've taken in most of your
suggestions and commented on some of them below. Any of your feedback
that I cut from this mail was taken in as a fix in v7 :-)
> On Sat, Mar 03, 2012 at 12:29
On Tue, Mar 13, 2012 at 4:24 AM, Sascha Hauer wrote:
> On Sat, Mar 03, 2012 at 12:29:00AM -0800, Mike Turquette wrote:
>> The common clock framework defines a common struct clk useful across
>> most platforms as well as an implementation of the clk api that drivers
>> can use safely for managing c
On Tue, Mar 13, 2012 at 2:48 PM, Rob Herring wrote:
> Mike,
>
> On 03/10/2012 01:54 AM, Mike Turquette wrote:
>> The common clock framework defines a common struct clk useful across
>> most platforms as well as an implementation of the clk api that drivers
>> can use safely for managing clocks.
>>
On Mon, Mar 12, 2012 at 4:51 AM, Sascha Hauer wrote:
> On Sun, Mar 11, 2012 at 02:24:46PM -0700, Turquette, Mike wrote:
>> On Sun, Mar 11, 2012 at 4:34 AM, Sascha Hauer wrote:
>> > Hi Mike,
>> >
>> > I was about to give my tested-by when I decide
On Mon, Mar 12, 2012 at 1:18 PM, Rob Herring wrote:
> On 03/10/2012 01:54 AM, Mike Turquette wrote:
>> Many platforms support simple gateable clocks, fixed-rate clocks,
>> adjustable divider clocks and multi-parent multiplexer clocks.
>>
>> This patch introduces basic clock types for the above-men
On Sun, Mar 11, 2012 at 4:34 AM, Sascha Hauer wrote:
> Hi Mike,
>
> I was about to give my tested-by when I decided to test the set_rate
> function. Unfortunately this is broken for several reasons. I'll try
> to come up with a fixup series later the day.
I haven't tested clk_set_rate since V4, b
On Sat, Mar 10, 2012 at 11:52 PM, Richard Zhao wrote:
> Looks like you didn't take my comments for v5.
> http://www.spinics.net/lists/arm-kernel/msg162903.html
Sorry Richard, that one slipped through the cracks. I'll publish a
new version tomorrow with some of those fixes. Some of the others
(s
On Mon, Mar 5, 2012 at 2:17 AM, Andrew Lunn wrote:
>> > I think i can wrap your simple gate clock, to make my "complex" gate
>> > clock. What would help is if you would EXPORT_SYMBOL_GPL
>> > clk_gate_enable() and clk_gate_disable(), since they do exactly what i
>> > want. I can then build my own
On Wed, Mar 7, 2012 at 1:20 PM, Sascha Hauer wrote:
> On Sat, Mar 03, 2012 at 12:29:01AM -0800, Mike Turquette wrote:
>> +struct clk *clk_register_divider(struct device *dev, const char *name,
>> + const char *parent_name, unsigned long flags,
>> + void __iomem *reg, u8 shi
On Thu, Mar 8, 2012 at 6:34 PM, Richard Zhao wrote:
> Hello Mike,
>
> The main interface for clk implementer is to register clocks dynamically.
> I think it highly depends on clk DT bindings. From the patch Grant sent
> out, it looks like he doesn't like one node per clk. So how do we
> register c
On Thu, Mar 8, 2012 at 11:57 PM, Andrew Lunn wrote:
>> I'd say use the nonstatic ones. I think using the static initializers
>> will cause us much pain in the future. I've been through several rebases
>> on the i.MX clock rework and everytime I wish my sed foo would be
>> better. Now imagine what
On Wed, Mar 7, 2012 at 10:27 PM, Andrew Lunn wrote:
>> Assuming that some day OMAP code can be refactored to allow for lazy
>> (or at least initcall-based) registration of clocks then perhaps your
>> suggestion can take root. Which leads me to this question: are there
>> any other platforms out t
On Tue, Mar 6, 2012 at 11:00 AM, Sascha Hauer wrote:
> On Mon, Mar 05, 2012 at 12:03:15PM -0800, Turquette, Mike wrote:
>> On Sun, Mar 4, 2012 at 11:38 PM, Sascha Hauer wrote:
>> > On Sun, Mar 04, 2012 at 04:12:21PM -0800, Turquette, Mike wrote:
>> >> >>
&
On Sun, Mar 4, 2012 at 11:38 PM, Sascha Hauer wrote:
> On Sun, Mar 04, 2012 at 04:12:21PM -0800, Turquette, Mike wrote:
>> >>
>> >> I believe this patch already does what you suggest, but I might be
>> >> missing your point.
>> >
>> > In
On Sun, Mar 4, 2012 at 6:04 PM, Richard Zhao wrote:
> On Sat, Mar 03, 2012 at 12:28:59AM -0800, Mike Turquette wrote:
>> The common clk framework provides clk_prepare and clk_unprepare
>> implementations. Create an entry for HAVE_CLK_PREPARE so that
>> COMMON_CLK can select it.
>>
>> Signed-off-b
On Sun, Mar 4, 2012 at 12:33 PM, Andrew Lunn wrote:
> From 71e9a676b2b2f0dc2bb0cc395e8325cf38f4808b Mon Sep 17 00:00:00 2001
> From: Andrew Lunn
> Date: Sun, 4 Mar 2012 16:31:14 +0100
> Subject: [PATCH] [clk] Fix compile errors in DEFINE_CLK_GATE()
>
> Signed-off-by: Andrew Lunn
Thanks Andrew.
On Sun, Mar 4, 2012 at 9:42 AM, Andrew Lunn wrote:
> On Sat, Mar 03, 2012 at 12:29:01AM -0800, Mike Turquette wrote:
>> Many platforms support simple gateable clocks, fixed-rate clocks,
>> adjustable divider clocks and multi-parent multiplexer clocks.
>>
>> This patch introduces basic clock types
On Sun, Mar 4, 2012 at 6:35 AM, Andrew Lunn wrote:
>> +#define DEFINE_CLK_GATE(_name, _parent_name, _parent_ptr, \
>> + _flags, _reg, _bit_idx, \
>> + _gate_flags, _lock) \
>> + static struct clk _name;
On Sun, Mar 4, 2012 at 3:52 AM, Sascha Hauer wrote:
> On Sat, Mar 03, 2012 at 09:14:43AM -0800, Turquette, Mike wrote:
>> On Sat, Mar 3, 2012 at 5:31 AM, Sascha Hauer wrote:
>> > On Sat, Mar 03, 2012 at 12:29:00AM -0800, Mike Turquette wrote:
>> >> The common cl
On Sat, Mar 3, 2012 at 5:31 AM, Sascha Hauer wrote:
> On Sat, Mar 03, 2012 at 12:29:00AM -0800, Mike Turquette wrote:
>> The common clock framework defines a common struct clk useful across
>> most platforms as well as an implementation of the clk api that drivers
>> can use safely for managing cl
On Tue, Feb 28, 2012 at 3:33 PM, Rob Lee wrote:
>>
>> I brought this topic up internally and Jon suggested that the 'usage'
>> statistics that are reported in sysfs should also reflect failed
>> versus successful C-state transitions, which is a great idea. This
>> could simply be achieved by rena
On Tue, Feb 28, 2012 at 7:50 AM, Rob Lee wrote:
> On Mon, Feb 27, 2012 at 6:49 PM, Turquette, Mike wrote:
>> On Sun, Feb 26, 2012 at 8:47 PM, Robert Lee wrote:
>>> +/**
>>> + * cpuidle_enter_wrap - performing timekeeping and irq around enter
>>> funct
On Sun, Feb 26, 2012 at 8:47 PM, Robert Lee wrote:
> +/**
> + * cpuidle_enter_wrap - performing timekeeping and irq around enter function
> + * @dev: pointer to a valid cpuidle_device object
> + * @drv: pointer to a valid cpuidle_driver object
> + * @index: index of the target cpuidle state.
> + *
On Sun, Feb 26, 2012 at 8:47 PM, Robert Lee wrote:
> +/**
> + * cpuidle_enter_wrap - performing timekeeping and irq around enter function
> + * @dev: pointer to a valid cpuidle_device object
> + * @drv: pointer to a valid cpuidle_driver object
> + * @index: index of the target cpuidle state.
> + *
On Sat, Feb 4, 2012 at 5:36 PM, Colin Cross wrote:
> On Sat, Feb 4, 2012 at 2:06 PM, Turquette, Mike wrote:
>> On Sat, Feb 4, 2012 at 11:02 AM, Colin Cross wrote:
>>> What's the point of the pre_enter call? This seems very similar to
>>> the prepare call that
On Sat, Feb 4, 2012 at 11:02 AM, Colin Cross wrote:
> On Tue, Jan 31, 2012 at 7:00 PM, Robert Lee wrote:
>> Make necessary changes to add implement time keepign and irq enabling
> keeping
>> in the core cpuidle code. This will allow the remove of these
>> functionalities from the platform cpuidl
On Fri, Jan 13, 2012 at 8:18 PM, Saravana Kannan wrote:
> On 12/17/2011 03:04 AM, Russell King - ARM Linux wrote:
>>
>> On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
>>>
>>> On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner
>>>
On Thu, Jan 5, 2012 at 6:31 AM, Amit Kucheria wrote:
> Tiny, tiny typo...
>
> On 11 Dec 13, Mike Turquette wrote:
>
>> +clk_set_rate deserves a special mention because it is more complex than
>> +the other operations. There are three key concepts to the common
>> +clk_set_rate implementation:
>>
On Wed, Jan 4, 2012 at 6:11 PM, Rob Herring wrote:
> On 01/04/2012 07:01 PM, Turquette, Mike wrote:
>> On Wed, Jan 4, 2012 at 6:32 AM, Rob Herring wrote:
>>> On 01/03/2012 08:15 PM, Richard Zhao wrote:
>>>> On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mi
On Wed, Jan 4, 2012 at 6:32 AM, Rob Herring wrote:
> On 01/03/2012 08:15 PM, Richard Zhao wrote:
>> On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
>>> On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner wrote:
>>>> On Tue, 13 Dec 2011,
On Tue, Dec 13, 2011 at 9:15 PM, Ryan Mallon wrote:
> On 14/12/11 14:53, Mike Turquette wrote:
>
>> Many platforms support simple gateable clks and fixed-rate clks that
>> should not be re-implemented by every platform.
>>
>> This patch introduces a gateable clk with a common programming model of
On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner wrote:
> On Tue, 13 Dec 2011, Mike Turquette wrote:
>> +void __clk_unprepare(struct clk *clk)
>> +{
>> + if (!clk)
>> + return;
>> +
>> + if (WARN_ON(clk->prepare_count == 0))
>> + return;
>> +
>> + if (--clk->pre
On Tue, Dec 13, 2011 at 8:52 PM, Ryan Mallon wrote:
> On 14/12/11 14:53, Mike Turquette wrote:
>> +void __clk_unprepare(struct clk *clk)
>> +{
>> + if (!clk)
>> + return;
>> +
>> + if (WARN_ON(clk->prepare_count == 0))
>> + return;
>> +
>> + if (--clk->prepare_c
On Tue, Dec 13, 2011 at 8:27 PM, Paul Walmsley wrote:
> Hi
>
> On Tue, 13 Dec 2011, Mike Turquette wrote:
>
>> omap_clk_get_by_name must die.
>
> You do realize that it exists for a reason? That hardware clock names
> don't have anything to do with the Linux device model?
We have a tree structur
On Tue, Dec 13, 2011 at 7:53 PM, Mike Turquette wrote:
> From: Mike Turquette
>
> The common clk framework is an attempt to define a generic struct clk
> which most platforms can use to build a clk tree and perform a set of
> well-defined operations.
Forgot to mention: these patches are based on
On Mon, Dec 12, 2011 at 11:47 AM, Andrew Lunn wrote:
> Hi Mike
>
> +int clk_register_gate(struct device *dev, const char *name, unsigned long
> flags,
> + struct clk *fixed_parent, void __iomem *reg, u8
> bit_idx,
> + int set_to_enab
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.
>
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 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:48 AM, Shawn Guo wrote:
> On Mon, Nov 21, 2011 at 05:40:46PM -0800, Mike Turquette wrote:
>> Many platforms support simple gateable clks and fixed-rate clks that
>> should not be re-implemented by every platform.
>>
>> This patch introduces a gateable clk with a common pr
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 Sat, Nov 26, 2011 at 12:47 AM, Shawn Guo wrote:
> On Wed, Nov 23, 2011 at 12:33:47PM -0800, Turquette, Mike wrote:
>> On Tue, Nov 22, 2011 at 6:03 PM, Saravana Kannan
>> wrote:
>> > On 11/21/2011 05:40 PM, Mike Turquette wrote:
>> > No strong opinion, but can
On Fri, Nov 25, 2011 at 11:06 PM, Shawn Guo wrote:
> On Mon, Nov 21, 2011 at 05:40:42PM -0800, Mike Turquette wrote:
>> .speaking of which, clk_set_rate has been overhauled and is now
>> recursive. *collective groan*. clk_set_rate is still simple for the
>> common case of simply setting a singl
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 Tue, Nov 22, 2011 at 7:48 PM, Saravana Kannan wrote:
> On 11/22/2011 11:13 AM, Greg KH wrote:
>>
>> On Tue, Nov 22, 2011 at 09:57:41AM -0800, Mike Turquette wrote:
Ah, comments like this warm my heart.
Come on, no abusing the kobject code please, if have problems with how
>>
On Tue, Nov 22, 2011 at 6:03 PM, Saravana Kannan wrote:
> On 11/21/2011 05:40 PM, Mike Turquette wrote:
>> +Below is the common struct clk definition from include/linux.clk.h. It
>
> Typo
Will fix in V4.
>
>> +is modified slightly for brevity:
>> +
>> +struct clk {
>> + const char
On Tue, Nov 22, 2011 at 12:02 PM, Arnd Bergmann wrote:
> On Tuesday 22 November 2011 12:19:51 Grant Likely wrote:
>> On Tue, Nov 22, 2011 at 11:01 AM, Mike Turquette
>> wrote:
>>
>> > Others have requested to have knobs made available for actually
>> > performing clk_enable/clk_disable and even
On Sun, Oct 23, 2011 at 7:30 AM, Shawn Guo wrote:
> On Thu, Sep 22, 2011 at 03:26:58PM -0700, Mike Turquette wrote:
>> From: Jeremy Kerr
>> +/* Base clock implementations. Platform clock implementations can use these
>> + * directly, or 'subclass' as approprate */
>> +
> /*
> * Multiple lines co
On Sun, Oct 23, 2011 at 7:24 AM, Shawn Guo wrote:
> On Thu, Sep 22, 2011 at 03:26:57PM -0700, Mike Turquette wrote:
>> From: Jeremy Kerr
> [...]
>
>> + * @set_rate Change the rate of this clock. If this callback returns
>> + * CLK_SET_RATE_PROPAGATE, the rate change will be propagated t
On Sun, Oct 23, 2011 at 5:55 AM, Shawn Guo wrote:
> Hi Mike,
>
> Some random comments/nits ...
Thanks for reviewing Shawn. Will roll changes into V3.
Regards,
Mike
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailma
On Sun, Oct 16, 2011 at 11:42 PM, Richard Zhao wrote:
> On Sun, Oct 16, 2011 at 08:26:49PM +0200, Sascha Hauer wrote:
>> On Wed, Oct 12, 2011 at 07:59:19AM -0700, Turquette, Mike wrote:
>> > On Tue, Oct 11, 2011 at 11:46 PM, Richard Zhao
>> > wrote:
>> >
On Fri, Oct 14, 2011 at 7:24 PM, Richard Zhao wrote:
> On Fri, Oct 14, 2011 at 11:14:19AM -0700, Turquette, Mike wrote:
>> On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette wrote:
>> unsigned long omap_recalc_rate(struct clk_hw *hw)
>> {
>> struct clk *parent;
&g
On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette wrote:
> From: Jeremy Kerr
> struct clk_hw_ops {
> int (*prepare)(struct clk_hw *);
> void (*unprepare)(struct clk_hw *);
> int (*enable)(struct clk_hw *);
> void (*disable)(
On Thu, Oct 13, 2011 at 7:45 AM, Russell King - ARM Linux
wrote:
> On Thu, Sep 22, 2011 at 03:26:59PM -0700, Mike Turquette wrote:
>> diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
>> new file mode 100644
>> index 000..a1d8e79
>> --- /dev/null
>> +++ b/drivers/clk/clk-gate.c
>> @
On Thu, Oct 13, 2011 at 7:44 AM, Russell King - ARM Linux
wrote:
> On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
>> struct clk_hw_ops {
>> int (*prepare)(struct clk_hw *);
>> void (*unprepare)(struct clk_hw *);
>> int (*enabl
On Tue, Oct 11, 2011 at 11:46 PM, Richard Zhao
wrote:
> On Thu, Sep 22, 2011 at 03:26:59PM -0700, Mike Turquette wrote:
>> From: Jeremy Kerr
>>
>> Signed-off-by: Jeremy Kerr
>> Signed-off-by: Mark Brown
>> Signed-off-by: Jamie Iles
>> Signed-off-by: Mike Turquette
>> ---
>> Changes since v1:
On Wed, Oct 5, 2011 at 6:17 PM, Saravana Kannan wrote:
> On 09/22/2011 03:26 PM, Mike Turquette wrote:
>> + unsigned long (*recalc_rate)(struct clk_hw *);
>> + long (*round_rate)(struct clk_hw *, unsigned long);
>> + struct clk * (*get_parent)(struct clk_hw *);
>>
On Mon, Oct 3, 2011 at 3:02 PM, Rob Herring wrote:
> Mike,
>
> On 09/22/2011 05:26 PM, Mike Turquette wrote:
>
>> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
>> index 6db161f..e2a9719 100644
>> --- a/drivers/clk/clkdev.c
>> +++ b/drivers/clk/clkdev.c
>> @@ -23,6 +23,13 @@
>> static L
On Mon, Sep 26, 2011 at 12:37 PM, Jamie Iles wrote:
> On Mon, Sep 26, 2011 at 02:10:32PM -0500, Rob Herring wrote:
>> On 09/26/2011 01:40 PM, Jamie Iles wrote:
>> > On Mon, Sep 26, 2011 at 01:33:08PM -0500, Rob Herring wrote:
>> >>> +static void clk_gate_set_bit(struct clk_hw *clk)
>> >>> +{
>> >>
On Sat, Sep 24, 2011 at 9:08 PM, Grant Likely wrote:
> On Thu, Sep 22, 2011 at 03:27:01PM -0700, Mike Turquette wrote:
>> From: Mark Brown
>>
>> The WM831x and WM832x series of PMICs contain a flexible clocking
>> subsystem intended to provide always on and system core clocks. It
>> features:
>>
On Sat, Sep 24, 2011 at 9:02 PM, Grant Likely wrote:
> On Thu, Sep 22, 2011 at 03:26:59PM -0700, Mike Turquette wrote:
>> From: Jeremy Kerr
>>
>> Signed-off-by: Jeremy Kerr
>> Signed-off-by: Mark Brown
>> Signed-off-by: Jamie Iles
>> Signed-off-by: Mike Turquette
>> ---
>> Changes since v1:
>
On Sat, Sep 24, 2011 at 8:55 PM, Grant Likely wrote:
> On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
>> From: Jeremy Kerr
>>
>> We currently have ~21 definitions of struct clk in the ARM architecture,
>> each defined on a per-platform basis. This makes it difficult to define
>>
On Thu, Sep 22, 2011 at 3:26 PM, Mike Turquette wrote:
> Hi all,
>
> The goal of this series is to provide a cross-platform clock framework
> that platforms can use to model their clock trees and perform common
> operations on them. Currently everyone re-invents their own clock tree
> inside plat
On Fri, Jul 22, 2011 at 5:53 AM, Santosh Shilimkar
wrote:
> On 7/22/2011 6:15 PM, Woodruff, Richard wrote:
>>
>>> From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm-
>>> kernel-boun...@lists.infradead.org] On Behalf Of Shilimkar, Santosh
>>
With fixed IRQ migration and forci
On Thu, Aug 11, 2011 at 11:30 AM, Peter Zijlstra wrote:
> On Wed, 2011-08-10 at 13:03 -0700, Mike Turquette wrote:
>> This patch series introduces a new cpumask which tracks CPUs that
>> support hotplugging. The purpose of this patch series is to provide a
>> simple method for kernel code to know
On Wed, Aug 10, 2011 at 11:06 PM, Amit Kucheria
wrote:
> See comments inline.
>
> On 11 Aug 10, Mike Turquette wrote:
>> On some platforms it is possible to have some CPUs which support CPU
>> hotplug and some which do not. Currently the prescence of an 'online'
>> sysfs entry in userspace is ade
On Wed, Aug 10, 2011 at 1:42 AM, Amit Kucheria wrote:
> On 11 Aug 09, Mike Turquette wrote:
>> On some platforms it is possible to have some CPUs which support CPU
>> hotplug and some which do not. Currently the prescence of an 'online'
>> sysfs entry in userspace is adequate for applications to
On Tue, Aug 9, 2011 at 7:01 PM, Christian Robottom Reis wrote:
> On Tue, Aug 09, 2011 at 06:33:26PM -0700, Mike Turquette wrote:
>> - * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
>> - * cpu_present_mask - has bit 'cpu' set iff cpu is populated
>> - * cpu_online_mask -
1 - 100 of 102 matches
Mail list logo