From owner-svn-src-head@freebsd.org Thu Jul 21 21:39:50 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 01F53BA102D; Thu, 21 Jul 2016 21:39:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D177A14AD; Thu, 21 Jul 2016 21:39:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5ACC5B94A; Thu, 21 Jul 2016 17:39:48 -0400 (EDT) From: John Baldwin To: Andrew Turner Cc: Michal Meloun , Nathan Whitehorn , Svatopluk Kraus , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org 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 Date: Thu, 21 Jul 2016 14:35:48 -0700 Message-ID: <13301107.Hm25rxUxW2@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160721133742.05f0e045@zapp> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578F6075.7010500@FreeBSD.org> <20160721133742.05f0e045@zapp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 21 Jul 2016 17:39:48 -0400 (EDT) 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: Thu, 21 Jul 2016 21:39:50 -0000 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(). 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. I would let the particular structure have different layouts for different resource types. On x86 we would replace bus_config_intr by passing the level and trigger-mode in this structure. However, I could also see allowing the memattr to be set for a SYS_RES_MEMORY resource so you could have a much shorter way than an explicit bus_map_resource to map an entire BAR as WC for example: struct alloc_resource_args { size_t len; union { struct { enum intr_trigger trigger; enum intr_polarity polarity; } irq; struct { vm_memattr_t memattr; } memory; } } ... union alloc_resource_args args; init_alloc_resource_args(&args, sizeof(args)); args.memattr = VM_MEMATTR_WRITE_COMBINING; /* Uses WC for the implicit mapping. */ res = bus_alloc_resource(...., &args); ... foobus_alloc_resource(..., union alloc_resource_args *args) { union alloc_resource_args args2; switch (type) { case SYS_RES_IRQ: if (args == NULL) { init_alloc_resource_args(&args2, sizeof(args2)); args = &args2; } /* Replace call to BUS_CONFIG_INTR on ACPI: */ if (args->irq.polarity == INTR_POLARITY_CONFORMING && device_has_polarity_from_CRS) args->irq.polarity = polarity_from_CRS; ... } However, you could associate arbitrary data with a resource request by adding more members to the approriate struct in the union. -- John Baldwin