On Mon, Mar 19, 2012 at 03:01:17PM +0800, Shawn Guo wrote:
> On Fri, Mar 09, 2012 at 10:25:00AM -0800, Turquette, Mike wrote:
> ...
> > However if you have the ability to use the clk_foo_register functions
> > please do use them in place of static initialization. The static init
> > stuff is only
On Fri, Mar 16, 2012 at 08:23:57PM -0700, Saravana Kannan wrote:
> On 03/07/2012 01:20 PM, Turquette, Mike wrote:
...
> >Admittedly I think that the OMAP code could migrate some of these bits
> >to a lazy-registration model, specifically the hwmod object instances,
> >but that requires an awful lot
On Fri, Mar 09, 2012 at 10:25:00AM -0800, Turquette, Mike wrote:
...
> However if you have the ability to use the clk_foo_register functions
> please do use them in place of static initialization. The static init
> stuff is only for folks backed into a corner and forced to use it...
> for now. I'
On Fri, Mar 16, 2012 at 08:23:57PM -0700, Saravana Kannan wrote:
...
> Hi Mike,
>
> I already took a quick look at the v7 series, but I thought this
> thread has more relevant context for my response. So, responding
> here.
>
> I'm with Sascha on creating a clk_internal/clk_initializer and
> remo
On 03/07/2012 01:20 PM, Turquette, Mike wrote:
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:
I belie
On Wed, 14 Mar 2012, Turquette, Mike wrote:
> On Wed, Mar 14, 2012 at 2:28 PM, Thomas Gleixner wrote:
> > So the right way to deal with it is to have an array of valid names
> > with no holes and NULL pointers allowed and have a mapping from the
> > array index to the register value.
>
> This is
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.
> On Wed, Mar 14, 2012 at 1:48 AM, Sascha Hauer wrote:
> >> Also, do you forsee needing hole in parent_names for any reason other
> >> than desc
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 sometimes...
>> On Wed, M
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 clock framework defines a common st
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 clock framework defines a common struct clk useful across
> >> most platforms as well as an im
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 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 clocks.
>
> The net result is consolidation of many differe
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
> 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 happens when it turns out that the internal
> struct clk
On Wed, 7 Mar 2012, Turquette, Mike 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 there that requ
On Thu, Mar 08, 2012 at 07:27:39AM +0100, 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 pla
> 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 there that require the level of expose to
> struct clk pre
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:
>> >> >>
>> >> >> I believe this patch already does
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:
> >> >>
> >> >> I believe this patch already does what you suggest, but I might be
> >> >> missing your point
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 include/linux/clk-private.h you expose struct clk outside th
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 include/linux/clk-private.h you expose struct clk outside the core.
> > This has to be done to make static initializers p
Hi Mike,
On Sat, Mar 03, 2012 at 12:29:00AM -0800, Mike Turquette wrote:
[snip]
> +static void __clk_disable(struct clk *clk)
> +{
> + if (!clk)
> + return;
> +
> + if (WARN_ON(clk->enable_count == 0))
> + return;
> +
> + if (--clk->enable_count > 0)
> +
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 clock framework defines a common stru
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 clock framework defines a common struct clk useful across
> >> most platforms as well as an imp
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 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 clocks.
>
> The net result is consolidation of many differe
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.
The net result is consolidation of many different struct clk definitions
and platform-specific clock framework implementa
29 matches
Mail list logo
