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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
