From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031484Ab2CQSCm (ORCPT ); Sat, 17 Mar 2012 14:02:42 -0400 Received: from na3sys009aog122.obsmtp.com ([74.125.149.147]:48358 "EHLO na3sys009aog122.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757081Ab2CQSCi convert rfc822-to-8bit (ORCPT ); Sat, 17 Mar 2012 14:02:38 -0400 MIME-Version: 1.0 In-Reply-To: <201203170905.33191.arnd@arndb.de> References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203170905.33191.arnd@arndb.de> From: "Turquette, Mike" Date: Sat, 17 Mar 2012 11:02:11 -0700 Message-ID: Subject: Re: [PATCH v7 1/3] Documentation: common clk API To: Arnd Bergmann 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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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. The consensus seems to be to not set experimental. > 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 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 might be fixing an imaginary problem. Regards, Mike From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Turquette, Mike" Subject: Re: [PATCH v7 1/3] Documentation: common clk API Date: Sat, 17 Mar 2012 11:02:11 -0700 Message-ID: References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203170905.33191.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from na3sys009aog122.obsmtp.com ([74.125.149.147]:50869 "EHLO na3sys009aog122.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757207Ab2CQSCi convert rfc822-to-8bit (ORCPT ); Sat, 17 Mar 2012 14:02:38 -0400 Received: by mail-ey0-f170.google.com with SMTP id o10so4337830eaa.1 for ; Sat, 17 Mar 2012 11:02:36 -0700 (PDT) In-Reply-To: <201203170905.33191.arnd@arndb.de> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Arnd Bergmann 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 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 wrot= e: >> > 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. =A0T= he API >> > is not well-defined and both it and the underlying mechanics are l= ikely >> > to need significant changes to support non-trivial uses of the rat= e >> > changing code, such as DVFS with external I/O devices. =A0So any p= latforms >> > that switch their implementation over to this may need to revise m= uch >> > of their driver code and revalidate their implementations until th= e >> > behavior of the code is better-defined. >> > >> > A good time for removing this EXPERIMENTAL designation would be af= ter 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. =A0This 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. The consensus seems to be to not set experimental. > 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. > > =A0 =A0 =A0 =A0Arnd > > 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 > > =A0menuconfig COMMON_CLK > - =A0 =A0 =A0 bool "Common Clock Framework" > + =A0 =A0 =A0 bool > =A0 =A0 =A0 =A0select HAVE_CLK_PREPARE > =A0 =A0 =A0 =A0---help--- > =A0 =A0 =A0 =A0 =A0The common clock framework is a single definition = of struct > =A0 =A0 =A0 =A0 =A0clk, useful across many platforms, as well as an 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 might be fixing an imaginary problem. Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-omap" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: mturquette@ti.com (Turquette, Mike) Date: Sat, 17 Mar 2012 11:02:11 -0700 Subject: [PATCH v7 1/3] Documentation: common clk API In-Reply-To: <201203170905.33191.arnd@arndb.de> References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203170905.33191.arnd@arndb.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 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. The consensus seems to be to not set experimental. > 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 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 might be fixing an imaginary problem. Regards, Mike