From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:42:40 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B496816A4CE for ; Sun, 1 Aug 2004 20:42:40 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AEE643D41 for ; Sun, 1 Aug 2004 20:42:40 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i71Kf1ok012747; Sun, 1 Aug 2004 14:41:01 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Aug 2004 14:41:30 -0600 (MDT) Message-Id: <20040801.144130.31235788.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <410D51AF.4070708@samsco.org> References: <410D2FEA.5050504@samsco.org> <20040801.124125.27781564.imp@bsdimp.com> <410D51AF.4070708@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: PCI-Express support X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2004 20:42:40 -0000 In message: <410D51AF.4070708@samsco.org> Scott Long writes: : M. Warner Losh wrote: : > In message: <410D2FEA.5050504@samsco.org> : > Scott Long writes: : > : In order to keep the API as consistent as possible between classic : > : interrupt sources and MSI sources, I'd like to add a new bus method: : > : : > : int : > : bus_reserve_resource(device_t, int *start, int *end, int *count, int flags); : > : : > : start, end, and count would be passed is as the desired range and would : > : map to the per-function interrupt index in MSI. On return, the range : > : supported and negotiated by the OS, bus, and function would be filled : > : into these values. flags would be something like SYS_RES_MESSAGE. : > : Internal failure of the function would be given in the return value. : > : Whether failure to support MSI should be given as an error code return : > : value can be debated. This function will also program the MSI : > : configuration registers on the device to use the correct message cookie : > : and number of messages. : > : > How is this different than bus_alloc_resource and adding : > SYS_RES_MESSAGE to the list of resources? You can get the same : > information using bus_alloc_resource w/o the RF_ACTIVE flag. : > bus_alloc_resource also has two args, one for the type, and another : > for the flags (which is a different type). start/end should be u_long : > to match newbus' other use of this stuff (actually, they should be a : > typedef, but that's a bigger change). : : bus_alloc_resource can only allocate one resource at a time. With MSI, : you can potentially allocate up to 64 interrupt vectors. You also need : to know up-front how many you can allocate. The point of : bus_reserve_resource is to give you this information before you make : your first allocation. It also will do the initial MSI function : configuration that is needed. bus_alloc_resource can allocate a range of things, so it is not entirely true that you can allocate only one resource at a time. You can put the count in != 1 and have the same information in the reserve API. Then you can ask the resource how big it is and base your decisions on that. You'd then need to have some way of associating subranage of the range you allocated easily, which presently isn't that easy to do, but is needed for a lot of other things. Doing that would solve the issues for msi, as well as having potential benefit to other bus drivers that need to be able to allocate a large range, and then give out subranges to its children. Warner