2000-12-08 22:11:23 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 1994,1995 Stefan Esser, Wolfgang StanglMeier
|
|
|
|
* Copyright (c) 2000 Michael Smith <msmith@freebsd.org>
|
|
|
|
* Copyright (c) 2000 BSDi
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. The name of the author may not be used to endorse or promote products
|
|
|
|
* derived from this software without specific prior written permission.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2003-08-24 17:55:58 +00:00
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
/*
|
|
|
|
* PCI:PCI bridge support.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/systm.h>
|
|
|
|
#include <sys/kernel.h>
|
2004-05-30 17:57:46 +00:00
|
|
|
#include <sys/module.h>
|
2000-12-08 22:11:23 +00:00
|
|
|
#include <sys/bus.h>
|
2002-12-03 08:34:20 +00:00
|
|
|
#include <machine/bus.h>
|
|
|
|
#include <sys/rman.h>
|
2002-11-13 09:42:25 +00:00
|
|
|
#include <sys/sysctl.h>
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
#include <machine/resource.h>
|
|
|
|
|
2003-08-22 06:42:59 +00:00
|
|
|
#include <dev/pci/pcivar.h>
|
|
|
|
#include <dev/pci/pcireg.h>
|
|
|
|
#include <dev/pci/pcib_private.h>
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
#include "pcib_if.h"
|
|
|
|
|
|
|
|
static int pcib_probe(device_t dev);
|
|
|
|
|
|
|
|
static device_method_t pcib_methods[] = {
|
|
|
|
/* Device interface */
|
|
|
|
DEVMETHOD(device_probe, pcib_probe),
|
|
|
|
DEVMETHOD(device_attach, pcib_attach),
|
2005-04-29 06:22:41 +00:00
|
|
|
DEVMETHOD(device_detach, bus_generic_detach),
|
2000-12-08 22:11:23 +00:00
|
|
|
DEVMETHOD(device_shutdown, bus_generic_shutdown),
|
|
|
|
DEVMETHOD(device_suspend, bus_generic_suspend),
|
|
|
|
DEVMETHOD(device_resume, bus_generic_resume),
|
|
|
|
|
|
|
|
/* Bus interface */
|
|
|
|
DEVMETHOD(bus_print_child, bus_generic_print_child),
|
|
|
|
DEVMETHOD(bus_read_ivar, pcib_read_ivar),
|
|
|
|
DEVMETHOD(bus_write_ivar, pcib_write_ivar),
|
|
|
|
DEVMETHOD(bus_alloc_resource, pcib_alloc_resource),
|
|
|
|
DEVMETHOD(bus_release_resource, bus_generic_release_resource),
|
|
|
|
DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
|
|
|
|
DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
|
|
|
|
DEVMETHOD(bus_setup_intr, bus_generic_setup_intr),
|
|
|
|
DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr),
|
|
|
|
|
|
|
|
/* pcib interface */
|
|
|
|
DEVMETHOD(pcib_maxslots, pcib_maxslots),
|
|
|
|
DEVMETHOD(pcib_read_config, pcib_read_config),
|
|
|
|
DEVMETHOD(pcib_write_config, pcib_write_config),
|
|
|
|
DEVMETHOD(pcib_route_interrupt, pcib_route_interrupt),
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
DEVMETHOD(pcib_alloc_msi, pcib_alloc_msi),
|
|
|
|
DEVMETHOD(pcib_release_msi, pcib_release_msi),
|
|
|
|
DEVMETHOD(pcib_alloc_msix, pcib_alloc_msix),
|
|
|
|
DEVMETHOD(pcib_release_msix, pcib_release_msix),
|
2007-05-02 17:50:36 +00:00
|
|
|
DEVMETHOD(pcib_map_msi, pcib_map_msi),
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
{ 0, 0 }
|
|
|
|
};
|
|
|
|
|
2006-01-06 19:22:19 +00:00
|
|
|
static devclass_t pcib_devclass;
|
2000-12-08 22:11:23 +00:00
|
|
|
|
2006-01-06 19:22:19 +00:00
|
|
|
DEFINE_CLASS_0(pcib, pcib_driver, pcib_methods, sizeof(struct pcib_softc));
|
2000-12-08 22:11:23 +00:00
|
|
|
DRIVER_MODULE(pcib, pci, pcib_driver, pcib_devclass, 0, 0);
|
|
|
|
|
2006-10-30 19:18:46 +00:00
|
|
|
/*
|
|
|
|
* Is the prefetch window open (eg, can we allocate memory in it?)
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pcib_is_prefetch_open(struct pcib_softc *sc)
|
|
|
|
{
|
|
|
|
return (sc->pmembase > 0 && sc->pmembase < sc->pmemlimit);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Is the nonprefetch window open (eg, can we allocate memory in it?)
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pcib_is_nonprefetch_open(struct pcib_softc *sc)
|
|
|
|
{
|
|
|
|
return (sc->membase > 0 && sc->membase < sc->memlimit);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Is the io window open (eg, can we allocate ports in it?)
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pcib_is_io_open(struct pcib_softc *sc)
|
|
|
|
{
|
|
|
|
return (sc->iobase > 0 && sc->iobase < sc->iolimit);
|
|
|
|
}
|
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
/*
|
|
|
|
* Generic device interface
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pcib_probe(device_t dev)
|
|
|
|
{
|
|
|
|
if ((pci_get_class(dev) == PCIC_BRIDGE) &&
|
|
|
|
(pci_get_subclass(dev) == PCIS_BRIDGE_PCI)) {
|
|
|
|
device_set_desc(dev, "PCI-PCI bridge");
|
|
|
|
return(-10000);
|
|
|
|
}
|
|
|
|
return(ENXIO);
|
|
|
|
}
|
|
|
|
|
2002-08-26 15:57:08 +00:00
|
|
|
void
|
|
|
|
pcib_attach_common(device_t dev)
|
2000-12-08 22:11:23 +00:00
|
|
|
{
|
|
|
|
struct pcib_softc *sc;
|
2003-08-22 03:11:53 +00:00
|
|
|
uint8_t iolow;
|
Add some sysctl reporting for most pci_pci bridges. We now report
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chip)
and subbus (the number of the highest bus behind this chip).
Normally, this information is reported via bootverbose parameters, but
that's hard to use for debugging in some cases.
This adds reading of pribus to make this happen. In addition, change
the narrow types to u_int to allow for easier reporting via sysctl for
domain, secbus and subbus. This should have no effect, but if it
does, please let me know.
2008-08-16 20:18:40 +00:00
|
|
|
struct sysctl_ctx_list *sctx;
|
|
|
|
struct sysctl_oid *soid;
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
sc = device_get_softc(dev);
|
|
|
|
sc->dev = dev;
|
2000-12-12 13:20:35 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Get current bridge configuration.
|
|
|
|
*/
|
2000-12-13 01:25:11 +00:00
|
|
|
sc->command = pci_read_config(dev, PCIR_COMMAND, 1);
|
2007-09-30 11:05:18 +00:00
|
|
|
sc->domain = pci_get_domain(dev);
|
Add some sysctl reporting for most pci_pci bridges. We now report
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chip)
and subbus (the number of the highest bus behind this chip).
Normally, this information is reported via bootverbose parameters, but
that's hard to use for debugging in some cases.
This adds reading of pribus to make this happen. In addition, change
the narrow types to u_int to allow for easier reporting via sysctl for
domain, secbus and subbus. This should have no effect, but if it
does, please let me know.
2008-08-16 20:18:40 +00:00
|
|
|
sc->pribus = pci_read_config(dev, PCIR_PRIBUS_1, 1);
|
2000-12-12 13:20:35 +00:00
|
|
|
sc->secbus = pci_read_config(dev, PCIR_SECBUS_1, 1);
|
|
|
|
sc->subbus = pci_read_config(dev, PCIR_SUBBUS_1, 1);
|
|
|
|
sc->secstat = pci_read_config(dev, PCIR_SECSTAT_1, 2);
|
|
|
|
sc->bridgectl = pci_read_config(dev, PCIR_BRIDGECTL_1, 2);
|
|
|
|
sc->seclat = pci_read_config(dev, PCIR_SECLAT_1, 1);
|
|
|
|
|
Add some sysctl reporting for most pci_pci bridges. We now report
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chip)
and subbus (the number of the highest bus behind this chip).
Normally, this information is reported via bootverbose parameters, but
that's hard to use for debugging in some cases.
This adds reading of pribus to make this happen. In addition, change
the narrow types to u_int to allow for easier reporting via sysctl for
domain, secbus and subbus. This should have no effect, but if it
does, please let me know.
2008-08-16 20:18:40 +00:00
|
|
|
/*
|
|
|
|
* Setup sysctl reporting nodes
|
|
|
|
*/
|
|
|
|
sctx = device_get_sysctl_ctx(dev);
|
|
|
|
soid = device_get_sysctl_tree(dev);
|
|
|
|
SYSCTL_ADD_UINT(sctx, SYSCTL_CHILDREN(soid), OID_AUTO, "domain",
|
2008-09-03 06:57:21 +00:00
|
|
|
CTLFLAG_RD, &sc->domain, 0, "Domain number");
|
Add some sysctl reporting for most pci_pci bridges. We now report
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chip)
and subbus (the number of the highest bus behind this chip).
Normally, this information is reported via bootverbose parameters, but
that's hard to use for debugging in some cases.
This adds reading of pribus to make this happen. In addition, change
the narrow types to u_int to allow for easier reporting via sysctl for
domain, secbus and subbus. This should have no effect, but if it
does, please let me know.
2008-08-16 20:18:40 +00:00
|
|
|
SYSCTL_ADD_UINT(sctx, SYSCTL_CHILDREN(soid), OID_AUTO, "pribus",
|
2008-09-03 06:57:21 +00:00
|
|
|
CTLFLAG_RD, &sc->pribus, 0, "Primary bus number");
|
Add some sysctl reporting for most pci_pci bridges. We now report
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chip)
and subbus (the number of the highest bus behind this chip).
Normally, this information is reported via bootverbose parameters, but
that's hard to use for debugging in some cases.
This adds reading of pribus to make this happen. In addition, change
the narrow types to u_int to allow for easier reporting via sysctl for
domain, secbus and subbus. This should have no effect, but if it
does, please let me know.
2008-08-16 20:18:40 +00:00
|
|
|
SYSCTL_ADD_UINT(sctx, SYSCTL_CHILDREN(soid), OID_AUTO, "secbus",
|
2008-09-03 06:57:21 +00:00
|
|
|
CTLFLAG_RD, &sc->secbus, 0, "Secondary bus number");
|
Add some sysctl reporting for most pci_pci bridges. We now report
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chip)
and subbus (the number of the highest bus behind this chip).
Normally, this information is reported via bootverbose parameters, but
that's hard to use for debugging in some cases.
This adds reading of pribus to make this happen. In addition, change
the narrow types to u_int to allow for easier reporting via sysctl for
domain, secbus and subbus. This should have no effect, but if it
does, please let me know.
2008-08-16 20:18:40 +00:00
|
|
|
SYSCTL_ADD_UINT(sctx, SYSCTL_CHILDREN(soid), OID_AUTO, "subbus",
|
2008-09-03 06:57:21 +00:00
|
|
|
CTLFLAG_RD, &sc->subbus, 0, "Subordinate bus number");
|
Add some sysctl reporting for most pci_pci bridges. We now report
domain, pribus (the primary bus, eg the bus that this chip is on),
secbus (the secondary bus, eg the bus immediately behind this chip)
and subbus (the number of the highest bus behind this chip).
Normally, this information is reported via bootverbose parameters, but
that's hard to use for debugging in some cases.
This adds reading of pribus to make this happen. In addition, change
the narrow types to u_int to allow for easier reporting via sysctl for
domain, secbus and subbus. This should have no effect, but if it
does, please let me know.
2008-08-16 20:18:40 +00:00
|
|
|
|
2000-12-12 13:20:35 +00:00
|
|
|
/*
|
|
|
|
* Determine current I/O decode.
|
|
|
|
*/
|
2000-12-13 01:25:11 +00:00
|
|
|
if (sc->command & PCIM_CMD_PORTEN) {
|
|
|
|
iolow = pci_read_config(dev, PCIR_IOBASEL_1, 1);
|
|
|
|
if ((iolow & PCIM_BRIO_MASK) == PCIM_BRIO_32) {
|
|
|
|
sc->iobase = PCI_PPBIOBASE(pci_read_config(dev, PCIR_IOBASEH_1, 2),
|
|
|
|
pci_read_config(dev, PCIR_IOBASEL_1, 1));
|
|
|
|
} else {
|
|
|
|
sc->iobase = PCI_PPBIOBASE(0, pci_read_config(dev, PCIR_IOBASEL_1, 1));
|
|
|
|
}
|
2000-12-12 13:20:35 +00:00
|
|
|
|
2000-12-13 01:25:11 +00:00
|
|
|
iolow = pci_read_config(dev, PCIR_IOLIMITL_1, 1);
|
|
|
|
if ((iolow & PCIM_BRIO_MASK) == PCIM_BRIO_32) {
|
|
|
|
sc->iolimit = PCI_PPBIOLIMIT(pci_read_config(dev, PCIR_IOLIMITH_1, 2),
|
|
|
|
pci_read_config(dev, PCIR_IOLIMITL_1, 1));
|
|
|
|
} else {
|
|
|
|
sc->iolimit = PCI_PPBIOLIMIT(0, pci_read_config(dev, PCIR_IOLIMITL_1, 1));
|
|
|
|
}
|
2000-12-12 13:20:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Determine current memory decode.
|
|
|
|
*/
|
2000-12-13 01:25:11 +00:00
|
|
|
if (sc->command & PCIM_CMD_MEMEN) {
|
|
|
|
sc->membase = PCI_PPBMEMBASE(0, pci_read_config(dev, PCIR_MEMBASE_1, 2));
|
|
|
|
sc->memlimit = PCI_PPBMEMLIMIT(0, pci_read_config(dev, PCIR_MEMLIMIT_1, 2));
|
2008-08-20 18:29:59 +00:00
|
|
|
iolow = pci_read_config(dev, PCIR_PMBASEL_1, 1);
|
|
|
|
if ((iolow & PCIM_BRPM_MASK) == PCIM_BRPM_64)
|
|
|
|
sc->pmembase = PCI_PPBMEMBASE(
|
|
|
|
pci_read_config(dev, PCIR_PMBASEH_1, 4),
|
|
|
|
pci_read_config(dev, PCIR_PMBASEL_1, 2));
|
|
|
|
else
|
|
|
|
sc->pmembase = PCI_PPBMEMBASE(0,
|
|
|
|
pci_read_config(dev, PCIR_PMBASEL_1, 2));
|
|
|
|
iolow = pci_read_config(dev, PCIR_PMLIMITL_1, 1);
|
|
|
|
if ((iolow & PCIM_BRPM_MASK) == PCIM_BRPM_64)
|
|
|
|
sc->pmemlimit = PCI_PPBMEMLIMIT(
|
|
|
|
pci_read_config(dev, PCIR_PMLIMITH_1, 4),
|
|
|
|
pci_read_config(dev, PCIR_PMLIMITL_1, 2));
|
|
|
|
else
|
|
|
|
sc->pmemlimit = PCI_PPBMEMLIMIT(0,
|
|
|
|
pci_read_config(dev, PCIR_PMLIMITL_1, 2));
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
2000-12-12 13:20:35 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Quirk handling.
|
|
|
|
*/
|
|
|
|
switch (pci_get_devid(dev)) {
|
2004-01-11 06:52:31 +00:00
|
|
|
case 0x12258086: /* Intel 82454KX/GX (Orion) */
|
2000-12-12 13:20:35 +00:00
|
|
|
{
|
2003-08-22 03:11:53 +00:00
|
|
|
uint8_t supbus;
|
2000-12-12 13:20:35 +00:00
|
|
|
|
|
|
|
supbus = pci_read_config(dev, 0x41, 1);
|
|
|
|
if (supbus != 0xff) {
|
|
|
|
sc->secbus = supbus + 1;
|
|
|
|
sc->subbus = supbus + 1;
|
|
|
|
}
|
2004-01-11 06:52:31 +00:00
|
|
|
break;
|
2000-12-12 13:20:35 +00:00
|
|
|
}
|
2004-01-11 06:52:31 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The i82380FB mobile docking controller is a PCI-PCI bridge,
|
|
|
|
* and it is a subtractive bridge. However, the ProgIf is wrong
|
|
|
|
* so the normal setting of PCIB_SUBTRACTIVE bit doesn't
|
|
|
|
* happen. There's also a Toshiba bridge that behaves this
|
|
|
|
* way.
|
|
|
|
*/
|
|
|
|
case 0x124b8086: /* Intel 82380FB Mobile */
|
|
|
|
case 0x060513d7: /* Toshiba ???? */
|
|
|
|
sc->flags |= PCIB_SUBTRACTIVE;
|
2000-12-12 13:20:35 +00:00
|
|
|
break;
|
2005-08-26 23:39:44 +00:00
|
|
|
|
|
|
|
/* Compaq R3000 BIOS sets wrong subordinate bus number. */
|
|
|
|
case 0x00dd10de:
|
|
|
|
{
|
|
|
|
char *cp;
|
|
|
|
|
2006-04-21 19:35:03 +00:00
|
|
|
if ((cp = getenv("smbios.planar.maker")) == NULL)
|
2005-08-26 23:39:44 +00:00
|
|
|
break;
|
2006-04-21 19:35:03 +00:00
|
|
|
if (strncmp(cp, "Compal", 6) != 0) {
|
|
|
|
freeenv(cp);
|
2005-08-26 23:39:44 +00:00
|
|
|
break;
|
2006-04-21 19:35:03 +00:00
|
|
|
}
|
|
|
|
freeenv(cp);
|
|
|
|
if ((cp = getenv("smbios.planar.product")) == NULL)
|
|
|
|
break;
|
|
|
|
if (strncmp(cp, "08A0", 4) != 0) {
|
|
|
|
freeenv(cp);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
freeenv(cp);
|
2005-08-26 23:39:44 +00:00
|
|
|
if (sc->subbus < 0xa) {
|
|
|
|
pci_write_config(dev, PCIR_SUBBUS_1, 0xa, 1);
|
|
|
|
sc->subbus = pci_read_config(dev, PCIR_SUBBUS_1, 1);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2000-12-12 13:20:35 +00:00
|
|
|
}
|
|
|
|
|
2007-01-13 04:57:37 +00:00
|
|
|
if (pci_msi_device_blacklisted(dev))
|
|
|
|
sc->flags |= PCIB_DISABLE_MSI;
|
|
|
|
|
2004-01-11 06:52:31 +00:00
|
|
|
/*
|
|
|
|
* Intel 815, 845 and other chipsets say they are PCI-PCI bridges,
|
|
|
|
* but have a ProgIF of 0x80. The 82801 family (AA, AB, BAM/CAM,
|
|
|
|
* BA/CA/DB and E) PCI bridges are HUB-PCI bridges, in Intelese.
|
|
|
|
* This means they act as if they were subtractively decoding
|
|
|
|
* bridges and pass all transactions. Mark them and real ProgIf 1
|
|
|
|
* parts as subtractive.
|
|
|
|
*/
|
|
|
|
if ((pci_get_devid(dev) & 0xff00ffff) == 0x24008086 ||
|
2007-03-31 20:41:00 +00:00
|
|
|
pci_read_config(dev, PCIR_PROGIF, 1) == PCIP_BRIDGE_PCI_SUBTRACTIVE)
|
2004-01-11 06:52:31 +00:00
|
|
|
sc->flags |= PCIB_SUBTRACTIVE;
|
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
if (bootverbose) {
|
2007-09-30 11:05:18 +00:00
|
|
|
device_printf(dev, " domain %d\n", sc->domain);
|
2000-12-08 22:11:23 +00:00
|
|
|
device_printf(dev, " secondary bus %d\n", sc->secbus);
|
|
|
|
device_printf(dev, " subordinate bus %d\n", sc->subbus);
|
|
|
|
device_printf(dev, " I/O decode 0x%x-0x%x\n", sc->iobase, sc->iolimit);
|
2006-10-30 19:18:46 +00:00
|
|
|
if (pcib_is_nonprefetch_open(sc))
|
|
|
|
device_printf(dev, " memory decode 0x%jx-0x%jx\n",
|
|
|
|
(uintmax_t)sc->membase, (uintmax_t)sc->memlimit);
|
|
|
|
if (pcib_is_prefetch_open(sc))
|
|
|
|
device_printf(dev, " prefetched decode 0x%jx-0x%jx\n",
|
|
|
|
(uintmax_t)sc->pmembase, (uintmax_t)sc->pmemlimit);
|
|
|
|
else
|
|
|
|
device_printf(dev, " no prefetched decode\n");
|
2004-01-11 06:52:31 +00:00
|
|
|
if (sc->flags & PCIB_SUBTRACTIVE)
|
|
|
|
device_printf(dev, " Subtractively decoded bridge.\n");
|
2000-12-08 22:11:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* XXX If the secondary bus number is zero, we should assign a bus number
|
2008-08-17 17:34:07 +00:00
|
|
|
* since the BIOS hasn't, then initialise the bridge. A simple
|
|
|
|
* bus_alloc_resource with the a couple of busses seems like the right
|
|
|
|
* approach, but we don't know what busses the BIOS might have already
|
|
|
|
* assigned to other bridges on this bus that probe later than we do.
|
|
|
|
*
|
|
|
|
* If the subordinate bus number is less than the secondary bus number,
|
2000-12-08 22:11:23 +00:00
|
|
|
* we should pick a better value. One sensible alternative would be to
|
|
|
|
* pick 255; the only tradeoff here is that configuration transactions
|
2008-08-17 17:34:07 +00:00
|
|
|
* would be more widely routed than absolutely necessary. We could
|
|
|
|
* then do a walk of the tree later and fix it.
|
2000-12-08 22:11:23 +00:00
|
|
|
*/
|
2002-08-26 15:57:08 +00:00
|
|
|
}
|
2000-12-08 22:11:23 +00:00
|
|
|
|
2002-09-06 22:14:00 +00:00
|
|
|
int
|
2002-08-26 15:57:08 +00:00
|
|
|
pcib_attach(device_t dev)
|
|
|
|
{
|
|
|
|
struct pcib_softc *sc;
|
|
|
|
device_t child;
|
|
|
|
|
|
|
|
pcib_attach_common(dev);
|
|
|
|
sc = device_get_softc(dev);
|
2000-12-08 22:11:23 +00:00
|
|
|
if (sc->secbus != 0) {
|
2002-09-06 16:09:07 +00:00
|
|
|
child = device_add_child(dev, "pci", sc->secbus);
|
2000-12-08 22:11:23 +00:00
|
|
|
if (child != NULL)
|
|
|
|
return(bus_generic_attach(dev));
|
2008-08-17 17:34:07 +00:00
|
|
|
}
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
/* no secondary bus; we should have fixed this */
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
|
2002-08-26 15:57:08 +00:00
|
|
|
int
|
2000-12-08 22:11:23 +00:00
|
|
|
pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
|
|
|
|
{
|
|
|
|
struct pcib_softc *sc = device_get_softc(dev);
|
|
|
|
|
|
|
|
switch (which) {
|
2007-09-30 11:05:18 +00:00
|
|
|
case PCIB_IVAR_DOMAIN:
|
|
|
|
*result = sc->domain;
|
|
|
|
return(0);
|
2000-12-08 22:11:23 +00:00
|
|
|
case PCIB_IVAR_BUS:
|
|
|
|
*result = sc->secbus;
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
return(ENOENT);
|
|
|
|
}
|
|
|
|
|
2002-08-26 15:57:08 +00:00
|
|
|
int
|
2000-12-08 22:11:23 +00:00
|
|
|
pcib_write_ivar(device_t dev, device_t child, int which, uintptr_t value)
|
|
|
|
{
|
|
|
|
struct pcib_softc *sc = device_get_softc(dev);
|
|
|
|
|
|
|
|
switch (which) {
|
2007-09-30 11:05:18 +00:00
|
|
|
case PCIB_IVAR_DOMAIN:
|
|
|
|
return(EINVAL);
|
2000-12-08 22:11:23 +00:00
|
|
|
case PCIB_IVAR_BUS:
|
|
|
|
sc->secbus = value;
|
2007-09-30 11:05:18 +00:00
|
|
|
return(0);
|
2000-12-08 22:11:23 +00:00
|
|
|
}
|
|
|
|
return(ENOENT);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We have to trap resource allocation requests and ensure that the bridge
|
|
|
|
* is set up to, or capable of handling them.
|
|
|
|
*/
|
2002-08-26 15:57:08 +00:00
|
|
|
struct resource *
|
2000-12-08 22:11:23 +00:00
|
|
|
pcib_alloc_resource(device_t dev, device_t child, int type, int *rid,
|
2005-02-18 17:35:03 +00:00
|
|
|
u_long start, u_long end, u_long count, u_int flags)
|
2000-12-08 22:11:23 +00:00
|
|
|
{
|
2004-01-11 06:52:31 +00:00
|
|
|
struct pcib_softc *sc = device_get_softc(dev);
|
2006-11-09 18:04:53 +00:00
|
|
|
const char *name, *suffix;
|
2004-01-11 06:52:31 +00:00
|
|
|
int ok;
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Fail the allocation for this range if it's not supported.
|
|
|
|
*/
|
2006-11-09 18:04:53 +00:00
|
|
|
name = device_get_nameunit(child);
|
|
|
|
if (name == NULL) {
|
|
|
|
name = "";
|
|
|
|
suffix = "";
|
|
|
|
} else
|
|
|
|
suffix = " ";
|
2000-12-08 22:11:23 +00:00
|
|
|
switch (type) {
|
|
|
|
case SYS_RES_IOPORT:
|
2002-12-03 08:34:20 +00:00
|
|
|
ok = 0;
|
2004-01-11 06:52:31 +00:00
|
|
|
if (!pcib_is_io_open(sc))
|
|
|
|
break;
|
|
|
|
ok = (start >= sc->iobase && end <= sc->iolimit);
|
2005-04-29 02:15:40 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure we allow access to VGA I/O addresses when the
|
|
|
|
* bridge has the "VGA Enable" bit set.
|
|
|
|
*/
|
|
|
|
if (!ok && pci_is_vga_ioport_range(start, end))
|
|
|
|
ok = (sc->bridgectl & PCIB_BCR_VGA_ENABLE) ? 1 : 0;
|
|
|
|
|
2004-01-11 06:52:31 +00:00
|
|
|
if ((sc->flags & PCIB_SUBTRACTIVE) == 0) {
|
|
|
|
if (!ok) {
|
|
|
|
if (start < sc->iobase)
|
|
|
|
start = sc->iobase;
|
|
|
|
if (end > sc->iolimit)
|
|
|
|
end = sc->iolimit;
|
2005-02-18 17:35:03 +00:00
|
|
|
if (start < end)
|
|
|
|
ok = 1;
|
2004-01-11 06:52:31 +00:00
|
|
|
}
|
2002-11-13 09:42:25 +00:00
|
|
|
} else {
|
2004-01-11 06:52:31 +00:00
|
|
|
ok = 1;
|
2009-03-15 06:40:57 +00:00
|
|
|
#if 0
|
2009-03-14 14:08:53 +00:00
|
|
|
/*
|
|
|
|
* If we overlap with the subtractive range, then
|
|
|
|
* pick the upper range to use.
|
|
|
|
*/
|
|
|
|
if (start < sc->iolimit && end > sc->iobase)
|
|
|
|
start = sc->iolimit + 1;
|
2009-03-15 06:40:57 +00:00
|
|
|
#endif
|
2002-11-13 09:42:25 +00:00
|
|
|
}
|
2004-01-11 06:52:31 +00:00
|
|
|
if (end < start) {
|
2005-02-18 17:35:03 +00:00
|
|
|
device_printf(dev, "ioport: end (%lx) < start (%lx)\n",
|
|
|
|
end, start);
|
2004-01-11 06:52:31 +00:00
|
|
|
start = 0;
|
|
|
|
end = 0;
|
|
|
|
ok = 0;
|
|
|
|
}
|
|
|
|
if (!ok) {
|
2006-11-09 18:04:53 +00:00
|
|
|
device_printf(dev, "%s%srequested unsupported I/O "
|
2004-01-11 06:52:31 +00:00
|
|
|
"range 0x%lx-0x%lx (decoding 0x%x-0x%x)\n",
|
2006-11-09 18:04:53 +00:00
|
|
|
name, suffix, start, end, sc->iobase, sc->iolimit);
|
2004-01-11 06:52:31 +00:00
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
if (bootverbose)
|
2005-02-18 17:35:03 +00:00
|
|
|
device_printf(dev,
|
2006-11-09 18:04:53 +00:00
|
|
|
"%s%srequested I/O range 0x%lx-0x%lx: in range\n",
|
|
|
|
name, suffix, start, end);
|
2004-01-11 06:52:31 +00:00
|
|
|
break;
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
case SYS_RES_MEMORY:
|
2002-12-03 08:34:20 +00:00
|
|
|
ok = 0;
|
|
|
|
if (pcib_is_nonprefetch_open(sc))
|
2004-01-11 06:52:31 +00:00
|
|
|
ok = ok || (start >= sc->membase && end <= sc->memlimit);
|
2002-12-03 08:34:20 +00:00
|
|
|
if (pcib_is_prefetch_open(sc))
|
2004-01-11 06:52:31 +00:00
|
|
|
ok = ok || (start >= sc->pmembase && end <= sc->pmemlimit);
|
2005-04-29 02:15:40 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure we allow access to VGA memory addresses when the
|
|
|
|
* bridge has the "VGA Enable" bit set.
|
|
|
|
*/
|
|
|
|
if (!ok && pci_is_vga_memory_range(start, end))
|
|
|
|
ok = (sc->bridgectl & PCIB_BCR_VGA_ENABLE) ? 1 : 0;
|
|
|
|
|
2004-01-11 06:52:31 +00:00
|
|
|
if ((sc->flags & PCIB_SUBTRACTIVE) == 0) {
|
|
|
|
if (!ok) {
|
|
|
|
ok = 1;
|
|
|
|
if (flags & RF_PREFETCHABLE) {
|
|
|
|
if (pcib_is_prefetch_open(sc)) {
|
|
|
|
if (start < sc->pmembase)
|
|
|
|
start = sc->pmembase;
|
|
|
|
if (end > sc->pmemlimit)
|
|
|
|
end = sc->pmemlimit;
|
|
|
|
} else {
|
|
|
|
ok = 0;
|
|
|
|
}
|
|
|
|
} else { /* non-prefetchable */
|
|
|
|
if (pcib_is_nonprefetch_open(sc)) {
|
|
|
|
if (start < sc->membase)
|
|
|
|
start = sc->membase;
|
|
|
|
if (end > sc->memlimit)
|
|
|
|
end = sc->memlimit;
|
|
|
|
} else {
|
|
|
|
ok = 0;
|
|
|
|
}
|
|
|
|
}
|
2002-12-03 08:34:20 +00:00
|
|
|
}
|
|
|
|
} else if (!ok) {
|
2004-01-11 06:52:31 +00:00
|
|
|
ok = 1; /* subtractive bridge: always ok */
|
2009-03-15 06:40:57 +00:00
|
|
|
#if 0
|
2004-01-11 06:52:31 +00:00
|
|
|
if (pcib_is_nonprefetch_open(sc)) {
|
2009-03-14 14:08:53 +00:00
|
|
|
if (start < sc->memlimit && end > sc->membase)
|
|
|
|
start = sc->memlimit + 1;
|
2004-01-11 06:52:31 +00:00
|
|
|
}
|
|
|
|
if (pcib_is_prefetch_open(sc)) {
|
2009-03-14 14:08:53 +00:00
|
|
|
if (start < sc->pmemlimit && end > sc->pmembase)
|
|
|
|
start = sc->pmemlimit + 1;
|
2004-01-11 06:52:31 +00:00
|
|
|
}
|
2009-03-15 06:40:57 +00:00
|
|
|
#endif
|
2002-11-13 09:42:25 +00:00
|
|
|
}
|
2004-01-11 06:52:31 +00:00
|
|
|
if (end < start) {
|
2005-02-18 17:35:03 +00:00
|
|
|
device_printf(dev, "memory: end (%lx) < start (%lx)\n",
|
|
|
|
end, start);
|
2004-01-11 06:52:31 +00:00
|
|
|
start = 0;
|
|
|
|
end = 0;
|
|
|
|
ok = 0;
|
|
|
|
}
|
|
|
|
if (!ok && bootverbose)
|
|
|
|
device_printf(dev,
|
2006-11-09 18:04:53 +00:00
|
|
|
"%s%srequested unsupported memory range %#lx-%#lx "
|
2006-10-30 19:18:46 +00:00
|
|
|
"(decoding %#jx-%#jx, %#jx-%#jx)\n",
|
2006-11-09 18:04:53 +00:00
|
|
|
name, suffix, start, end,
|
2006-10-30 19:18:46 +00:00
|
|
|
(uintmax_t)sc->membase, (uintmax_t)sc->memlimit,
|
|
|
|
(uintmax_t)sc->pmembase, (uintmax_t)sc->pmemlimit);
|
2004-01-11 06:52:31 +00:00
|
|
|
if (!ok)
|
|
|
|
return (NULL);
|
|
|
|
if (bootverbose)
|
2006-11-09 18:04:53 +00:00
|
|
|
device_printf(dev,"%s%srequested memory range "
|
2005-02-18 17:35:03 +00:00
|
|
|
"0x%lx-0x%lx: good\n",
|
2006-11-09 18:04:53 +00:00
|
|
|
name, suffix, start, end);
|
2004-01-11 06:52:31 +00:00
|
|
|
break;
|
2000-12-12 13:20:35 +00:00
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
default:
|
2004-01-11 06:52:31 +00:00
|
|
|
break;
|
2000-12-08 22:11:23 +00:00
|
|
|
}
|
2004-01-11 06:52:31 +00:00
|
|
|
/*
|
|
|
|
* Bridge is OK decoding this resource, so pass it up.
|
|
|
|
*/
|
2005-02-18 17:35:03 +00:00
|
|
|
return (bus_generic_alloc_resource(dev, child, type, rid, start, end,
|
|
|
|
count, flags));
|
2000-12-08 22:11:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PCIB interface.
|
|
|
|
*/
|
2002-08-26 15:57:08 +00:00
|
|
|
int
|
2000-12-08 22:11:23 +00:00
|
|
|
pcib_maxslots(device_t dev)
|
|
|
|
{
|
2000-12-12 13:20:35 +00:00
|
|
|
return(PCI_SLOTMAX);
|
2000-12-08 22:11:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since we are a child of a PCI bus, its parent must support the pcib interface.
|
|
|
|
*/
|
2003-08-22 03:11:53 +00:00
|
|
|
uint32_t
|
2009-03-14 14:08:53 +00:00
|
|
|
pcib_read_config(device_t dev, u_int b, u_int s, u_int f, u_int reg, int width)
|
2000-12-08 22:11:23 +00:00
|
|
|
{
|
|
|
|
return(PCIB_READ_CONFIG(device_get_parent(device_get_parent(dev)), b, s, f, reg, width));
|
|
|
|
}
|
|
|
|
|
2002-08-26 15:57:08 +00:00
|
|
|
void
|
2009-03-14 14:08:53 +00:00
|
|
|
pcib_write_config(device_t dev, u_int b, u_int s, u_int f, u_int reg, uint32_t val, int width)
|
2000-12-08 22:11:23 +00:00
|
|
|
{
|
|
|
|
PCIB_WRITE_CONFIG(device_get_parent(device_get_parent(dev)), b, s, f, reg, val, width);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Route an interrupt across a PCI bridge.
|
|
|
|
*/
|
2003-01-14 11:37:56 +00:00
|
|
|
int
|
2000-12-08 22:11:23 +00:00
|
|
|
pcib_route_interrupt(device_t pcib, device_t dev, int pin)
|
|
|
|
{
|
|
|
|
device_t bus;
|
|
|
|
int parent_intpin;
|
|
|
|
int intnum;
|
|
|
|
|
|
|
|
/*
|
|
|
|
*
|
|
|
|
* The PCI standard defines a swizzle of the child-side device/intpin to
|
|
|
|
* the parent-side intpin as follows.
|
|
|
|
*
|
|
|
|
* device = device on child bus
|
|
|
|
* child_intpin = intpin on child bus slot (0-3)
|
|
|
|
* parent_intpin = intpin on parent bus slot (0-3)
|
|
|
|
*
|
|
|
|
* parent_intpin = (device + child_intpin) % 4
|
|
|
|
*/
|
2003-05-22 17:45:26 +00:00
|
|
|
parent_intpin = (pci_get_slot(dev) + (pin - 1)) % 4;
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Our parent is a PCI bus. Its parent must export the pcib interface
|
|
|
|
* which includes the ability to route interrupts.
|
|
|
|
*/
|
|
|
|
bus = device_get_parent(pcib);
|
|
|
|
intnum = PCIB_ROUTE_INTERRUPT(device_get_parent(bus), pcib, parent_intpin + 1);
|
2004-07-01 07:46:29 +00:00
|
|
|
if (PCI_INTERRUPT_VALID(intnum) && bootverbose) {
|
2002-09-05 17:08:35 +00:00
|
|
|
device_printf(pcib, "slot %d INT%c is routed to irq %d\n",
|
|
|
|
pci_get_slot(dev), 'A' + pin - 1, intnum);
|
2002-02-12 01:28:49 +00:00
|
|
|
}
|
2000-12-08 22:11:23 +00:00
|
|
|
return(intnum);
|
|
|
|
}
|
2002-11-22 17:50:47 +00:00
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
/* Pass request to alloc MSI/MSI-X messages up to the parent bridge. */
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
int
|
|
|
|
pcib_alloc_msi(device_t pcib, device_t dev, int count, int maxcount, int *irqs)
|
|
|
|
{
|
2007-05-23 15:31:00 +00:00
|
|
|
struct pcib_softc *sc = device_get_softc(pcib);
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
device_t bus;
|
|
|
|
|
2007-01-13 04:57:37 +00:00
|
|
|
if (sc->flags & PCIB_DISABLE_MSI)
|
|
|
|
return (ENXIO);
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
bus = device_get_parent(pcib);
|
|
|
|
return (PCIB_ALLOC_MSI(device_get_parent(bus), dev, count, maxcount,
|
|
|
|
irqs));
|
|
|
|
}
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
/* Pass request to release MSI/MSI-X messages up to the parent bridge. */
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
int
|
|
|
|
pcib_release_msi(device_t pcib, device_t dev, int count, int *irqs)
|
|
|
|
{
|
|
|
|
device_t bus;
|
|
|
|
|
|
|
|
bus = device_get_parent(pcib);
|
|
|
|
return (PCIB_RELEASE_MSI(device_get_parent(bus), dev, count, irqs));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Pass request to alloc an MSI-X message up to the parent bridge. */
|
|
|
|
int
|
2007-05-02 17:50:36 +00:00
|
|
|
pcib_alloc_msix(device_t pcib, device_t dev, int *irq)
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
{
|
2007-05-23 15:31:00 +00:00
|
|
|
struct pcib_softc *sc = device_get_softc(pcib);
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
device_t bus;
|
|
|
|
|
2007-01-13 04:57:37 +00:00
|
|
|
if (sc->flags & PCIB_DISABLE_MSI)
|
|
|
|
return (ENXIO);
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
bus = device_get_parent(pcib);
|
2007-05-02 17:50:36 +00:00
|
|
|
return (PCIB_ALLOC_MSIX(device_get_parent(bus), dev, irq));
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
}
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
/* Pass request to release an MSI-X message up to the parent bridge. */
|
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support.
- First off, device drivers really do need to know if they are allocating
MSI or MSI-X messages. MSI requires allocating powerof2() messages for
example where MSI-X does not. To address this, split out the MSI-X
support from pci_msi_count() and pci_alloc_msi() into new driver-visible
functions pci_msix_count() and pci_alloc_msix(). As a result,
pci_msi_count() now just returns a count of the max supported MSI
messages for the device, and pci_alloc_msi() only tries to allocate MSI
messages. To get a count of the max supported MSI-X messages, use
pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix().
pci_release_msi() still handles both MSI and MSI-X messages, however.
As a result of this change, drivers using the existing API will only
use MSI messages and will no longer try to use MSI-X messages.
- Because MSI-X allows for each message to have its own data and address
values (and thus does not require all of the messages to have their
MD vectors allocated as a group), some devices allow for "sparse" use
of MSI-X message slots. For example, if a device supports 8 messages
but the OS is only able to allocate 2 messages, the device may make the
best use of 2 IRQs if it enables the messages at slots 1 and 4 rather
than default of using the first N slots (or indicies) at 1 and 2. To
support this, add a new pci_remap_msix() function that a driver may call
after a successful pci_alloc_msix() (but before allocating any of the
SYS_RES_IRQ resources) to allow the allocated IRQ resources to be
assigned to different message indices. For example, from the earlier
example, after pci_alloc_msix() returned a value of 2, the driver would
call pci_remap_msix() passing in array of integers { 1, 4 } as the
new message indices to use. The rid's for the SYS_RES_IRQ resources
will always match the message indices. Thus, after the call to
pci_remap_msix() the driver would be able to access the first message
in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at
SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based
rather than 0-based so that they will always correspond to the rid
values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt).
To support this API, a new PCIB_REMAP_MSIX() method was added to the
pcib interface to change the message index for a single IRQ.
Tested by: scottl
2007-01-22 21:48:44 +00:00
|
|
|
int
|
2007-05-02 17:50:36 +00:00
|
|
|
pcib_release_msix(device_t pcib, device_t dev, int irq)
|
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support.
- First off, device drivers really do need to know if they are allocating
MSI or MSI-X messages. MSI requires allocating powerof2() messages for
example where MSI-X does not. To address this, split out the MSI-X
support from pci_msi_count() and pci_alloc_msi() into new driver-visible
functions pci_msix_count() and pci_alloc_msix(). As a result,
pci_msi_count() now just returns a count of the max supported MSI
messages for the device, and pci_alloc_msi() only tries to allocate MSI
messages. To get a count of the max supported MSI-X messages, use
pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix().
pci_release_msi() still handles both MSI and MSI-X messages, however.
As a result of this change, drivers using the existing API will only
use MSI messages and will no longer try to use MSI-X messages.
- Because MSI-X allows for each message to have its own data and address
values (and thus does not require all of the messages to have their
MD vectors allocated as a group), some devices allow for "sparse" use
of MSI-X message slots. For example, if a device supports 8 messages
but the OS is only able to allocate 2 messages, the device may make the
best use of 2 IRQs if it enables the messages at slots 1 and 4 rather
than default of using the first N slots (or indicies) at 1 and 2. To
support this, add a new pci_remap_msix() function that a driver may call
after a successful pci_alloc_msix() (but before allocating any of the
SYS_RES_IRQ resources) to allow the allocated IRQ resources to be
assigned to different message indices. For example, from the earlier
example, after pci_alloc_msix() returned a value of 2, the driver would
call pci_remap_msix() passing in array of integers { 1, 4 } as the
new message indices to use. The rid's for the SYS_RES_IRQ resources
will always match the message indices. Thus, after the call to
pci_remap_msix() the driver would be able to access the first message
in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at
SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based
rather than 0-based so that they will always correspond to the rid
values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt).
To support this API, a new PCIB_REMAP_MSIX() method was added to the
pcib interface to change the message index for a single IRQ.
Tested by: scottl
2007-01-22 21:48:44 +00:00
|
|
|
{
|
|
|
|
device_t bus;
|
|
|
|
|
|
|
|
bus = device_get_parent(pcib);
|
2007-05-02 17:50:36 +00:00
|
|
|
return (PCIB_RELEASE_MSIX(device_get_parent(bus), dev, irq));
|
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support.
- First off, device drivers really do need to know if they are allocating
MSI or MSI-X messages. MSI requires allocating powerof2() messages for
example where MSI-X does not. To address this, split out the MSI-X
support from pci_msi_count() and pci_alloc_msi() into new driver-visible
functions pci_msix_count() and pci_alloc_msix(). As a result,
pci_msi_count() now just returns a count of the max supported MSI
messages for the device, and pci_alloc_msi() only tries to allocate MSI
messages. To get a count of the max supported MSI-X messages, use
pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix().
pci_release_msi() still handles both MSI and MSI-X messages, however.
As a result of this change, drivers using the existing API will only
use MSI messages and will no longer try to use MSI-X messages.
- Because MSI-X allows for each message to have its own data and address
values (and thus does not require all of the messages to have their
MD vectors allocated as a group), some devices allow for "sparse" use
of MSI-X message slots. For example, if a device supports 8 messages
but the OS is only able to allocate 2 messages, the device may make the
best use of 2 IRQs if it enables the messages at slots 1 and 4 rather
than default of using the first N slots (or indicies) at 1 and 2. To
support this, add a new pci_remap_msix() function that a driver may call
after a successful pci_alloc_msix() (but before allocating any of the
SYS_RES_IRQ resources) to allow the allocated IRQ resources to be
assigned to different message indices. For example, from the earlier
example, after pci_alloc_msix() returned a value of 2, the driver would
call pci_remap_msix() passing in array of integers { 1, 4 } as the
new message indices to use. The rid's for the SYS_RES_IRQ resources
will always match the message indices. Thus, after the call to
pci_remap_msix() the driver would be able to access the first message
in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at
SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based
rather than 0-based so that they will always correspond to the rid
values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt).
To support this API, a new PCIB_REMAP_MSIX() method was added to the
pcib interface to change the message index for a single IRQ.
Tested by: scottl
2007-01-22 21:48:44 +00:00
|
|
|
}
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
/* Pass request to map MSI/MSI-X message up to parent bridge. */
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
int
|
2007-05-02 17:50:36 +00:00
|
|
|
pcib_map_msi(device_t pcib, device_t dev, int irq, uint64_t *addr,
|
|
|
|
uint32_t *data)
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
{
|
|
|
|
device_t bus;
|
2008-07-23 09:44:36 +00:00
|
|
|
int error;
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
|
|
|
|
bus = device_get_parent(pcib);
|
2008-07-23 09:44:36 +00:00
|
|
|
error = PCIB_MAP_MSI(device_get_parent(bus), dev, irq, addr, data);
|
|
|
|
if (error)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
pci_ht_map_msi(pcib, *addr);
|
|
|
|
return (0);
|
First cut at MI support for PCI Message Signalled Interrupts (MSI):
- Add 3 new functions to the pci_if interface along with suitable wrappers
to provide the device driver visible API:
- pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count'
here is an in and out parameter. The driver stores the desired number
of messages in '*count' before calling the function. On success,
'*count' holds the number of messages allocated to the device. Also on
success, the driver can access the messages as SYS_RES_IRQ resources
starting at rid 1. Note that the legacy INTx interrupt resource will
not be available when using MSI. Note that this function will allocate
either MSI or MSI-X messages depending on the devices capabilities and
the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note
that the driver should activate the memory resource that holds the
MSI-X table and pending bit array (PBA) before calling this function
if the device supports MSI-X.
- pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function
releases the messages allocated for this device. All of the
SYS_RES_IRQ resources need to be released for this function to succeed.
- pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns
the maximum number of MSI or MSI-X messages supported by this device.
MSI-X is preferred if present, but this function will honor the
'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function
should return the largest value that pci_alloc_msi() can return
(assuming the MD code is able to allocate sufficient backing resources
for all of the messages).
- Add default implementations for these 3 methods to the pci_driver generic
PCI bus driver. (The various other PCI bus drivers such as for ACPI and
OFW will inherit these default implementations.) This default
implementation depends on 4 new pcib_if methods that bubble up through
the PCI bridges to the MD code to allocate IRQ values and perform any
needed MD setup code needed:
- PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages.
- PCIB_RELEASE_MSI() releases a group of MSI messages.
- PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message.
- PCIB_RELEASE_MSIX() releases a single MSI-X message.
- Add default implementations for these 4 methods that just pass the
request up to the parent bus's parent bridge driver and use the
default implementation in the various MI PCI bridge drivers.
- Add MI functions for use by MD code when managing MSI and MSI-X
interrupts:
- pci_enable_msi(dev, address, data) programs the MSI capability address
and data registers for a group of MSI messages
- pci_enable_msix(dev, index, address, data) initializes a single MSI-X
message in the MSI-X table
- pci_mask_msix(dev, index) masks a single MSI-X message
- pci_unmask_msix(dev, index) unmasks a single MSI-X message
- pci_pending_msix(dev, index) returns true if the specified MSI-X
message is currently pending
- Save the MSI capability address and data registers in the pci_cfgreg
block in a PCI devices ivars and restore the values when a device is
resumed. Note that the MSI-X table is not currently restored during
resume.
- Add constants for MSI-X register offsets and fields.
- Record interesting data about any MSI-X capability blocks we come
across in the pci_cfgreg block in the ivars for PCI devices.
Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X)
Reviewed by: scottl, grehan, jfv
MFC after: 2 months
2006-11-13 21:47:30 +00:00
|
|
|
}
|
|
|
|
|
2002-11-22 17:50:47 +00:00
|
|
|
/*
|
|
|
|
* Try to read the bus number of a host-PCI bridge using appropriate config
|
|
|
|
* registers.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
host_pcib_get_busno(pci_read_config_fn read_config, int bus, int slot, int func,
|
2003-08-22 03:11:53 +00:00
|
|
|
uint8_t *busnum)
|
2002-11-22 17:50:47 +00:00
|
|
|
{
|
2003-08-22 03:11:53 +00:00
|
|
|
uint32_t id;
|
2002-11-22 17:50:47 +00:00
|
|
|
|
|
|
|
id = read_config(bus, slot, func, PCIR_DEVVENDOR, 4);
|
2002-11-25 21:53:14 +00:00
|
|
|
if (id == 0xffffffff)
|
2002-11-22 17:50:47 +00:00
|
|
|
return (0);
|
|
|
|
|
|
|
|
switch (id) {
|
|
|
|
case 0x12258086:
|
|
|
|
/* Intel 824?? */
|
|
|
|
/* XXX This is a guess */
|
|
|
|
/* *busnum = read_config(bus, slot, func, 0x41, 1); */
|
|
|
|
*busnum = bus;
|
|
|
|
break;
|
|
|
|
case 0x84c48086:
|
|
|
|
/* Intel 82454KX/GX (Orion) */
|
|
|
|
*busnum = read_config(bus, slot, func, 0x4a, 1);
|
|
|
|
break;
|
|
|
|
case 0x84ca8086:
|
|
|
|
/*
|
|
|
|
* For the 450nx chipset, there is a whole bundle of
|
|
|
|
* things pretending to be host bridges. The MIOC will
|
|
|
|
* be seen first and isn't really a pci bridge (the
|
|
|
|
* actual busses are attached to the PXB's). We need to
|
|
|
|
* read the registers of the MIOC to figure out the
|
|
|
|
* bus numbers for the PXB channels.
|
|
|
|
*
|
|
|
|
* Since the MIOC doesn't have a pci bus attached, we
|
|
|
|
* pretend it wasn't there.
|
|
|
|
*/
|
|
|
|
return (0);
|
|
|
|
case 0x84cb8086:
|
|
|
|
switch (slot) {
|
|
|
|
case 0x12:
|
|
|
|
/* Intel 82454NX PXB#0, Bus#A */
|
2002-11-25 21:53:14 +00:00
|
|
|
*busnum = read_config(bus, 0x10, func, 0xd0, 1);
|
2002-11-22 17:50:47 +00:00
|
|
|
break;
|
|
|
|
case 0x13:
|
|
|
|
/* Intel 82454NX PXB#0, Bus#B */
|
2002-11-25 21:53:14 +00:00
|
|
|
*busnum = read_config(bus, 0x10, func, 0xd1, 1) + 1;
|
2002-11-22 17:50:47 +00:00
|
|
|
break;
|
|
|
|
case 0x14:
|
|
|
|
/* Intel 82454NX PXB#1, Bus#A */
|
2002-11-25 21:53:14 +00:00
|
|
|
*busnum = read_config(bus, 0x10, func, 0xd3, 1);
|
2002-11-22 17:50:47 +00:00
|
|
|
break;
|
|
|
|
case 0x15:
|
|
|
|
/* Intel 82454NX PXB#1, Bus#B */
|
2002-11-25 21:53:14 +00:00
|
|
|
*busnum = read_config(bus, 0x10, func, 0xd4, 1) + 1;
|
2002-11-22 17:50:47 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* ServerWorks -- vendor 0x1166 */
|
|
|
|
case 0x00051166:
|
|
|
|
case 0x00061166:
|
|
|
|
case 0x00081166:
|
|
|
|
case 0x00091166:
|
|
|
|
case 0x00101166:
|
|
|
|
case 0x00111166:
|
|
|
|
case 0x00171166:
|
|
|
|
case 0x01011166:
|
|
|
|
case 0x010f1014:
|
|
|
|
case 0x02011166:
|
|
|
|
case 0x03021014:
|
|
|
|
*busnum = read_config(bus, slot, func, 0x44, 1);
|
|
|
|
break;
|
2005-03-25 14:18:50 +00:00
|
|
|
|
|
|
|
/* Compaq/HP -- vendor 0x0e11 */
|
|
|
|
case 0x60100e11:
|
|
|
|
*busnum = read_config(bus, slot, func, 0xc8, 1);
|
|
|
|
break;
|
2002-11-22 17:50:47 +00:00
|
|
|
default:
|
|
|
|
/* Don't know how to read bus number. */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|