From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH v7 1/3] Documentation: common clk API Date: Sat, 17 Mar 2012 09:05:32 +0000 Message-ID: <201203170905.33191.arnd@arndb.de> References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linaro-dev-bounces-cunTk1MwBs8s++Sfvej+rw@public.gmane.org Errors-To: linaro-dev-bounces-cunTk1MwBs8s++Sfvej+rw@public.gmane.org To: "Turquette, Mike" Cc: Nicolas Pitre , linaro-dev-cunTk1MwBs8s++Sfvej+rw@public.gmane.org, Saravana Kannan , Jeremy Kerr , Russell King , Magnus Damm , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Sascha Hauer , Rob Herring , Thomas Gleixner , linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Paul Walmsley , Linus Walleij , Mark Brown , Stephen Boyd , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-omap@vger.kernel.org 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 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 > > ACK. This will set some reasonable expectations while things are in flux. > > Arnd are you willing to take this in? 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. Also, there are no user space interfaces that we have to warn users about not being stable, because the framework is internal to the kernel. However, I wonder whether we need the patch below to prevent users from accidentally enabling COMMON_CLK on platforms that already provide their own implementation. Arnd 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 Framework" + bool select HAVE_CLK_PREPARE ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Sat, 17 Mar 2012 09:05:32 +0000 Subject: [PATCH v7 1/3] Documentation: common clk API In-Reply-To: References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> Message-ID: <201203170905.33191.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 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 > > ACK. This will set some reasonable expectations while things are in flux. > > Arnd are you willing to take this in? 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. Also, there are no user space interfaces that we have to warn users about not being stable, because the framework is internal to the kernel. However, I wonder whether we need the patch below to prevent users from accidentally enabling COMMON_CLK on platforms that already provide their own implementation. Arnd 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 Framework" + bool select HAVE_CLK_PREPARE ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756189Ab2CQJGP (ORCPT ); Sat, 17 Mar 2012 05:06:15 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]:61821 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752917Ab2CQJGH (ORCPT ); Sat, 17 Mar 2012 05:06:07 -0400 From: Arnd Bergmann To: "Turquette, Mike" Subject: Re: [PATCH v7 1/3] Documentation: common clk API Date: Sat, 17 Mar 2012 09:05:32 +0000 User-Agent: KMail/1.12.2 (Linux/3.3.0-rc1; KDE/4.3.2; x86_64; ; ) Cc: Paul Walmsley , linux-arm-kernel@lists.infradead.org, Amit Kucheria , Nicolas Pitre , linaro-dev@lists.linaro.org, Linus Walleij , Grant Likely , Saravana Kannan , Jeremy Kerr , 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 References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203170905.33191.arnd@arndb.de> X-Provags-ID: V02:K0:Re8/0Q/VyVfaZN1kUlRE9ffQ/0tFHXgswrz4RNm+oqN Eq4Uj7PJWB2Nl2LgwMHbr7RUF7/Hke4YCnui2CfG4ONN7Az/XA QOhPRFml8Qm667d/In9pDbNeWi61wOBSgLLya8WloidXpIj3ak ys0/F5t75mK4/cTFD1biETtzOqrvrTIh717PB0bhOyOdIZHILO L+SPLzm9cvT0quHtSpfVJ68CFEu1i58YFNt978ZGp7uBsPLgJc OxyU2WrErXzwaA1uYeFAkH2qvv50EJBm6nBUoduqV148Mir2lo UYX6poQ4QZVI0q8SIMsA+YhRXv75P7f9O0jUy3rYWzUpAXRA0G GvzpmH9ODtQBGFhf1CJE= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 > > ACK. This will set some reasonable expectations while things are in flux. > > Arnd are you willing to take this in? 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. Also, there are no user space interfaces that we have to warn users about not being stable, because the framework is internal to the kernel. However, I wonder whether we need the patch below to prevent users from accidentally enabling COMMON_CLK on platforms that already provide their own implementation. Arnd 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 Framework" + bool select HAVE_CLK_PREPARE ---help--- The common clock framework is a single definition of struct clk, useful across many platforms, as well as an