Dear Wolfgang
Wolfgang Denk wrote:
> What exactly is the reason that we cannot have better timer
> resolutions in NIOS?
You _can_ have better timer resolutions in Nios. However, there
are legacy systems that implement timer(s) with a fixed period
of 10 msec. The use of such implementations is very common.
How do I know? Because my customers have such implementations.
Why not upgrade? Because most sane engineers are loathe to
change their rtl just so they can fix a simple software bug
or add a simple custom feature.
My obvious preference is to continue to use the latest u-boot in
such systems ... without having to create a custom branch for
customers with older Nios implementations, where I use the old
timer interfaces ... simply because we "improved" the API.
> Scott, maybe you can comment here?
I have only one comment: Out of pure frustration, I have been
avoiding any discussions regarding this timer re-write effort.
> At the moment I'm trying to understand if we really have a problem on
> NIOS2 that cannot be fixed in a way that is compatible with our
> current plans.
This is where my frustration begins. I've said this several times
before, and I don't know how else to say this ... but I'll give it
one more try:
This is not a Nios problem.
If I can't use a 10 msec timer interrupt to detect a simple timeout
condition when I'm programming a flash memory, then the timer API
design is garbage. And quite frankly, the enormous amount of
discussion in this matter reminds me of an undergraduate science
project.
> We also have to deal with decrementing counters, but this is just aan
> unimportant detail. And it appears that we actually can have this,
> even on NIOS.
Wow! Even on Nios! Arrggghh!
> The only architecture I remember that seemed prolematic was NIOS
Really? There have been occasional issues that have required a patch
here and there. But I consider most of them far from "problematic."
This is exhausting. As I recall, this entire fuss was born out
of an issue with nested calls to get_timer() ... and that begat
removing reset_timer ... and that begat ... and so on. And we're
still spilling lots of intellectual seed here. And now we have
what? A jack-of-all-trades API that can do everything with
exacting precision ... other than handling a 10 msec interrupt?
Best Regards,
--Scott
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
