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