On 7/15/2015 12:30 PM, Martin Galvan wrote:
On Wed, Jul 15, 2015 at 12:22 PM, Pavel Pisa <p...@cmp.felk.cvut.cz> wrote:
Patch provides way to the previous working state at least.
I would suggest to apply this patch because current mainline is broken
in actual state - time read goes totally unrelated to the delay functions.
Could you elaborate a bit more on why is this happening, and why does
this patch fix it? We've done some testing in the past and we never
saw such behavior. I could be wrong, though.
Is this similar to the bug fixed recently on the Pi BSP where
it had a hard-coded tick value in the driver? It ignored the
configured microseconds per tick value.
It requires more changes in the code because else the tick configuration
would be incorrect, so you read right time but all timing/delay functions
would be 90x or so times times faster.
Does this apply to the patch as it is, or only if we keep it like it
was before? What I mean is, is there a follow-up to this patch that
fixes the issue you mention?
As for common 1 usec, we use different
clock (i.e. 160 MHz and even other) on different test boards so I like
idea of common base for precise trimming and possible high resolution
POSIX nanosleep functionality with use of fixed conversion ratio instead
of runtime at startup computed one. We even consider lop power operation
and have demand for such mode from carmaker.
I still don't think we should just assume 1 usec will work in every
case and happily ignore what TI gives us. But it's not up to me to
decide what goes in.
It doesn't matter what the lowest resolution is. What is important
is that:
(1) rtems_clock_tick() is invoked every configured microseconds
per tick.
(2) the driver can provide the amount of time since the last
clock tick so timestamps and time of day have the highest
granularity appropriate to support.
I am not sure what the issue the patch is trying to fix.
Low power would move you to what is commonly called a tickless
system but I prefer to think of as a variable tick.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
