From owner-svn-src-head@freebsd.org Fri Jul 22 21:00:00 2016 Return-Path: Delivered-To: svn-src-head@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 8D4FDBA1805; Fri, 22 Jul 2016 21:00:00 +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 77E9F1502; Fri, 22 Jul 2016 21:00:00 +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 u6MKxwKM027862 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Jul 2016 13:59:58 -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: Andrew Turner , 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> <20160722215351.5fbb2a49@zapp> Cc: Michal Meloun , Svatopluk Kraus , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Nathan Whitehorn Message-ID: <32fbc7f3-eb27-29f6-f7d7-7e05b7c2f07e@freebsd.org> Date: Fri, 22 Jul 2016 13:59:58 -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: <20160722215351.5fbb2a49@zapp> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbDZgjPIjLf106nj/Blm0n1rCygC+q+N3O9hR/h0Q6R5XAkKWGRoNBT7LxeWAXAW5w7HTQbUjq6TPDwuAIrjdC8Mx8cEIbxrVw= X-Sonic-ID: C;DkfZP09Q5hGckpNwxPCmMQ== M;Do8EQE9Q5hGckpNwxPCmMQ== X-Spam-Flag: No X-Sonic-Spam-Details: 2.5/5.0 by cerberusd X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 21:00:00 -0000 On 07/22/16 13:53, Andrew Turner wrote: > On Fri, 22 Jul 2016 13:19:32 -0700 > 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. > For some planes the structure would look more like a directed > graph. Devices can have multiple clock parents, e.g. one for the > register interface, and another to drive the external bus. > > I can also imagine the case where a device could have multiple > interrupt parents, an MMC/SD controller comes to mind where it may have > an interrupt on a GPIO line to detect the card being inserted, with > another for command completion, etc. In this case one parent would be > the standard interrupt controller, with the other being the GPIO > controller. > > Andrew > That's a good point for the generalized system (this already works for the specific case of interrupts, of course). It's more the resources that have a non-bus parent than the device. There are also devices with multiple bus parents, but those are more oddball kinds of things (Apple made some on-board PCI devices that are also connected by a second non-PCI path). -Nathan