From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:45:21 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 E083316A4CE for ; Sun, 1 Aug 2004 20:45:20 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7814A43D45 for ; Sun, 1 Aug 2004 20:45:20 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i71KqcVD031550; Sun, 1 Aug 2004 14:52:38 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <410D55E4.40101@samsco.org> Date: Sun, 01 Aug 2004 14:43:16 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <410D2FEA.5050504@samsco.org> <20040801.124125.27781564.imp@bsdimp.com> <410D51AF.4070708@samsco.org> <20040801.144130.31235788.imp@bsdimp.com> In-Reply-To: <20040801.144130.31235788.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org 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:45:21 -0000 M. Warner Losh wrote: > 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 Well, this is exactly the problem that I'm trying to solve. What is your suggestion? Also, I'm trying to keep from modifying the bus_setup_intr() API, so it seemed logical to keep bus_alloc_resource and bus_setup_intr functioning exactly as they are today but still provide the added information to the driver in an optional and non-obtrusive way. Scott