From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4FA9380F.90700@ti.com> Date: Tue, 8 May 2012 10:13:19 -0500 From: Jon Hunter MIME-Version: 1.0 To: "Mohammed, Afzal" Subject: Re: [PATCH v4 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD References: <4FA04A8C.4050703@ti.com> <4FA4041D.9010000@ti.com> <4FA7F473.7060607@ti.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "Hilman, Kevin" , "Menon, Nishanth" , "linux@arm.linux.org.uk" , "tony@atomide.com" , "gregkh@linuxfoundation.org" , "linux-usb@vger.kernel.org" , "Balbi, Felipe" , "dbaryshkov@gmail.com" , "kyungmin.park@samsung.com" , "vimal.newwork@gmail.com" , "grinberg@compulab.co.il" , "artem.bityutskiy@linux.intel.com" , "linux-mtd@lists.infradead.org" , "linux-omap@vger.kernel.org" , "dwmw2@infradead.org" , "linux-arm-kernel@lists.infradead.org" , "notasas@gmail.com" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Afzal, On 05/08/2012 01:24 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote: > >>> Clk_prd is a platform data passed to the driver, so platform code >>> updates it, where else can it be done ? >> >> The point is that you can pass what ever you like. You do not need to >> pass the frequency you can pass the clock handle instead. > > As clk rate is required in platform code for timing calculation, and > already available, period was passed Sure. >> >> What happens it the clk_get() of the gpmc_l3_clk fails during the init? > > Thanks for bringing this point, invalid clk_prd has to be handled by driver. > >> >> In fact if you migrate to runtime pm then we should not have the clk_get >> in the gpmc_init any more. > > Even if converted to RPM, to get clk rate, clk_get has to be done > somewhere, right ? Yes exactly. However, you could now do this in the driver itself like the probe function. Or may be just pass the frequency of the gpmc fclk to the driver and let the driver convert to the period. No reason we need to convert to the period outside of the driver. Hence, we can keep the function to do the conversion static in the driver and don't need to expose externally. Jon From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Hunter Subject: Re: [PATCH v4 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD Date: Tue, 8 May 2012 10:13:19 -0500 Message-ID: <4FA9380F.90700@ti.com> References: <4FA04A8C.4050703@ti.com> <4FA4041D.9010000@ti.com> <4FA7F473.7060607@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]:45211 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755834Ab2EHPNj (ORCPT ); Tue, 8 May 2012 11:13:39 -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" , "linux@arm.linux.org.uk" , "Hilman, Kevin" , "Balbi, Felipe" , "dwmw2@infradead.org" , "kyungmin.park@samsung.com" , "gregkh@linuxfoundation.org" , "Menon, Nishanth" , "grinberg@compulab.co.il" , "notasas@gmail.com" , "artem.bityutskiy@linux.intel.com" , "vimal.newwork@gmail.com" , "dbaryshkov@gmail.com" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-usb@vger.kernel.org" , "linux-mtd@lists.infradead.org" Hi Afzal, On 05/08/2012 01:24 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote: > >>> Clk_prd is a platform data passed to the driver, so platform code >>> updates it, where else can it be done ? >> >> The point is that you can pass what ever you like. You do not need to >> pass the frequency you can pass the clock handle instead. > > As clk rate is required in platform code for timing calculation, and > already available, period was passed Sure. >> >> What happens it the clk_get() of the gpmc_l3_clk fails during the init? > > Thanks for bringing this point, invalid clk_prd has to be handled by driver. > >> >> In fact if you migrate to runtime pm then we should not have the clk_get >> in the gpmc_init any more. > > Even if converted to RPM, to get clk rate, clk_get has to be done > somewhere, right ? Yes exactly. However, you could now do this in the driver itself like the probe function. Or may be just pass the frequency of the gpmc fclk to the driver and let the driver convert to the period. No reason we need to convert to the period outside of the driver. Hence, we can keep the function to do the conversion static in the driver and don't need to expose externally. Jon From mboxrd@z Thu Jan 1 00:00:00 1970 From: jon-hunter@ti.com (Jon Hunter) Date: Tue, 8 May 2012 10:13:19 -0500 Subject: [PATCH v4 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD In-Reply-To: References: <4FA04A8C.4050703@ti.com> <4FA4041D.9010000@ti.com> <4FA7F473.7060607@ti.com> Message-ID: <4FA9380F.90700@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Afzal, On 05/08/2012 01:24 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote: > >>> Clk_prd is a platform data passed to the driver, so platform code >>> updates it, where else can it be done ? >> >> The point is that you can pass what ever you like. You do not need to >> pass the frequency you can pass the clock handle instead. > > As clk rate is required in platform code for timing calculation, and > already available, period was passed Sure. >> >> What happens it the clk_get() of the gpmc_l3_clk fails during the init? > > Thanks for bringing this point, invalid clk_prd has to be handled by driver. > >> >> In fact if you migrate to runtime pm then we should not have the clk_get >> in the gpmc_init any more. > > Even if converted to RPM, to get clk rate, clk_get has to be done > somewhere, right ? Yes exactly. However, you could now do this in the driver itself like the probe function. Or may be just pass the frequency of the gpmc fclk to the driver and let the driver convert to the period. No reason we need to convert to the period outside of the driver. Hence, we can keep the function to do the conversion static in the driver and don't need to expose externally. Jon