From owner-freebsd-arch@freebsd.org Sun Jul 31 14:54:39 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AEE19BA9363; Sun, 31 Jul 2016 14:54:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9466A15B2; Sun, 31 Jul 2016 14:54:39 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6VEsaOF003749 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 31 Jul 2016 07:54:36 -0700 Subject: Re: INTRNG (Was: svn commit: r301453....) To: Svatopluk Kraus References: <201606051620.u55GKD5S066398@repo.freebsd.org> <57950005.6070403@FreeBSD.org> <57961549.4020105@FreeBSD.org> <57976867.6080705@FreeBSD.org> <5798E104.5020104@FreeBSD.org> <579A25BB.8070206@FreeBSD.org> <30790e40-58b4-3371-c0f0-b7545571f389@freebsd.org> <579AFFC5.1040005@FreeBSD.org> <8efe4828-ab2a-02a6-902b-8614b1f4b24e@freebsd.org> Cc: "freebsd-arm@freebsd.org" , Michal Meloun , "freebsd-arch@freebsd.org" From: Nathan Whitehorn Message-ID: <17f46646-95b7-3bcd-f652-942c802f7cf7@freebsd.org> Date: Sun, 31 Jul 2016 07:54:36 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbhWuT1q6TGz1sR6C7THvdIp5QWRpLpclfbQOJbhHXV1+oYyy/lalE9IO7Ttd+aa5lUutAdpEhZAorif4r1XwcnWUVlZFSepZ0= X-Sonic-ID: C;Ip7Osi5X5hGDHa/hcgQksw== M;MlA0sy5X5hGDHa/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 14:54:39 -0000 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" >