Hi Albert,

On 22.06.2013 11:58, Albert ARIBAUD 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:

• CONFIG_USE_IRQ is very general and imprecise as far as overall meaning goes. It does not say "allow drivers to use IRQs", or "IRQs are provided by supporting this specific interrupt controller", or "this driver requires IRQs to work". It does not help us either that the option was never documented...

• CONFIG_USE_IRQ is, OTOH, very specific as far as interrupt types go. IRQ is an acronym known in ARM for a specific type of interrupt, but ARM also knows FIQ. IRQ may have a different meaning for another architecture, and each platform has its own classification and attributes for interrupts.

• no API is defined for registering interrupt controller or interrupt client drivers.

But the worst part is, CONFIG_USE_IRQ is never *ever* defined. :)

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?

I know that interrupts are currently used on PowerPC for the PPC4xx ethernet driver (emac). This could be reworked to of cause, but I just wanted to point this out.

I have no idea if interrupts are used on any ARM platform though.

Thanks, Stefan

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