From patchwork Fri Mar 16 22:21:17 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Walmsley X-Patchwork-Id: 7337 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id 0F51723DEA for ; Fri, 16 Mar 2012 22:21:21 +0000 (UTC) Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by fiordland.canonical.com (Postfix) with ESMTP id A6CECA1835B for ; Fri, 16 Mar 2012 22:21:20 +0000 (UTC) Received: by iage36 with SMTP id e36so8009902iag.11 for ; Fri, 16 Mar 2012 15:21:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-forwarded-to:x-forwarded-for:delivered-to:received-spf:date:from :to:cc:subject:in-reply-to:message-id:references:user-agent :mime-version:content-type:x-gm-message-state; bh=Hn7g81eUG0LG8Qr9gOh1Q40rwQ1jRE69Rt53x07rYUo=; b=ZEEqnrdxSelRAoYYgmmF8M5FwDQ+AqZBWy18PqVvk4lgi1pORSoDXt8H50LXdr6v6l BQ2y2C9J2uTPkiILmVSqDU5v3xIYCT5Hwhb4NPOKbrrgbaA6ZLOoUC4KmPJVy71842Vr 3qpcxfkP/FfZPLTl+rShm6nVZ8X9nNGR6G97+Fk4Jmh/02Wq2eI/z/5ggj437bfYOyyN XnlwuUomgrQK8/qHCjsMA6HkeWUUpTBfKEqTL2YIIBBJCusq8/oAkWU7rlo8aXMiOkqp pVsB6ic0KQ/Lfy7eGTbMqLKdUFXEsrgMcIRxWuWkRnvadmz7KD/Hv6ACVDMu23iE3k4q h0hw== Received: by 10.50.197.132 with SMTP id iu4mr679494igc.74.1331936480069; Fri, 16 Mar 2012 15:21:20 -0700 (PDT) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.231.53.18 with SMTP id k18csp17836ibg; Fri, 16 Mar 2012 15:21:19 -0700 (PDT) Received: by 10.224.31.203 with SMTP id z11mr5831903qac.72.1331936478372; Fri, 16 Mar 2012 15:21:18 -0700 (PDT) Received: from utopia.booyaka.com (utopia.booyaka.com. [72.9.107.138]) by mx.google.com with ESMTPS id fz1si6609985qab.64.2012.03.16.15.21.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 15:21:18 -0700 (PDT) Received-SPF: pass (google.com: domain of pwsan@booyaka.com designates 72.9.107.138 as permitted sender) client-ip=72.9.107.138; Authentication-Results: mx.google.com; spf=pass (google.com: domain of pwsan@booyaka.com designates 72.9.107.138 as permitted sender) smtp.mail=pwsan@booyaka.com Received: (qmail 32261 invoked by uid 1019); 16 Mar 2012 22:21:17 -0000 Date: Fri, 16 Mar 2012 16:21:17 -0600 (MDT) From: Paul Walmsley To: Arnd Bergmann cc: linux-arm-kernel@lists.infradead.org, Amit Kucheria , Nicolas Pitre , linaro-dev@lists.linaro.org, Linus Walleij , Grant Likely , Saravana Kannan , Jeremy Kerr , Mike Turquette , Mike Turquette , Magnus Damm , Deepak Saxena , patches@linaro.org, Sascha Hauer , Rob Herring , Russell King , Thomas Gleixner , Richard Zhao , Shawn Guo , Linus Walleij , Mark Brown , Stephen Boyd , linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 1/3] Documentation: common clk API In-Reply-To: <201203162057.58706.arnd@arndb.de> Message-ID: References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203161218.05125.arnd.bergmann@linaro.org> <201203162057.58706.arnd@arndb.de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 X-Gm-Message-State: ALoCoQlTgnE3/ATs9dfkM+jRaRYiNP4NDo26n2wxLt/j1sBUvzStQCw5Qs4X/zdV3SYqOD5Mv+yz 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. > > > > > > And what is the path into mainline - will Russell carry it or Arnd > > > (with Russell's blessing)? > > > > I would suggest putting it into a late/* branch of arm-soc so it finally > > gets some linux-next exposure, and then sending it in the second week of the > > merge window. > > > > Russell, please let me know if you want to carry it instead or if you > > have found any last-minute show stoppers in the code. > > FWIW, it's in arm-soc now [...] If the common clock code is to go upstream now, it should be marked as 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). While I understand and accept the motivation to get the common clk code upstream now, if platforms start to use it, they need to be aware that the behavior of the code can change significantly. These platforms may need to revalidate their implementations or change the way that many of their drivers use the clock functions. It also seems important to recognize that significant changes are still coming into the common clk code (e.g., the clk_set_rate() changes that came in just a few days ago). So, the following is a patch to mark it as experimental. It applies on the current head of arm-soc/next/clk (9d9f78ed9af0e465d2fd15550471956e7f559b9f). This should be a good compromise: it allows simple platforms or platforms with maintainers with lots of time to start converting over to the common clk code, while still clearly indicating that the API and underlying code is likely to change in significant ways. Once at least two major SoC ports have DVFS with external I/O devices safely up and running on their mainline kernels with the common clk code, I'd suggest removing the experimental designation. ... None of this is meant to reflect on Mike, by the way, who is doing a good job in a difficult situation. - Paul 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 and the underlying mechanics are likely to need significant changes to support non-trivial uses of the rate changing code, such as DVFS with external I/O devices. So any platforms that switch their implementation over to this may need to revise much of their driver code and revalidate their implementations until the behavior of the code is better-defined. A good time for removing this EXPERIMENTAL designation would be after at least two platforms that do DVFS on groups of external I/O devices have ported their clock implementations over to the common clk code. Signed-off-by: Paul Walmsley Cc: Mike Turquette --- drivers/clk/Kconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 2eaf17e..a0a83de 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -12,6 +12,7 @@ config HAVE_MACH_CLKDEV menuconfig COMMON_CLK bool "Common Clock Framework" select HAVE_CLK_PREPARE + depends on EXPERIMENTAL ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an