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 <p...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
