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

[Pavel Pisa]

Hello Joel,

On Wednesday 15 of July 2015 20:05:12 Joel Sherrill wrote:
> 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.

the switch to timecounter sweep out support for time after tick
(which is great) and read time resolution is directly timer counter
register resolution. On the other hand, RTEMS as I know,
does not support high resolution timing (nanosleep etc.)
and tickless mode for now. So the target specific tick is required.
I hope that we compute tick period in the (same) timer resolution
right way and configure constant tick right (based on defines).

But read time scaling has been wrong because it used PLL frequency
directly instead of actual divided frequency of timer register edvances.

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

Thanks to prescale of timer to 1 increment per microsecond this
works nicely and without roundup error - if we consider erasonable
crystal providing PLL high frequency exactly divisible to CAN
required 1 MHz clock, RM48 required 12 MHz or ETHERNET required 50/25 MHz.
OK, I do not count error caused by crystal PPM. But generally I do not
expect use of crystal not divisible after PLL multiply to 1 MHz.

We remember and use directly rtems_configuration_get_microseconds_per_tick()
to setup timer.

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

This mechanism is not in use after switch to timecounter
for straight BSPs. Thanks to exact 1 usec timing there is
minimal chance that there would appear offset between task
delays/sleeps and time reads.

Best wishes,

              Pavel