This change adds support for GPIO interrupts on non-INTRNG platforms.
There are still a lot of things to discuss and settle.
INTRNG provides a PIC interface for newbus devices.
So, in principle, any device (bus) can implement (a subset of) that interface.
And that's what GPIO controllers do.
Non-INTRNG platforms, as such x86, have a much less flexible PIC interface that's not based on newbus.
For example, on x86 it's possible to register PICs only during early boot.
I decided to add yet another PIC interface.
It's newbus based, it's somewhat similar to INTRNG, it's limited to operations that are useful for GPIO.
The interface is designed to be compatible with kern_intr MI interrupt event handling code.
In my design, interrupts are completely local to a bus that provides them.
So far, it is gpiobus alone.
Interrupt sources are managed by the bus.
Interrupt counters are optional and are managed by the bus as well.
Any other interrupt properties are also private to the bus.
The bus does not propagate any interrupt-related bus methods.
So, nexus and MI interrupt management machinery are completely unaware of bus-private interrupts,
which also means no interrupt balancing and shuffling for the private interrupts (which I think is good).
I think that this provides for maximum implementation flexibility and cross-platform portability.
amdgpio driver commonly found on AMD-based x86 hardware is extended to implement the new PIC interface.
The theory of operation is very simple. The driver sets up its own interrupt handler and upon receiving
an interrupt the driver examines status registers to see which pin had an event. Then the driver notifies
its child gpiobus of the pin event.
gpiobus driver is extended with interrupt management code.
It implements newbus methods for interrupt resource allocation, interrupt setup, etc.
It uses MI interrupt event handler KPI to dispatch interrupts to downstream interrupt handlers.
I also tried to support non-child (non-descendant) interrupt consumers.
It works for some definition of works, but I think that we really need to extend subr_bus code
to support cross-tree dependencies between resource providers and consumers.
Maybe that can be done purely "extres" style, but I would be more comfortable if the bus code
was also aware of such dependencies.
There are some implementation wrinkles and many things to discuss about the design.
But the code works.