From owner-svn-src-all@freebsd.org Fri Jul 22 20:42:10 2016 Return-Path: Delivered-To: svn-src-all@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 992D8BA139D; Fri, 22 Jul 2016 20:42:10 +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 84A301877; Fri, 22 Jul 2016 20:42:10 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from aurora.physics.berkeley.edu (aurora.physics.berkeley.edu [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6MKg2at007406 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Jul 2016 13:42:03 -0700 Subject: Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys To: John Baldwin References: <201606051620.u55GKD5S066398@repo.freebsd.org> <13301107.Hm25rxUxW2@ralph.baldwin.cx> <03bcc081-5b93-c2ba-4e9b-e51d0b2e773a@freebsd.org> <2764416.DJT1n7EiEe@ralph.baldwin.cx> Cc: Andrew Turner , Michal Meloun , Svatopluk Kraus , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Nathan Whitehorn Message-ID: <1a118114-836f-92bf-dbc3-38d4266668bb@freebsd.org> Date: Fri, 22 Jul 2016 13:42:02 -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: <2764416.DJT1n7EiEe@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbjSRoqxOZFI06ZzF5WEBWTG8xORVk4thdYcBA3B6dR1cr7MedZu3F9Ntfo1vcujkPHWnTLTza+Y7DN3Y1rngAopWvpo/qz6pE= X-Sonic-ID: C;4v2fvkxQ5hGggpNwxPCmMQ== M;BoLKvkxQ5hGggpNwxPCmMQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 20:42:10 -0000 On 07/22/16 13:19, John Baldwin wrote: > On Thursday, July 21, 2016 10:51:20 PM Nathan Whitehorn wrote: >> On 07/21/16 14:35, John Baldwin wrote: >>> On Thursday, July 21, 2016 01:37:42 PM Andrew Turner wrote: >>>> On Wed, 20 Jul 2016 13:28:53 +0200 >>>> Michal Meloun wrote: >>>>> Dne 19.07.2016 v 17:06 Nathan Whitehorn napsal(a): >>>>>> 2. It partially duplicates the functionality of OFW_BUS_MAP_INTR(), >>>>>> but is both problematically more general and less flexible (it has >>>>>> requirements on timing of PIC attachment vs. driver resource >>>>>> allocation) >>>>> OFW_BUS_MAP_INTR() can parse only OFW based data and expect that >>>>> parsed data are magicaly stored within the call. >>>>> The new method, bus_map_intr(), can parse data from multiple sources >>>>> (OFW, UEFI / ACPI, synthetic[gpio device + pin number]). It also >>>>> returns parsed data back to caller. >>>>> And no, it doesn't add any additional timing requirements . >>>> I've been looking at ACPI on arm64. So far I have not found the need >>>> for this with ACPI as we don't need to send the data to the interrupt >>>> controller driver to be parsed in the way OFW/FDT needs to. >>> ACPI though has a gross hack where we call BUS_CONFIG_INTR on the IRQ >>> in bus_alloc_resource(). >> I hadn't realized that. It looks like you could do essentially the same >> thing we do on PowerPC to clean this up by explicitly mapping the ACPI >> interrupt domains to different PICs with varying default interrupt >> properties. >> >>> What I had advocated in the discussions >>> leading up to this was to have some sort of opaque structure containing >>> a set of properties (the sort of thing bus_map_resource and make_dev_s >>> use) that was passed up at bus_setup_intr() time. >>> I think it should now >>> be passed up at bus_alloc_resource() time instead, but it would allow bus >>> drivers to "decorate" a SYS_RES_IRQ request as it goes up the device tree >>> with properties that the interrupt controller can then associate with >>> the IRQ cookie it allocates in its own code. >> >> We used to do this on PPC and MIPS, and the current code still supports >> it, but it turned out not to be useful in the end for IRQs. The >> hierarchy for IRQs rarely (read: almost never) follows the bus hierarchy >> and often is enumerated in a different order. I have hardware, for >> example, where the children of a single parent bus are all wired to >> different interrupt controllers and sometimes to a mixture of interrupt >> controllers. Those controllers are cascaded in ways that cross the >> newbus tree laterally and, on some of them, the parent device from the >> bus topology has interrupts handled by its own (bus) children. Trying to >> make the newbus parents do something sensible with all of this would be >> crazy and, in the case where parents depend on resources provided by >> their own children, impossible. >> >> This is all to say that, since you want the interrupts to be decorated >> along a path that usually has nothing to do with the newbus hierarchy, >> it doesn't add much to add extra features to resource allocation. >> ofw_bus_map_intr() is a newbus method to support this kind of thing but, >> on all supported platforms, it is implemented only in nexus and no cases >> have appeared where anyone ever wanted anything at the intermediate layers. > Mmm. Another idea that has been bandied about is to create a separate > "plane" in new-bus for an interrupt hierarchy and allow devices to have > "interrupt" parents that are not the same as the "bus" parent. (Additional > planes for power and clocks might also make sense.) The idea is borrowed > from IOKit on Darwin which has multiple planes. The "bus" plane is always > fully populated, but the other planes (Darwin has one for power for example) > can be sparse. ACPI has methods that effectively describe the power plane > on x86. > That's basically what the virtual IRQ code does: it implements a separate IRQ "plane" that is lazily interconnected during bus attachment and then strongly interconnected at configure_final() (i.e. it panics at that point if the topology hasn't converged yet). A generalized version of this concept would be useful for a number of other resource types (power, clocks, GPIOs, etc.) and I would be very happy to see it as a standard part of the OS. -Nathan