Hello,
Woodruff, Richard wrote:
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'.
I'm not sure if I see any problem. If the timer programming cost is
bigger than min_delta_ns, the framework should adapt to it.
By setting this value to the cost of the timer operation you allow the frame
work to adapt.
If 5 users call into this api and try and set wake ups at an rate the hardware
can't support, you end up wasting time writing wake ups which can't be met.
Yes, I actually made a test case with hrtimers too see the difference
(though I think I'm also seeing hrtimer/oneshot code still doing some
unnecessary programming...)
Thanks for you patience, I will try to send a new patch.
A.
--
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
