[PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

[Mohammed, Afzal]

Hi Jon,

On Fri, Jun 15, 2012 at 00:28:44, Hunter, Jon wrote:
> On 06/14/2012 08:32 AM, Mohammed, Afzal wrote:
> > On Thu, Jun 14, 2012 at 18:52:55, Hunter, Jon wrote:

> >> 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,
> > 
> > [1] http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/27634
> > [2] http://www.mail-archive.com/linux-samsung-soc@vger.kernel.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 [1] 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.

Here clock is required even before driver is probed, i.e for platform to
calculate timings, that has to be passed through platform data.

I understand the necessity for clk rate information in driver, but seems
unless we have a generic way to scale timings for all the kinds of
peripheral, having it may not be of much help.

Regards
Afzal