[PATCH v4 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD
Jon Hunter
jon-hunter at ti.com
Tue May 8 11:13:19 EDT 2012
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
More information about the linux-mtd
mailing list