Re: [PATCH V4 12/12] ARM: OMAP2+: Simplify dmtimer clock aliases

[Jon Hunter <jon-hunter@ti.com>]

Hi Paul,

On 06/14/2012 03:31 PM, Paul Walmsley wrote:
> Hi Jon
> 
> On Tue, 5 Jun 2012, Jon Hunter wrote:
> 
>> The OMAP dmtimer driver allows you to dynamically configure the functional
>> clock that drives the timer logic. The dmtimer driver uses the device name and
>> a "con-id" string to search for the appropriate functional clock.
>>
>> Currently, we define a clock alias for each functional clock source each timer
>> supports. Some functional clock sources are common to all of the timers on a
>> device and so for these clock sources we can use a single alias with a unique
>> con-id string.
>>
>> The possible functional clock sources for an OMAP device are a 32kHz clock,
>> a system (MHz range) clock and (for OMAP2 only) an external clock. By defining
>> a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and
>> timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This
>> reduces code, speeds-up searches and clock initialisation time.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> 
> Sorry to make you change this, but how about adding the optional clock 
> aliases to the hwmod data instead?

Yes, we can do. However, technically these are not optional clocks but
parents clocks. So if you are ok with that we can.

> So rather than:
> 
>> +	CLK(NULL,	"timer_32k_ck",	&func_32k_ck,	CK_243X),
>> +	CLK(NULL,	"timer_sys_ck",	&sys_ck,	CK_243X),
>> +	CLK(NULL,	"timer_ext_ck",	&alt_ck,	CK_243X),
> 
> add something like (rough example):
> 
> static struct omap_hwmod_opt_clk timer_opt_clks[] = {
> 	{ .role = "32k", .clk = "func_32k_ck" },
> 	{ .role = "sys", .clk = "sys_ck" },
> 	{ .role = "alt", .clk = "alt_ck" },
> };
> 
> and then add the .opt_clks and .opt_clks_cnt fields to the struct 
> omap_hwmod records; see for example omap44xx_dss_hwmod.
> 
> Doing it this way will remove the clkdev entries, which we're trying to 
> get rid of.  I hope also that these should be auto-generatable from the 
> hardware data at some point.  And adding the opt_clk data should result in 
> a faster search time for these aliases, since only the omap_hwmod_opt_clk 
> records would need to be iterated over, rather than the clkdev data which 
> is quite a bit larger.

Ok, but what it not clear to me is how I retrieve the clock handle from
the driver. Is there an API I can use to retrieve the optional clocks
using the device structure? In other words, similar to clk_get()?

Cheers
Jon