[PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
Jon Hunter
jon-hunter at ti.com
Thu Nov 8 12:39:57 EST 2012
On 11/08/2012 11:08 AM, Hiremath, Vaibhav wrote:
> On Thu, Nov 08, 2012 at 21:46:53, Hunter, Jon wrote:
>>
>> On 11/08/2012 01:59 AM, Igor Grinberg wrote:
>>> On 11/07/12 23:36, Jon Hunter wrote:
>>>> Hi Igor,
>>>>
>>>> On 11/07/2012 08:42 AM, Igor Grinberg wrote:
>>>>> CONFIG_OMAP_32K_TIMER is kind of standing on the single zImage way.
>>>>> Make OMAP2+ timer code independant from the CONFIG_OMAP_32K_TIMER
>>>>> setting.
>>>>> To remove the dependancy, several conversions/additions had to be done:
>>>>> 1) Timer structures and initialization functions are named by the platform
>>>>> name and the clock source in use. The decision which timer is
>>>>> used is done statically from the machine_desc structure. In the
>>>>> future it should come from DT.
>>>>> 2) Settings under the CONFIG_OMAP_32K_TIMER option are expanded into
>>>>> separate timer structures along with the timer init functions.
>>>>> This removes the CONFIG_OMAP_32K_TIMER on OMAP2+ timer code.
>>>>> 3) Since we have all the timers defined inside machine_desc structure
>>>>> and we no longer need the fallback to gp_timer clock source in case
>>>>> 32k_timer clock source is unavailable (namely on AM33xx), we no
>>>>> longer need the #ifdef around __omap2_sync32k_clocksource_init()
>>>>> function. Remove the #ifdef CONFIG_OMAP_32K_TIMER around the
>>>>> __omap2_sync32k_clocksource_init() function.
>>>>>
>>>>> Signed-off-by: Igor Grinberg <grinberg at compulab.co.il>
>>>>> Cc: Jon Hunter <jon-hunter at ti.com>
>>>>> Cc: Santosh Shilimkar <santosh.shilimkar at ti.com>
>>>>> Cc: Vaibhav Hiremath <hvaibhav at ti.com>
>>>>
>>>> [snip]
>>>>
>>>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>>>> index 684d2fc..a4ad7a0 100644
>>>>> --- a/arch/arm/mach-omap2/timer.c
>>>>> +++ b/arch/arm/mach-omap2/timer.c
>>>>> @@ -63,20 +63,8 @@
>>>>> #define OMAP2_32K_SOURCE "func_32k_ck"
>>>>> #define OMAP3_32K_SOURCE "omap_32k_fck"
>>>>> #define OMAP4_32K_SOURCE "sys_32k_ck"
>>>>> -
>>>>> -#ifdef CONFIG_OMAP_32K_TIMER
>>>>> -#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
>>>>> -#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
>>>>> -#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
>>>>> -#define OMAP3_SECURE_TIMER 12
>>>>> #define TIMER_PROP_SECURE "ti,timer-secure"
>>>>> -#else
>>>>> -#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
>>>>> -#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
>>>>> -#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
>>>>> -#define OMAP3_SECURE_TIMER 1
>>>>> -#define TIMER_PROP_SECURE "ti,timer-alwon"
>>>>> -#endif
>>>>> +#define TIMER_PROP_ALWON "ti,timer-alwon"
>>>>
>>>> Nit-pick, can we drop the TIMER_PROP_SECURE/ALWON and use the
>>>> "ti,timer-secure" and "ti,timer-alwon" directly?
>>>>
>>>> Initially, I also defined TIMER_PROP_ALWON and Rob Herring's feedback
>>>> was to drop this and use the property string directly to remove any
>>>> abstraction.
>>>
>>> Well, I don't understand what do you mean by "any abstraction".
>>> The purpose of defining those two was to eliminate multiple occurrences
>>> of the string in the code, so for example if someone decides to change the
>>> property string for some currently unknown reason - it will be easy and small.
>>> Defines are a common practice for that, no?
>>> If you still think it should be inlined, I will do.
>>
>> I understand your point, but right now I don't anticipate that we will
>> have many options here and so I think that we should drop these.
>>
>>>>> #define REALTIME_COUNTER_BASE 0x48243200
>>>>> #define INCREMENTER_NUMERATOR_OFFSET 0x10
>>>>> @@ -216,7 +204,7 @@ void __init omap_dmtimer_init(void)
>>>>>
>>>>> /* If we are a secure device, remove any secure timer nodes */
>>>>> if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
>>>>> - np = omap_get_timer_dt(omap_timer_match, "ti,timer-secure");
>>>>> + np = omap_get_timer_dt(omap_timer_match, TIMER_PROP_SECURE);
>>>>> if (np)
>>>>> of_node_put(np);
>>>>> }
>>>>> @@ -378,9 +366,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> -#ifdef CONFIG_OMAP_32K_TIMER
>>>>> /* Setup free-running counter for clocksource */
>>>>> -static int __init omap2_sync32k_clocksource_init(void)
>>>>> +static int __init __omap2_sync32k_clocksource_init(void)
>>>>
>>>> Not sure I follow why you renamed this function here ...
>>>
>>> I didn't want to add unused arguments to this function, so I've made a
>>> wrapper below to have both the sync32k and the gp functions have the same
>>> signature (argument list) and be called from a single macro.
>>> Anyway, see below.
>>
>> Ok.
>>
>>>>
>>>>> {
>>>>> int ret;
>>>>> struct device_node *np = NULL;
>>>>> @@ -439,15 +426,9 @@ static int __init omap2_sync32k_clocksource_init(void)
>>>>>
>>>>> return ret;
>>>>> }
>>>>> -#else
>>>>> -static inline int omap2_sync32k_clocksource_init(void)
>>>>> -{
>>>>> - return -ENODEV;
>>>>> -}
>>>>> -#endif
>>>>>
>>>>> -static void __init omap2_gptimer_clocksource_init(int gptimer_id,
>>>>> - const char *fck_source)
>>>>> +static void __init omap2_gp_clocksource_init(int gptimer_id,
>>>>> + const char *fck_source)
>>>>
>>>> Nit, I personally prefer keeping gptimer, because gp just means
>>>> "general-purpose" and does not imply a timer per-se.
>>>
>>> I've made this change, so we will not get something like:
>>> omapx_gptimer_timer_init(), but this really does not meter to me,
>>> so no problem will do for v2.
>>
>> Thanks.
>>
>>>>
>>>>> {
>>>>> int res;
>>>>>
>>>>> @@ -466,23 +447,10 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
>>>>> gptimer_id, clksrc.rate);
>>>>> }
>>>>>
>>>>> -static void __init omap2_clocksource_init(int gptimer_id,
>>>>> - const char *fck_source)
>>>>> +static void __init omap2_sync32k_clocksource_init(int gptimer_id,
>>>>> + const char *fck_source)
>>>>> {
>>>>> - /*
>>>>> - * First give preference to kernel parameter configuration
>>>>> - * by user (clocksource="gp_timer").
>>>>> - *
>>>>> - * In case of missing kernel parameter for clocksource,
>>>>> - * first check for availability for 32k-sync timer, in case
>>>>> - * of failure in finding 32k_counter module or registering
>>>>> - * it as clocksource, execution will fallback to gp-timer.
>>>>> - */
>>>>> - if (use_gptimer_clksrc == true)
>>>>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
>>>>> - else if (omap2_sync32k_clocksource_init())
>>>>> - /* Fall back to gp-timer code */
>>>>> - omap2_gptimer_clocksource_init(gptimer_id, fck_source);
>>>>> + __omap2_sync32k_clocksource_init();
>>>>> }
>>>>
>>>> ... this just appears to be a wrapper function, but I don't see why this
>>>> is needed? Do we need this wrapper?
>>>
>>> no, not really, just consider the explanation above.
>>> I will remove the wrapper for v2.
>>
>> Ok, thanks.
>>
>>>>
>>>>> #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
>>>>> @@ -563,52 +531,64 @@ static inline void __init realtime_counter_init(void)
>>>>> {}
>>>>> #endif
>>>>>
>>>>> -#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
>>>>> - clksrc_nr, clksrc_src) \
>>>>> -static void __init omap##name##_timer_init(void) \
>>>>> +#define OMAP_SYS_TIMER_INIT(n, clksrc_name, clkev_nr, clkev_src, \
>>>>> + clkev_prop, clksrc_nr, clksrc_src) \
>>>>> +static void __init omap##n##_##clksrc_name##_timer_init(void) \
>>>>
>>>>
>>>>> { \
>>>>> omap_dmtimer_init(); \
>>>>> omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop); \
>>>>> - omap2_clocksource_init((clksrc_nr), clksrc_src); \
>>>>> + \
>>>>> + if (use_gptimer_clksrc) \
>>>>> + omap2_gp_clocksource_init((clksrc_nr), clksrc_src); \
>>>>> + else \
>>>>> + omap2_##clksrc_name##_clocksource_init((clksrc_nr), \
>>>>> + clksrc_src); \
>>>>
>>>> Something here seems a little odd. If "clksrc_name" is "gp", then the
>>>> if-else parts will call the same function. Or am I missing something here?
>>>
>>> Yes, you are right - this is odd.
>>> What do you think of:
>>>
>>> if (use_gptimer_clksrc) {
>>> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
>>> return;
>>> }
>>> omap2_##clksrc_name##_clocksource_init((clksrc_nr), clksrc_src);
>>
>> Yes, but it still seems a little odd that we could have ...
>>
>> if (use_gptimer_clksrc) {
>> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
>> return;
>> }
>> omap2_gp_clocksource_init((clksrc_nr), clksrc_src);
>>
>>>>
>>>> I think that I prefer how it works today where we call just
>>>> omap2_clocksource_init(), and it determines whether to use the gptimer
>>>> or the 32k-sync.
>>>
>>> There is no reliable way to determine which source should be used in runtime
>>> for boards that do not have the 32k oscillator wired.
>>
>> Hmmm ... well for OMAP devices the 32kHz clock is mandatory AFAIK. At
>> least for OMAP devices and I would need to check on the AM33xx but I
>> would imagine they are the same. Which devices are you referring to
>> where the 32kHz is optional?
>>
> No we do not have 32k_counter block in AM335x.
I am painfully aware of that :-)
> If you are referring to 32Khz clock availability alone, then yes, we need to
> get persistent clock and we use RTC 32Khz clock source for it.
> But please note that this is not a 32k_counter block which OMAP family of
> devices has.
>
> The way AM335x works is, we have timers (0-7), timer0 being secure timer.
> We use timer1 and timer2 for clockevent and clocksource and they are driven
> by 26MHz OSC clock currently. So when you go into Low power state, OSC is turned off and you need persistent clock for time keeping, right?
>
> And only persistent clock available is RTC 32khz crystal clock, being RTC is
> in wakeup domain.
I think you are missing the point here. For OMAP devices we have two
main external clock sources which are the 32kHz clock and the sys_clk
(can be a range of frequencies from 12-38.4MHz for OMAP4). The point is
for OMAP these clock sources are always present and AFAIK there is no
h/w configuration that allows you not to have the 32kHz clock source.
PRCM needs it and I think for OMAP1 the reset logic needs it (if memory
serves).
Igor was mentioning a h/w scenario where the 32kHz source is not
present. However, I am not sure which devices support this and is
applicable too.
So we are not discussing the 32k-sync-timer here. We are discussing
whether there are any device configurations where a 32k clock source
would not be available for the gptimer.
Jon
More information about the linux-arm-kernel
mailing list