From owner-svn-src-all@freebsd.org Sat Jul 23 11:04:11 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 B1A7CBA1EFC; Sat, 23 Jul 2016 11:04:11 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.miracle.cz", Issuer "Miracle Group Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DB0C18B2; Sat, 23 Jul 2016 11:04:10 +0000 (UTC) (envelope-from mmel@FreeBSD.org) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id D671E3AC9C; Sat, 23 Jul 2016 13:04:07 +0200 (CEST) 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 , Andrew Turner References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578F6075.7010500@FreeBSD.org> <20160721133742.05f0e045@zapp> <13301107.Hm25rxUxW2@ralph.baldwin.cx> Cc: Nathan Whitehorn , Svatopluk Kraus , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Michal Meloun X-Enigmail-Draft-Status: N1110 Message-ID: <57934F27.9070800@FreeBSD.org> Date: Sat, 23 Jul 2016 13:04:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <13301107.Hm25rxUxW2@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Sat, 23 Jul 2016 13:04:07 +0200 (CEST) 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: Sat, 23 Jul 2016 11:04:11 -0000 Dne 21.07.2016 v 23:35 John Baldwin napsal(a): > 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. > I like this idea. Mainly if we can add 'struct alloc_resource_args' into 'struct resource_list_entry' and, eventually, also into struct resource_i. Inability to pass something more complex as single integer between bus enumerator (aka resource_list_entry creator) and bus_alloc_resource() (aka resource_list_entry consumer) is serious limitation. At lest for me :) Michal