From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Hunter Subject: Re: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD Date: Thu, 14 Jun 2012 08:22:55 -0500 Message-ID: <4FD9E5AF.6010201@ti.com> References: <4FD64D6D.3020401@ti.com> <4FD77EF1.8000600@ti.com> <4FD8A906.8080202@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from devils.ext.ti.com ([198.47.26.153]:50631 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753016Ab2FNNWy (ORCPT ); Thu, 14 Jun 2012 09:22:54 -0400 In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Mohammed, Afzal" Cc: "tony@atomide.com" , "paul@pwsan.com" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" On 06/14/2012 02:03 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Wed, Jun 13, 2012 at 20:21:50, Hunter, Jon wrote: > >> If the clk handle for the gpmc is passed to the gpmc driver, then there >> is no reason why the driver cannot do this. > > I believe passing clk details through platform data is an abuse of > clock framework. Why? You currently have a global variable storing the clock handle. It can be quite common for drivers to know the clock frequencies of their functional clocks. How else can drivers calculate timings? Jon From mboxrd@z Thu Jan 1 00:00:00 1970 From: jon-hunter@ti.com (Jon Hunter) Date: Thu, 14 Jun 2012 08:22:55 -0500 Subject: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD In-Reply-To: References: <4FD64D6D.3020401@ti.com> <4FD77EF1.8000600@ti.com> <4FD8A906.8080202@ti.com> Message-ID: <4FD9E5AF.6010201@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/14/2012 02:03 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Wed, Jun 13, 2012 at 20:21:50, Hunter, Jon wrote: > >> If the clk handle for the gpmc is passed to the gpmc driver, then there >> is no reason why the driver cannot do this. > > I believe passing clk details through platform data is an abuse of > clock framework. Why? You currently have a global variable storing the clock handle. It can be quite common for drivers to know the clock frequencies of their functional clocks. How else can drivers calculate timings? Jon