Hi,
> clockevent_delta2ns() used to initialize min_delta_ns rounds the value
> down, so the result can be too small. When clockevents_program_event()
> is using too small value it will try to program the timer with zero
> ticks stalling the timer queue.
> + clockevent_delta2ns(1, &clockevent_gpt) + 1;
That value is still not correct. The base perhaps should be '3'. The additional +1 is needed if you use a base value of 1 which can cause the error your patch addresses.
clockevent_delta2ns(3, &clockevent_gpt);
min_delta_ns stops the frame work from trying to program an expiry time which may not be achievable due to timer costs.
A write to the timer when it has a 32KHz F-Clock can take ~3 32Khz clock cycles to complete. Hence the cost of '3' not '1'.
If your lucky the write will be posted and not stall the CPU. But just because the IP block has captured the change doesn't mean it will take effect immediately. The write will still have to resynchronization internally with f-clk.
Regards,
Richard W.
--
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
