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

[Pavel Pisa]

Hello Martin,

On Wednesday 15 of July 2015 16:58:02 Martin Galvan wrote:
> On Wed, Jul 15, 2015 at 11:41 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> > the code has been tested for internal RAM now.
> > We have more cleanups in the mind but headers are critical
> > for now. Premek is working on that, time for feedback
> > form previous e-mail passed without input so he plans
> > to send prepared changes as patch intended for inclusion/final
> > review today.
>
> I'll admit that was my fault, at least partially. I didn't have time
> to test the new headers, mostly because I'd have to change all of our
> (and HALCoGen's) init code to actually use them. In any case, are
> these tested by loading RTEMS from both internal RAM and flash?
>
> I'd still like to have a say on the naming when the patch is sent, if
> it's not too late.
>
> > As for time resolution, we have made initial assumption
> > that 1usec is reasonable and has advantage, that it can be
> > maintained constant even if there are different PLL setups
> > between boards. Other option is to set resolution exactly
> > to PLL clock but at least I do not see big added value in that.
>
> I don't think we should make this kind of assumptions when both the
> manual and TI's tools say otherwise, for a number of reasons:
>
> 1) We're not 100% sure it'll work the same in all configurations.
> 2) Any future maintainers will suspect something's wrong when they
> compare this to the HALCoGen code.
> 3) Any future bugs will have us coming back to this patch to check if
> it's not causing them.
> 4) It's not really necessary to make this change, nor it's too big of
> a deal to use the HALCoGen formula.

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.
If there is consensus that timer resolution should be equal
to the PLL clock then we would prepare next patch.
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. 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.

But this is only my weak personal preference so if there are arguments
to change concept/resolution than it is OK for me.

Best wishes,

             Pavel