INTRNG (Was: svn commit: r301453....)

[Nathan Whitehorn]

On 07/31/16 07:22, Svatopluk Kraus wrote:
> Unfortunatelly, I have no time now to read back all this message
> thread and related ones. Nevertheless, I found time to summarize the
> main ideas about INTRNG design related to this discussion.
>
> Svata

Thank you for the summary. It would be great if you could look at the 
wiki page at https://wiki.freebsd.org/Complicated_Interrupts at some 
point and see how it corresponds to this. In particular, there are five 
cases at the end that I cannot figure out to implement with your API and 
that are essential to support PowerPC. I have a few comments inline below.
-Nathan

>
> -----------------------------------------------------------
>
> INTRNG is designed with three main ideas:
>
> (1) An interrupt is identified by one and only unique number.
> (2) This unique number is assigned only to registered interrupt.
> (3) The framework does not know any interrupt mapping encoding semantics.

This is also true of the previous system; these are good design principles.

> A general intr_map_irq() serves to get this unique number for an
> interrupt mapping. As INTRNG itself does not know any interrupt
> mapping encoding semantics, it pushes the request to a PIC. Of course,
> a PIC specification must be provided as arguments to this function. A
> PIC is specified by either device_t or/and xref (intptr_t). It means
> that such PIC should be already registered in INTRNG.
>
> The idea that INTRNG does not know any interrupt mapping encoding
> semantics is crucial. It makes INTRNG true general framework. Any
> interrupt mapping is fully transparent for INTRNG. Any new interrupt
> mapping semantics can be added without INTRNG concern.
>
> That said, centralized interrupt mapping table is no concern for
> INTRNG as INTRNG works with its interrupt numbers, not with numbers
> associated with something else.

All of this, again, is true of the old code. You provide a PIC 
specification and data meaningful to that PIC, you get back an abstract 
IRQ. The core interrupt code neither knows nor cares about what that 
information means.

>
> In general, an interrupt mapping table can be established anywhere and
> clients of this table may use indexes to this table as interrupt
> specifiers. But if INTRNG bus interface functions are used, a
> translation to INTRNG interrupt numbers must be done (see paragraph
> above about intr_map_irq()). In fact, this is a natural case of
> bridges where interrupts must be remapped.

Yes, of course.

> The main reasons why INTRNG does not use a centralized interrupt
> mapping table instead of an interrupt table are the following:
>
> (1) As not only one interrupt mappings can exist for an interrupt in
> the very same time, it's far more simple, sane, and framework like.
> One interrupt, one interrupt number, one data associated, no need to
> know any interrupt mapping semantics.
>
> (2) An interrupt mapping is associated with consumer driver and
> belongs to this driver or some of its parent driver. It's not both
> sane and newbus like to store an interrupt mapping in some third party
> - in INTRNG in this case.

I agree with this completely. The sticking point is whether you 
associate PIC-specific interrupt data with the interrupt when the bus 
parent enumerates the bus or when resources are allocated with 
bus_alloc_resource().

Doing it at enumeration time means that there is a robust relationship 
between what the interrupt specifier the bus parent meant to assign and 
what actually *is* assigned and fixes a large number of issues where 
interrupts are enumerated by code over which the bus parent does not 
have full control: its children, the MI PCI code, etc.

Doing it when the resources are allocated, as r301453 does, makes it 
much more fragile (as well as a little confusing, since what interrupts 
refer to is only set long after they are allocated). For example, I have 
no idea how to implement PCIB_ROUTE_INTERRUPT(), and so non-MSI PCI 
interrupts, with this framework and MSI interrupts work only in simple 
cases. This is a critical thing: It means I can't support PCI. I could 
hack around the issue with a mapping table and API that records which 
abstract OFW IRQ meant what specifier and iparent and put that in, say, 
nexus, using it to do the right thing when bus_alloc_resource() is later 
called on those specifiers -- but we are immediately back to the 
pre-310453 API at that point. There are a number of examples (not 
complete, but illustrative) of other such cases on the referenced wiki page.
-Nathan

> -----------------------------------------------------------
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>