id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	field_blocks	field_dependson	field_seealso
381	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)."	enhancement	new	major		helenos/unspecified	mainline