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
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
