Hi Hemant,
"Pedanekar, Hemant" <hemantp@xxxxxx> writes:
> Hello,
>
> linux-omap-owner@xxxxxxxxxxxxxxx wrote on Saturday, May 07, 2011 10:21 PM:
>
>> On a linux-next kernel built for the Pandaboard, disabling
>> CONFIG_OMAP_32K_TIMER makes the kernel use the gptimer as the
>> clocksource, but this appears to be non-functional. Judging from the
>> all-zeros printk timings and the fact the "sleep 1" hangs indefinitely,
>> it looks like the clocksource reads are always zero.
>>
>> Boot log below and .config attached. Ideas?
>>
>> [ 0.000000] Linux version 2.6.39-rc6-next-20110506+ (rabin@debian)
> [...]
>> [ 0.000000] Freeing init memory: 112K
>
> This looks similar to the issue I observed on TI816X with 32K timer disabled.
>
> I have created following patch (currently a tempfix) for making timekeeping work
> with MPU timer selected (other option is to use ".flags = HWMOD_INIT_NO_RESET"
> in hwmod data for the timer used as clocksource):
>
> commit 77cce922c00ced4407776cc0a1d84cee40b7da90
> Author: Hemant Pedanekar <hemantp@xxxxxx>
> Date: Thu Apr 28 12:59:24 2011 +0530
>
> dmtimer: Initialize the hwmod for timer used as clocksource
>
> Since dmtimer driver still doesn't use hwmods, the 2nd timer used as clocksource
> is not set up.
The driver will never be the one to init the hwmod, it's up to device
level code to do that, so your approach is the right one.
> This results into timekeepoing failure when the timer used as
> clocksource gets reset during hwmod setup.
>
> To prevent this, explicitly call omap_hwmod_setup_one() for timer used as
> clocksource.
>
> Note that is is aplpicable when NOT using 32k timer which is the case for
typo: applicable
> TI816X. For other configurations, this code will not be executed unless 32K
> timer is explicitly disabled.
Also, you can fix up this changelog to say it's not only for 816x, but
for any case where the MPU timer is the clocksource.
> Signed-off-by: Hemant Pedanekar <hemantp@xxxxxx>
>
> diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
> index 3b9cf85..290fbfa 100644
> --- a/arch/arm/mach-omap2/timer-gp.c
> +++ b/arch/arm/mach-omap2/timer-gp.c
> @@ -229,6 +229,11 @@ static void __init omap2_gp_clocksource_init(void)
> "%s: failed to request dm-timer\n";
> static char err2[] __initdata = KERN_ERR
> "%s: can't register clocksource!\n";
> + char clocksource_hwmod_name[8]; /* 8 = sizeof("timerXX0") */
> +
> + /* XXX: This may not be always true, we might get different timer */
> + sprintf(clocksource_hwmod_name, "timer%d", gptimer_id + 1);
Do you have ideas to make an upstream fix for this? As you already
notied, this can't work in the general case (and will fail today on
beagle where gptimer_id gets set to 12.)
Kevin
> + omap_hwmod_setup_one(clocksource_hwmod_name);
>
> gpt = omap_dm_timer_request();
> if (!gpt)
>
> Hemant--
> 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
--
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
