[PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

[Joel Sherrill]

On 7/15/2015 12:30 PM, Martin Galvan wrote:
> On Wed, Jul 15, 2015 at 12:22 PM, Pavel Pisa <pisa at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985