Page MenuHomeFreeBSD

arm: add an interrupt rman to nexus
AcceptedPublic

Authored by mhorne on Oct 7 2021, 5:58 PM.

Details

Reviewers
ehem_freebsd_m5p.com
ian
Group Reviewers
ARM
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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 42005
Build 38893: arc lint + arc unit

Event Timeline

mhorne requested review of this revision.Oct 7 2021, 5:58 PM

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.

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.

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.

This revision is now accepted and ready to land.Oct 21 2021, 2:39 AM
ian added a subscriber: ian.

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