On 03/21/2012 12:44 AM, Paul Walmsley wrote:
Hello Saravana,
On Tue, 20 Mar 2012, Saravana Kannan wrote:
To add a few more thoughts, while I agree with Paul that there is room for
improvement in the APIs, I think the difference in opinion comes when we ask
the question:
"When we eventually re
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
* Mark Brown [120321 12:11]:
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
So it would be interesting to know more about why you (or anyone else)
perceive that the Kconfig changes would be harmful.
But the enthusiasm of the cl
On 03/21/2012 12:56 PM, Mark Brown wrote:
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
* Mark Brown [120321 12:11]:
These aren't new APIs, the clock API has been around since forever.
I disagree. When I say clock API, I me
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
> The meaning of clk_enable/disable has been changed and they won't work
> without calling clk_prepare/unprepare. So, these are definitely new
> APIs. If it weren't new APIs, then none of the general drivers would
> need to chan
On Wed, Mar 21, 2012 at 01:04:22PM -0700, Saravana Kannan wrote:
> Sure, prepare/unprepare are already there in the .h file. But they
> are stubs and have no impact till we move to the common clock
> framework or platforms move to them with their own implementation
> (certainly not happening in up
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
> On 03/21/2012 12:33 PM, Tony Lindgren wrote:
> >* Mark Brown [120321 12:11]:
> >>These aren't new APIs, the clock API has been around since forever.
> I disagree. When I say clock API, I mean the actual functions and
> their sema
* Mark Brown [120321 12:11]:
> On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
>
> > >So it would be interesting to know more about why you (or anyone else)
> > >perceive that the Kconfig changes would be harmful.
>
> > But the enthusiasm of the clock driver developers doesn't
>
On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote:
> >So it would be interesting to know more about why you (or anyone else)
> >perceive that the Kconfig changes would be harmful.
> But the enthusiasm of the clock driver developers doesn't
> necessarily translate to users of the clo
On Wed, 21 Mar 2012, Paul Walmsley wrote:
> Hello Nico,
>
> On Tue, 20 Mar 2012, Nicolas Pitre wrote:
>
> > This common clk API has been under development for over *two* years
> > already, with several attempts to merge it. And each previous merge
> > attempt aborted because someone came alon
On Tuesday 20 March 2012, Paul Walmsley wrote:
> Hello Arnd,
>
> On Sat, 17 Mar 2012, Arnd Bergmann wrote:
>
> > I think it's rather pointless, because the option is not going to
> > be user selectable but will get selected by the platform unless I'm
> > mistaken. The platform maintainers that ca
Hello Saravana,
On Tue, 20 Mar 2012, Saravana Kannan wrote:
> To add a few more thoughts, while I agree with Paul that there is room for
> improvement in the APIs, I think the difference in opinion comes when we ask
> the question:
>
> "When we eventually refine the APIs in the future to be more
Hello Nico,
On Tue, 20 Mar 2012, Nicolas Pitre wrote:
> This common clk API has been under development for over *two* years
> already, with several attempts to merge it. And each previous merge
> attempt aborted because someone came along at the last minute to do
> exactly what you are doing
On 03/20/2012 08:15 PM, Nicolas Pitre wrote:
On Tue, 20 Mar 2012, Paul Walmsley wrote:
We need to indicate in some way that the existing code and API is very
likely to change in ways that could involve quite a bit of work for
adopters.
[...]
Anyway. It is okay if we want to have some start
Hello Sascha,
On Sat, 17 Mar 2012, Sascha Hauer wrote:
> On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
>
> > If the common clock code is to go upstream now, it should be marked as
> > experimental.
>
> No, please don't do this. This effectively marks the architectures using
>
Hello Arnd,
On Sat, 17 Mar 2012, Arnd Bergmann wrote:
> I think it's rather pointless, because the option is not going to
> be user selectable but will get selected by the platform unless I'm
> mistaken. The platform maintainers that care already know the state
> of the framework.
This is where
On Wed, Mar 21, 2012 at 01:44:01AM -0600, Paul Walmsley wrote:
> Hello Saravana,
>
> Certainly a Kconfig help text change seems trivial enough. But even the
> resistance to CONFIG_EXPERIMENTAL has been quite surprising to me, given
> that every single defconfig in arch/arm/defconfig sets it:
>
On Tue, 20 Mar 2012, Paul Walmsley wrote:
> We need to indicate in some way that the existing code and API is very
> likely to change in ways that could involve quite a bit of work for
> adopters.
[...]
> Anyway. It is okay if we want to have some starter common clock framework
> in mainline
On Saturday 17 March 2012, Sascha Hauer wrote:
> On Sat, Mar 17, 2012 at 11:02:11AM -0700, Turquette, Mike wrote:
> >
> > Much like experimental I'm not sure how needed this change is. The
> > help section does say to leave it disabled by default, if unsure. If
> > you merge it I won't object but
On Sat, Mar 17, 2012 at 11:02:11AM -0700, Turquette, Mike wrote:
> 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:3
On Saturday 17 March 2012, Turquette, Mike wrote:
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > index 2eaf17e..a0a83de 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -12,7 +12,7 @@ config HAVE_MACH_CLKDEV
> >
> > menuconfig COMMON_CLK
> > - bool "C
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: [PATCH] clk: mark the common clk code as EXPERIMENTAL
On 03/16/2012 05:54 PM, Rob Herring wrote:
On 03/16/2012 06:47 PM, Sascha Hauer wrote:
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as
experimental.
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: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
> >
> > Mark the common clk code as depending on CON
On 03/16/2012 06:47 PM, Sascha Hauer wrote:
> Hi Paul,
>
> On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
>> Hi
>>
>> On Fri, 16 Mar 2012, Arnd Bergmann wrote:
>>
>>
>> If the common clock code is to go upstream now, it should be marked as
>> experimental.
>
> No, please don't do
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
> Hi
>
> On Fri, 16 Mar 2012, Arnd Bergmann wrote:
>
>
> If the common clock code is to go upstream now, it should be marked as
> experimental.
No, please don't do this. This effectively marks the architectures using
the
Hi
On Fri, 16 Mar 2012, 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 starting t
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, 16 Mar 2012, Arnd Bergmann wrote:
> FWIW, it's in arm-soc now, and it's the last thing I put in there
> for v3.4.
Amen!
Nicolas
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
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 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 starting their ports.
> >
> > And what is the path into mainline -
On Fri, 16 Mar 2012, Linus Walleij wrote:
> On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette wrote:
>
> > Provide documentation for the common clk structures and APIs. This code
> > can be found in drivers/clk/ and include/linux/clk*.h.
>
> Acked-by: Linus Wallej
> For this three-piece v7 patc
On Friday 16 March 2012, Amit Kucheria wrote:
> On Fri, Mar 16, 2012 at 12:29 PM, Thomas Gleixner wrote:
> > On Fri, 16 Mar 2012, Linus Walleij wrote:
> >
> >> On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette
> >> wrote:
> >>
> >> > Provide documentation for the common clk structures and APIs. T
On Fri, Mar 16, 2012 at 12:29 PM, Thomas Gleixner wrote:
> On Fri, 16 Mar 2012, Linus Walleij wrote:
>
>> On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette
>> wrote:
>>
>> > Provide documentation for the common clk structures and APIs. This code
>> > can be found in drivers/clk/ and include/linux
On Fri, Mar 16, 2012 at 7:11 AM, Mike Turquette wrote:
> Provide documentation for the common clk structures and APIs. This code
> can be found in drivers/clk/ and include/linux/clk*.h.
Acked-by: Linus Wallej
For this three-piece v7 patchset.
It already does magnitudes more advanced stuff tha
34 matches
Mail list logo
