Date: Sun, 31 Jul 2016 07:54:36 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Svatopluk Kraus <skra@freebsd.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, Michal Meloun <mmel@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: INTRNG (Was: svn commit: r301453....) Message-ID: <17f46646-95b7-3bcd-f652-942c802f7cf7@freebsd.org> In-Reply-To: <CAFHCsPU1_HinEWEDO9OG2NJmJyYFaOJXa5Zthab69WQJFni_%2Bw@mail.gmail.com> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57950005.6070403@FreeBSD.org> <f82018ee-51e7-60fa-2682-f0ef307a52b5@freebsd.org> <57961549.4020105@FreeBSD.org> <e2cace17-0924-2084-5fcf-626f87e41cc3@freebsd.org> <CANCZdfr%2BZ4XxXRY0yMiWXwp=8iKq54y3uJ9-OfAOdfxAs1qdtw@mail.gmail.com> <f94bfd25-fabf-efc3-55c9-cfdfd9e4d6e6@freebsd.org> <CANCZdfpz=z3gc3pyb_Qssa3vGJSnPv_r6J-SWDPPpE9zPYB9=w@mail.gmail.com> <ab44ddb1-515b-94ac-6b12-673b7c53d658@freebsd.org> <57976867.6080705@FreeBSD.org> <f2edac8f-2859-cd98-754e-881e2b2d1e63@freebsd.org> <5798E104.5020104@FreeBSD.org> <a5d43044-1733-6cc7-2e99-e85b60b0fcf3@freebsd.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <eb603349-eb88-866d-7a26-9e026518fd39@freebsd.org> <CAFHCsPXON9xQdLou=0ZXEieMVenL-Og2cpWYucSgD3fTp63%2BTw@mail.gmail.com> <8efe4828-ab2a-02a6-902b-8614b1f4b24e@freebsd.org> <CAFHCsPU1_HinEWEDO9OG2NJmJyYFaOJXa5Zthab69WQJFni_%2Bw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17f46646-95b7-3bcd-f652-942c802f7cf7>