From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756783Ab2CQDjG (ORCPT ); Fri, 16 Mar 2012 23:39:06 -0400 Received: from wolverine01.qualcomm.com ([199.106.114.254]:48116 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752922Ab2CQDjD (ORCPT ); Fri, 16 Mar 2012 23:39:03 -0400 X-IronPort-AV: E=McAfee;i="5400,1158,6651"; a="173320389" Message-ID: <4F64074E.2070903@codeaurora.org> Date: Fri, 16 Mar 2012 20:38:54 -0700 From: Saravana Kannan User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Rob Herring CC: Sascha Hauer , Nicolas Pitre , Paul Walmsley , Russell King , Linus Walleij , Arnd Bergmann , patches@linaro.org, Stephen Boyd , Mark Brown , Magnus Damm , linux-kernel@vger.kernel.org, Rob Herring , linaro-dev@lists.linaro.org, Jeremy Kerr , linux-omap@vger.kernel.org, Thomas Gleixner , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v7 1/3] Documentation: common clk API References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203161218.05125.arnd.bergmann@linaro.org> <201203162057.58706.arnd@arndb.de> <20120316234706.GJ3852@pengutronix.de> <4F63E0D3.3060106@gmail.com> In-Reply-To: <4F63E0D3.3060106@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >> >> 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) >> > > +1 > > For simple users at least, the api is perfectly adequate and it is not > experimental (unless new means experimental). > +1 - not experimental please. While I agree with Mike and Paul that there is room for a lot of improvements to the clock APIs, I think the existing APIs in this patch series can become macro wrappers around any new APIs improvements we add in the future. We should have really done that for the clk_prepare_enable/unprepare_disable(), but it should certainly be doable for future API additions now that we have the atomic/non-atomic differentiation out of the way. Thanks, Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Saravana Kannan Subject: Re: [PATCH v7 1/3] Documentation: common clk API Date: Fri, 16 Mar 2012 20:38:54 -0700 Message-ID: <4F64074E.2070903@codeaurora.org> References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203161218.05125.arnd.bergmann@linaro.org> <201203162057.58706.arnd@arndb.de> <20120316234706.GJ3852@pengutronix.de> <4F63E0D3.3060106@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F63E0D3.3060106@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Rob Herring Cc: Nicolas Pitre , Paul Walmsley , Russell King , Linus Walleij , Arnd Bergmann , patches@linaro.org, Magnus Damm , Sascha Hauer , Mark Brown , Stephen Boyd , linux-kernel@vger.kernel.org, Rob Herring , linaro-dev@lists.linaro.org, Jeremy Kerr , linux-omap@vger.kernel.org, Thomas Gleixner , linux-arm-kernel@lists.infradead.org List-Id: linux-omap@vger.kernel.org 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. >> >> 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) >> > > +1 > > For simple users at least, the api is perfectly adequate and it is not > experimental (unless new means experimental). > +1 - not experimental please. While I agree with Mike and Paul that there is room for a lot of improvements to the clock APIs, I think the existing APIs in this patch series can become macro wrappers around any new APIs improvements we add in the future. We should have really done that for the clk_prepare_enable/unprepare_disable(), but it should certainly be doable for future API additions now that we have the atomic/non-atomic differentiation out of the way. Thanks, Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. From mboxrd@z Thu Jan 1 00:00:00 1970 From: skannan@codeaurora.org (Saravana Kannan) Date: Fri, 16 Mar 2012 20:38:54 -0700 Subject: [PATCH v7 1/3] Documentation: common clk API In-Reply-To: <4F63E0D3.3060106@gmail.com> References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203161218.05125.arnd.bergmann@linaro.org> <201203162057.58706.arnd@arndb.de> <20120316234706.GJ3852@pengutronix.de> <4F63E0D3.3060106@gmail.com> Message-ID: <4F64074E.2070903@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. >> >> 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) >> > > +1 > > For simple users at least, the api is perfectly adequate and it is not > experimental (unless new means experimental). > +1 - not experimental please. While I agree with Mike and Paul that there is room for a lot of improvements to the clock APIs, I think the existing APIs in this patch series can become macro wrappers around any new APIs improvements we add in the future. We should have really done that for the clk_prepare_enable/unprepare_disable(), but it should certainly be doable for future API additions now that we have the atomic/non-atomic differentiation out of the way. Thanks, Saravana -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.