[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
jon-hunter at ti.com
Thu Jun 14 14:58:44 EDT 2012
On 06/14/2012 08:32 AM, Mohammed, Afzal wrote:
> Hi Jon,
> On Thu, Jun 14, 2012 at 18:52:55, Hunter, Jon wrote:
>> On 06/14/2012 02:03 AM, Mohammed, Afzal wrote:
>>> 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?
> Please see Russell King's comments,
>  http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/27634
>  http://firstname.lastname@example.org/msg05365.html
Thanks. So I still think you need to get rid of the global variable for
storing the gpmc fclk, that is really my point.
So if you look at commit  mentioned by Russell in the above thread,
the appropriate thing to do would be to create a gpmc clock alias for
all OMAP2+ devices and then you could simply call the following from the
gpmc probe ...
gpmc_fck = clk_get(&pdev->dev, "fck");
You could then store somewhere in one of the gpmc structures.
More information about the linux-arm-kernel