From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH v7 1/3] Documentation: common clk API Date: Wed, 21 Mar 2012 12:33:04 -0700 Message-ID: <20120321193304.GO9859@atomide.com> References: <4F6A2042.9030302@codeaurora.org> <20120321190741.GL3226@opensource.wolfsonmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20120321190741.GL3226-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> 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: Mark Brown 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, Sascha Hauer , Rob Herring , Thomas Gleixner , linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Paul Walmsley , Linus Walleij , Stephen Boyd , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-omap@vger.kernel.org * Mark Brown [120321 12:11]: > On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote: > > > >So it would be interesting to know more about why you (or anyone else) > > >perceive that the Kconfig changes would be harmful. > > > But the enthusiasm of the clock driver developers doesn't > > necessarily translate to users of the clock APIs (other driver > > devs). My worry with marking it as experimental in Kconfig and to a > > certain extent in the documentation is that it will discourage the > > driver devs from switching to the new APIs. If no one is using the > > new APIs, then platforms can't switch to the common clock framework > > These aren't new APIs, the clock API has been around since forever. > For driver authors working on anything that isn't platform specific the > issue has been that it's not implemented at all on the overwhelming > majority of architectures and those that do all have their own random > implementations with their own random quirks and with no ability for > anything except the platform to even try to do incredibly basic stuff > like register a new clock. > > Simply having something, anything, in place even if it's going to churn > is a massive step forward here for people working with clocks. Right, and now at least the people reading this thread are pretty aware of the yet unsolved issues with clock fwk api :) Regards, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Wed, 21 Mar 2012 12:33:04 -0700 Subject: [PATCH v7 1/3] Documentation: common clk API In-Reply-To: <20120321190741.GL3226@opensource.wolfsonmicro.com> References: <4F6A2042.9030302@codeaurora.org> <20120321190741.GL3226@opensource.wolfsonmicro.com> Message-ID: <20120321193304.GO9859@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Mark Brown [120321 12:11]: > On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote: > > > >So it would be interesting to know more about why you (or anyone else) > > >perceive that the Kconfig changes would be harmful. > > > But the enthusiasm of the clock driver developers doesn't > > necessarily translate to users of the clock APIs (other driver > > devs). My worry with marking it as experimental in Kconfig and to a > > certain extent in the documentation is that it will discourage the > > driver devs from switching to the new APIs. If no one is using the > > new APIs, then platforms can't switch to the common clock framework > > These aren't new APIs, the clock API has been around since forever. > For driver authors working on anything that isn't platform specific the > issue has been that it's not implemented at all on the overwhelming > majority of architectures and those that do all have their own random > implementations with their own random quirks and with no ability for > anything except the platform to even try to do incredibly basic stuff > like register a new clock. > > Simply having something, anything, in place even if it's going to churn > is a massive step forward here for people working with clocks. Right, and now at least the people reading this thread are pretty aware of the yet unsolved issues with clock fwk api :) Regards, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756580Ab2CUTde (ORCPT ); Wed, 21 Mar 2012 15:33:34 -0400 Received: from mho-01-ewr.mailhop.org ([204.13.248.71]:32478 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756149Ab2CUTdb (ORCPT ); Wed, 21 Mar 2012 15:33:31 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 98.234.237.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+TAhg5OGbJ04+NQsDrBUMf Date: Wed, 21 Mar 2012 12:33:04 -0700 From: Tony Lindgren To: Mark Brown Cc: Saravana Kannan , Paul Walmsley , Nicolas Pitre , Sascha Hauer , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, Amit Kucheria , linaro-dev@lists.linaro.org, Linus Walleij , Grant Likely , 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 , Stephen Boyd , linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 1/3] Documentation: common clk API Message-ID: <20120321193304.GO9859@atomide.com> References: <4F6A2042.9030302@codeaurora.org> <20120321190741.GL3226@opensource.wolfsonmicro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120321190741.GL3226@opensource.wolfsonmicro.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Mark Brown [120321 12:11]: > On Wed, Mar 21, 2012 at 11:38:58AM -0700, Saravana Kannan wrote: > > > >So it would be interesting to know more about why you (or anyone else) > > >perceive that the Kconfig changes would be harmful. > > > But the enthusiasm of the clock driver developers doesn't > > necessarily translate to users of the clock APIs (other driver > > devs). My worry with marking it as experimental in Kconfig and to a > > certain extent in the documentation is that it will discourage the > > driver devs from switching to the new APIs. If no one is using the > > new APIs, then platforms can't switch to the common clock framework > > These aren't new APIs, the clock API has been around since forever. > For driver authors working on anything that isn't platform specific the > issue has been that it's not implemented at all on the overwhelming > majority of architectures and those that do all have their own random > implementations with their own random quirks and with no ability for > anything except the platform to even try to do incredibly basic stuff > like register a new clock. > > Simply having something, anything, in place even if it's going to churn > is a massive step forward here for people working with clocks. Right, and now at least the people reading this thread are pretty aware of the yet unsolved issues with clock fwk api :) Regards, Tony