arm: add an interrupt rman to nexus

[mhorne]

Summary

Allow the nexus bus to own and manage interrupt resources. Currently,
interrupt resources on this architecture are managed completely by
ofwbus, but it is desirable that system-wide memory and interrupt
resources be managed by the top-level bus.

This is a pre-requisite to moving this resource management out of
ofwbus, in D30554.

[mmel]

on ARM (and on other intrng enabled systems) the interrupt resource does not represent the real interrupt - it is an arbitrarily assigned index that points to opaque interrupt mapping data collected by ofwbus - so multiple different interrupt resources can identify one actual interrupt or similar.

[ehem_freebsd_m5p.com]

This is odd how ARM has an rman_mem, but no irq_rman (PowerPC had neither due to OFW, ARM64 had both due to ACPI). I'm sure it was sensible when done. This looks pretty generic. Should be okay, though I certainly have my quirks as a developer.

sys/arm/arm/nexus.c

178

I dislike this (you already knew) as this is well beyond the limits of anything likely to be seen for several years.

I'm inclined to suggest using INTR_IRQ_INVALID - 1. It will be interesting if interrupt numbers get that large.

181

I favor rman_manage_region(&irq_rman, irq_rman.rm_start, irq_rman.rm_end), but that is the type of developer I am.

[ehem_freebsd_m5p.com]

You already know I really dislike the default range, but I have no reason its use causes actual harm. For the moment, things need to go this way.

[• ian]

In D32357#735518, @ehem_freebsd_m5p.com wrote:

You already know I really dislike the default range, but I have no reason its use causes actual harm. For the moment, things need to go this way.

An rman instance in nexus can't limit the range of interrupt numbers, because it knows nothing about how those numbers get used at higher layers. For example, there could be a scheme that divides the range up into various sub-ranges which are managed by different interrupt controllers. In a scheme like that a PIC that only handles 4 interrupts could still identify one of those interrupts with a number such as '0xF0000002' because that's in the range it owns. (IMO, this example is no more theoretical or far-fetched than your objection.)