!CONFIG_OMAP_32K_TIMER on OMAP4/panda
diff mbox

Message ID 2A3DCF3DA181AD40BDE86A3150B27B6B0374D103A2@dbde02.ent.ti.com
State New, archived
Headers show

Commit Message

Hemant Pedanekar May 8, 2011, 4:59 a.m. UTC
Hello,

linux-omap-owner@vger.kernel.org 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@ti.com>
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. 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
    TI816X. For other configurations, this code will not be executed unless 32K
    timer is explicitly disabled.
    
    Signed-off-by: Hemant Pedanekar <hemantp@ti.com>


   Hemant--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Kevin Hilman May 13, 2011, 12:53 p.m. UTC | #1
Hi Hemant,

"Pedanekar, Hemant" <hemantp@ti.com> writes:

> Hello,
>
> linux-omap-owner@vger.kernel.org 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@ti.com>
> 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@ti.com>
>
> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

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);
+	omap_hwmod_setup_one(clocksource_hwmod_name);
 
 	gpt = omap_dm_timer_request();
 	if (!gpt)