PCI-Express support

[Scott Long]

M. Warner Losh wrote:
> 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).

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