Date: Sun, 31 Jul 2016 16:22:13 +0200 From: Svatopluk Kraus <skra@freebsd.org> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Michal Meloun <mmel@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: INTRNG (Was: svn commit: r301453....) Message-ID: <CAFHCsPU1_HinEWEDO9OG2NJmJyYFaOJXa5Zthab69WQJFni_%2Bw@mail.gmail.com> In-Reply-To: <8efe4828-ab2a-02a6-902b-8614b1f4b24e@freebsd.org> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ----------------------------------------------------------- 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. 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. 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. 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. -----------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPU1_HinEWEDO9OG2NJmJyYFaOJXa5Zthab69WQJFni_%2Bw>