Page MenuHomeFreeBSD

arm: add an interrupt rman to nexus
ClosedPublic

Authored by mhorne on Oct 7 2021, 5:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Oct 22, 6:07 PM
Unknown Object (File)
Fri, Oct 18, 10:13 AM
Unknown Object (File)
Oct 3 2024, 3:20 AM
Unknown Object (File)
Sep 23 2024, 11:03 PM
Unknown Object (File)
Sep 21 2024, 2:13 PM
Unknown Object (File)
Sep 21 2024, 5:24 AM
Unknown Object (File)
Sep 12 2024, 11:47 AM
Unknown Object (File)
Sep 6 2024, 12:11 AM

Details

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
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

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
176

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.

179

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

This revision was automatically updated to reflect the committed changes.