[U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

[Scott McNutt]

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