Integrate interrupt controller drivers into DDF

[Martin Decky]

Currently we have interrupt controller drivers in the kernel and a few standalone drivers in uspace. These are, however, not integrated with the DDF and complex interrupt controller hierarchies (local APIC, IO-APIC, MSI interrupts on PCI, etc.) cannot be controlled in this way.

The goal is to integrate interrupt controller drivers into DDF and export their functionality in a transparent way to the rest of the DDF (ideally without affecting other drivers).

As discussed in the mailing list:

These are the areas where interrupt controllers and their drivers get involved:

(A1) interrupt comes and we need to acknowledge the interrupt in the controller

• the IRQ dispatching is done separately on each architecture
• on ia32 and amd64, we assume one of two probable interrupt controllers (PIC or APIC) and we use the trap_virtual_eoi() function to acknowledge the interrupt in one of them
• for some reason that I can't remember now, we need to be able to specify per IRQ, whether the IRQ is to be acknowledged prior to calling its handler or after
• this is always done in the kernel
• situation on ppc32 is somewhat similar

(A2) interrupt comes and we need to clear it in the controller

• this is what the situation is on sparc64
• there can be various interrupt controllers
  • FHC
  • Sabre
  • Psycho
  • …
• need to clear the interrupt in the interrupt controller after it is serviced or there will be no further interrupts of the same kind
• this is done both in the kernel and in the userspace driver, depending on whether a kernel or userspace driver is used to handle the interrupt
• for this reason, the IRQ structure is passed the cir function and an argument

(C1) a level interrupt comes and we need to clear the condition which caused it before

reenabling interrupts (i.e. before the userspace driver can run)

• level interrupts will keep on reoccurring until the condition which caused them is canceled → unable to return to userspace before the condition is canceled
• canceling of the condition is usually done by reading or writing to one of the device's register
• handling these interrupts in the kernel is relatively straightforward
• handling these interrupts in the userspace is hard and we use the pseudocode for this reason (the driver uploads its interrupt handling top-half pseudocode into the kernel)

(C2) same as (C1), but need to clear the interrupt in the interrupt controller

• I think this is what prevents us from quickly implementing the Mac keyboard driver in userspace (am I right Jiri?)
• the interrupt controller userspace driver will have a different address space from the userspace keyboard driver
  • need to use some form of the pseudocode in the userspace interrupt controller driver?

As you can see, there is a whole variety of options. I believe it is important to find
a system in this mess. For instance, are (A1) and (A2) the same phenomena? And (C1) and
(C2) are the same too because the interrupt can theoretically need to be cleared in
each node along the way from the device, through all possible bridge devices acting as
interrupt controllers up to the root device tree node? Should the userspace device
driver register the interrupt at the parent node instead of the kernel? (The parent
node can delegate sending of these interrupts to the kernel or its own parent).

[Jiri Svoboda]

First we need to (re)define/verify the appropriate interfaces for device drivers. The implementation is then really just cosmetic shifting of code around.

Although the most general case of interrupt routing would be quite complex to implement, the configurations we encounter in practice seem to be much more simple. For example, I hope that we will never need to assemble IRQ pseudo-code from pieces coming from different drivers. KISS principle should be applied.

[Jakub Jermář]

All interrupt controller device drivers have been already DDFied. Do we need to keep this open?

[Jiri Svoboda]

Only the top half has been converted. I would keep this ticket open until we sort out the top half, too. The interrupt controller service cannot be provided via a fixed location service identifier. This prevents more than one bus/interrupt controller to exist.