From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946423Ab2CPXsA (ORCPT ); Fri, 16 Mar 2012 19:48:00 -0400 Received: from metis.ext.pengutronix.de ([92.198.50.35]:43355 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1946336Ab2CPXrq (ORCPT ); Fri, 16 Mar 2012 19:47:46 -0400 Date: Sat, 17 Mar 2012 00:47:06 +0100 From: Sascha Hauer To: Paul Walmsley Cc: Arnd Bergmann , 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, 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 Message-ID: <20120316234706.GJ3852@pengutronix.de> References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203161218.05125.arnd.bergmann@linaro.org> <201203162057.58706.arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 23:44:30 up 125 days, 6:31, 26 users, load average: 0.00, 0.01, 0.05 User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 2001:6f8:1178:2:21e:67ff:fe11:9c5c X-SA-Exim-Mail-From: sha@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) > 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 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sascha Hauer Subject: Re: [PATCH v7 1/3] Documentation: common clk API Date: Sat, 17 Mar 2012 00:47:06 +0100 Message-ID: <20120316234706.GJ3852@pengutronix.de> References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203161218.05125.arnd.bergmann@linaro.org> <201203162057.58706.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline 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: Paul Walmsley 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, Arnd Bergmann , patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Rob Herring , Thomas Gleixner , linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linus Walleij , Mark Brown , Stephen Boyd , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-omap@vger.kernel.org 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) > 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 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | From mboxrd@z Thu Jan 1 00:00:00 1970 From: s.hauer@pengutronix.de (Sascha Hauer) Date: Sat, 17 Mar 2012 00:47:06 +0100 Subject: [PATCH v7 1/3] Documentation: common clk API In-Reply-To: References: <1331878280-2758-1-git-send-email-mturquette@linaro.org> <201203161218.05125.arnd.bergmann@linaro.org> <201203162057.58706.arnd@arndb.de> Message-ID: <20120316234706.GJ3852@pengutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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) > 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 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |