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
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
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 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 care
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 along at the
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
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 clock
* Mark Brown broo...@opensource.wolfsonmicro.com [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
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
* Mark Brownbroo...@opensource.wolfsonmicro.com [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
On Wed, Mar 21, 2012 at 12:41:41PM -0700, Saravana Kannan wrote:
On 03/21/2012 12:33 PM, Tony Lindgren wrote:
* Mark Brownbroo...@opensource.wolfsonmicro.com [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
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 Brownbroo...@opensource.wolfsonmicro.com [120321 12:11]:
These aren't new APIs, the clock API has been around since forever.
I
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
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 change.
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
the
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 we
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 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
On Friday 16 March 2012, Turquette, Mike wrote:
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley p...@pwsan.com wrote:
From: Paul Walmsley p...@pwsan.com
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
On Sat, Mar 17, 2012 at 2:05 AM, Arnd Bergmann a...@arndb.de wrote:
On Friday 16 March 2012, Turquette, Mike wrote:
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley p...@pwsan.com wrote:
From: Paul Walmsley p...@pwsan.com
Date: Fri, 16 Mar 2012 16:06:30 -0600
Subject: [PATCH] clk: mark the
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 Common Clock
On Sat, Mar 17, 2012 at 11:02:11AM -0700, Turquette, Mike wrote:
On Sat, Mar 17, 2012 at 2:05 AM, Arnd Bergmann a...@arndb.de wrote:
On Friday 16 March 2012, Turquette, Mike wrote:
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley p...@pwsan.com wrote:
From: Paul Walmsley p...@pwsan.com
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 this
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 their ports.
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley p...@pwsan.com wrote:
From: Paul Walmsley p...@pwsan.com
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
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
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 this. This
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.
27 matches
Mail list logo
