Dear Albert,
In message 20130622115844.0a9b0c9a@lilith you wrote:
From time to time there is discussion about the need for proper interrupt support in U-Boot.
Right now, the only thing left in the source code which remotely looks like interrupt support is a few code sections compiled conditionally under CONFIG_USE_IRQ, and it does not constitute a good approach to interrupt support, if only for the following reasons:
I think we should add as an explanation here thatt allt his refers to the ARM architecture.
For other architectures the situation is different. Some (like PPC) already have working interrupt support.
So I am tempted to start this RFC with a first question: do we *need* interrupts in the first place, and if we do, do we need an organized interrupts subsystem or do we keep an ad hoc approach?
In the strict sense we do not mandatorily _need_ interrupts. We always claim that U-Boot is strictly single-tasking. Of course interrupts can also be used in a strictly single-tasking way (which would essentially be the same as polling), but I would expect that they open a door to multiple parallel threads of execution.
Like other powerful tools this can be very useful, but it can also be dangerous if used without the necessary care.
I the past I have seen a number of situations where the (sensible!) use of interrupts would have significantly reduced the efforts, or allowed for cleaner implementations, or even enbaled to implement certain functionality in a clean way - for example for appearently simple requirements like a blinking status LED.
For example, having just an interrupt based timer implementation could help to implement a few things in a simpler and cleaner way.
My gut feeling is that adding interrupt support would be a good thing.
Best regards,
Wolfgang Denk