Date: Sun, 01 Aug 2004 14:43:16 -0600 From: Scott Long <scottl@samsco.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: PCI-Express support Message-ID: <410D55E4.40101@samsco.org> In-Reply-To: <20040801.144130.31235788.imp@bsdimp.com> References: <410D2FEA.5050504@samsco.org> <20040801.124125.27781564.imp@bsdimp.com> <410D51AF.4070708@samsco.org> <20040801.144130.31235788.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > In message: <410D51AF.4070708@samsco.org> > Scott Long <scottl@samsco.org> writes: > : M. Warner Losh wrote: > : > In message: <410D2FEA.5050504@samsco.org> > : > Scott Long <scottl@samsco.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?410D55E4.40101>