[U-Boot] [RFC] interrupt handling

[U-Boot] [RFC] interrupt handling

[Albert ARIBAUD]

Hello all,

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?

Amicalement,
-- 
Albert.

[U-Boot] [RFC] interrupt handling

[Stefan Roese]

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

[U-Boot] [RFC] ARM interrupt handling - was: interrupt handling

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is better to marry than to burn.
                                - Bible ``I Corinthians'' ch. 7, v. 9

[U-Boot] [RFC] interrupt handling

[Lukasz Majewski]

Hi Stefan,

> 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.

For me it looks, like a fundamental decision to support interrupts on
ARM. Do we need them - it's an open question. Does anyone have good use
case for it?

On the other hand I remember that Marek was struggling to introduce new
driver model. It was also a fundamental change and as fair as I know we
don't have it yet finished. 

Anyway it is a good discussion topic :-)


> 
> Thanks,
> Stefan
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group