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

[Martin Galvan]

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.

> 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.