On 10/25/2012 07:18 AM, Jon Hunter wrote:
...
>> @@ -113,6 +114,9 @@ static int omap_timer_interrupt_test(struct omap_dm_timer *gptimer)
>>
>> irq_data.gptimer = gptimer;
>> init_completion(&irq_data.complete);
>> +
>> + omap_dm_timer_enable(gptimer);
>> +
>> omap_dm_timer_set_int_enable(gptimer, OMAP_TIMER_INT_OVERFLOW);
>> omap_dm_timer_set_load_start(gptimer, 0, 0xffffff00);
>>
>> @@ -128,6 +132,8 @@ static int omap_timer_interrupt_test(struct omap_dm_timer *gptimer)
>>
>> omap_dm_timer_stop(gptimer);
>> omap_dm_timer_set_int_enable(gptimer, 0);
>> + omap_dm_timer_disable(gptimer);
>> +
>
> Hmmm ... I am wondering if there is another bug lingering in the dmtimer
> driver. Ideally, the context should be preserved by the driver.
Looking at omap_dm_timer_set_load_start() we have the following code to
restore context ...
if (!(timer->capability & OMAP_TIMER_ALWON)) {
if (omap_pm_get_dev_context_loss_count(&timer->pdev->dev) !=
timer->ctx_loss_count)
omap_timer_restore_context(timer);
}
Can you see if this is getting called for AM33xx for the failing timers?
If not then it would suggest that we are not detecting context loss
correctly and not restoring the context. With the above context restore
code we should not need those extra omap_dm_timer_enable/disable calls.
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
