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@xxxxxx>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
