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)
Jan 3 2024, 4:46 AM
Unknown Object (File)
Dec 30 2023, 10:33 AM
Unknown Object (File)
Dec 30 2023, 10:05 AM
Unknown Object (File)
Dec 27 2023, 8:15 AM
Unknown Object (File)
Dec 20 2023, 4:31 AM
Unknown Object (File)
Dec 10 2023, 9:28 AM
Unknown Object (File)
Sep 6 2023, 7:06 AM
Unknown Object (File)
Aug 15 2023, 9:06 PM

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.