Hi,
> > 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.
Worse to stall the processor. If you look at the ETM trace output of programming the timer you will see the whole call path to writing to the timer takes some few uS. By you can be stuck at the writing of the timer registers up to 90uS (if f-clk is set to 32khz).
By allowing frequent accesses you:
- don't meet the deadline anyway
- program a wake for 20uS it won't signal till 90uS anyway.
- you can at least query and round to get what the hardware supports if the interface is set properly.
- you stall the processor and waste cycles.
> I guess you would want to make min_delta_ns bigger to avoid excessive
> scheduling/wakeups, but I think there is no any single "correct" value
> for every system/board.
The correct value for the chip timer IP is 3 if the functional clock is at 32MHz. If you use a faster time base like 12Mhz use 1. Next, If you want to try and factor in the software cost you can try. This software cost (what DPLL rate am I at, how much code is executed on path, ...) will be very board and port specific.
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
