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

[Pavel Pisa]

Hello Martin,

On Wednesday 15 of July 2015 19:30:55 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.

What is last mainline version you have checked?

There is complete RTEMS time retrieval subsystem change
and switch to timecounter infrastructure - as I understand
based on BSD concept. I like it much more because
tricks with time after tick cannot reliably work on SMP
and even on UP require interrupts blocking, retry loops
and overflow detections to work reliably.
See Alexander Krutwig patch 

bsps: Convert clock drivers to use a timecounter

https://git.rtems.org/rtems/commit/?id=75acd9e69f906cbd880a17ee4ca705ad7caa92c0

It changes most of BSPs and the change of time retrieval in TMS570
does not reflect how timer is configured and used for tick generation.

We are testing mainline before 4.11 fork and check it without
and with our registers related changes and even if the registers
do not get in then this fix is required because else times goes
wild on TMS570 - read time advances about 3 secs during sleep 240 sec.

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

If there is follow up patch it requires more changes, redefine
tick computation etc. We are trying to restore previous working
state the first. I am not sure if higher resolution resulting
in more often overflows is really needed.

But please, check and think about mainline to ensure future
RTEMS functionality. You should not freeze on arbitrary development
commit if the project is intended for production application
and if it is safety related then it is real/fatal problem
to not declare that source is from stable official version
(at least my view).

I do not expect to switch to 4.11 for our medical application
in at least two next years. We stay on 4.10.x but I follow
development and proceed testing to know that future release
is not heavily broken for our other target.

Try to help us when we try to do TMS570 RTEMS work based
on my belief that it worth to be done for RTEMS but
without any actual or directly foreseen project/funding
backup. Try the code it would ease and shorten this
discussion. Or found another issue. But is the way forwad
instead of need to describe he problem third time.

Best wishes,

             Pavel