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

Hi Jon,

On Fri, Jun 15, 2012 at 00:28:44, Hunter, Jon wrote:

On 06/14/2012 08:32 AM, Mohammed, Afzal wrote:

quoted

On Thu, Jun 14, 2012 at 18:52:55, Hunter, Jon wrote:

quoted

quoted

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 at 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