From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:27:25 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 2B7C516A4D1 for ; Sun, 1 Aug 2004 20:27:25 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CE3743D39 for ; Sun, 1 Aug 2004 20:27:24 +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 i71KYfkK031456; Sun, 1 Aug 2004 14:34:41 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <410D51AF.4070708@samsco.org> Date: Sun, 01 Aug 2004 14:25:19 -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> In-Reply-To: <20040801.124125.27781564.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:27:25 -0000 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. > > You then would just trap the SYS_RES_MESSAGE at the right places to > configure things. In this case, the right places would be the pci > bridge code. There would be no need to have separate drivers for > PCI-Express for the short term, since you could easily flag things as > failures for non express bridges. > > Warner MSI support will be mostly in the PIC/APIC abstraction that exists now. I don't expect the upper-level bus code to change much. Scott