PCI-Express support

M. Warner Losh imp at bsdimp.com
Sun Aug 1 11:42:39 PDT 2004


In message: <410D2FEA.5050504 at samsco.org>
            Scott Long <scottl at 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).

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


More information about the freebsd-arch mailing list