[lkml]   [2012]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 1/3] Documentation: common clk API
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 effectively marks the architectures using
> the generic clock framework experimental. We can mark drivers as 'you
> have been warned', but marking an architecture as experimental is the
> wrong sign for both its users and people willing to adopt the framework.
> Also we get this:
> warning: (ARCH_MX1 && MACH_MX21 && ARCH_MX25 && MACH_MX27) selects COMMON_CLK which has unmet direct dependencies (EXPERIMENTAL)
> (and no, I don't want to support to clock frameworks in parallel)


For simple users at least, the api is perfectly adequate and it is not
experimental (unless new means experimental).


>> This is because we know the API is not well-defined, and
>> that both the API and the underlying mechanics will almost certainly need
>> to change for non-trivial uses of the rate changing code (e.g., DVFS with
>> external I/O devices).
> Please leave DVFS out of the game. DVFS will use the clock framework for
> the F part and the regulator framework for the V part, but the clock
> framework should not get extended with DVFS features. The notifiers we
> currently have in the clock framework should give enough information
> for DVFS implementations. Even if they don't and we have to change
> something here this will have no influence on the architectures
> implementing their clock tree with the common clock framework.
> Sascha

 \ /
  Last update: 2012-03-17 01:57    [W:0.141 / U:11.940 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site