2005-01-06 01:43:34 +00:00
|
|
|
/*-
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
* Copyright (c) 1997, Stefan Esser <se@freebsd.org>
|
2000-12-13 01:25:11 +00:00
|
|
|
* Copyright (c) 2000, Michael Smith <msmith@freebsd.org>
|
|
|
|
* Copyright (c) 2000, BSDi
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
* 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 unmodified, 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.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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 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.
|
|
|
|
*/
|
1994-09-01 01:45:19 +00:00
|
|
|
|
2004-06-29 20:25:43 +00:00
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
1999-04-16 21:22:55 +00:00
|
|
|
#include "opt_bus.h"
|
|
|
|
|
1994-09-14 01:34:51 +00:00
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/systm.h>
|
1994-10-12 02:33:23 +00:00
|
|
|
#include <sys/malloc.h>
|
1999-04-24 19:59:20 +00:00
|
|
|
#include <sys/module.h>
|
2000-12-08 22:11:23 +00:00
|
|
|
#include <sys/linker.h>
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
#include <sys/fcntl.h>
|
1996-10-22 20:20:14 +00:00
|
|
|
#include <sys/conf.h>
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
#include <sys/kernel.h>
|
1998-09-15 08:21:13 +00:00
|
|
|
#include <sys/queue.h>
|
2002-07-26 07:58:16 +00:00
|
|
|
#include <sys/sysctl.h>
|
2006-10-09 16:15:56 +00:00
|
|
|
#include <sys/endian.h>
|
1995-03-21 23:01:06 +00:00
|
|
|
|
1994-09-01 01:45:19 +00:00
|
|
|
#include <vm/vm.h>
|
1995-12-07 12:48:31 +00:00
|
|
|
#include <vm/pmap.h>
|
1998-09-15 08:21:13 +00:00
|
|
|
#include <vm/vm_extern.h>
|
1994-09-01 01:45:19 +00:00
|
|
|
|
1999-04-16 21:22:55 +00:00
|
|
|
#include <sys/bus.h>
|
|
|
|
#include <machine/bus.h>
|
|
|
|
#include <sys/rman.h>
|
|
|
|
#include <machine/resource.h>
|
2009-06-02 12:35:04 +00:00
|
|
|
#include <machine/stdarg.h>
|
1999-04-16 21:22:55 +00:00
|
|
|
|
2010-05-16 15:18:25 +00:00
|
|
|
#if defined(__i386__) || defined(__amd64__) || defined(__powerpc__)
|
2006-12-12 19:33:25 +00:00
|
|
|
#include <machine/intr_machdep.h>
|
|
|
|
#endif
|
|
|
|
|
2000-05-28 16:35:57 +00:00
|
|
|
#include <sys/pciio.h>
|
2002-02-27 05:09:14 +00:00
|
|
|
#include <dev/pci/pcireg.h>
|
|
|
|
#include <dev/pci/pcivar.h>
|
|
|
|
#include <dev/pci/pci_private.h>
|
1995-03-21 23:01:06 +00:00
|
|
|
|
2011-07-22 15:37:23 +00:00
|
|
|
#include <dev/usb/controller/xhcireg.h>
|
2009-10-15 20:07:08 +00:00
|
|
|
#include <dev/usb/controller/ehcireg.h>
|
|
|
|
#include <dev/usb/controller/ohcireg.h>
|
|
|
|
#include <dev/usb/controller/uhcireg.h>
|
|
|
|
|
2000-08-28 21:48:13 +00:00
|
|
|
#include "pcib_if.h"
|
2000-12-13 01:25:11 +00:00
|
|
|
#include "pci_if.h"
|
|
|
|
|
2011-03-31 13:22:12 +00:00
|
|
|
#define PCIR_IS_BIOS(cfg, reg) \
|
|
|
|
(((cfg)->hdrtype == PCIM_HDRTYPE_NORMAL && reg == PCIR_BIOS) || \
|
|
|
|
((cfg)->hdrtype == PCIM_HDRTYPE_BRIDGE && reg == PCIR_BIOS_1))
|
|
|
|
|
|
|
|
|
2009-03-05 15:33:04 +00:00
|
|
|
static pci_addr_t pci_mapbase(uint64_t mapreg);
|
|
|
|
static const char *pci_maptype(uint64_t mapreg);
|
|
|
|
static int pci_mapsize(uint64_t testval);
|
|
|
|
static int pci_maprange(uint64_t mapreg);
|
2009-12-30 20:47:14 +00:00
|
|
|
static pci_addr_t pci_rombase(uint64_t mapreg);
|
|
|
|
static int pci_romsize(uint64_t testval);
|
2000-12-13 01:25:11 +00:00
|
|
|
static void pci_fixancient(pcicfgregs *cfg);
|
2009-06-01 20:30:00 +00:00
|
|
|
static int pci_printf(pcicfgregs *cfg, const char *fmt, ...);
|
2000-12-13 01:25:11 +00:00
|
|
|
|
2009-04-14 18:32:37 +00:00
|
|
|
static int pci_porten(device_t dev);
|
|
|
|
static int pci_memen(device_t dev);
|
2005-09-29 15:04:41 +00:00
|
|
|
static void pci_assign_interrupt(device_t bus, device_t dev,
|
|
|
|
int force_route);
|
2009-04-14 18:32:37 +00:00
|
|
|
static int pci_add_map(device_t bus, device_t dev, int reg,
|
2005-12-30 19:28:26 +00:00
|
|
|
struct resource_list *rl, int force, int prefetch);
|
2000-12-13 01:25:11 +00:00
|
|
|
static int pci_probe(device_t dev);
|
2002-08-26 15:23:52 +00:00
|
|
|
static int pci_attach(device_t dev);
|
2002-09-04 03:13:16 +00:00
|
|
|
static void pci_load_vendor_data(void);
|
2006-11-07 18:55:51 +00:00
|
|
|
static int pci_describe_parse_line(char **ptr, int *vendor,
|
2003-12-24 02:01:22 +00:00
|
|
|
int *device, char **desc);
|
2000-12-13 01:25:11 +00:00
|
|
|
static char *pci_describe_device(device_t dev);
|
|
|
|
static int pci_modevent(module_t mod, int what, void *arg);
|
2006-11-07 18:55:51 +00:00
|
|
|
static void pci_hdrtypedata(device_t pcib, int b, int s, int f,
|
2003-12-24 02:01:22 +00:00
|
|
|
pcicfgregs *cfg);
|
2011-03-22 12:05:49 +00:00
|
|
|
static void pci_read_cap(device_t pcib, pcicfgregs *cfg);
|
2007-11-16 20:49:34 +00:00
|
|
|
static int pci_read_vpd_reg(device_t pcib, pcicfgregs *cfg,
|
|
|
|
int reg, uint32_t *data);
|
2006-10-09 16:15:56 +00:00
|
|
|
#if 0
|
2007-11-16 20:49:34 +00:00
|
|
|
static int pci_write_vpd_reg(device_t pcib, pcicfgregs *cfg,
|
2006-10-09 16:15:56 +00:00
|
|
|
int reg, uint32_t data);
|
|
|
|
#endif
|
|
|
|
static void pci_read_vpd(device_t pcib, pcicfgregs *cfg);
|
2007-05-02 17:50:36 +00:00
|
|
|
static void pci_disable_msi(device_t dev);
|
|
|
|
static void pci_enable_msi(device_t dev, uint64_t address,
|
|
|
|
uint16_t data);
|
|
|
|
static void pci_enable_msix(device_t dev, u_int index,
|
|
|
|
uint64_t address, uint32_t data);
|
|
|
|
static void pci_mask_msix(device_t dev, u_int index);
|
|
|
|
static void pci_unmask_msix(device_t dev, u_int index);
|
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
|
|
|
static int pci_msi_blacklisted(void);
|
2007-05-02 17:50:36 +00:00
|
|
|
static void pci_resume_msi(device_t dev);
|
|
|
|
static void pci_resume_msix(device_t dev);
|
2010-06-14 07:10:37 +00:00
|
|
|
static int pci_remap_intr_method(device_t bus, device_t dev,
|
|
|
|
u_int irq);
|
2000-12-13 01:25:11 +00:00
|
|
|
|
|
|
|
static device_method_t pci_methods[] = {
|
|
|
|
/* Device interface */
|
|
|
|
DEVMETHOD(device_probe, pci_probe),
|
2002-08-26 15:23:52 +00:00
|
|
|
DEVMETHOD(device_attach, pci_attach),
|
2005-04-29 06:22:41 +00:00
|
|
|
DEVMETHOD(device_detach, bus_generic_detach),
|
2000-12-13 01:25:11 +00:00
|
|
|
DEVMETHOD(device_shutdown, bus_generic_shutdown),
|
2004-04-09 15:44:34 +00:00
|
|
|
DEVMETHOD(device_suspend, pci_suspend),
|
2003-09-17 08:32:44 +00:00
|
|
|
DEVMETHOD(device_resume, pci_resume),
|
2000-12-13 01:25:11 +00:00
|
|
|
|
|
|
|
/* Bus interface */
|
|
|
|
DEVMETHOD(bus_print_child, pci_print_child),
|
|
|
|
DEVMETHOD(bus_probe_nomatch, pci_probe_nomatch),
|
|
|
|
DEVMETHOD(bus_read_ivar, pci_read_ivar),
|
|
|
|
DEVMETHOD(bus_write_ivar, pci_write_ivar),
|
2004-04-09 15:44:34 +00:00
|
|
|
DEVMETHOD(bus_driver_added, pci_driver_added),
|
2007-05-02 17:50:36 +00:00
|
|
|
DEVMETHOD(bus_setup_intr, pci_setup_intr),
|
|
|
|
DEVMETHOD(bus_teardown_intr, pci_teardown_intr),
|
2000-12-13 01:25:11 +00:00
|
|
|
|
|
|
|
DEVMETHOD(bus_get_resource_list,pci_get_resource_list),
|
|
|
|
DEVMETHOD(bus_set_resource, bus_generic_rl_set_resource),
|
|
|
|
DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),
|
|
|
|
DEVMETHOD(bus_delete_resource, pci_delete_resource),
|
|
|
|
DEVMETHOD(bus_alloc_resource, pci_alloc_resource),
|
2011-05-02 14:13:12 +00:00
|
|
|
DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
|
2000-12-13 01:25:11 +00:00
|
|
|
DEVMETHOD(bus_release_resource, bus_generic_rl_release_resource),
|
2009-03-03 16:38:59 +00:00
|
|
|
DEVMETHOD(bus_activate_resource, pci_activate_resource),
|
2009-12-30 20:47:14 +00:00
|
|
|
DEVMETHOD(bus_deactivate_resource, pci_deactivate_resource),
|
2003-02-17 21:20:35 +00:00
|
|
|
DEVMETHOD(bus_child_pnpinfo_str, pci_child_pnpinfo_str_method),
|
|
|
|
DEVMETHOD(bus_child_location_str, pci_child_location_str_method),
|
2010-06-14 07:10:37 +00:00
|
|
|
DEVMETHOD(bus_remap_intr, pci_remap_intr_method),
|
2000-12-13 01:25:11 +00:00
|
|
|
|
|
|
|
/* PCI interface */
|
|
|
|
DEVMETHOD(pci_read_config, pci_read_config_method),
|
|
|
|
DEVMETHOD(pci_write_config, pci_write_config_method),
|
2001-02-27 23:13:20 +00:00
|
|
|
DEVMETHOD(pci_enable_busmaster, pci_enable_busmaster_method),
|
|
|
|
DEVMETHOD(pci_disable_busmaster, pci_disable_busmaster_method),
|
|
|
|
DEVMETHOD(pci_enable_io, pci_enable_io_method),
|
|
|
|
DEVMETHOD(pci_disable_io, pci_disable_io_method),
|
2006-10-09 16:15:56 +00:00
|
|
|
DEVMETHOD(pci_get_vpd_ident, pci_get_vpd_ident_method),
|
|
|
|
DEVMETHOD(pci_get_vpd_readonly, pci_get_vpd_readonly_method),
|
2001-02-27 23:13:20 +00:00
|
|
|
DEVMETHOD(pci_get_powerstate, pci_get_powerstate_method),
|
|
|
|
DEVMETHOD(pci_set_powerstate, pci_set_powerstate_method),
|
2003-07-01 14:08:33 +00:00
|
|
|
DEVMETHOD(pci_assign_interrupt, pci_assign_interrupt_method),
|
2005-12-20 19:57:47 +00:00
|
|
|
DEVMETHOD(pci_find_extcap, pci_find_extcap_method),
|
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(pci_alloc_msi, pci_alloc_msi_method),
|
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
|
|
|
DEVMETHOD(pci_alloc_msix, pci_alloc_msix_method),
|
|
|
|
DEVMETHOD(pci_remap_msix, pci_remap_msix_method),
|
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(pci_release_msi, pci_release_msi_method),
|
|
|
|
DEVMETHOD(pci_msi_count, pci_msi_count_method),
|
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
|
|
|
DEVMETHOD(pci_msix_count, pci_msix_count_method),
|
2000-12-13 01:25:11 +00:00
|
|
|
|
|
|
|
{ 0, 0 }
|
|
|
|
};
|
|
|
|
|
2003-11-01 12:45:03 +00:00
|
|
|
DEFINE_CLASS_0(pci, pci_driver, pci_methods, 0);
|
2000-12-13 01:25:11 +00:00
|
|
|
|
2006-01-20 22:00:50 +00:00
|
|
|
static devclass_t pci_devclass;
|
2000-12-13 01:25:11 +00:00
|
|
|
DRIVER_MODULE(pci, pcib, pci_driver, pci_devclass, pci_modevent, 0);
|
2002-04-17 00:31:32 +00:00
|
|
|
MODULE_VERSION(pci, 1);
|
2000-08-28 21:48:13 +00:00
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
static char *pci_vendordata;
|
|
|
|
static size_t pci_vendordata_size;
|
1997-06-25 20:56:29 +00:00
|
|
|
|
2000-08-28 21:48:13 +00:00
|
|
|
|
1999-10-28 08:06:59 +00:00
|
|
|
struct pci_quirk {
|
2003-08-22 03:11:53 +00:00
|
|
|
uint32_t devid; /* Vendor/device of the card */
|
1999-10-28 08:06:59 +00:00
|
|
|
int type;
|
2006-12-14 16:53:48 +00:00
|
|
|
#define PCI_QUIRK_MAP_REG 1 /* PCI map register in weird place */
|
2006-12-14 19:57:06 +00:00
|
|
|
#define PCI_QUIRK_DISABLE_MSI 2 /* MSI/MSI-X doesn't work */
|
2010-10-22 11:42:02 +00:00
|
|
|
#define PCI_QUIRK_ENABLE_MSI_VM 3 /* Older chipset in VM where MSI works */
|
1999-10-28 08:06:59 +00:00
|
|
|
int arg1;
|
|
|
|
int arg2;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct pci_quirk pci_quirks[] = {
|
2001-12-21 01:28:59 +00:00
|
|
|
/* The Intel 82371AB and 82443MX has a map register at offset 0x90. */
|
1999-10-28 08:06:59 +00:00
|
|
|
{ 0x71138086, PCI_QUIRK_MAP_REG, 0x90, 0 },
|
2001-12-21 01:28:59 +00:00
|
|
|
{ 0x719b8086, PCI_QUIRK_MAP_REG, 0x90, 0 },
|
2001-03-15 06:51:45 +00:00
|
|
|
/* As does the Serverworks OSB4 (the SMBus mapping register) */
|
|
|
|
{ 0x02001166, PCI_QUIRK_MAP_REG, 0x90, 0 },
|
1999-10-28 08:06:59 +00:00
|
|
|
|
2007-01-12 21:37:51 +00:00
|
|
|
/*
|
|
|
|
* MSI doesn't work with the ServerWorks CNB20-HE Host Bridge
|
|
|
|
* or the CMIC-SL (AKA ServerWorks GC_LE).
|
|
|
|
*/
|
|
|
|
{ 0x00141166, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
|
|
|
{ 0x00171166, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
|
|
|
|
2006-12-14 19:59:29 +00:00
|
|
|
/*
|
2007-01-12 21:30:25 +00:00
|
|
|
* MSI doesn't work on earlier Intel chipsets including
|
2007-01-16 19:44:45 +00:00
|
|
|
* E7500, E7501, E7505, 845, 865, 875/E7210, and 855.
|
2006-12-14 19:59:29 +00:00
|
|
|
*/
|
2007-01-12 21:30:25 +00:00
|
|
|
{ 0x25408086, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
2006-12-14 19:59:29 +00:00
|
|
|
{ 0x254c8086, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
2006-12-28 06:14:42 +00:00
|
|
|
{ 0x25508086, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
2007-01-16 19:44:45 +00:00
|
|
|
{ 0x25608086, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
|
|
|
{ 0x25708086, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
2007-01-12 13:33:56 +00:00
|
|
|
{ 0x25788086, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
2007-01-12 21:30:25 +00:00
|
|
|
{ 0x35808086, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
2006-12-28 06:14:42 +00:00
|
|
|
|
2007-01-13 04:57:37 +00:00
|
|
|
/*
|
|
|
|
* MSI doesn't work with devices behind the AMD 8131 HT-PCIX
|
|
|
|
* bridge.
|
|
|
|
*/
|
|
|
|
{ 0x74501022, PCI_QUIRK_DISABLE_MSI, 0, 0 },
|
|
|
|
|
2010-10-22 11:42:02 +00:00
|
|
|
/*
|
|
|
|
* Some virtualization environments emulate an older chipset
|
|
|
|
* but support MSI just fine. QEMU uses the Intel 82440.
|
|
|
|
*/
|
|
|
|
{ 0x12378086, PCI_QUIRK_ENABLE_MSI_VM, 0, 0 },
|
|
|
|
|
1999-10-28 08:06:59 +00:00
|
|
|
{ 0 }
|
|
|
|
};
|
|
|
|
|
1999-10-14 21:38:33 +00:00
|
|
|
/* map register information */
|
2006-12-14 16:53:48 +00:00
|
|
|
#define PCI_MAPMEM 0x01 /* memory map */
|
|
|
|
#define PCI_MAPMEMP 0x02 /* prefetchable memory map */
|
|
|
|
#define PCI_MAPPORT 0x04 /* port map */
|
1999-10-14 21:38:33 +00:00
|
|
|
|
2001-12-19 08:49:11 +00:00
|
|
|
struct devlist pci_devq;
|
2003-08-22 03:11:53 +00:00
|
|
|
uint32_t pci_generation;
|
|
|
|
uint32_t pci_numdevs = 0;
|
2011-03-18 14:06:12 +00:00
|
|
|
static int pcie_chipset, pcix_chipset;
|
1998-09-15 08:21:13 +00:00
|
|
|
|
2002-07-26 07:58:16 +00:00
|
|
|
/* sysctl vars */
|
|
|
|
SYSCTL_NODE(_hw, OID_AUTO, pci, CTLFLAG_RD, 0, "PCI bus tuning parameters");
|
|
|
|
|
2004-04-16 15:01:54 +00:00
|
|
|
static int pci_enable_io_modes = 1;
|
2004-12-02 08:07:12 +00:00
|
|
|
TUNABLE_INT("hw.pci.enable_io_modes", &pci_enable_io_modes);
|
2002-07-26 07:58:16 +00:00
|
|
|
SYSCTL_INT(_hw_pci, OID_AUTO, enable_io_modes, CTLFLAG_RW,
|
2004-04-16 15:01:54 +00:00
|
|
|
&pci_enable_io_modes, 1,
|
2002-07-26 07:58:16 +00:00
|
|
|
"Enable I/O and memory bits in the config register. Some BIOSes do not\n\
|
|
|
|
enable these bits correctly. We'd like to do this all the time, but there\n\
|
|
|
|
are some peripherals that this causes problems with.");
|
|
|
|
|
2005-09-21 19:47:00 +00:00
|
|
|
static int pci_do_power_nodriver = 0;
|
|
|
|
TUNABLE_INT("hw.pci.do_power_nodriver", &pci_do_power_nodriver);
|
|
|
|
SYSCTL_INT(_hw_pci, OID_AUTO, do_power_nodriver, CTLFLAG_RW,
|
|
|
|
&pci_do_power_nodriver, 0,
|
|
|
|
"Place a function into D3 state when no driver attaches to it. 0 means\n\
|
|
|
|
disable. 1 means conservatively place devices into D3 state. 2 means\n\
|
|
|
|
agressively place devices into D3 state. 3 means put absolutely everything\n\
|
|
|
|
in D3 state.");
|
|
|
|
|
2009-12-10 01:01:53 +00:00
|
|
|
int pci_do_power_resume = 1;
|
2005-09-21 19:47:00 +00:00
|
|
|
TUNABLE_INT("hw.pci.do_power_resume", &pci_do_power_resume);
|
|
|
|
SYSCTL_INT(_hw_pci, OID_AUTO, do_power_resume, CTLFLAG_RW,
|
|
|
|
&pci_do_power_resume, 1,
|
|
|
|
"Transition from D3 -> D0 on resume.");
|
2004-04-11 07:02:49 +00:00
|
|
|
|
2010-10-20 16:47:09 +00:00
|
|
|
int pci_do_power_suspend = 1;
|
|
|
|
TUNABLE_INT("hw.pci.do_power_suspend", &pci_do_power_suspend);
|
|
|
|
SYSCTL_INT(_hw_pci, OID_AUTO, do_power_suspend, CTLFLAG_RW,
|
|
|
|
&pci_do_power_suspend, 1,
|
|
|
|
"Transition from D0 -> D3 on suspend.");
|
|
|
|
|
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
|
|
|
static int pci_do_msi = 1;
|
|
|
|
TUNABLE_INT("hw.pci.enable_msi", &pci_do_msi);
|
|
|
|
SYSCTL_INT(_hw_pci, OID_AUTO, enable_msi, CTLFLAG_RW, &pci_do_msi, 1,
|
|
|
|
"Enable support for MSI interrupts");
|
|
|
|
|
|
|
|
static int pci_do_msix = 1;
|
|
|
|
TUNABLE_INT("hw.pci.enable_msix", &pci_do_msix);
|
|
|
|
SYSCTL_INT(_hw_pci, OID_AUTO, enable_msix, CTLFLAG_RW, &pci_do_msix, 1,
|
|
|
|
"Enable support for MSI-X interrupts");
|
|
|
|
|
2006-12-14 19:57:06 +00:00
|
|
|
static int pci_honor_msi_blacklist = 1;
|
|
|
|
TUNABLE_INT("hw.pci.honor_msi_blacklist", &pci_honor_msi_blacklist);
|
|
|
|
SYSCTL_INT(_hw_pci, OID_AUTO, honor_msi_blacklist, CTLFLAG_RD,
|
|
|
|
&pci_honor_msi_blacklist, 1, "Honor chipset blacklist for MSI");
|
|
|
|
|
2009-10-23 22:53:01 +00:00
|
|
|
#if defined(__i386__) || defined(__amd64__)
|
2009-10-15 20:07:08 +00:00
|
|
|
static int pci_usb_takeover = 1;
|
2009-10-23 22:53:01 +00:00
|
|
|
#else
|
|
|
|
static int pci_usb_takeover = 0;
|
|
|
|
#endif
|
2009-10-15 20:07:08 +00:00
|
|
|
TUNABLE_INT("hw.pci.usb_early_takeover", &pci_usb_takeover);
|
2011-06-21 19:31:31 +00:00
|
|
|
SYSCTL_INT(_hw_pci, OID_AUTO, usb_early_takeover, CTLFLAG_RDTUN,
|
2009-10-15 20:07:08 +00:00
|
|
|
&pci_usb_takeover, 1, "Enable early takeover of USB controllers.\n\
|
|
|
|
Disable this if you depend on BIOS emulation of USB devices, that is\n\
|
|
|
|
you use USB devices (like keyboard or mouse) but do not load USB drivers");
|
|
|
|
|
2007-09-30 11:05:18 +00:00
|
|
|
/* Find a device_t by bus/slot/function in domain 0 */
|
2002-01-10 00:56:02 +00:00
|
|
|
|
|
|
|
device_t
|
2003-08-22 03:11:53 +00:00
|
|
|
pci_find_bsf(uint8_t bus, uint8_t slot, uint8_t func)
|
2007-09-30 11:05:18 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
return (pci_find_dbsf(0, bus, slot, func));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Find a device_t by domain/bus/slot/function */
|
|
|
|
|
|
|
|
device_t
|
|
|
|
pci_find_dbsf(uint32_t domain, uint8_t bus, uint8_t slot, uint8_t func)
|
2002-01-10 00:56:02 +00:00
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
|
|
|
|
STAILQ_FOREACH(dinfo, &pci_devq, pci_links) {
|
2007-09-30 11:05:18 +00:00
|
|
|
if ((dinfo->cfg.domain == domain) &&
|
|
|
|
(dinfo->cfg.bus == bus) &&
|
2002-01-10 00:56:02 +00:00
|
|
|
(dinfo->cfg.slot == slot) &&
|
|
|
|
(dinfo->cfg.func == func)) {
|
|
|
|
return (dinfo->cfg.dev);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Find a device_t by vendor/device ID */
|
|
|
|
|
|
|
|
device_t
|
2003-08-22 03:11:53 +00:00
|
|
|
pci_find_device(uint16_t vendor, uint16_t device)
|
2002-01-10 00:56:02 +00:00
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
|
|
|
|
STAILQ_FOREACH(dinfo, &pci_devq, pci_links) {
|
|
|
|
if ((dinfo->cfg.vendor == vendor) &&
|
|
|
|
(dinfo->cfg.device == device)) {
|
|
|
|
return (dinfo->cfg.dev);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
2011-07-09 14:30:13 +00:00
|
|
|
device_t
|
|
|
|
pci_find_class(uint8_t class, uint8_t subclass)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
|
|
|
|
STAILQ_FOREACH(dinfo, &pci_devq, pci_links) {
|
|
|
|
if (dinfo->cfg.baseclass == class &&
|
|
|
|
dinfo->cfg.subclass == subclass) {
|
|
|
|
return (dinfo->cfg.dev);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
2009-06-01 20:30:00 +00:00
|
|
|
static int
|
|
|
|
pci_printf(pcicfgregs *cfg, const char *fmt, ...)
|
|
|
|
{
|
|
|
|
va_list ap;
|
|
|
|
int retval;
|
|
|
|
|
|
|
|
retval = printf("pci%d:%d:%d:%d: ", cfg->domain, cfg->bus, cfg->slot,
|
|
|
|
cfg->func);
|
|
|
|
va_start(ap, fmt);
|
|
|
|
retval += vprintf(fmt, ap);
|
|
|
|
va_end(ap);
|
|
|
|
return (retval);
|
|
|
|
}
|
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
/* return base address of memory or port map */
|
1994-10-12 02:33:23 +00:00
|
|
|
|
2009-03-05 15:33:04 +00:00
|
|
|
static pci_addr_t
|
|
|
|
pci_mapbase(uint64_t mapreg)
|
1995-03-21 23:01:06 +00:00
|
|
|
{
|
2007-03-31 21:39:02 +00:00
|
|
|
|
|
|
|
if (PCI_BAR_MEM(mapreg))
|
|
|
|
return (mapreg & PCIM_BAR_MEM_BASE);
|
|
|
|
else
|
|
|
|
return (mapreg & PCIM_BAR_IO_BASE);
|
1995-03-21 23:01:06 +00:00
|
|
|
}
|
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
/* return map type of memory or port map */
|
1996-04-14 20:14:36 +00:00
|
|
|
|
2007-03-31 21:39:02 +00:00
|
|
|
static const char *
|
2009-03-05 15:33:04 +00:00
|
|
|
pci_maptype(uint64_t mapreg)
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
{
|
2007-03-31 21:39:02 +00:00
|
|
|
|
|
|
|
if (PCI_BAR_IO(mapreg))
|
|
|
|
return ("I/O Port");
|
|
|
|
if (mapreg & PCIM_BAR_MEM_PREFETCH)
|
|
|
|
return ("Prefetchable Memory");
|
|
|
|
return ("Memory");
|
1997-01-21 23:23:40 +00:00
|
|
|
}
|
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
/* return log2 of map size decoded for memory or port map */
|
1995-03-21 23:01:06 +00:00
|
|
|
|
1996-01-30 01:14:29 +00:00
|
|
|
static int
|
2009-03-05 15:33:04 +00:00
|
|
|
pci_mapsize(uint64_t testval)
|
1996-01-30 01:14:29 +00:00
|
|
|
{
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
int ln2size;
|
1996-01-30 01:14:29 +00:00
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
testval = pci_mapbase(testval);
|
1997-05-28 10:01:03 +00:00
|
|
|
ln2size = 0;
|
|
|
|
if (testval != 0) {
|
|
|
|
while ((testval & 1) == 0)
|
|
|
|
{
|
|
|
|
ln2size++;
|
|
|
|
testval >>= 1;
|
|
|
|
}
|
1995-09-07 15:20:53 +00:00
|
|
|
}
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
return (ln2size);
|
1995-03-21 23:01:06 +00:00
|
|
|
}
|
|
|
|
|
2009-12-30 20:47:14 +00:00
|
|
|
/* return base address of device ROM */
|
|
|
|
|
|
|
|
static pci_addr_t
|
|
|
|
pci_rombase(uint64_t mapreg)
|
|
|
|
{
|
|
|
|
|
|
|
|
return (mapreg & PCIM_BIOS_ADDR_MASK);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* return log2 of map size decided for device ROM */
|
|
|
|
|
|
|
|
static int
|
|
|
|
pci_romsize(uint64_t testval)
|
|
|
|
{
|
|
|
|
int ln2size;
|
|
|
|
|
|
|
|
testval = pci_rombase(testval);
|
|
|
|
ln2size = 0;
|
|
|
|
if (testval != 0) {
|
|
|
|
while ((testval & 1) == 0)
|
|
|
|
{
|
|
|
|
ln2size++;
|
|
|
|
testval >>= 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return (ln2size);
|
|
|
|
}
|
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
/* return log2 of address range supported by map register */
|
1995-03-21 23:01:06 +00:00
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
static int
|
2009-03-05 15:33:04 +00:00
|
|
|
pci_maprange(uint64_t mapreg)
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
{
|
|
|
|
int ln2range = 0;
|
2007-03-31 21:39:02 +00:00
|
|
|
|
|
|
|
if (PCI_BAR_IO(mapreg))
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
ln2range = 32;
|
2007-03-31 21:39:02 +00:00
|
|
|
else
|
|
|
|
switch (mapreg & PCIM_BAR_MEM_TYPE) {
|
|
|
|
case PCIM_BAR_MEM_32:
|
|
|
|
ln2range = 32;
|
|
|
|
break;
|
|
|
|
case PCIM_BAR_MEM_1MB:
|
|
|
|
ln2range = 20;
|
|
|
|
break;
|
|
|
|
case PCIM_BAR_MEM_64:
|
|
|
|
ln2range = 64;
|
|
|
|
break;
|
|
|
|
}
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
return (ln2range);
|
1995-02-02 13:12:18 +00:00
|
|
|
}
|
1995-03-21 23:01:06 +00:00
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
/* adjust some values from PCI 1.0 devices to match 2.0 standards ... */
|
1997-01-21 23:23:40 +00:00
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
static void
|
|
|
|
pci_fixancient(pcicfgregs *cfg)
|
1997-01-21 23:23:40 +00:00
|
|
|
{
|
2010-07-29 20:42:38 +00:00
|
|
|
if ((cfg->hdrtype & PCIM_HDRTYPE) != PCIM_HDRTYPE_NORMAL)
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
return;
|
1997-01-21 23:23:40 +00:00
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
/* PCI to PCI bridges use header type 1 */
|
1998-08-13 19:12:20 +00:00
|
|
|
if (cfg->baseclass == PCIC_BRIDGE && cfg->subclass == PCIS_BRIDGE_PCI)
|
2010-07-29 20:42:38 +00:00
|
|
|
cfg->hdrtype = PCIM_HDRTYPE_BRIDGE;
|
1997-01-21 23:23:40 +00:00
|
|
|
}
|
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
/* extract header type specific config data */
|
1995-03-21 23:01:06 +00:00
|
|
|
|
2003-02-17 19:47:02 +00:00
|
|
|
static void
|
2000-08-28 21:48:13 +00:00
|
|
|
pci_hdrtypedata(device_t pcib, int b, int s, int f, pcicfgregs *cfg)
|
1995-03-21 23:01:06 +00:00
|
|
|
{
|
2006-12-14 16:53:48 +00:00
|
|
|
#define REG(n, w) PCIB_READ_CONFIG(pcib, b, s, f, n, w)
|
2010-07-29 20:42:38 +00:00
|
|
|
switch (cfg->hdrtype & PCIM_HDRTYPE) {
|
|
|
|
case PCIM_HDRTYPE_NORMAL:
|
2000-08-28 21:48:13 +00:00
|
|
|
cfg->subvendor = REG(PCIR_SUBVEND_0, 2);
|
|
|
|
cfg->subdevice = REG(PCIR_SUBDEV_0, 2);
|
1999-10-14 21:38:33 +00:00
|
|
|
cfg->nummaps = PCI_MAXMAPS_0;
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
break;
|
2010-07-29 20:42:38 +00:00
|
|
|
case PCIM_HDRTYPE_BRIDGE:
|
1999-10-14 21:38:33 +00:00
|
|
|
cfg->nummaps = PCI_MAXMAPS_1;
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
break;
|
2010-07-29 20:42:38 +00:00
|
|
|
case PCIM_HDRTYPE_CARDBUS:
|
2000-08-28 21:48:13 +00:00
|
|
|
cfg->subvendor = REG(PCIR_SUBVEND_2, 2);
|
|
|
|
cfg->subdevice = REG(PCIR_SUBDEV_2, 2);
|
1999-10-14 21:38:33 +00:00
|
|
|
cfg->nummaps = PCI_MAXMAPS_2;
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
break;
|
1995-09-07 15:20:53 +00:00
|
|
|
}
|
2000-08-28 21:48:13 +00:00
|
|
|
#undef REG
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
}
|
1995-03-21 23:01:06 +00:00
|
|
|
|
2000-12-13 01:25:11 +00:00
|
|
|
/* read configuration header into pcicfgregs structure */
|
2002-02-27 05:09:14 +00:00
|
|
|
struct pci_devinfo *
|
2007-09-30 11:05:18 +00:00
|
|
|
pci_read_device(device_t pcib, int d, int b, int s, int f, size_t size)
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
{
|
2006-12-14 16:53:48 +00:00
|
|
|
#define REG(n, w) PCIB_READ_CONFIG(pcib, b, s, f, n, w)
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
pcicfgregs *cfg = NULL;
|
1998-09-15 08:21:13 +00:00
|
|
|
struct pci_devinfo *devlist_entry;
|
|
|
|
struct devlist *devlist_head;
|
|
|
|
|
|
|
|
devlist_head = &pci_devq;
|
|
|
|
|
|
|
|
devlist_entry = NULL;
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
|
2008-08-09 03:54:12 +00:00
|
|
|
if (REG(PCIR_DEVVENDOR, 4) != 0xfffffffful) {
|
2003-02-19 05:47:46 +00:00
|
|
|
devlist_entry = malloc(size, M_DEVBUF, M_WAITOK | M_ZERO);
|
1998-09-15 08:21:13 +00:00
|
|
|
if (devlist_entry == NULL)
|
|
|
|
return (NULL);
|
|
|
|
|
|
|
|
cfg = &devlist_entry->cfg;
|
2006-11-07 18:55:51 +00:00
|
|
|
|
2007-09-30 11:05:18 +00:00
|
|
|
cfg->domain = d;
|
2000-08-28 21:48:13 +00:00
|
|
|
cfg->bus = b;
|
|
|
|
cfg->slot = s;
|
|
|
|
cfg->func = f;
|
|
|
|
cfg->vendor = REG(PCIR_VENDOR, 2);
|
|
|
|
cfg->device = REG(PCIR_DEVICE, 2);
|
|
|
|
cfg->cmdreg = REG(PCIR_COMMAND, 2);
|
|
|
|
cfg->statreg = REG(PCIR_STATUS, 2);
|
|
|
|
cfg->baseclass = REG(PCIR_CLASS, 1);
|
|
|
|
cfg->subclass = REG(PCIR_SUBCLASS, 1);
|
|
|
|
cfg->progif = REG(PCIR_PROGIF, 1);
|
|
|
|
cfg->revid = REG(PCIR_REVID, 1);
|
2003-08-28 21:22:25 +00:00
|
|
|
cfg->hdrtype = REG(PCIR_HDRTYPE, 1);
|
2000-08-28 21:48:13 +00:00
|
|
|
cfg->cachelnsz = REG(PCIR_CACHELNSZ, 1);
|
|
|
|
cfg->lattimer = REG(PCIR_LATTIMER, 1);
|
|
|
|
cfg->intpin = REG(PCIR_INTPIN, 1);
|
|
|
|
cfg->intline = REG(PCIR_INTLINE, 1);
|
1997-05-27 04:09:01 +00:00
|
|
|
|
2000-08-28 21:48:13 +00:00
|
|
|
cfg->mingnt = REG(PCIR_MINGNT, 1);
|
|
|
|
cfg->maxlat = REG(PCIR_MAXLAT, 1);
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
|
|
|
|
cfg->mfdev = (cfg->hdrtype & PCIM_MFDEV) != 0;
|
|
|
|
cfg->hdrtype &= ~PCIM_MFDEV;
|
2011-03-31 13:22:12 +00:00
|
|
|
STAILQ_INIT(&cfg->maps);
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
|
|
|
|
pci_fixancient(cfg);
|
2000-08-28 21:48:13 +00:00
|
|
|
pci_hdrtypedata(pcib, b, s, f, cfg);
|
1998-09-15 08:21:13 +00:00
|
|
|
|
2000-12-13 01:25:11 +00:00
|
|
|
if (REG(PCIR_STATUS, 2) & PCIM_STATUS_CAPPRESENT)
|
2011-03-22 12:05:49 +00:00
|
|
|
pci_read_cap(pcib, cfg);
|
2000-12-13 01:25:11 +00:00
|
|
|
|
1998-09-15 08:21:13 +00:00
|
|
|
STAILQ_INSERT_TAIL(devlist_head, devlist_entry, pci_links);
|
|
|
|
|
2007-09-30 11:05:18 +00:00
|
|
|
devlist_entry->conf.pc_sel.pc_domain = cfg->domain;
|
1998-09-15 08:21:13 +00:00
|
|
|
devlist_entry->conf.pc_sel.pc_bus = cfg->bus;
|
|
|
|
devlist_entry->conf.pc_sel.pc_dev = cfg->slot;
|
|
|
|
devlist_entry->conf.pc_sel.pc_func = cfg->func;
|
|
|
|
devlist_entry->conf.pc_hdr = cfg->hdrtype;
|
|
|
|
|
|
|
|
devlist_entry->conf.pc_subvendor = cfg->subvendor;
|
|
|
|
devlist_entry->conf.pc_subdevice = cfg->subdevice;
|
|
|
|
devlist_entry->conf.pc_vendor = cfg->vendor;
|
|
|
|
devlist_entry->conf.pc_device = cfg->device;
|
|
|
|
|
|
|
|
devlist_entry->conf.pc_class = cfg->baseclass;
|
|
|
|
devlist_entry->conf.pc_subclass = cfg->subclass;
|
|
|
|
devlist_entry->conf.pc_progif = cfg->progif;
|
|
|
|
devlist_entry->conf.pc_revid = cfg->revid;
|
|
|
|
|
|
|
|
pci_numdevs++;
|
|
|
|
pci_generation++;
|
1995-09-07 15:20:53 +00:00
|
|
|
}
|
1998-09-15 08:21:13 +00:00
|
|
|
return (devlist_entry);
|
2000-08-28 21:48:13 +00:00
|
|
|
#undef REG
|
1995-03-21 23:01:06 +00:00
|
|
|
}
|
|
|
|
|
2003-02-17 19:47:02 +00:00
|
|
|
static void
|
2011-03-22 12:05:49 +00:00
|
|
|
pci_read_cap(device_t pcib, pcicfgregs *cfg)
|
2000-12-13 01:25:11 +00:00
|
|
|
{
|
2006-12-14 16:53:48 +00:00
|
|
|
#define REG(n, w) PCIB_READ_CONFIG(pcib, cfg->bus, cfg->slot, cfg->func, n, w)
|
|
|
|
#define WREG(n, v, w) PCIB_WRITE_CONFIG(pcib, cfg->bus, cfg->slot, cfg->func, n, v, w)
|
2010-05-16 15:18:25 +00:00
|
|
|
#if defined(__i386__) || defined(__amd64__) || defined(__powerpc__)
|
2006-12-12 19:33:25 +00:00
|
|
|
uint64_t addr;
|
|
|
|
#endif
|
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
|
|
|
uint32_t val;
|
2000-12-13 01:25:11 +00:00
|
|
|
int ptr, nextptr, ptrptr;
|
|
|
|
|
2003-09-14 06:23:19 +00:00
|
|
|
switch (cfg->hdrtype & PCIM_HDRTYPE) {
|
2010-07-29 20:42:38 +00:00
|
|
|
case PCIM_HDRTYPE_NORMAL:
|
|
|
|
case PCIM_HDRTYPE_BRIDGE:
|
2003-09-14 06:23:19 +00:00
|
|
|
ptrptr = PCIR_CAP_PTR;
|
2000-12-13 01:25:11 +00:00
|
|
|
break;
|
2010-07-29 20:42:38 +00:00
|
|
|
case PCIM_HDRTYPE_CARDBUS:
|
2006-10-09 16:15:56 +00:00
|
|
|
ptrptr = PCIR_CAP_PTR_2; /* cardbus capabilities ptr */
|
2000-12-13 01:25:11 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return; /* no extended capabilities support */
|
|
|
|
}
|
|
|
|
nextptr = REG(ptrptr, 1); /* sanity check? */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read capability entries.
|
|
|
|
*/
|
|
|
|
while (nextptr != 0) {
|
2001-01-01 16:49:31 +00:00
|
|
|
/* Sanity check */
|
|
|
|
if (nextptr > 255) {
|
|
|
|
printf("illegal PCI extended capability offset %d\n",
|
|
|
|
nextptr);
|
|
|
|
return;
|
|
|
|
}
|
2000-12-13 01:25:11 +00:00
|
|
|
/* Find the next entry */
|
|
|
|
ptr = nextptr;
|
2005-12-20 19:57:47 +00:00
|
|
|
nextptr = REG(ptr + PCICAP_NEXTPTR, 1);
|
2000-12-13 01:25:11 +00:00
|
|
|
|
|
|
|
/* Process this entry */
|
2005-12-20 19:57:47 +00:00
|
|
|
switch (REG(ptr + PCICAP_ID, 1)) {
|
2003-09-14 06:23:19 +00:00
|
|
|
case PCIY_PMG: /* PCI power management */
|
2003-09-14 19:30:00 +00:00
|
|
|
if (cfg->pp.pp_cap == 0) {
|
|
|
|
cfg->pp.pp_cap = REG(ptr + PCIR_POWER_CAP, 2);
|
|
|
|
cfg->pp.pp_status = ptr + PCIR_POWER_STATUS;
|
2010-10-20 23:41:16 +00:00
|
|
|
cfg->pp.pp_bse = ptr + PCIR_POWER_BSE;
|
2000-12-13 01:25:11 +00:00
|
|
|
if ((nextptr - ptr) > PCIR_POWER_DATA)
|
2003-09-14 19:30:00 +00:00
|
|
|
cfg->pp.pp_data = ptr + PCIR_POWER_DATA;
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
|
|
|
break;
|
2006-12-12 19:33:25 +00:00
|
|
|
case PCIY_HT: /* HyperTransport */
|
|
|
|
/* Determine HT-specific capability type. */
|
|
|
|
val = REG(ptr + PCIR_HT_COMMAND, 2);
|
2011-03-18 12:13:04 +00:00
|
|
|
|
2011-03-18 14:06:12 +00:00
|
|
|
if ((val & 0xe000) == PCIM_HTCAP_SLAVE)
|
2011-03-18 12:13:04 +00:00
|
|
|
cfg->ht.ht_slave = ptr;
|
|
|
|
|
|
|
|
#if defined(__i386__) || defined(__amd64__) || defined(__powerpc__)
|
2006-12-12 19:33:25 +00:00
|
|
|
switch (val & PCIM_HTCMD_CAP_MASK) {
|
|
|
|
case PCIM_HTCAP_MSI_MAPPING:
|
2007-04-25 14:45:46 +00:00
|
|
|
if (!(val & PCIM_HTCMD_MSI_FIXED)) {
|
|
|
|
/* Sanity check the mapping window. */
|
|
|
|
addr = REG(ptr + PCIR_HTMSI_ADDRESS_HI,
|
|
|
|
4);
|
|
|
|
addr <<= 32;
|
2009-02-26 14:32:14 +00:00
|
|
|
addr |= REG(ptr + PCIR_HTMSI_ADDRESS_LO,
|
2007-04-25 14:45:46 +00:00
|
|
|
4);
|
|
|
|
if (addr != MSI_INTEL_ADDR_BASE)
|
|
|
|
device_printf(pcib,
|
2011-03-18 12:13:04 +00:00
|
|
|
"HT device at pci%d:%d:%d:%d has non-default MSI window 0x%llx\n",
|
2007-09-30 11:05:18 +00:00
|
|
|
cfg->domain, cfg->bus,
|
|
|
|
cfg->slot, cfg->func,
|
|
|
|
(long long)addr);
|
2008-07-23 09:44:36 +00:00
|
|
|
} else
|
|
|
|
addr = MSI_INTEL_ADDR_BASE;
|
2006-12-12 19:33:25 +00:00
|
|
|
|
2008-07-23 09:44:36 +00:00
|
|
|
cfg->ht.ht_msimap = ptr;
|
|
|
|
cfg->ht.ht_msictrl = val;
|
|
|
|
cfg->ht.ht_msiaddr = addr;
|
2006-12-12 19:33:25 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
#endif
|
2011-03-18 12:13:04 +00:00
|
|
|
break;
|
2003-09-14 19:30:00 +00:00
|
|
|
case PCIY_MSI: /* PCI MSI */
|
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
|
|
|
cfg->msi.msi_location = ptr;
|
2003-09-14 19:30:00 +00:00
|
|
|
cfg->msi.msi_ctrl = REG(ptr + PCIR_MSI_CTRL, 2);
|
|
|
|
cfg->msi.msi_msgnum = 1 << ((cfg->msi.msi_ctrl &
|
|
|
|
PCIM_MSICTRL_MMC_MASK)>>1);
|
2006-10-09 16:15:56 +00:00
|
|
|
break;
|
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
|
|
|
case PCIY_MSIX: /* PCI MSI-X */
|
|
|
|
cfg->msix.msix_location = ptr;
|
|
|
|
cfg->msix.msix_ctrl = REG(ptr + PCIR_MSIX_CTRL, 2);
|
|
|
|
cfg->msix.msix_msgnum = (cfg->msix.msix_ctrl &
|
|
|
|
PCIM_MSIXCTRL_TABLE_SIZE) + 1;
|
|
|
|
val = REG(ptr + PCIR_MSIX_TABLE, 4);
|
|
|
|
cfg->msix.msix_table_bar = PCIR_BAR(val &
|
|
|
|
PCIM_MSIX_BIR_MASK);
|
|
|
|
cfg->msix.msix_table_offset = val & ~PCIM_MSIX_BIR_MASK;
|
|
|
|
val = REG(ptr + PCIR_MSIX_PBA, 4);
|
|
|
|
cfg->msix.msix_pba_bar = PCIR_BAR(val &
|
|
|
|
PCIM_MSIX_BIR_MASK);
|
|
|
|
cfg->msix.msix_pba_offset = val & ~PCIM_MSIX_BIR_MASK;
|
|
|
|
break;
|
2006-10-09 16:15:56 +00:00
|
|
|
case PCIY_VPD: /* PCI Vital Product Data */
|
2007-03-26 20:18:52 +00:00
|
|
|
cfg->vpd.vpd_reg = ptr;
|
2006-10-09 16:15:56 +00:00
|
|
|
break;
|
2007-01-16 17:04:42 +00:00
|
|
|
case PCIY_SUBVENDOR:
|
|
|
|
/* Should always be true. */
|
2010-07-29 20:42:38 +00:00
|
|
|
if ((cfg->hdrtype & PCIM_HDRTYPE) ==
|
|
|
|
PCIM_HDRTYPE_BRIDGE) {
|
2007-01-16 17:04:42 +00:00
|
|
|
val = REG(ptr + PCIR_SUBVENDCAP_ID, 4);
|
|
|
|
cfg->subvendor = val & 0xffff;
|
|
|
|
cfg->subdevice = val >> 16;
|
|
|
|
}
|
2007-02-14 17:02:15 +00:00
|
|
|
break;
|
2007-02-14 22:36:27 +00:00
|
|
|
case PCIY_PCIX: /* PCI-X */
|
|
|
|
/*
|
|
|
|
* Assume we have a PCI-X chipset if we have
|
|
|
|
* at least one PCI-PCI bridge with a PCI-X
|
|
|
|
* capability. Note that some systems with
|
|
|
|
* PCI-express or HT chipsets might match on
|
|
|
|
* this check as well.
|
|
|
|
*/
|
2010-07-29 20:42:38 +00:00
|
|
|
if ((cfg->hdrtype & PCIM_HDRTYPE) ==
|
|
|
|
PCIM_HDRTYPE_BRIDGE)
|
2007-02-14 22:36:27 +00:00
|
|
|
pcix_chipset = 1;
|
|
|
|
break;
|
|
|
|
case PCIY_EXPRESS: /* PCI-express */
|
|
|
|
/*
|
|
|
|
* Assume we have a PCI-express chipset if we have
|
2008-02-01 20:31:09 +00:00
|
|
|
* at least one PCI-express device.
|
2007-02-14 22:36:27 +00:00
|
|
|
*/
|
2008-02-01 20:31:09 +00:00
|
|
|
pcie_chipset = 1;
|
2007-02-14 22:36:27 +00:00
|
|
|
break;
|
2006-10-09 16:15:56 +00:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2011-03-18 12:13:04 +00:00
|
|
|
|
|
|
|
|
|
|
|
#if defined(__i386__) || defined(__amd64__) || defined(__powerpc__)
|
|
|
|
/*
|
|
|
|
* Enable the MSI mapping window for all HyperTransport
|
|
|
|
* slaves. PCI-PCI bridges have their windows enabled via
|
|
|
|
* PCIB_MAP_MSI().
|
|
|
|
*/
|
|
|
|
if (cfg->ht.ht_slave != 0 && cfg->ht.ht_msimap != 0 &&
|
|
|
|
!(cfg->ht.ht_msictrl & PCIM_HTCMD_MSI_ENABLE)) {
|
|
|
|
device_printf(pcib,
|
|
|
|
"Enabling MSI window for HyperTransport slave at pci%d:%d:%d:%d\n",
|
|
|
|
cfg->domain, cfg->bus, cfg->slot, cfg->func);
|
|
|
|
cfg->ht.ht_msictrl |= PCIM_HTCMD_MSI_ENABLE;
|
|
|
|
WREG(cfg->ht.ht_msimap + PCIR_HT_COMMAND, cfg->ht.ht_msictrl,
|
|
|
|
2);
|
|
|
|
}
|
|
|
|
#endif
|
2006-12-12 19:30:40 +00:00
|
|
|
/* REG and WREG use carry through to next functions */
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PCI Vital Product Data
|
|
|
|
*/
|
2007-11-16 20:49:34 +00:00
|
|
|
|
|
|
|
#define PCI_VPD_TIMEOUT 1000000
|
|
|
|
|
|
|
|
static int
|
|
|
|
pci_read_vpd_reg(device_t pcib, pcicfgregs *cfg, int reg, uint32_t *data)
|
2006-10-09 16:15:56 +00:00
|
|
|
{
|
2007-11-16 20:49:34 +00:00
|
|
|
int count = PCI_VPD_TIMEOUT;
|
2006-10-09 16:15:56 +00:00
|
|
|
|
|
|
|
KASSERT((reg & 3) == 0, ("VPD register must by 4 byte aligned"));
|
|
|
|
|
2007-03-05 16:21:59 +00:00
|
|
|
WREG(cfg->vpd.vpd_reg + PCIR_VPD_ADDR, reg, 2);
|
2007-11-16 20:49:34 +00:00
|
|
|
|
|
|
|
while ((REG(cfg->vpd.vpd_reg + PCIR_VPD_ADDR, 2) & 0x8000) != 0x8000) {
|
|
|
|
if (--count < 0)
|
|
|
|
return (ENXIO);
|
2006-10-09 16:15:56 +00:00
|
|
|
DELAY(1); /* limit looping */
|
2007-11-16 20:49:34 +00:00
|
|
|
}
|
|
|
|
*data = (REG(cfg->vpd.vpd_reg + PCIR_VPD_DATA, 4));
|
2006-10-09 16:15:56 +00:00
|
|
|
|
2007-11-16 20:49:34 +00:00
|
|
|
return (0);
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#if 0
|
2007-11-16 20:49:34 +00:00
|
|
|
static int
|
2006-10-09 16:15:56 +00:00
|
|
|
pci_write_vpd_reg(device_t pcib, pcicfgregs *cfg, int reg, uint32_t data)
|
|
|
|
{
|
2007-11-16 20:49:34 +00:00
|
|
|
int count = PCI_VPD_TIMEOUT;
|
|
|
|
|
2006-10-09 16:15:56 +00:00
|
|
|
KASSERT((reg & 3) == 0, ("VPD register must by 4 byte aligned"));
|
|
|
|
|
2007-03-05 16:21:59 +00:00
|
|
|
WREG(cfg->vpd.vpd_reg + PCIR_VPD_DATA, data, 4);
|
|
|
|
WREG(cfg->vpd.vpd_reg + PCIR_VPD_ADDR, reg | 0x8000, 2);
|
2007-11-16 20:49:34 +00:00
|
|
|
while ((REG(cfg->vpd.vpd_reg + PCIR_VPD_ADDR, 2) & 0x8000) == 0x8000) {
|
|
|
|
if (--count < 0)
|
|
|
|
return (ENXIO);
|
2006-10-09 16:15:56 +00:00
|
|
|
DELAY(1); /* limit looping */
|
2007-11-16 20:49:34 +00:00
|
|
|
}
|
2006-10-09 16:15:56 +00:00
|
|
|
|
2007-11-16 20:49:34 +00:00
|
|
|
return (0);
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2007-11-16 20:49:34 +00:00
|
|
|
#undef PCI_VPD_TIMEOUT
|
|
|
|
|
2006-10-09 16:15:56 +00:00
|
|
|
struct vpd_readstate {
|
|
|
|
device_t pcib;
|
|
|
|
pcicfgregs *cfg;
|
|
|
|
uint32_t val;
|
|
|
|
int bytesinval;
|
|
|
|
int off;
|
|
|
|
uint8_t cksum;
|
|
|
|
};
|
|
|
|
|
2007-11-16 20:49:34 +00:00
|
|
|
static int
|
|
|
|
vpd_nextbyte(struct vpd_readstate *vrs, uint8_t *data)
|
2006-10-09 16:15:56 +00:00
|
|
|
{
|
2007-11-16 20:49:34 +00:00
|
|
|
uint32_t reg;
|
2006-10-09 16:15:56 +00:00
|
|
|
uint8_t byte;
|
|
|
|
|
|
|
|
if (vrs->bytesinval == 0) {
|
2007-11-16 20:49:34 +00:00
|
|
|
if (pci_read_vpd_reg(vrs->pcib, vrs->cfg, vrs->off, ®))
|
|
|
|
return (ENXIO);
|
|
|
|
vrs->val = le32toh(reg);
|
2006-10-09 16:15:56 +00:00
|
|
|
vrs->off += 4;
|
|
|
|
byte = vrs->val & 0xff;
|
|
|
|
vrs->bytesinval = 3;
|
|
|
|
} else {
|
|
|
|
vrs->val = vrs->val >> 8;
|
|
|
|
byte = vrs->val & 0xff;
|
|
|
|
vrs->bytesinval--;
|
|
|
|
}
|
|
|
|
|
|
|
|
vrs->cksum += byte;
|
2007-11-16 20:49:34 +00:00
|
|
|
*data = byte;
|
|
|
|
return (0);
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
pci_read_vpd(device_t pcib, pcicfgregs *cfg)
|
|
|
|
{
|
|
|
|
struct vpd_readstate vrs;
|
|
|
|
int state;
|
|
|
|
int name;
|
|
|
|
int remain;
|
|
|
|
int i;
|
|
|
|
int alloc, off; /* alloc/off for RO/W arrays */
|
|
|
|
int cksumvalid;
|
|
|
|
int dflen;
|
2007-11-16 20:49:34 +00:00
|
|
|
uint8_t byte;
|
|
|
|
uint8_t byte2;
|
2007-03-26 20:18:52 +00:00
|
|
|
|
2006-10-09 16:15:56 +00:00
|
|
|
/* init vpd reader */
|
|
|
|
vrs.bytesinval = 0;
|
|
|
|
vrs.off = 0;
|
|
|
|
vrs.pcib = pcib;
|
|
|
|
vrs.cfg = cfg;
|
|
|
|
vrs.cksum = 0;
|
|
|
|
|
|
|
|
state = 0;
|
|
|
|
name = remain = i = 0; /* shut up stupid gcc */
|
|
|
|
alloc = off = 0; /* shut up stupid gcc */
|
|
|
|
dflen = 0; /* shut up stupid gcc */
|
|
|
|
cksumvalid = -1;
|
2007-11-16 20:49:34 +00:00
|
|
|
while (state >= 0) {
|
|
|
|
if (vpd_nextbyte(&vrs, &byte)) {
|
|
|
|
state = -2;
|
|
|
|
break;
|
|
|
|
}
|
2006-10-09 16:15:56 +00:00
|
|
|
#if 0
|
|
|
|
printf("vpd: val: %#x, off: %d, bytesinval: %d, byte: %#hhx, " \
|
|
|
|
"state: %d, remain: %d, name: %#x, i: %d\n", vrs.val,
|
|
|
|
vrs.off, vrs.bytesinval, byte, state, remain, name, i);
|
|
|
|
#endif
|
|
|
|
switch (state) {
|
|
|
|
case 0: /* item name */
|
|
|
|
if (byte & 0x80) {
|
2007-11-16 20:49:34 +00:00
|
|
|
if (vpd_nextbyte(&vrs, &byte2)) {
|
|
|
|
state = -2;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
remain = byte2;
|
|
|
|
if (vpd_nextbyte(&vrs, &byte2)) {
|
|
|
|
state = -2;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
remain |= byte2 << 8;
|
2006-10-09 16:15:56 +00:00
|
|
|
if (remain > (0x7f*4 - vrs.off)) {
|
2007-11-16 20:49:34 +00:00
|
|
|
state = -1;
|
2006-10-09 16:15:56 +00:00
|
|
|
printf(
|
2007-11-16 20:49:34 +00:00
|
|
|
"pci%d:%d:%d:%d: invalid VPD data, remain %#x\n",
|
2007-09-30 11:05:18 +00:00
|
|
|
cfg->domain, cfg->bus, cfg->slot,
|
|
|
|
cfg->func, remain);
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
name = byte & 0x7f;
|
|
|
|
} else {
|
|
|
|
remain = byte & 0x7;
|
|
|
|
name = (byte >> 3) & 0xf;
|
|
|
|
}
|
|
|
|
switch (name) {
|
|
|
|
case 0x2: /* String */
|
|
|
|
cfg->vpd.vpd_ident = malloc(remain + 1,
|
|
|
|
M_DEVBUF, M_WAITOK);
|
|
|
|
i = 0;
|
|
|
|
state = 1;
|
|
|
|
break;
|
|
|
|
case 0xf: /* End */
|
|
|
|
state = -1;
|
|
|
|
break;
|
|
|
|
case 0x10: /* VPD-R */
|
|
|
|
alloc = 8;
|
|
|
|
off = 0;
|
|
|
|
cfg->vpd.vpd_ros = malloc(alloc *
|
2007-11-16 20:49:34 +00:00
|
|
|
sizeof(*cfg->vpd.vpd_ros), M_DEVBUF,
|
|
|
|
M_WAITOK | M_ZERO);
|
2006-10-09 16:15:56 +00:00
|
|
|
state = 2;
|
|
|
|
break;
|
|
|
|
case 0x11: /* VPD-W */
|
|
|
|
alloc = 8;
|
|
|
|
off = 0;
|
|
|
|
cfg->vpd.vpd_w = malloc(alloc *
|
2007-11-16 20:49:34 +00:00
|
|
|
sizeof(*cfg->vpd.vpd_w), M_DEVBUF,
|
|
|
|
M_WAITOK | M_ZERO);
|
2006-10-09 16:15:56 +00:00
|
|
|
state = 5;
|
|
|
|
break;
|
2006-11-09 21:05:32 +00:00
|
|
|
default: /* Invalid data, abort */
|
2007-11-16 20:49:34 +00:00
|
|
|
state = -1;
|
|
|
|
break;
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 1: /* Identifier String */
|
|
|
|
cfg->vpd.vpd_ident[i++] = byte;
|
|
|
|
remain--;
|
|
|
|
if (remain == 0) {
|
|
|
|
cfg->vpd.vpd_ident[i] = '\0';
|
|
|
|
state = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 2: /* VPD-R Keyword Header */
|
|
|
|
if (off == alloc) {
|
|
|
|
cfg->vpd.vpd_ros = reallocf(cfg->vpd.vpd_ros,
|
2007-11-16 20:49:34 +00:00
|
|
|
(alloc *= 2) * sizeof(*cfg->vpd.vpd_ros),
|
|
|
|
M_DEVBUF, M_WAITOK | M_ZERO);
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
cfg->vpd.vpd_ros[off].keyword[0] = byte;
|
2007-11-16 20:49:34 +00:00
|
|
|
if (vpd_nextbyte(&vrs, &byte2)) {
|
|
|
|
state = -2;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
cfg->vpd.vpd_ros[off].keyword[1] = byte2;
|
|
|
|
if (vpd_nextbyte(&vrs, &byte2)) {
|
|
|
|
state = -2;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
dflen = byte2;
|
2006-10-20 21:28:11 +00:00
|
|
|
if (dflen == 0 &&
|
|
|
|
strncmp(cfg->vpd.vpd_ros[off].keyword, "RV",
|
|
|
|
2) == 0) {
|
|
|
|
/*
|
|
|
|
* if this happens, we can't trust the rest
|
|
|
|
* of the VPD.
|
|
|
|
*/
|
2007-09-30 11:05:18 +00:00
|
|
|
printf(
|
|
|
|
"pci%d:%d:%d:%d: bad keyword length: %d\n",
|
|
|
|
cfg->domain, cfg->bus, cfg->slot,
|
|
|
|
cfg->func, dflen);
|
2006-10-20 21:28:11 +00:00
|
|
|
cksumvalid = 0;
|
2007-11-16 20:49:34 +00:00
|
|
|
state = -1;
|
2006-10-20 21:28:11 +00:00
|
|
|
break;
|
|
|
|
} else if (dflen == 0) {
|
|
|
|
cfg->vpd.vpd_ros[off].value = malloc(1 *
|
2007-11-16 20:49:34 +00:00
|
|
|
sizeof(*cfg->vpd.vpd_ros[off].value),
|
2006-10-20 21:28:11 +00:00
|
|
|
M_DEVBUF, M_WAITOK);
|
|
|
|
cfg->vpd.vpd_ros[off].value[0] = '\x00';
|
|
|
|
} else
|
|
|
|
cfg->vpd.vpd_ros[off].value = malloc(
|
|
|
|
(dflen + 1) *
|
2007-11-16 20:49:34 +00:00
|
|
|
sizeof(*cfg->vpd.vpd_ros[off].value),
|
2006-10-20 21:28:11 +00:00
|
|
|
M_DEVBUF, M_WAITOK);
|
2006-10-09 16:15:56 +00:00
|
|
|
remain -= 3;
|
|
|
|
i = 0;
|
2006-10-20 21:28:11 +00:00
|
|
|
/* keep in sync w/ state 3's transistions */
|
|
|
|
if (dflen == 0 && remain == 0)
|
|
|
|
state = 0;
|
|
|
|
else if (dflen == 0)
|
|
|
|
state = 2;
|
|
|
|
else
|
|
|
|
state = 3;
|
2006-10-09 16:15:56 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 3: /* VPD-R Keyword Value */
|
|
|
|
cfg->vpd.vpd_ros[off].value[i++] = byte;
|
|
|
|
if (strncmp(cfg->vpd.vpd_ros[off].keyword,
|
|
|
|
"RV", 2) == 0 && cksumvalid == -1) {
|
|
|
|
if (vrs.cksum == 0)
|
|
|
|
cksumvalid = 1;
|
|
|
|
else {
|
2007-11-16 20:49:34 +00:00
|
|
|
if (bootverbose)
|
|
|
|
printf(
|
2007-09-30 11:05:18 +00:00
|
|
|
"pci%d:%d:%d:%d: bad VPD cksum, remain %hhu\n",
|
2007-11-16 20:49:34 +00:00
|
|
|
cfg->domain, cfg->bus,
|
|
|
|
cfg->slot, cfg->func,
|
|
|
|
vrs.cksum);
|
2006-10-09 16:15:56 +00:00
|
|
|
cksumvalid = 0;
|
2007-11-16 20:49:34 +00:00
|
|
|
state = -1;
|
2006-10-20 21:28:11 +00:00
|
|
|
break;
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
dflen--;
|
|
|
|
remain--;
|
2006-10-20 21:28:11 +00:00
|
|
|
/* keep in sync w/ state 2's transistions */
|
2006-10-09 16:15:56 +00:00
|
|
|
if (dflen == 0)
|
|
|
|
cfg->vpd.vpd_ros[off++].value[i++] = '\0';
|
|
|
|
if (dflen == 0 && remain == 0) {
|
|
|
|
cfg->vpd.vpd_rocnt = off;
|
|
|
|
cfg->vpd.vpd_ros = reallocf(cfg->vpd.vpd_ros,
|
2007-11-16 20:49:34 +00:00
|
|
|
off * sizeof(*cfg->vpd.vpd_ros),
|
|
|
|
M_DEVBUF, M_WAITOK | M_ZERO);
|
2006-10-09 16:15:56 +00:00
|
|
|
state = 0;
|
|
|
|
} else if (dflen == 0)
|
|
|
|
state = 2;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 4:
|
|
|
|
remain--;
|
|
|
|
if (remain == 0)
|
|
|
|
state = 0;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 5: /* VPD-W Keyword Header */
|
|
|
|
if (off == alloc) {
|
|
|
|
cfg->vpd.vpd_w = reallocf(cfg->vpd.vpd_w,
|
2007-11-16 20:49:34 +00:00
|
|
|
(alloc *= 2) * sizeof(*cfg->vpd.vpd_w),
|
|
|
|
M_DEVBUF, M_WAITOK | M_ZERO);
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
cfg->vpd.vpd_w[off].keyword[0] = byte;
|
2007-11-16 20:49:34 +00:00
|
|
|
if (vpd_nextbyte(&vrs, &byte2)) {
|
|
|
|
state = -2;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
cfg->vpd.vpd_w[off].keyword[1] = byte2;
|
|
|
|
if (vpd_nextbyte(&vrs, &byte2)) {
|
|
|
|
state = -2;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
cfg->vpd.vpd_w[off].len = dflen = byte2;
|
2006-10-09 16:15:56 +00:00
|
|
|
cfg->vpd.vpd_w[off].start = vrs.off - vrs.bytesinval;
|
|
|
|
cfg->vpd.vpd_w[off].value = malloc((dflen + 1) *
|
2007-11-16 20:49:34 +00:00
|
|
|
sizeof(*cfg->vpd.vpd_w[off].value),
|
2006-10-09 16:15:56 +00:00
|
|
|
M_DEVBUF, M_WAITOK);
|
|
|
|
remain -= 3;
|
|
|
|
i = 0;
|
2006-10-20 21:28:11 +00:00
|
|
|
/* keep in sync w/ state 6's transistions */
|
|
|
|
if (dflen == 0 && remain == 0)
|
|
|
|
state = 0;
|
|
|
|
else if (dflen == 0)
|
|
|
|
state = 5;
|
|
|
|
else
|
|
|
|
state = 6;
|
2006-10-09 16:15:56 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 6: /* VPD-W Keyword Value */
|
|
|
|
cfg->vpd.vpd_w[off].value[i++] = byte;
|
|
|
|
dflen--;
|
|
|
|
remain--;
|
2006-10-20 21:28:11 +00:00
|
|
|
/* keep in sync w/ state 5's transistions */
|
2006-10-09 16:15:56 +00:00
|
|
|
if (dflen == 0)
|
|
|
|
cfg->vpd.vpd_w[off++].value[i++] = '\0';
|
|
|
|
if (dflen == 0 && remain == 0) {
|
|
|
|
cfg->vpd.vpd_wcnt = off;
|
|
|
|
cfg->vpd.vpd_w = reallocf(cfg->vpd.vpd_w,
|
2007-11-16 20:49:34 +00:00
|
|
|
off * sizeof(*cfg->vpd.vpd_w),
|
|
|
|
M_DEVBUF, M_WAITOK | M_ZERO);
|
2006-10-09 16:15:56 +00:00
|
|
|
state = 0;
|
|
|
|
} else if (dflen == 0)
|
|
|
|
state = 5;
|
|
|
|
break;
|
|
|
|
|
2000-12-13 01:25:11 +00:00
|
|
|
default:
|
2007-09-30 11:05:18 +00:00
|
|
|
printf("pci%d:%d:%d:%d: invalid state: %d\n",
|
|
|
|
cfg->domain, cfg->bus, cfg->slot, cfg->func,
|
|
|
|
state);
|
2007-11-16 20:49:34 +00:00
|
|
|
state = -1;
|
2000-12-13 01:25:11 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2006-10-20 21:28:11 +00:00
|
|
|
|
2007-11-16 20:49:34 +00:00
|
|
|
if (cksumvalid == 0 || state < -1) {
|
2006-10-20 21:28:11 +00:00
|
|
|
/* read-only data bad, clean up */
|
2007-11-16 20:49:34 +00:00
|
|
|
if (cfg->vpd.vpd_ros != NULL) {
|
|
|
|
for (off = 0; cfg->vpd.vpd_ros[off].value; off++)
|
|
|
|
free(cfg->vpd.vpd_ros[off].value, M_DEVBUF);
|
|
|
|
free(cfg->vpd.vpd_ros, M_DEVBUF);
|
|
|
|
cfg->vpd.vpd_ros = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (state < -1) {
|
|
|
|
/* I/O error, clean up */
|
|
|
|
printf("pci%d:%d:%d:%d: failed to read VPD data.\n",
|
|
|
|
cfg->domain, cfg->bus, cfg->slot, cfg->func);
|
|
|
|
if (cfg->vpd.vpd_ident != NULL) {
|
|
|
|
free(cfg->vpd.vpd_ident, M_DEVBUF);
|
|
|
|
cfg->vpd.vpd_ident = NULL;
|
|
|
|
}
|
|
|
|
if (cfg->vpd.vpd_w != NULL) {
|
|
|
|
for (off = 0; cfg->vpd.vpd_w[off].value; off++)
|
|
|
|
free(cfg->vpd.vpd_w[off].value, M_DEVBUF);
|
|
|
|
free(cfg->vpd.vpd_w, M_DEVBUF);
|
|
|
|
cfg->vpd.vpd_w = NULL;
|
|
|
|
}
|
2006-10-20 21:28:11 +00:00
|
|
|
}
|
2007-03-26 20:18:52 +00:00
|
|
|
cfg->vpd.vpd_cached = 1;
|
2000-12-13 01:25:11 +00:00
|
|
|
#undef REG
|
2006-12-12 19:30:40 +00:00
|
|
|
#undef WREG
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
|
|
|
|
2006-10-09 16:15:56 +00:00
|
|
|
int
|
|
|
|
pci_get_vpd_ident_method(device_t dev, device_t child, const char **identptr)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
|
2007-03-26 20:18:52 +00:00
|
|
|
if (!cfg->vpd.vpd_cached && cfg->vpd.vpd_reg != 0)
|
|
|
|
pci_read_vpd(device_get_parent(dev), cfg);
|
|
|
|
|
2006-10-09 16:15:56 +00:00
|
|
|
*identptr = cfg->vpd.vpd_ident;
|
|
|
|
|
|
|
|
if (*identptr == NULL)
|
2007-03-05 16:21:59 +00:00
|
|
|
return (ENXIO);
|
2006-10-09 16:15:56 +00:00
|
|
|
|
2007-03-05 16:21:59 +00:00
|
|
|
return (0);
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
pci_get_vpd_readonly_method(device_t dev, device_t child, const char *kw,
|
|
|
|
const char **vptr)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
int i;
|
|
|
|
|
2007-03-26 20:18:52 +00:00
|
|
|
if (!cfg->vpd.vpd_cached && cfg->vpd.vpd_reg != 0)
|
|
|
|
pci_read_vpd(device_get_parent(dev), cfg);
|
|
|
|
|
2006-10-09 16:15:56 +00:00
|
|
|
for (i = 0; i < cfg->vpd.vpd_rocnt; i++)
|
|
|
|
if (memcmp(kw, cfg->vpd.vpd_ros[i].keyword,
|
2007-11-16 20:49:34 +00:00
|
|
|
sizeof(cfg->vpd.vpd_ros[i].keyword)) == 0) {
|
2006-10-09 16:15:56 +00:00
|
|
|
*vptr = cfg->vpd.vpd_ros[i].value;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i != cfg->vpd.vpd_rocnt)
|
2007-03-05 16:21:59 +00:00
|
|
|
return (0);
|
2006-10-09 16:15:56 +00:00
|
|
|
|
|
|
|
*vptr = NULL;
|
2007-03-05 16:21:59 +00:00
|
|
|
return (ENXIO);
|
2006-10-09 16:15:56 +00:00
|
|
|
}
|
|
|
|
|
2005-12-20 19:57:47 +00:00
|
|
|
/*
|
2009-04-03 10:15:00 +00:00
|
|
|
* Find the requested extended capability and return the offset in
|
|
|
|
* configuration space via the pointer provided. The function returns
|
|
|
|
* 0 on success and error code otherwise.
|
2009-04-03 13:35:54 +00:00
|
|
|
*/
|
2005-12-20 19:57:47 +00:00
|
|
|
int
|
|
|
|
pci_find_extcap_method(device_t dev, device_t child, int capability,
|
|
|
|
int *capreg)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
u_int32_t status;
|
|
|
|
u_int8_t ptr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check the CAP_LIST bit of the PCI status register first.
|
|
|
|
*/
|
|
|
|
status = pci_read_config(child, PCIR_STATUS, 2);
|
|
|
|
if (!(status & PCIM_STATUS_CAPPRESENT))
|
|
|
|
return (ENXIO);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Determine the start pointer of the capabilities list.
|
|
|
|
*/
|
|
|
|
switch (cfg->hdrtype & PCIM_HDRTYPE) {
|
2010-07-29 20:42:38 +00:00
|
|
|
case PCIM_HDRTYPE_NORMAL:
|
|
|
|
case PCIM_HDRTYPE_BRIDGE:
|
2005-12-20 19:57:47 +00:00
|
|
|
ptr = PCIR_CAP_PTR;
|
|
|
|
break;
|
2010-07-29 20:42:38 +00:00
|
|
|
case PCIM_HDRTYPE_CARDBUS:
|
2005-12-20 19:57:47 +00:00
|
|
|
ptr = PCIR_CAP_PTR_2;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* XXX: panic? */
|
|
|
|
return (ENXIO); /* no extended capabilities support */
|
|
|
|
}
|
|
|
|
ptr = pci_read_config(child, ptr, 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Traverse the capabilities list.
|
|
|
|
*/
|
|
|
|
while (ptr != 0) {
|
|
|
|
if (pci_read_config(child, ptr + PCICAP_ID, 1) == capability) {
|
|
|
|
if (capreg != NULL)
|
|
|
|
*capreg = ptr;
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
ptr = pci_read_config(child, ptr + PCICAP_NEXTPTR, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (ENOENT);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Support for MSI-X message interrupts.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
pci_enable_msix(device_t dev, u_int index, uint64_t address, uint32_t data)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msix *msix = &dinfo->cfg.msix;
|
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
|
|
|
uint32_t offset;
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
KASSERT(msix->msix_table_len > index, ("bogus index"));
|
2007-05-02 16:21:18 +00:00
|
|
|
offset = msix->msix_table_offset + index * 16;
|
|
|
|
bus_write_4(msix->msix_table_res, offset, address & 0xffffffff);
|
|
|
|
bus_write_4(msix->msix_table_res, offset + 4, address >> 32);
|
|
|
|
bus_write_4(msix->msix_table_res, offset + 8, data);
|
2008-07-23 09:44:36 +00:00
|
|
|
|
|
|
|
/* Enable MSI -> HT mapping. */
|
|
|
|
pci_ht_map_msi(dev, address);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
pci_mask_msix(device_t dev, u_int index)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msix *msix = &dinfo->cfg.msix;
|
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
|
|
|
uint32_t offset, val;
|
|
|
|
|
2007-05-02 16:21:18 +00:00
|
|
|
KASSERT(msix->msix_msgnum > index, ("bogus index"));
|
|
|
|
offset = msix->msix_table_offset + index * 16 + 12;
|
|
|
|
val = bus_read_4(msix->msix_table_res, offset);
|
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
|
|
|
if (!(val & PCIM_MSIX_VCTRL_MASK)) {
|
|
|
|
val |= PCIM_MSIX_VCTRL_MASK;
|
2007-05-02 16:21:18 +00:00
|
|
|
bus_write_4(msix->msix_table_res, offset, val);
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
pci_unmask_msix(device_t dev, u_int index)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msix *msix = &dinfo->cfg.msix;
|
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
|
|
|
uint32_t offset, val;
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
KASSERT(msix->msix_table_len > index, ("bogus index"));
|
2007-05-02 16:21:18 +00:00
|
|
|
offset = msix->msix_table_offset + index * 16 + 12;
|
|
|
|
val = bus_read_4(msix->msix_table_res, offset);
|
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
|
|
|
if (val & PCIM_MSIX_VCTRL_MASK) {
|
|
|
|
val &= ~PCIM_MSIX_VCTRL_MASK;
|
2007-05-02 16:21:18 +00:00
|
|
|
bus_write_4(msix->msix_table_res, offset, val);
|
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
|
|
|
|
pci_pending_msix(device_t dev, u_int index)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msix *msix = &dinfo->cfg.msix;
|
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
|
|
|
uint32_t offset, bit;
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
KASSERT(msix->msix_table_len > index, ("bogus index"));
|
2007-05-02 16:21:18 +00:00
|
|
|
offset = msix->msix_pba_offset + (index / 32) * 4;
|
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
|
|
|
bit = 1 << index % 32;
|
2007-05-02 16:21:18 +00:00
|
|
|
return (bus_read_4(msix->msix_pba_res, offset) & bit);
|
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
|
|
|
/*
|
|
|
|
* Restore MSI-X registers and table during resume. If MSI-X is
|
|
|
|
* enabled then walk the virtual table to restore the actual MSI-X
|
|
|
|
* table.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
pci_resume_msix(device_t dev)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
|
|
|
struct pcicfg_msix *msix = &dinfo->cfg.msix;
|
|
|
|
struct msix_table_entry *mte;
|
|
|
|
struct msix_vector *mv;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (msix->msix_alloc > 0) {
|
|
|
|
/* First, mask all vectors. */
|
|
|
|
for (i = 0; i < msix->msix_msgnum; i++)
|
|
|
|
pci_mask_msix(dev, i);
|
|
|
|
|
|
|
|
/* Second, program any messages with at least one handler. */
|
|
|
|
for (i = 0; i < msix->msix_table_len; i++) {
|
|
|
|
mte = &msix->msix_table[i];
|
|
|
|
if (mte->mte_vector == 0 || mte->mte_handlers == 0)
|
|
|
|
continue;
|
|
|
|
mv = &msix->msix_vectors[mte->mte_vector - 1];
|
|
|
|
pci_enable_msix(dev, i, mv->mv_address, mv->mv_data);
|
|
|
|
pci_unmask_msix(dev, i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
pci_write_config(dev, msix->msix_location + PCIR_MSIX_CTRL,
|
|
|
|
msix->msix_ctrl, 2);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Attempt to allocate *count MSI-X messages. The actual number allocated is
|
|
|
|
* returned in *count. After this function returns, each message will be
|
|
|
|
* available to the driver as SYS_RES_IRQ resources starting at rid 1.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
pci_alloc_msix_method(device_t dev, device_t child, int *count)
|
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
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
struct resource_list_entry *rle;
|
|
|
|
int actual, error, i, irq, max;
|
|
|
|
|
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
|
|
|
/* Don't let count == 0 get us into trouble. */
|
|
|
|
if (*count == 0)
|
|
|
|
return (EINVAL);
|
|
|
|
|
|
|
|
/* If rid 0 is allocated, then fail. */
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ, 0);
|
|
|
|
if (rle != NULL && rle->res != NULL)
|
|
|
|
return (ENXIO);
|
|
|
|
|
|
|
|
/* Already have allocated messages? */
|
|
|
|
if (cfg->msi.msi_alloc != 0 || cfg->msix.msix_alloc != 0)
|
|
|
|
return (ENXIO);
|
|
|
|
|
|
|
|
/* If MSI is blacklisted for this system, fail. */
|
|
|
|
if (pci_msi_blacklisted())
|
|
|
|
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
|
|
|
/* MSI-X capability present? */
|
|
|
|
if (cfg->msix.msix_location == 0 || !pci_do_msix)
|
|
|
|
return (ENODEV);
|
|
|
|
|
|
|
|
/* Make sure the appropriate BARs are mapped. */
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_MEMORY,
|
|
|
|
cfg->msix.msix_table_bar);
|
|
|
|
if (rle == NULL || rle->res == NULL ||
|
|
|
|
!(rman_get_flags(rle->res) & RF_ACTIVE))
|
|
|
|
return (ENXIO);
|
|
|
|
cfg->msix.msix_table_res = rle->res;
|
|
|
|
if (cfg->msix.msix_pba_bar != cfg->msix.msix_table_bar) {
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_MEMORY,
|
|
|
|
cfg->msix.msix_pba_bar);
|
|
|
|
if (rle == NULL || rle->res == NULL ||
|
|
|
|
!(rman_get_flags(rle->res) & RF_ACTIVE))
|
|
|
|
return (ENXIO);
|
|
|
|
}
|
|
|
|
cfg->msix.msix_pba_res = rle->res;
|
|
|
|
|
2006-12-12 19:29:01 +00:00
|
|
|
if (bootverbose)
|
|
|
|
device_printf(child,
|
|
|
|
"attempting to allocate %d MSI-X vectors (%d supported)\n",
|
|
|
|
*count, cfg->msix.msix_msgnum);
|
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
|
|
|
max = min(*count, cfg->msix.msix_msgnum);
|
|
|
|
for (i = 0; i < max; i++) {
|
|
|
|
/* Allocate a message. */
|
2007-05-02 17:50:36 +00:00
|
|
|
error = PCIB_ALLOC_MSIX(device_get_parent(dev), child, &irq);
|
2011-07-13 18:35:47 +00:00
|
|
|
if (error) {
|
|
|
|
if (i == 0)
|
|
|
|
return (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
|
|
|
break;
|
2011-07-13 18:35:47 +00:00
|
|
|
}
|
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
|
|
|
resource_list_add(&dinfo->resources, SYS_RES_IRQ, i + 1, irq,
|
|
|
|
irq, 1);
|
|
|
|
}
|
|
|
|
actual = i;
|
|
|
|
|
2006-12-12 19:29:01 +00:00
|
|
|
if (bootverbose) {
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ, 1);
|
|
|
|
if (actual == 1)
|
|
|
|
device_printf(child, "using IRQ %lu for MSI-X\n",
|
|
|
|
rle->start);
|
|
|
|
else {
|
|
|
|
int run;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Be fancy and try to print contiguous runs of
|
|
|
|
* IRQ values as ranges. 'irq' is the previous IRQ.
|
|
|
|
* 'run' is true if we are in a range.
|
|
|
|
*/
|
|
|
|
device_printf(child, "using IRQs %lu", rle->start);
|
|
|
|
irq = rle->start;
|
|
|
|
run = 0;
|
|
|
|
for (i = 1; i < actual; i++) {
|
|
|
|
rle = resource_list_find(&dinfo->resources,
|
|
|
|
SYS_RES_IRQ, i + 1);
|
|
|
|
|
|
|
|
/* Still in a run? */
|
|
|
|
if (rle->start == irq + 1) {
|
|
|
|
run = 1;
|
|
|
|
irq++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Finish previous range. */
|
|
|
|
if (run) {
|
|
|
|
printf("-%d", irq);
|
|
|
|
run = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Start new range. */
|
|
|
|
printf(",%lu", rle->start);
|
|
|
|
irq = rle->start;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Unfinished range? */
|
|
|
|
if (run)
|
2007-02-14 22:32:55 +00:00
|
|
|
printf("-%d", irq);
|
2006-12-12 19:29:01 +00:00
|
|
|
printf(" for MSI-X\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/* Mask all vectors. */
|
|
|
|
for (i = 0; i < cfg->msix.msix_msgnum; i++)
|
|
|
|
pci_mask_msix(child, i);
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
/* Allocate and initialize vector data and virtual table. */
|
|
|
|
cfg->msix.msix_vectors = malloc(sizeof(struct msix_vector) * actual,
|
|
|
|
M_DEVBUF, M_WAITOK | M_ZERO);
|
|
|
|
cfg->msix.msix_table = malloc(sizeof(struct msix_table_entry) * actual,
|
|
|
|
M_DEVBUF, M_WAITOK | M_ZERO);
|
|
|
|
for (i = 0; i < actual; i++) {
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ, i + 1);
|
|
|
|
cfg->msix.msix_vectors[i].mv_irq = rle->start;
|
|
|
|
cfg->msix.msix_table[i].mte_vector = i + 1;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/* Update control register to enable MSI-X. */
|
|
|
|
cfg->msix.msix_ctrl |= PCIM_MSIXCTRL_MSIX_ENABLE;
|
|
|
|
pci_write_config(child, cfg->msix.msix_location + PCIR_MSIX_CTRL,
|
|
|
|
cfg->msix.msix_ctrl, 2);
|
|
|
|
|
|
|
|
/* Update counts of alloc'd messages. */
|
|
|
|
cfg->msix.msix_alloc = actual;
|
2007-05-02 17:50:36 +00:00
|
|
|
cfg->msix.msix_table_len = actual;
|
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
|
|
|
*count = actual;
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
* By default, pci_alloc_msix() will assign the allocated IRQ
|
|
|
|
* resources consecutively to the first N messages in the MSI-X table.
|
|
|
|
* However, device drivers may want to use different layouts if they
|
|
|
|
* either receive fewer messages than they asked for, or they wish to
|
|
|
|
* populate the MSI-X table sparsely. This method allows the driver
|
|
|
|
* to specify what layout it wants. It must be called after a
|
|
|
|
* successful pci_alloc_msix() but before any of the associated
|
|
|
|
* SYS_RES_IRQ resources are allocated via bus_alloc_resource().
|
|
|
|
*
|
|
|
|
* The 'vectors' array contains 'count' message vectors. The array
|
|
|
|
* maps directly to the MSI-X table in that index 0 in the array
|
|
|
|
* specifies the vector for the first message in the MSI-X table, etc.
|
|
|
|
* The vector value in each array index can either be 0 to indicate
|
|
|
|
* that no vector should be assigned to a message slot, or it can be a
|
|
|
|
* number from 1 to N (where N is the count returned from a
|
|
|
|
* succcessful call to pci_alloc_msix()) to indicate which message
|
|
|
|
* vector (IRQ) to be used for the corresponding message.
|
|
|
|
*
|
|
|
|
* On successful return, each message with a non-zero vector will have
|
|
|
|
* an associated SYS_RES_IRQ whose rid is equal to the array index +
|
|
|
|
* 1. Additionally, if any of the IRQs allocated via the previous
|
|
|
|
* call to pci_alloc_msix() are not used in the mapping, those IRQs
|
|
|
|
* will be freed back to the system automatically.
|
|
|
|
*
|
|
|
|
* For example, suppose a driver has a MSI-X table with 6 messages and
|
|
|
|
* asks for 6 messages, but pci_alloc_msix() only returns a count of
|
|
|
|
* 3. Call the three vectors allocated by pci_alloc_msix() A, B, and
|
|
|
|
* C. After the call to pci_alloc_msix(), the device will be setup to
|
|
|
|
* have an MSI-X table of ABC--- (where - means no vector assigned).
|
|
|
|
* If the driver ten passes a vector array of { 1, 0, 1, 2, 0, 2 },
|
|
|
|
* then the MSI-X table will look like A-AB-B, and the 'C' vector will
|
|
|
|
* be freed back to the system. This device will also have valid
|
|
|
|
* SYS_RES_IRQ rids of 1, 3, 4, and 6.
|
|
|
|
*
|
|
|
|
* In any case, the SYS_RES_IRQ rid X will always map to the message
|
|
|
|
* at MSI-X table index X - 1 and will only be valid if a vector is
|
|
|
|
* assigned to that table entry.
|
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
|
|
|
pci_remap_msix_method(device_t dev, device_t child, int count,
|
|
|
|
const u_int *vectors)
|
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
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
2007-05-02 17:50:36 +00:00
|
|
|
struct pcicfg_msix *msix = &dinfo->cfg.msix;
|
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
|
|
|
struct resource_list_entry *rle;
|
2007-05-02 17:50:36 +00:00
|
|
|
int i, irq, j, *used;
|
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
|
|
|
/*
|
|
|
|
* Have to have at least one message in the table but the
|
|
|
|
* table can't be bigger than the actual MSI-X table in the
|
|
|
|
* device.
|
|
|
|
*/
|
|
|
|
if (count == 0 || count > msix->msix_msgnum)
|
|
|
|
return (EINVAL);
|
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
|
|
|
/* Sanity check the vectors. */
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
if (vectors[i] > msix->msix_alloc)
|
|
|
|
return (EINVAL);
|
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
|
|
|
/*
|
|
|
|
* Make sure there aren't any holes in the vectors to be used.
|
|
|
|
* It's a big pain to support it, and it doesn't really make
|
|
|
|
* sense anyway. Also, at least one vector must be used.
|
|
|
|
*/
|
|
|
|
used = malloc(sizeof(int) * msix->msix_alloc, M_DEVBUF, M_WAITOK |
|
|
|
|
M_ZERO);
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
if (vectors[i] != 0)
|
|
|
|
used[vectors[i] - 1] = 1;
|
|
|
|
for (i = 0; i < msix->msix_alloc - 1; i++)
|
|
|
|
if (used[i] == 0 && used[i + 1] == 1) {
|
|
|
|
free(used, M_DEVBUF);
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
|
|
|
if (used[0] != 1) {
|
|
|
|
free(used, M_DEVBUF);
|
|
|
|
return (EINVAL);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/* Make sure none of the resources are allocated. */
|
2007-05-02 17:50:36 +00:00
|
|
|
for (i = 0; i < msix->msix_table_len; i++) {
|
|
|
|
if (msix->msix_table[i].mte_vector == 0)
|
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
|
|
|
continue;
|
2007-05-02 17:50:36 +00:00
|
|
|
if (msix->msix_table[i].mte_handlers > 0)
|
|
|
|
return (EBUSY);
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ, i + 1);
|
|
|
|
KASSERT(rle != NULL, ("missing resource"));
|
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
|
|
|
if (rle->res != NULL)
|
|
|
|
return (EBUSY);
|
|
|
|
}
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
/* Free the existing resource list entries. */
|
|
|
|
for (i = 0; i < msix->msix_table_len; i++) {
|
|
|
|
if (msix->msix_table[i].mte_vector == 0)
|
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
|
|
|
continue;
|
2007-05-02 17:50:36 +00:00
|
|
|
resource_list_delete(&dinfo->resources, SYS_RES_IRQ, i + 1);
|
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
|
|
|
/*
|
|
|
|
* Build the new virtual table keeping track of which vectors are
|
|
|
|
* used.
|
|
|
|
*/
|
|
|
|
free(msix->msix_table, M_DEVBUF);
|
|
|
|
msix->msix_table = malloc(sizeof(struct msix_table_entry) * count,
|
|
|
|
M_DEVBUF, M_WAITOK | M_ZERO);
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
msix->msix_table[i].mte_vector = vectors[i];
|
|
|
|
msix->msix_table_len = count;
|
|
|
|
|
|
|
|
/* Free any unused IRQs and resize the vectors array if necessary. */
|
|
|
|
j = msix->msix_alloc - 1;
|
|
|
|
if (used[j] == 0) {
|
|
|
|
struct msix_vector *vec;
|
|
|
|
|
|
|
|
while (used[j] == 0) {
|
|
|
|
PCIB_RELEASE_MSIX(device_get_parent(dev), child,
|
|
|
|
msix->msix_vectors[j].mv_irq);
|
|
|
|
j--;
|
|
|
|
}
|
|
|
|
vec = malloc(sizeof(struct msix_vector) * (j + 1), M_DEVBUF,
|
|
|
|
M_WAITOK);
|
|
|
|
bcopy(msix->msix_vectors, vec, sizeof(struct msix_vector) *
|
|
|
|
(j + 1));
|
|
|
|
free(msix->msix_vectors, M_DEVBUF);
|
|
|
|
msix->msix_vectors = vec;
|
|
|
|
msix->msix_alloc = j + 1;
|
|
|
|
}
|
|
|
|
free(used, M_DEVBUF);
|
|
|
|
|
|
|
|
/* Map the IRQs onto the rids. */
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
if (vectors[i] == 0)
|
|
|
|
continue;
|
|
|
|
irq = msix->msix_vectors[vectors[i]].mv_irq;
|
|
|
|
resource_list_add(&dinfo->resources, SYS_RES_IRQ, i + 1, irq,
|
|
|
|
irq, 1);
|
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
|
|
|
|
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
|
|
|
if (bootverbose) {
|
2007-05-02 17:50:36 +00:00
|
|
|
device_printf(child, "Remapped MSI-X IRQs as: ");
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
if (i != 0)
|
|
|
|
printf(", ");
|
|
|
|
if (vectors[i] == 0)
|
|
|
|
printf("---");
|
|
|
|
else
|
|
|
|
printf("%d",
|
|
|
|
msix->msix_vectors[vectors[i]].mv_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
|
|
|
printf("\n");
|
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
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
static int
|
|
|
|
pci_release_msix(device_t dev, device_t child)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msix *msix = &dinfo->cfg.msix;
|
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
|
|
|
struct resource_list_entry *rle;
|
2007-05-02 17:50:36 +00:00
|
|
|
int i;
|
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
|
|
|
|
|
|
|
/* Do we have any messages to release? */
|
2007-05-02 16:21:18 +00:00
|
|
|
if (msix->msix_alloc == 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
|
|
|
return (ENODEV);
|
|
|
|
|
|
|
|
/* Make sure none of the resources are allocated. */
|
2007-05-02 17:50:36 +00:00
|
|
|
for (i = 0; i < msix->msix_table_len; i++) {
|
|
|
|
if (msix->msix_table[i].mte_vector == 0)
|
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
|
|
|
continue;
|
2007-05-02 17:50:36 +00:00
|
|
|
if (msix->msix_table[i].mte_handlers > 0)
|
|
|
|
return (EBUSY);
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ, i + 1);
|
|
|
|
KASSERT(rle != NULL, ("missing resource"));
|
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
|
|
|
if (rle->res != NULL)
|
|
|
|
return (EBUSY);
|
|
|
|
}
|
|
|
|
|
2007-05-02 16:21:18 +00:00
|
|
|
/* Update control register to disable MSI-X. */
|
|
|
|
msix->msix_ctrl &= ~PCIM_MSIXCTRL_MSIX_ENABLE;
|
|
|
|
pci_write_config(child, msix->msix_location + PCIR_MSIX_CTRL,
|
|
|
|
msix->msix_ctrl, 2);
|
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
|
|
|
/* Free the resource list entries. */
|
|
|
|
for (i = 0; i < msix->msix_table_len; i++) {
|
|
|
|
if (msix->msix_table[i].mte_vector == 0)
|
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
|
|
|
continue;
|
2007-05-02 17:50:36 +00:00
|
|
|
resource_list_delete(&dinfo->resources, SYS_RES_IRQ, i + 1);
|
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
|
|
|
free(msix->msix_table, M_DEVBUF);
|
|
|
|
msix->msix_table_len = 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
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
/* Release the IRQs. */
|
|
|
|
for (i = 0; i < msix->msix_alloc; i++)
|
|
|
|
PCIB_RELEASE_MSIX(device_get_parent(dev), child,
|
|
|
|
msix->msix_vectors[i].mv_irq);
|
|
|
|
free(msix->msix_vectors, M_DEVBUF);
|
2007-05-02 16:21:18 +00:00
|
|
|
msix->msix_alloc = 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
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Return the max supported MSI-X messages this device supports.
|
|
|
|
* Basically, assuming the MD code can alloc messages, this function
|
|
|
|
* should return the maximum value that pci_alloc_msix() can return.
|
|
|
|
* Thus, it is subject to the tunables, etc.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
pci_msix_count_method(device_t dev, device_t child)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msix *msix = &dinfo->cfg.msix;
|
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 16:21:18 +00:00
|
|
|
if (pci_do_msix && msix->msix_location != 0)
|
|
|
|
return (msix->msix_msgnum);
|
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
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2008-07-23 09:44:36 +00:00
|
|
|
/*
|
|
|
|
* HyperTransport MSI mapping control
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
pci_ht_map_msi(device_t dev, uint64_t addr)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
|
|
|
struct pcicfg_ht *ht = &dinfo->cfg.ht;
|
|
|
|
|
|
|
|
if (!ht->ht_msimap)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (addr && !(ht->ht_msictrl & PCIM_HTCMD_MSI_ENABLE) &&
|
|
|
|
ht->ht_msiaddr >> 20 == addr >> 20) {
|
|
|
|
/* Enable MSI -> HT mapping. */
|
|
|
|
ht->ht_msictrl |= PCIM_HTCMD_MSI_ENABLE;
|
|
|
|
pci_write_config(dev, ht->ht_msimap + PCIR_HT_COMMAND,
|
|
|
|
ht->ht_msictrl, 2);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!addr && ht->ht_msictrl & PCIM_HTCMD_MSI_ENABLE) {
|
|
|
|
/* Disable MSI -> HT mapping. */
|
|
|
|
ht->ht_msictrl &= ~PCIM_HTCMD_MSI_ENABLE;
|
|
|
|
pci_write_config(dev, ht->ht_msimap + PCIR_HT_COMMAND,
|
|
|
|
ht->ht_msictrl, 2);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-02-05 17:18:48 +00:00
|
|
|
int
|
|
|
|
pci_get_max_read_req(device_t dev)
|
|
|
|
{
|
|
|
|
int cap;
|
|
|
|
uint16_t val;
|
|
|
|
|
2011-03-22 12:05:49 +00:00
|
|
|
if (pci_find_cap(dev, PCIY_EXPRESS, &cap) != 0)
|
2010-02-05 17:18:48 +00:00
|
|
|
return (0);
|
|
|
|
val = pci_read_config(dev, cap + PCIR_EXPRESS_DEVICE_CTL, 2);
|
|
|
|
val &= PCIM_EXP_CTL_MAX_READ_REQUEST;
|
|
|
|
val >>= 12;
|
|
|
|
return (1 << (val + 7));
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
pci_set_max_read_req(device_t dev, int size)
|
|
|
|
{
|
|
|
|
int cap;
|
|
|
|
uint16_t val;
|
|
|
|
|
2011-03-22 12:05:49 +00:00
|
|
|
if (pci_find_cap(dev, PCIY_EXPRESS, &cap) != 0)
|
2010-02-05 17:18:48 +00:00
|
|
|
return (0);
|
|
|
|
if (size < 128)
|
|
|
|
size = 128;
|
|
|
|
if (size > 4096)
|
|
|
|
size = 4096;
|
|
|
|
size = (1 << (fls(size) - 1));
|
|
|
|
val = pci_read_config(dev, cap + PCIR_EXPRESS_DEVICE_CTL, 2);
|
|
|
|
val &= ~PCIM_EXP_CTL_MAX_READ_REQUEST;
|
|
|
|
val |= (fls(size) - 8) << 12;
|
|
|
|
pci_write_config(dev, cap + PCIR_EXPRESS_DEVICE_CTL, val, 2);
|
|
|
|
return (size);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Support for MSI message signalled interrupts.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
pci_enable_msi(device_t dev, uint64_t address, uint16_t data)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msi *msi = &dinfo->cfg.msi;
|
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
|
|
|
|
|
|
|
/* Write data and address values. */
|
2007-05-02 16:21:18 +00:00
|
|
|
pci_write_config(dev, msi->msi_location + PCIR_MSI_ADDR,
|
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
|
|
|
address & 0xffffffff, 4);
|
2007-05-02 16:21:18 +00:00
|
|
|
if (msi->msi_ctrl & PCIM_MSICTRL_64BIT) {
|
|
|
|
pci_write_config(dev, msi->msi_location + PCIR_MSI_ADDR_HIGH,
|
|
|
|
address >> 32, 4);
|
|
|
|
pci_write_config(dev, msi->msi_location + PCIR_MSI_DATA_64BIT,
|
|
|
|
data, 2);
|
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
|
|
|
} else
|
2007-05-02 16:21:18 +00:00
|
|
|
pci_write_config(dev, msi->msi_location + PCIR_MSI_DATA, data,
|
|
|
|
2);
|
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
|
|
|
|
|
|
|
/* Enable MSI in the control register. */
|
2007-05-02 16:21:18 +00:00
|
|
|
msi->msi_ctrl |= PCIM_MSICTRL_MSI_ENABLE;
|
|
|
|
pci_write_config(dev, msi->msi_location + PCIR_MSI_CTRL, msi->msi_ctrl,
|
|
|
|
2);
|
2008-07-23 09:44:36 +00:00
|
|
|
|
|
|
|
/* Enable MSI -> HT mapping. */
|
|
|
|
pci_ht_map_msi(dev, address);
|
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
|
|
|
void
|
|
|
|
pci_disable_msi(device_t dev)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
|
|
|
struct pcicfg_msi *msi = &dinfo->cfg.msi;
|
|
|
|
|
2008-07-23 09:44:36 +00:00
|
|
|
/* Disable MSI -> HT mapping. */
|
|
|
|
pci_ht_map_msi(dev, 0);
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
/* Disable MSI in the control register. */
|
|
|
|
msi->msi_ctrl &= ~PCIM_MSICTRL_MSI_ENABLE;
|
|
|
|
pci_write_config(dev, msi->msi_location + PCIR_MSI_CTRL, msi->msi_ctrl,
|
|
|
|
2);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Restore MSI registers during resume. If MSI is enabled then
|
|
|
|
* restore the data and address registers in addition to the control
|
|
|
|
* register.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
pci_resume_msi(device_t dev)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msi *msi = &dinfo->cfg.msi;
|
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
|
|
|
uint64_t address;
|
|
|
|
uint16_t data;
|
|
|
|
|
2007-05-02 16:21:18 +00:00
|
|
|
if (msi->msi_ctrl & PCIM_MSICTRL_MSI_ENABLE) {
|
|
|
|
address = msi->msi_addr;
|
|
|
|
data = msi->msi_data;
|
|
|
|
pci_write_config(dev, msi->msi_location + PCIR_MSI_ADDR,
|
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
|
|
|
address & 0xffffffff, 4);
|
2007-05-02 16:21:18 +00:00
|
|
|
if (msi->msi_ctrl & PCIM_MSICTRL_64BIT) {
|
|
|
|
pci_write_config(dev, msi->msi_location +
|
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
|
|
|
PCIR_MSI_ADDR_HIGH, address >> 32, 4);
|
2007-05-02 16:21:18 +00:00
|
|
|
pci_write_config(dev, msi->msi_location +
|
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
|
|
|
PCIR_MSI_DATA_64BIT, data, 2);
|
|
|
|
} else
|
2007-05-02 16:21:18 +00:00
|
|
|
pci_write_config(dev, msi->msi_location + PCIR_MSI_DATA,
|
|
|
|
data, 2);
|
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 16:21:18 +00:00
|
|
|
pci_write_config(dev, msi->msi_location + PCIR_MSI_CTRL, msi->msi_ctrl,
|
|
|
|
2);
|
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
|
|
|
}
|
|
|
|
|
2010-06-14 07:10:37 +00:00
|
|
|
static int
|
|
|
|
pci_remap_intr_method(device_t bus, device_t dev, u_int irq)
|
2007-05-02 17:50:36 +00:00
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
struct resource_list_entry *rle;
|
|
|
|
struct msix_table_entry *mte;
|
|
|
|
struct msix_vector *mv;
|
|
|
|
uint64_t addr;
|
|
|
|
uint32_t data;
|
|
|
|
int error, i, j;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Handle MSI first. We try to find this IRQ among our list
|
|
|
|
* of MSI IRQs. If we find it, we request updated address and
|
|
|
|
* data registers and apply the results.
|
|
|
|
*/
|
|
|
|
if (cfg->msi.msi_alloc > 0) {
|
|
|
|
|
|
|
|
/* If we don't have any active handlers, nothing to do. */
|
|
|
|
if (cfg->msi.msi_handlers == 0)
|
|
|
|
return (0);
|
|
|
|
for (i = 0; i < cfg->msi.msi_alloc; i++) {
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ,
|
|
|
|
i + 1);
|
|
|
|
if (rle->start == irq) {
|
|
|
|
error = PCIB_MAP_MSI(device_get_parent(bus),
|
|
|
|
dev, irq, &addr, &data);
|
|
|
|
if (error)
|
|
|
|
return (error);
|
|
|
|
pci_disable_msi(dev);
|
|
|
|
dinfo->cfg.msi.msi_addr = addr;
|
|
|
|
dinfo->cfg.msi.msi_data = data;
|
|
|
|
pci_enable_msi(dev, addr, data);
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return (ENOENT);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For MSI-X, we check to see if we have this IRQ. If we do,
|
|
|
|
* we request the updated mapping info. If that works, we go
|
|
|
|
* through all the slots that use this IRQ and update them.
|
|
|
|
*/
|
|
|
|
if (cfg->msix.msix_alloc > 0) {
|
|
|
|
for (i = 0; i < cfg->msix.msix_alloc; i++) {
|
|
|
|
mv = &cfg->msix.msix_vectors[i];
|
|
|
|
if (mv->mv_irq == irq) {
|
|
|
|
error = PCIB_MAP_MSI(device_get_parent(bus),
|
|
|
|
dev, irq, &addr, &data);
|
|
|
|
if (error)
|
|
|
|
return (error);
|
|
|
|
mv->mv_address = addr;
|
|
|
|
mv->mv_data = data;
|
|
|
|
for (j = 0; j < cfg->msix.msix_table_len; j++) {
|
|
|
|
mte = &cfg->msix.msix_table[j];
|
|
|
|
if (mte->mte_vector != i + 1)
|
|
|
|
continue;
|
|
|
|
if (mte->mte_handlers == 0)
|
|
|
|
continue;
|
|
|
|
pci_mask_msix(dev, j);
|
|
|
|
pci_enable_msix(dev, j, addr, data);
|
|
|
|
pci_unmask_msix(dev, j);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return (ENOENT);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (ENOENT);
|
|
|
|
}
|
|
|
|
|
2006-12-14 19:57:06 +00:00
|
|
|
/*
|
|
|
|
* Returns true if the specified device is blacklisted because MSI
|
|
|
|
* doesn't work.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
pci_msi_device_blacklisted(device_t dev)
|
|
|
|
{
|
|
|
|
struct pci_quirk *q;
|
|
|
|
|
|
|
|
if (!pci_honor_msi_blacklist)
|
|
|
|
return (0);
|
|
|
|
|
|
|
|
for (q = &pci_quirks[0]; q->devid; q++) {
|
|
|
|
if (q->devid == pci_get_devid(dev) &&
|
|
|
|
q->type == PCI_QUIRK_DISABLE_MSI)
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2010-10-22 11:42:02 +00:00
|
|
|
/*
|
|
|
|
* Returns true if a specified chipset supports MSI when it is
|
|
|
|
* emulated hardware in a virtual machine.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pci_msi_vm_chipset(device_t dev)
|
|
|
|
{
|
|
|
|
struct pci_quirk *q;
|
|
|
|
|
|
|
|
for (q = &pci_quirks[0]; q->devid; q++) {
|
|
|
|
if (q->devid == pci_get_devid(dev) &&
|
|
|
|
q->type == PCI_QUIRK_ENABLE_MSI_VM)
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2006-12-14 19:57:06 +00:00
|
|
|
/*
|
|
|
|
* Determine if MSI is blacklisted globally on this sytem. Currently,
|
|
|
|
* we just check for blacklisted chipsets as represented by the
|
|
|
|
* host-PCI bridge at device 0:0:0. In the future, it may become
|
|
|
|
* necessary to check other system attributes, such as the kenv values
|
|
|
|
* that give the motherboard manufacturer and model number.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pci_msi_blacklisted(void)
|
|
|
|
{
|
|
|
|
device_t dev;
|
|
|
|
|
|
|
|
if (!pci_honor_msi_blacklist)
|
|
|
|
return (0);
|
|
|
|
|
2007-02-14 22:36:27 +00:00
|
|
|
/* Blacklist all non-PCI-express and non-PCI-X chipsets. */
|
2010-10-22 11:42:02 +00:00
|
|
|
if (!(pcie_chipset || pcix_chipset)) {
|
|
|
|
if (vm_guest != VM_GUEST_NO) {
|
|
|
|
dev = pci_find_bsf(0, 0, 0);
|
|
|
|
if (dev != NULL)
|
|
|
|
return (pci_msi_vm_chipset(dev) == 0);
|
|
|
|
}
|
2007-02-14 22:36:27 +00:00
|
|
|
return (1);
|
2010-10-22 11:42:02 +00:00
|
|
|
}
|
2007-02-14 22:36:27 +00:00
|
|
|
|
2006-12-14 19:57:06 +00:00
|
|
|
dev = pci_find_bsf(0, 0, 0);
|
|
|
|
if (dev != NULL)
|
|
|
|
return (pci_msi_device_blacklisted(dev));
|
|
|
|
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
|
|
|
/*
|
|
|
|
* Attempt to allocate *count MSI messages. The actual number allocated is
|
|
|
|
* returned in *count. After this function returns, each message will be
|
|
|
|
* available to the driver as SYS_RES_IRQ resources starting at a rid 1.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
pci_alloc_msi_method(device_t dev, device_t child, int *count)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
struct resource_list_entry *rle;
|
|
|
|
int actual, error, i, irqs[32];
|
|
|
|
uint16_t ctrl;
|
|
|
|
|
|
|
|
/* Don't let count == 0 get us into trouble. */
|
|
|
|
if (*count == 0)
|
|
|
|
return (EINVAL);
|
|
|
|
|
|
|
|
/* If rid 0 is allocated, then fail. */
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ, 0);
|
|
|
|
if (rle != NULL && rle->res != NULL)
|
|
|
|
return (ENXIO);
|
|
|
|
|
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
|
|
|
/* Already have allocated messages? */
|
|
|
|
if (cfg->msi.msi_alloc != 0 || cfg->msix.msix_alloc != 0)
|
|
|
|
return (ENXIO);
|
|
|
|
|
2006-12-14 19:57:06 +00:00
|
|
|
/* If MSI is blacklisted for this system, fail. */
|
|
|
|
if (pci_msi_blacklisted())
|
|
|
|
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
|
|
|
/* MSI capability present? */
|
|
|
|
if (cfg->msi.msi_location == 0 || !pci_do_msi)
|
|
|
|
return (ENODEV);
|
|
|
|
|
2006-12-12 19:29:01 +00:00
|
|
|
if (bootverbose)
|
|
|
|
device_printf(child,
|
|
|
|
"attempting to allocate %d MSI vectors (%d supported)\n",
|
|
|
|
*count, cfg->msi.msi_msgnum);
|
|
|
|
|
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
|
|
|
/* Don't ask for more than the device supports. */
|
|
|
|
actual = min(*count, cfg->msi.msi_msgnum);
|
|
|
|
|
|
|
|
/* Don't ask for more than 32 messages. */
|
|
|
|
actual = min(actual, 32);
|
|
|
|
|
|
|
|
/* MSI requires power of 2 number of messages. */
|
|
|
|
if (!powerof2(actual))
|
|
|
|
return (EINVAL);
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
/* Try to allocate N messages. */
|
|
|
|
error = PCIB_ALLOC_MSI(device_get_parent(dev), child, actual,
|
2011-04-27 20:08:44 +00:00
|
|
|
actual, irqs);
|
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
|
|
|
if (error == 0)
|
|
|
|
break;
|
|
|
|
if (actual == 1)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
/* Try N / 2. */
|
|
|
|
actual >>= 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We now have N actual messages mapped onto SYS_RES_IRQ
|
|
|
|
* resources in the irqs[] array, so add new resources
|
|
|
|
* starting at rid 1.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < actual; i++)
|
|
|
|
resource_list_add(&dinfo->resources, SYS_RES_IRQ, i + 1,
|
|
|
|
irqs[i], irqs[i], 1);
|
|
|
|
|
2006-12-12 19:29:01 +00:00
|
|
|
if (bootverbose) {
|
|
|
|
if (actual == 1)
|
|
|
|
device_printf(child, "using IRQ %d for MSI\n", irqs[0]);
|
|
|
|
else {
|
|
|
|
int run;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Be fancy and try to print contiguous runs
|
|
|
|
* of IRQ values as ranges. 'run' is true if
|
|
|
|
* we are in a range.
|
|
|
|
*/
|
|
|
|
device_printf(child, "using IRQs %d", irqs[0]);
|
|
|
|
run = 0;
|
|
|
|
for (i = 1; i < actual; i++) {
|
|
|
|
|
|
|
|
/* Still in a run? */
|
|
|
|
if (irqs[i] == irqs[i - 1] + 1) {
|
|
|
|
run = 1;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Finish previous range. */
|
|
|
|
if (run) {
|
|
|
|
printf("-%d", irqs[i - 1]);
|
|
|
|
run = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Start new range. */
|
|
|
|
printf(",%d", irqs[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Unfinished range? */
|
|
|
|
if (run)
|
2007-05-07 18:29:37 +00:00
|
|
|
printf("-%d", irqs[actual - 1]);
|
2006-12-12 19:29:01 +00:00
|
|
|
printf(" for MSI\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-05-02 16:21:18 +00:00
|
|
|
/* Update control register with actual count. */
|
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
|
|
|
ctrl = cfg->msi.msi_ctrl;
|
|
|
|
ctrl &= ~PCIM_MSICTRL_MME_MASK;
|
|
|
|
ctrl |= (ffs(actual) - 1) << 4;
|
|
|
|
cfg->msi.msi_ctrl = ctrl;
|
|
|
|
pci_write_config(child, cfg->msi.msi_location + PCIR_MSI_CTRL, ctrl, 2);
|
|
|
|
|
|
|
|
/* Update counts of alloc'd messages. */
|
|
|
|
cfg->msi.msi_alloc = actual;
|
2007-05-02 17:50:36 +00:00
|
|
|
cfg->msi.msi_handlers = 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
|
|
|
*count = actual;
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Release the MSI messages associated with this device. */
|
|
|
|
int
|
|
|
|
pci_release_msi_method(device_t dev, device_t child)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msi *msi = &dinfo->cfg.msi;
|
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
|
|
|
struct resource_list_entry *rle;
|
|
|
|
int error, i, irqs[32];
|
|
|
|
|
|
|
|
/* Try MSI-X first. */
|
|
|
|
error = pci_release_msix(dev, child);
|
|
|
|
if (error != ENODEV)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
/* Do we have any messages to release? */
|
2007-05-02 16:21:18 +00:00
|
|
|
if (msi->msi_alloc == 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
|
|
|
return (ENODEV);
|
2007-05-02 16:21:18 +00:00
|
|
|
KASSERT(msi->msi_alloc <= 32, ("more than 32 alloc'd messages"));
|
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
|
|
|
|
|
|
|
/* Make sure none of the resources are allocated. */
|
2007-05-02 17:50:36 +00:00
|
|
|
if (msi->msi_handlers > 0)
|
|
|
|
return (EBUSY);
|
2007-05-02 16:21:18 +00:00
|
|
|
for (i = 0; i < msi->msi_alloc; i++) {
|
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
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ, i + 1);
|
|
|
|
KASSERT(rle != NULL, ("missing MSI resource"));
|
|
|
|
if (rle->res != NULL)
|
|
|
|
return (EBUSY);
|
|
|
|
irqs[i] = rle->start;
|
|
|
|
}
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
/* Update control register with 0 count. */
|
|
|
|
KASSERT(!(msi->msi_ctrl & PCIM_MSICTRL_MSI_ENABLE),
|
|
|
|
("%s: MSI still enabled", __func__));
|
|
|
|
msi->msi_ctrl &= ~PCIM_MSICTRL_MME_MASK;
|
2007-05-02 16:21:18 +00:00
|
|
|
pci_write_config(child, msi->msi_location + PCIR_MSI_CTRL,
|
|
|
|
msi->msi_ctrl, 2);
|
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
|
|
|
|
|
|
|
/* Release the messages. */
|
2007-05-02 16:21:18 +00:00
|
|
|
PCIB_RELEASE_MSI(device_get_parent(dev), child, msi->msi_alloc, irqs);
|
|
|
|
for (i = 0; i < msi->msi_alloc; i++)
|
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
|
|
|
resource_list_delete(&dinfo->resources, SYS_RES_IRQ, i + 1);
|
|
|
|
|
|
|
|
/* Update alloc count. */
|
2007-05-02 16:21:18 +00:00
|
|
|
msi->msi_alloc = 0;
|
2007-05-02 17:50:36 +00:00
|
|
|
msi->msi_addr = 0;
|
|
|
|
msi->msi_data = 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
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
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
|
|
|
* Return the max supported MSI messages this device supports.
|
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
|
|
|
* Basically, assuming the MD code can alloc messages, this function
|
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
|
|
|
* should return the maximum value that pci_alloc_msi() can return.
|
|
|
|
* Thus, it is subject to the tunables, etc.
|
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
|
|
|
|
pci_msi_count_method(device_t dev, device_t child)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
2007-05-02 16:21:18 +00:00
|
|
|
struct pcicfg_msi *msi = &dinfo->cfg.msi;
|
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 16:21:18 +00:00
|
|
|
if (pci_do_msi && msi->msi_location != 0)
|
|
|
|
return (msi->msi_msgnum);
|
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
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
/* free pcicfgregs structure and all depending data structures */
|
1995-03-21 23:01:06 +00:00
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
int
|
1998-09-15 08:21:13 +00:00
|
|
|
pci_freecfg(struct pci_devinfo *dinfo)
|
1995-03-21 23:01:06 +00:00
|
|
|
{
|
1998-09-15 08:21:13 +00:00
|
|
|
struct devlist *devlist_head;
|
2011-03-31 13:22:12 +00:00
|
|
|
struct pci_map *pm, *next;
|
2006-10-09 16:15:56 +00:00
|
|
|
int i;
|
1998-09-15 08:21:13 +00:00
|
|
|
|
|
|
|
devlist_head = &pci_devq;
|
|
|
|
|
2006-10-09 16:15:56 +00:00
|
|
|
if (dinfo->cfg.vpd.vpd_reg) {
|
|
|
|
free(dinfo->cfg.vpd.vpd_ident, M_DEVBUF);
|
|
|
|
for (i = 0; i < dinfo->cfg.vpd.vpd_rocnt; i++)
|
|
|
|
free(dinfo->cfg.vpd.vpd_ros[i].value, M_DEVBUF);
|
|
|
|
free(dinfo->cfg.vpd.vpd_ros, M_DEVBUF);
|
|
|
|
for (i = 0; i < dinfo->cfg.vpd.vpd_wcnt; i++)
|
|
|
|
free(dinfo->cfg.vpd.vpd_w[i].value, M_DEVBUF);
|
|
|
|
free(dinfo->cfg.vpd.vpd_w, M_DEVBUF);
|
|
|
|
}
|
2011-03-31 13:22:12 +00:00
|
|
|
STAILQ_FOREACH_SAFE(pm, &dinfo->cfg.maps, pm_link, next) {
|
|
|
|
free(pm, M_DEVBUF);
|
|
|
|
}
|
2000-05-26 02:09:24 +00:00
|
|
|
STAILQ_REMOVE(devlist_head, dinfo, pci_devinfo, pci_links);
|
1998-09-15 08:21:13 +00:00
|
|
|
free(dinfo, M_DEVBUF);
|
|
|
|
|
|
|
|
/* increment the generation count */
|
|
|
|
pci_generation++;
|
|
|
|
|
|
|
|
/* we're losing one device */
|
|
|
|
pci_numdevs--;
|
Completely replace the PCI bus driver code to make it better reflect
reality. There will be a new call interface, but for now the file
pci_compat.c (which is to be deleted, after all drivers are converted)
provides an emulation of the old PCI bus driver functions. The only
change that might be visible to drivers is, that the type pcici_t
(which had been meant to be just a handle, whose exact definition
should not be relied on), has been converted into a pcicfgregs* .
The Tekram AMD SCSI driver bogusly relied on the definition of pcici_t
and has been converted to just call the PCI drivers functions to access
configuration space register, instead of inventing its own ...
This code is by no means complete, but assumed to be fully operational,
and brings the official code base more in line with my development code.
A new generic device descriptor data type has to be agreed on. The PCI
code will then use that data type to provide new functionality:
1) userconfig support
2) "wired" PCI devices
3) conflicts checking against ISA/EISA
4) maps will depend on the command register enable bits
5) PCI to Anything bridges can be defined as devices,
and are probed like any "standard" PCI device.
The following features are currently missing, but will be added back,
soon:
1) unknown device probe message
2) suppression of "mirrored" devices caused by ancient, broken chip-sets
This code relies on generic shared interrupt support just commited to
kern_intr.c (plus the modifications of isa.c and isa_device.h).
1997-05-26 15:08:43 +00:00
|
|
|
return (0);
|
1995-03-21 23:01:06 +00:00
|
|
|
}
|
|
|
|
|
1996-10-22 20:20:14 +00:00
|
|
|
/*
|
2000-12-13 01:25:11 +00:00
|
|
|
* PCI power manangement
|
1996-10-22 20:20:14 +00:00
|
|
|
*/
|
2002-02-27 05:09:14 +00:00
|
|
|
int
|
2001-02-27 23:13:20 +00:00
|
|
|
pci_set_powerstate_method(device_t dev, device_t child, int state)
|
1996-10-22 20:20:14 +00:00
|
|
|
{
|
2001-02-27 23:13:20 +00:00
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
2000-12-13 01:25:11 +00:00
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
2003-08-22 03:11:53 +00:00
|
|
|
uint16_t status;
|
2004-12-31 20:43:46 +00:00
|
|
|
int result, oldstate, highest, delay;
|
|
|
|
|
|
|
|
if (cfg->pp.pp_cap == 0)
|
|
|
|
return (EOPNOTSUPP);
|
2000-12-13 01:25:11 +00:00
|
|
|
|
2004-04-11 07:02:49 +00:00
|
|
|
/*
|
2004-12-31 20:43:46 +00:00
|
|
|
* Optimize a no state change request away. While it would be OK to
|
|
|
|
* write to the hardware in theory, some devices have shown odd
|
|
|
|
* behavior when going from D3 -> D3.
|
2004-04-11 07:02:49 +00:00
|
|
|
*/
|
2004-12-31 20:43:46 +00:00
|
|
|
oldstate = pci_get_powerstate(child);
|
|
|
|
if (oldstate == state)
|
2004-04-11 07:02:49 +00:00
|
|
|
return (0);
|
|
|
|
|
2004-12-31 20:43:46 +00:00
|
|
|
/*
|
|
|
|
* The PCI power management specification states that after a state
|
|
|
|
* transition between PCI power states, system software must
|
|
|
|
* guarantee a minimal delay before the function accesses the device.
|
|
|
|
* Compute the worst case delay that we need to guarantee before we
|
|
|
|
* access the device. Many devices will be responsive much more
|
|
|
|
* quickly than this delay, but there are some that don't respond
|
|
|
|
* instantly to state changes. Transitions to/from D3 state require
|
|
|
|
* 10ms, while D2 requires 200us, and D0/1 require none. The delay
|
|
|
|
* is done below with DELAY rather than a sleeper function because
|
|
|
|
* this function can be called from contexts where we cannot sleep.
|
|
|
|
*/
|
|
|
|
highest = (oldstate > state) ? oldstate : state;
|
2004-12-31 23:59:24 +00:00
|
|
|
if (highest == PCI_POWERSTATE_D3)
|
2004-12-31 20:43:46 +00:00
|
|
|
delay = 10000;
|
2004-12-31 23:59:24 +00:00
|
|
|
else if (highest == PCI_POWERSTATE_D2)
|
2004-12-31 20:43:46 +00:00
|
|
|
delay = 200;
|
|
|
|
else
|
|
|
|
delay = 0;
|
|
|
|
status = PCI_READ_CONFIG(dev, child, cfg->pp.pp_status, 2)
|
|
|
|
& ~PCIM_PSTAT_DMASK;
|
|
|
|
result = 0;
|
|
|
|
switch (state) {
|
|
|
|
case PCI_POWERSTATE_D0:
|
|
|
|
status |= PCIM_PSTAT_D0;
|
|
|
|
break;
|
|
|
|
case PCI_POWERSTATE_D1:
|
|
|
|
if ((cfg->pp.pp_cap & PCIM_PCAP_D1SUPP) == 0)
|
|
|
|
return (EOPNOTSUPP);
|
|
|
|
status |= PCIM_PSTAT_D1;
|
|
|
|
break;
|
|
|
|
case PCI_POWERSTATE_D2:
|
|
|
|
if ((cfg->pp.pp_cap & PCIM_PCAP_D2SUPP) == 0)
|
|
|
|
return (EOPNOTSUPP);
|
|
|
|
status |= PCIM_PSTAT_D2;
|
|
|
|
break;
|
|
|
|
case PCI_POWERSTATE_D3:
|
|
|
|
status |= PCIM_PSTAT_D3;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return (EINVAL);
|
1999-05-31 22:13:37 +00:00
|
|
|
}
|
2005-04-01 16:22:50 +00:00
|
|
|
|
|
|
|
if (bootverbose)
|
2009-06-01 20:30:00 +00:00
|
|
|
pci_printf(cfg, "Transition from D%d to D%d\n", oldstate,
|
|
|
|
state);
|
2005-04-01 16:22:50 +00:00
|
|
|
|
2004-12-31 20:43:46 +00:00
|
|
|
PCI_WRITE_CONFIG(dev, child, cfg->pp.pp_status, status, 2);
|
|
|
|
if (delay)
|
|
|
|
DELAY(delay);
|
|
|
|
return (0);
|
1999-05-31 22:13:37 +00:00
|
|
|
}
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
int
|
2001-02-27 23:13:20 +00:00
|
|
|
pci_get_powerstate_method(device_t dev, device_t child)
|
1996-10-22 20:20:14 +00:00
|
|
|
{
|
2001-02-27 23:13:20 +00:00
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
2000-12-13 01:25:11 +00:00
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
2003-08-22 03:11:53 +00:00
|
|
|
uint16_t status;
|
2000-12-13 01:25:11 +00:00
|
|
|
int result;
|
|
|
|
|
2003-09-14 19:30:00 +00:00
|
|
|
if (cfg->pp.pp_cap != 0) {
|
|
|
|
status = PCI_READ_CONFIG(dev, child, cfg->pp.pp_status, 2);
|
2000-12-13 01:25:11 +00:00
|
|
|
switch (status & PCIM_PSTAT_DMASK) {
|
|
|
|
case PCIM_PSTAT_D0:
|
|
|
|
result = PCI_POWERSTATE_D0;
|
1998-09-15 08:21:13 +00:00
|
|
|
break;
|
2000-12-13 01:25:11 +00:00
|
|
|
case PCIM_PSTAT_D1:
|
|
|
|
result = PCI_POWERSTATE_D1;
|
1998-09-15 08:21:13 +00:00
|
|
|
break;
|
2000-12-13 01:25:11 +00:00
|
|
|
case PCIM_PSTAT_D2:
|
|
|
|
result = PCI_POWERSTATE_D2;
|
1998-09-15 08:21:13 +00:00
|
|
|
break;
|
2000-12-13 01:25:11 +00:00
|
|
|
case PCIM_PSTAT_D3:
|
|
|
|
result = PCI_POWERSTATE_D3;
|
1998-09-15 08:21:13 +00:00
|
|
|
break;
|
2000-12-13 01:25:11 +00:00
|
|
|
default:
|
|
|
|
result = PCI_POWERSTATE_UNKNOWN;
|
1998-09-15 08:21:13 +00:00
|
|
|
break;
|
|
|
|
}
|
2000-12-13 01:25:11 +00:00
|
|
|
} else {
|
|
|
|
/* No support, device is always at D0 */
|
|
|
|
result = PCI_POWERSTATE_D0;
|
|
|
|
}
|
2004-12-31 20:43:46 +00:00
|
|
|
return (result);
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
1998-09-15 08:21:13 +00:00
|
|
|
|
2000-12-13 01:25:11 +00:00
|
|
|
/*
|
|
|
|
* Some convenience functions for PCI device drivers.
|
|
|
|
*/
|
1998-09-15 08:21:13 +00:00
|
|
|
|
2000-12-13 01:25:11 +00:00
|
|
|
static __inline void
|
2003-08-22 03:11:53 +00:00
|
|
|
pci_set_command_bit(device_t dev, device_t child, uint16_t bit)
|
2000-12-13 01:25:11 +00:00
|
|
|
{
|
2003-08-22 03:11:53 +00:00
|
|
|
uint16_t command;
|
1998-09-15 08:21:13 +00:00
|
|
|
|
2002-06-01 03:41:02 +00:00
|
|
|
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
|
|
|
|
command |= bit;
|
|
|
|
PCI_WRITE_CONFIG(dev, child, PCIR_COMMAND, command, 2);
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
1998-09-15 08:21:13 +00:00
|
|
|
|
2000-12-13 01:25:11 +00:00
|
|
|
static __inline void
|
2003-08-22 03:11:53 +00:00
|
|
|
pci_clear_command_bit(device_t dev, device_t child, uint16_t bit)
|
2000-12-13 01:25:11 +00:00
|
|
|
{
|
2003-08-22 03:11:53 +00:00
|
|
|
uint16_t command;
|
1996-10-22 20:20:14 +00:00
|
|
|
|
2002-06-01 03:41:02 +00:00
|
|
|
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
|
|
|
|
command &= ~bit;
|
|
|
|
PCI_WRITE_CONFIG(dev, child, PCIR_COMMAND, command, 2);
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
1997-01-21 23:23:40 +00:00
|
|
|
|
2003-04-16 03:15:08 +00:00
|
|
|
int
|
2001-02-27 23:13:20 +00:00
|
|
|
pci_enable_busmaster_method(device_t dev, device_t child)
|
2000-12-13 01:25:11 +00:00
|
|
|
{
|
2002-06-01 03:41:02 +00:00
|
|
|
pci_set_command_bit(dev, child, PCIM_CMD_BUSMASTEREN);
|
2003-04-16 03:15:08 +00:00
|
|
|
return (0);
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
1996-10-22 20:20:14 +00:00
|
|
|
|
2003-04-16 03:15:08 +00:00
|
|
|
int
|
2001-02-27 23:13:20 +00:00
|
|
|
pci_disable_busmaster_method(device_t dev, device_t child)
|
2000-12-13 01:25:11 +00:00
|
|
|
{
|
2002-06-01 03:41:02 +00:00
|
|
|
pci_clear_command_bit(dev, child, PCIM_CMD_BUSMASTEREN);
|
2003-04-16 03:15:08 +00:00
|
|
|
return (0);
|
1996-10-22 20:20:14 +00:00
|
|
|
}
|
|
|
|
|
2003-04-16 03:15:08 +00:00
|
|
|
int
|
2001-02-27 23:13:20 +00:00
|
|
|
pci_enable_io_method(device_t dev, device_t child, int space)
|
2000-12-13 01:25:11 +00:00
|
|
|
{
|
2003-08-22 03:11:53 +00:00
|
|
|
uint16_t bit;
|
2003-04-16 03:15:08 +00:00
|
|
|
|
2002-06-01 03:41:02 +00:00
|
|
|
switch(space) {
|
|
|
|
case SYS_RES_IOPORT:
|
2003-04-16 03:15:08 +00:00
|
|
|
bit = PCIM_CMD_PORTEN;
|
2002-06-01 03:41:02 +00:00
|
|
|
break;
|
|
|
|
case SYS_RES_MEMORY:
|
2003-04-16 03:15:08 +00:00
|
|
|
bit = PCIM_CMD_MEMEN;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return (EINVAL);
|
2002-06-01 03:41:02 +00:00
|
|
|
}
|
2003-04-16 03:15:08 +00:00
|
|
|
pci_set_command_bit(dev, child, bit);
|
2009-09-22 15:43:03 +00:00
|
|
|
return (0);
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
1996-10-22 20:20:14 +00:00
|
|
|
|
2003-04-16 03:15:08 +00:00
|
|
|
int
|
2001-02-27 23:13:20 +00:00
|
|
|
pci_disable_io_method(device_t dev, device_t child, int space)
|
2000-12-13 01:25:11 +00:00
|
|
|
{
|
2003-08-22 03:11:53 +00:00
|
|
|
uint16_t bit;
|
2003-04-16 03:15:08 +00:00
|
|
|
|
2002-06-01 03:41:02 +00:00
|
|
|
switch(space) {
|
|
|
|
case SYS_RES_IOPORT:
|
2003-04-16 03:15:08 +00:00
|
|
|
bit = PCIM_CMD_PORTEN;
|
2002-06-01 03:41:02 +00:00
|
|
|
break;
|
|
|
|
case SYS_RES_MEMORY:
|
2003-04-16 03:15:08 +00:00
|
|
|
bit = PCIM_CMD_MEMEN;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return (EINVAL);
|
2002-06-01 03:41:02 +00:00
|
|
|
}
|
2003-04-16 03:15:08 +00:00
|
|
|
pci_clear_command_bit(dev, child, bit);
|
|
|
|
return (0);
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
1999-04-16 21:22:55 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* New style pci driver. Parent device is either a pci-host-bridge or a
|
|
|
|
* pci-pci-bridge. Both kinds are represented by instances of pcib.
|
|
|
|
*/
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
void
|
1999-04-16 21:22:55 +00:00
|
|
|
pci_print_verbose(struct pci_devinfo *dinfo)
|
|
|
|
{
|
2006-10-09 16:15:56 +00:00
|
|
|
|
1999-04-16 21:22:55 +00:00
|
|
|
if (bootverbose) {
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
|
2006-11-07 18:55:51 +00:00
|
|
|
printf("found->\tvendor=0x%04x, dev=0x%04x, revid=0x%02x\n",
|
2002-06-01 03:41:02 +00:00
|
|
|
cfg->vendor, cfg->device, cfg->revid);
|
2007-09-30 11:05:18 +00:00
|
|
|
printf("\tdomain=%d, bus=%d, slot=%d, func=%d\n",
|
|
|
|
cfg->domain, cfg->bus, cfg->slot, cfg->func);
|
1999-04-16 21:22:55 +00:00
|
|
|
printf("\tclass=%02x-%02x-%02x, hdrtype=0x%02x, mfdev=%d\n",
|
2002-06-01 03:41:02 +00:00
|
|
|
cfg->baseclass, cfg->subclass, cfg->progif, cfg->hdrtype,
|
|
|
|
cfg->mfdev);
|
2006-11-07 18:55:51 +00:00
|
|
|
printf("\tcmdreg=0x%04x, statreg=0x%04x, cachelnsz=%d (dwords)\n",
|
2002-06-01 03:41:02 +00:00
|
|
|
cfg->cmdreg, cfg->statreg, cfg->cachelnsz);
|
1999-04-16 21:22:55 +00:00
|
|
|
printf("\tlattimer=0x%02x (%d ns), mingnt=0x%02x (%d ns), maxlat=0x%02x (%d ns)\n",
|
2002-06-01 03:41:02 +00:00
|
|
|
cfg->lattimer, cfg->lattimer * 30, cfg->mingnt,
|
|
|
|
cfg->mingnt * 250, cfg->maxlat, cfg->maxlat * 250);
|
1999-04-16 21:22:55 +00:00
|
|
|
if (cfg->intpin > 0)
|
2002-06-01 03:41:02 +00:00
|
|
|
printf("\tintpin=%c, irq=%d\n",
|
|
|
|
cfg->intpin +'a' -1, cfg->intline);
|
2003-09-14 19:30:00 +00:00
|
|
|
if (cfg->pp.pp_cap) {
|
2003-08-22 03:11:53 +00:00
|
|
|
uint16_t status;
|
2000-12-13 01:25:11 +00:00
|
|
|
|
2003-09-14 19:30:00 +00:00
|
|
|
status = pci_read_config(cfg->dev, cfg->pp.pp_status, 2);
|
2000-12-13 01:25:11 +00:00
|
|
|
printf("\tpowerspec %d supports D0%s%s D3 current D%d\n",
|
2003-09-14 19:30:00 +00:00
|
|
|
cfg->pp.pp_cap & PCIM_PCAP_SPEC,
|
|
|
|
cfg->pp.pp_cap & PCIM_PCAP_D1SUPP ? " D1" : "",
|
|
|
|
cfg->pp.pp_cap & PCIM_PCAP_D2SUPP ? " D2" : "",
|
2002-06-01 03:41:02 +00:00
|
|
|
status & PCIM_PSTAT_DMASK);
|
2000-12-13 01:25:11 +00:00
|
|
|
}
|
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
|
|
|
if (cfg->msi.msi_location) {
|
2003-09-14 19:30:00 +00:00
|
|
|
int ctrl;
|
|
|
|
|
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
|
|
|
ctrl = cfg->msi.msi_ctrl;
|
2003-09-14 19:30:00 +00:00
|
|
|
printf("\tMSI supports %d message%s%s%s\n",
|
|
|
|
cfg->msi.msi_msgnum,
|
|
|
|
(cfg->msi.msi_msgnum == 1) ? "" : "s",
|
|
|
|
(ctrl & PCIM_MSICTRL_64BIT) ? ", 64 bit" : "",
|
|
|
|
(ctrl & PCIM_MSICTRL_VECTOR) ? ", vector masks":"");
|
|
|
|
}
|
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
|
|
|
if (cfg->msix.msix_location) {
|
|
|
|
printf("\tMSI-X supports %d message%s ",
|
|
|
|
cfg->msix.msix_msgnum,
|
|
|
|
(cfg->msix.msix_msgnum == 1) ? "" : "s");
|
|
|
|
if (cfg->msix.msix_table_bar == cfg->msix.msix_pba_bar)
|
|
|
|
printf("in map 0x%x\n",
|
|
|
|
cfg->msix.msix_table_bar);
|
|
|
|
else
|
|
|
|
printf("in maps 0x%x and 0x%x\n",
|
|
|
|
cfg->msix.msix_table_bar,
|
|
|
|
cfg->msix.msix_pba_bar);
|
|
|
|
}
|
1999-10-14 21:38:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_porten(device_t dev)
|
1999-10-14 21:38:33 +00:00
|
|
|
{
|
2009-04-14 18:32:37 +00:00
|
|
|
return (pci_read_config(dev, PCIR_COMMAND, 2) & PCIM_CMD_PORTEN) != 0;
|
1999-10-14 21:38:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_memen(device_t dev)
|
1999-10-14 21:38:33 +00:00
|
|
|
{
|
2009-04-14 18:32:37 +00:00
|
|
|
return (pci_read_config(dev, PCIR_COMMAND, 2) & PCIM_CMD_MEMEN) != 0;
|
1999-10-14 21:38:33 +00:00
|
|
|
}
|
|
|
|
|
2009-04-14 18:32:37 +00:00
|
|
|
static void
|
|
|
|
pci_read_bar(device_t dev, int reg, pci_addr_t *mapp, pci_addr_t *testvalp)
|
1999-10-14 21:38:33 +00:00
|
|
|
{
|
2011-03-31 13:22:12 +00:00
|
|
|
struct pci_devinfo *dinfo;
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_addr_t map, testval;
|
|
|
|
int ln2range;
|
2003-08-22 03:11:53 +00:00
|
|
|
uint16_t cmd;
|
1999-10-28 08:06:59 +00:00
|
|
|
|
2009-12-30 20:47:14 +00:00
|
|
|
/*
|
|
|
|
* The device ROM BAR is special. It is always a 32-bit
|
|
|
|
* memory BAR. Bit 0 is special and should not be set when
|
|
|
|
* sizing the BAR.
|
|
|
|
*/
|
2011-03-31 13:22:12 +00:00
|
|
|
dinfo = device_get_ivars(dev);
|
|
|
|
if (PCIR_IS_BIOS(&dinfo->cfg, reg)) {
|
2009-12-30 20:47:14 +00:00
|
|
|
map = pci_read_config(dev, reg, 4);
|
|
|
|
pci_write_config(dev, reg, 0xfffffffe, 4);
|
|
|
|
testval = pci_read_config(dev, reg, 4);
|
|
|
|
pci_write_config(dev, reg, map, 4);
|
|
|
|
*mapp = map;
|
|
|
|
*testvalp = testval;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-04-14 18:32:37 +00:00
|
|
|
map = pci_read_config(dev, reg, 4);
|
2009-03-05 15:33:04 +00:00
|
|
|
ln2range = pci_maprange(map);
|
|
|
|
if (ln2range == 64)
|
2009-04-14 18:32:37 +00:00
|
|
|
map |= (pci_addr_t)pci_read_config(dev, reg + 4, 4) << 32;
|
2009-01-16 22:22:30 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Disable decoding via the command register before
|
2009-03-03 16:38:59 +00:00
|
|
|
* determining the BAR's length since we will be placing it in
|
|
|
|
* a weird state.
|
2009-01-16 22:22:30 +00:00
|
|
|
*/
|
2009-04-14 18:32:37 +00:00
|
|
|
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
|
|
|
|
pci_write_config(dev, PCIR_COMMAND,
|
2009-01-16 22:22:30 +00:00
|
|
|
cmd & ~(PCI_BAR_MEM(map) ? PCIM_CMD_MEMEN : PCIM_CMD_PORTEN), 2);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Determine the BAR's length by writing all 1's. The bottom
|
|
|
|
* log_2(size) bits of the BAR will stick as 0 when we read
|
|
|
|
* the value back.
|
|
|
|
*/
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_write_config(dev, reg, 0xffffffff, 4);
|
|
|
|
testval = pci_read_config(dev, reg, 4);
|
2009-03-05 15:33:04 +00:00
|
|
|
if (ln2range == 64) {
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_write_config(dev, reg + 4, 0xffffffff, 4);
|
|
|
|
testval |= (pci_addr_t)pci_read_config(dev, reg + 4, 4) << 32;
|
2009-03-05 15:33:04 +00:00
|
|
|
}
|
2009-01-16 22:22:30 +00:00
|
|
|
|
2009-04-14 18:32:37 +00:00
|
|
|
/*
|
|
|
|
* Restore the original value of the BAR. We may have reprogrammed
|
|
|
|
* the BAR of the low-level console device and when booting verbose,
|
|
|
|
* we need the console device addressable.
|
|
|
|
*/
|
|
|
|
pci_write_config(dev, reg, map, 4);
|
2009-03-05 15:33:04 +00:00
|
|
|
if (ln2range == 64)
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_write_config(dev, reg + 4, map >> 32, 4);
|
|
|
|
pci_write_config(dev, PCIR_COMMAND, cmd, 2);
|
1999-10-28 08:06:59 +00:00
|
|
|
|
2009-04-14 18:32:37 +00:00
|
|
|
*mapp = map;
|
|
|
|
*testvalp = testval;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2011-03-31 13:22:12 +00:00
|
|
|
pci_write_bar(device_t dev, struct pci_map *pm, pci_addr_t base)
|
2009-04-14 18:32:37 +00:00
|
|
|
{
|
2011-03-31 13:22:12 +00:00
|
|
|
struct pci_devinfo *dinfo;
|
2009-04-14 18:32:37 +00:00
|
|
|
int ln2range;
|
|
|
|
|
2011-03-31 13:22:12 +00:00
|
|
|
/* The device ROM BAR is always a 32-bit memory BAR. */
|
|
|
|
dinfo = device_get_ivars(dev);
|
|
|
|
if (PCIR_IS_BIOS(&dinfo->cfg, pm->pm_reg))
|
|
|
|
ln2range = 32;
|
|
|
|
else
|
|
|
|
ln2range = pci_maprange(pm->pm_value);
|
|
|
|
pci_write_config(dev, pm->pm_reg, base, 4);
|
|
|
|
if (ln2range == 64)
|
|
|
|
pci_write_config(dev, pm->pm_reg + 4, base >> 32, 4);
|
|
|
|
pm->pm_value = pci_read_config(dev, pm->pm_reg, 4);
|
2009-04-14 18:32:37 +00:00
|
|
|
if (ln2range == 64)
|
2011-06-21 19:31:31 +00:00
|
|
|
pm->pm_value |= (pci_addr_t)pci_read_config(dev,
|
|
|
|
pm->pm_reg + 4, 4) << 32;
|
2011-03-31 13:22:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
struct pci_map *
|
|
|
|
pci_find_bar(device_t dev, int reg)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
struct pci_map *pm;
|
|
|
|
|
|
|
|
dinfo = device_get_ivars(dev);
|
|
|
|
STAILQ_FOREACH(pm, &dinfo->cfg.maps, pm_link) {
|
|
|
|
if (pm->pm_reg == reg)
|
|
|
|
return (pm);
|
|
|
|
}
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
pci_bar_enabled(device_t dev, struct pci_map *pm)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
uint16_t cmd;
|
|
|
|
|
|
|
|
dinfo = device_get_ivars(dev);
|
|
|
|
if (PCIR_IS_BIOS(&dinfo->cfg, pm->pm_reg) &&
|
|
|
|
!(pm->pm_value & PCIM_BIOS_ENABLE))
|
|
|
|
return (0);
|
|
|
|
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
|
|
|
|
if (PCIR_IS_BIOS(&dinfo->cfg, pm->pm_reg) || PCI_BAR_MEM(pm->pm_value))
|
|
|
|
return ((cmd & PCIM_CMD_MEMEN) != 0);
|
|
|
|
else
|
|
|
|
return ((cmd & PCIM_CMD_PORTEN) != 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct pci_map *
|
|
|
|
pci_add_bar(device_t dev, int reg, pci_addr_t value, pci_addr_t size)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
struct pci_map *pm, *prev;
|
|
|
|
|
|
|
|
dinfo = device_get_ivars(dev);
|
|
|
|
pm = malloc(sizeof(*pm), M_DEVBUF, M_WAITOK | M_ZERO);
|
|
|
|
pm->pm_reg = reg;
|
|
|
|
pm->pm_value = value;
|
|
|
|
pm->pm_size = size;
|
|
|
|
STAILQ_FOREACH(prev, &dinfo->cfg.maps, pm_link) {
|
|
|
|
KASSERT(prev->pm_reg != pm->pm_reg, ("duplicate map %02x",
|
|
|
|
reg));
|
|
|
|
if (STAILQ_NEXT(prev, pm_link) == NULL ||
|
|
|
|
STAILQ_NEXT(prev, pm_link)->pm_reg > pm->pm_reg)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (prev != NULL)
|
|
|
|
STAILQ_INSERT_AFTER(&dinfo->cfg.maps, prev, pm, pm_link);
|
|
|
|
else
|
|
|
|
STAILQ_INSERT_TAIL(&dinfo->cfg.maps, pm, pm_link);
|
|
|
|
return (pm);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
pci_restore_bars(device_t dev)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
struct pci_map *pm;
|
|
|
|
int ln2range;
|
|
|
|
|
|
|
|
dinfo = device_get_ivars(dev);
|
|
|
|
STAILQ_FOREACH(pm, &dinfo->cfg.maps, pm_link) {
|
|
|
|
if (PCIR_IS_BIOS(&dinfo->cfg, pm->pm_reg))
|
|
|
|
ln2range = 32;
|
|
|
|
else
|
|
|
|
ln2range = pci_maprange(pm->pm_value);
|
|
|
|
pci_write_config(dev, pm->pm_reg, pm->pm_value, 4);
|
|
|
|
if (ln2range == 64)
|
|
|
|
pci_write_config(dev, pm->pm_reg + 4,
|
|
|
|
pm->pm_value >> 32, 4);
|
|
|
|
}
|
2009-04-14 18:32:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add a resource based on a pci map register. Return 1 if the map
|
|
|
|
* register is a 32bit map register or 2 if it is a 64bit register.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
pci_add_map(device_t bus, device_t dev, int reg, struct resource_list *rl,
|
|
|
|
int force, int prefetch)
|
|
|
|
{
|
2011-03-31 13:22:12 +00:00
|
|
|
struct pci_map *pm;
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_addr_t base, map, testval;
|
|
|
|
pci_addr_t start, end, count;
|
2009-07-21 19:06:39 +00:00
|
|
|
int barlen, basezero, maprange, mapsize, type;
|
2009-04-14 18:32:37 +00:00
|
|
|
uint16_t cmd;
|
|
|
|
struct resource *res;
|
|
|
|
|
2011-06-06 13:21:11 +00:00
|
|
|
/*
|
|
|
|
* The BAR may already exist if the device is a CardBus card
|
|
|
|
* whose CIS is stored in this BAR.
|
|
|
|
*/
|
|
|
|
pm = pci_find_bar(dev, reg);
|
|
|
|
if (pm != NULL) {
|
|
|
|
maprange = pci_maprange(pm->pm_value);
|
|
|
|
barlen = maprange == 64 ? 2 : 1;
|
|
|
|
return (barlen);
|
|
|
|
}
|
|
|
|
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_read_bar(dev, reg, &map, &testval);
|
2009-03-05 15:28:46 +00:00
|
|
|
if (PCI_BAR_MEM(map)) {
|
1999-10-28 08:06:59 +00:00
|
|
|
type = SYS_RES_MEMORY;
|
2009-03-05 15:28:46 +00:00
|
|
|
if (map & PCIM_BAR_MEM_PREFETCH)
|
|
|
|
prefetch = 1;
|
|
|
|
} else
|
1999-10-28 08:06:59 +00:00
|
|
|
type = SYS_RES_IOPORT;
|
2009-04-14 18:32:37 +00:00
|
|
|
mapsize = pci_mapsize(testval);
|
2004-04-09 15:44:34 +00:00
|
|
|
base = pci_mapbase(map);
|
2009-07-21 19:06:39 +00:00
|
|
|
#ifdef __PCI_BAR_ZERO_VALID
|
|
|
|
basezero = 0;
|
|
|
|
#else
|
|
|
|
basezero = base == 0;
|
|
|
|
#endif
|
2009-04-14 18:32:37 +00:00
|
|
|
maprange = pci_maprange(map);
|
|
|
|
barlen = maprange == 64 ? 2 : 1;
|
2004-04-09 15:44:34 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For I/O registers, if bottom bit is set, and the next bit up
|
|
|
|
* isn't clear, we know we have a BAR that doesn't conform to the
|
|
|
|
* spec, so ignore it. Also, sanity check the size of the data
|
2004-04-11 07:02:49 +00:00
|
|
|
* areas to the type of memory involved. Memory must be at least
|
2006-04-27 04:53:18 +00:00
|
|
|
* 16 bytes in size, while I/O ranges must be at least 4.
|
2004-04-09 15:44:34 +00:00
|
|
|
*/
|
2007-03-31 21:39:02 +00:00
|
|
|
if (PCI_BAR_IO(testval) && (testval & PCIM_BAR_IO_RESERVED) != 0)
|
2005-09-03 23:15:46 +00:00
|
|
|
return (barlen);
|
2009-04-14 18:32:37 +00:00
|
|
|
if ((type == SYS_RES_MEMORY && mapsize < 4) ||
|
|
|
|
(type == SYS_RES_IOPORT && mapsize < 2))
|
2005-09-03 23:15:46 +00:00
|
|
|
return (barlen);
|
2004-04-09 15:44:34 +00:00
|
|
|
|
2011-03-31 13:22:12 +00:00
|
|
|
/* Save a record of this BAR. */
|
|
|
|
pm = pci_add_bar(dev, reg, map, mapsize);
|
2000-03-18 19:18:36 +00:00
|
|
|
if (bootverbose) {
|
2007-03-31 21:39:02 +00:00
|
|
|
printf("\tmap[%02x]: type %s, range %2d, base %#jx, size %2d",
|
2009-04-14 18:32:37 +00:00
|
|
|
reg, pci_maptype(map), maprange, (uintmax_t)base, mapsize);
|
|
|
|
if (type == SYS_RES_IOPORT && !pci_porten(dev))
|
2000-03-18 19:18:36 +00:00
|
|
|
printf(", port disabled\n");
|
2009-04-14 18:32:37 +00:00
|
|
|
else if (type == SYS_RES_MEMORY && !pci_memen(dev))
|
2000-03-18 19:18:36 +00:00
|
|
|
printf(", memory disabled\n");
|
|
|
|
else
|
|
|
|
printf(", enabled\n");
|
|
|
|
}
|
2000-10-28 23:07:13 +00:00
|
|
|
|
2005-05-31 21:33:33 +00:00
|
|
|
/*
|
2009-07-21 19:06:39 +00:00
|
|
|
* If base is 0, then we have problems if this architecture does
|
|
|
|
* not allow that. It is best to ignore such entries for the
|
|
|
|
* moment. These will be allocated later if the driver specifically
|
|
|
|
* requests them. However, some removable busses look better when
|
|
|
|
* all resources are allocated, so allow '0' to be overriden.
|
2005-09-01 02:42:34 +00:00
|
|
|
*
|
2005-09-01 16:41:42 +00:00
|
|
|
* Similarly treat maps whose values is the same as the test value
|
2005-09-01 02:42:34 +00:00
|
|
|
* read back. These maps have had all f's written to them by the
|
|
|
|
* BIOS in an attempt to disable the resources.
|
2005-05-31 21:33:33 +00:00
|
|
|
*/
|
2009-07-21 19:06:39 +00:00
|
|
|
if (!force && (basezero || map == testval))
|
2005-09-03 23:15:46 +00:00
|
|
|
return (barlen);
|
2006-10-30 19:18:46 +00:00
|
|
|
if ((u_long)base != base) {
|
|
|
|
device_printf(bus,
|
2007-09-30 11:05:18 +00:00
|
|
|
"pci%d:%d:%d:%d bar %#x too many address bits",
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_get_domain(dev), pci_get_bus(dev), pci_get_slot(dev),
|
|
|
|
pci_get_function(dev), reg);
|
2006-10-30 19:18:46 +00:00
|
|
|
return (barlen);
|
|
|
|
}
|
2006-11-07 18:55:51 +00:00
|
|
|
|
2000-10-28 23:07:13 +00:00
|
|
|
/*
|
|
|
|
* This code theoretically does the right thing, but has
|
2004-04-09 15:44:34 +00:00
|
|
|
* undesirable side effects in some cases where peripherals
|
|
|
|
* respond oddly to having these bits enabled. Let the user
|
|
|
|
* be able to turn them off (since pci_enable_io_modes is 1 by
|
|
|
|
* default).
|
2000-10-28 23:07:13 +00:00
|
|
|
*/
|
2002-07-26 07:58:16 +00:00
|
|
|
if (pci_enable_io_modes) {
|
|
|
|
/* Turn on resources that have been left off by a lazy BIOS */
|
2009-04-14 18:32:37 +00:00
|
|
|
if (type == SYS_RES_IOPORT && !pci_porten(dev)) {
|
|
|
|
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
|
2002-07-26 07:58:16 +00:00
|
|
|
cmd |= PCIM_CMD_PORTEN;
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_write_config(dev, PCIR_COMMAND, cmd, 2);
|
2002-07-26 07:58:16 +00:00
|
|
|
}
|
2009-04-14 18:32:37 +00:00
|
|
|
if (type == SYS_RES_MEMORY && !pci_memen(dev)) {
|
|
|
|
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
|
2002-07-26 07:58:16 +00:00
|
|
|
cmd |= PCIM_CMD_MEMEN;
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_write_config(dev, PCIR_COMMAND, cmd, 2);
|
2002-07-26 07:58:16 +00:00
|
|
|
}
|
|
|
|
} else {
|
2009-04-14 18:32:37 +00:00
|
|
|
if (type == SYS_RES_IOPORT && !pci_porten(dev))
|
2005-09-03 23:15:46 +00:00
|
|
|
return (barlen);
|
2009-04-14 18:32:37 +00:00
|
|
|
if (type == SYS_RES_MEMORY && !pci_memen(dev))
|
2005-09-03 23:15:46 +00:00
|
|
|
return (barlen);
|
2000-09-01 23:09:02 +00:00
|
|
|
}
|
2004-04-20 20:57:29 +00:00
|
|
|
|
2011-02-23 12:58:50 +00:00
|
|
|
count = (pci_addr_t)1 << mapsize;
|
2009-07-21 19:06:39 +00:00
|
|
|
if (basezero || base == pci_mapbase(testval)) {
|
2008-08-05 18:24:41 +00:00
|
|
|
start = 0; /* Let the parent decide. */
|
2011-06-21 19:31:31 +00:00
|
|
|
end = ~0ul;
|
2005-12-30 19:28:26 +00:00
|
|
|
} else {
|
|
|
|
start = base;
|
2011-02-23 12:58:50 +00:00
|
|
|
end = base + count - 1;
|
2005-12-30 19:28:26 +00:00
|
|
|
}
|
2004-04-09 15:44:34 +00:00
|
|
|
resource_list_add(rl, type, reg, start, end, count);
|
1999-10-14 21:38:33 +00:00
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
/*
|
2008-08-05 18:24:41 +00:00
|
|
|
* Try to allocate the resource for this BAR from our parent
|
|
|
|
* so that this resource range is already reserved. The
|
|
|
|
* driver for this device will later inherit this resource in
|
|
|
|
* pci_alloc_resource().
|
2004-04-09 15:44:34 +00:00
|
|
|
*/
|
2009-12-09 21:52:53 +00:00
|
|
|
res = resource_list_reserve(rl, bus, dev, type, ®, start, end, count,
|
2005-12-30 19:28:26 +00:00
|
|
|
prefetch ? RF_PREFETCHABLE : 0);
|
2008-08-05 18:24:41 +00:00
|
|
|
if (res == NULL) {
|
|
|
|
/*
|
|
|
|
* If the allocation fails, clear the BAR and delete
|
|
|
|
* the resource list entry to force
|
|
|
|
* pci_alloc_resource() to allocate resources from the
|
|
|
|
* parent.
|
|
|
|
*/
|
|
|
|
resource_list_delete(rl, type, reg);
|
|
|
|
start = 0;
|
2009-12-09 21:52:53 +00:00
|
|
|
} else
|
2008-08-05 18:24:41 +00:00
|
|
|
start = rman_get_start(res);
|
2011-03-31 13:22:12 +00:00
|
|
|
pci_write_bar(dev, pm, start);
|
2005-09-03 23:15:46 +00:00
|
|
|
return (barlen);
|
1999-10-28 08:06:59 +00:00
|
|
|
}
|
|
|
|
|
2004-04-21 20:19:56 +00:00
|
|
|
/*
|
2004-06-29 20:25:43 +00:00
|
|
|
* For ATA devices we need to decide early what addressing mode to use.
|
|
|
|
* Legacy demands that the primary and secondary ATA ports sits on the
|
|
|
|
* same addresses that old ISA hardware did. This dictates that we use
|
2006-11-07 18:55:51 +00:00
|
|
|
* those addresses and ignore the BAR's if we cannot set PCI native
|
2004-06-29 20:25:43 +00:00
|
|
|
* addressing mode.
|
2004-04-21 20:19:56 +00:00
|
|
|
*/
|
|
|
|
static void
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_ata_maps(device_t bus, device_t dev, struct resource_list *rl, int force,
|
|
|
|
uint32_t prefetchmask)
|
2004-04-21 20:19:56 +00:00
|
|
|
{
|
2009-03-03 16:38:59 +00:00
|
|
|
struct resource *r;
|
2004-06-29 20:25:43 +00:00
|
|
|
int rid, type, progif;
|
2004-07-02 13:42:36 +00:00
|
|
|
#if 0
|
2004-06-29 20:25:43 +00:00
|
|
|
/* if this device supports PCI native addressing use it */
|
|
|
|
progif = pci_read_config(dev, PCIR_PROGIF, 1);
|
|
|
|
if ((progif & 0x8a) == 0x8a) {
|
|
|
|
if (pci_mapbase(pci_read_config(dev, PCIR_BAR(0), 4)) &&
|
|
|
|
pci_mapbase(pci_read_config(dev, PCIR_BAR(2), 4))) {
|
|
|
|
printf("Trying ATA native PCI addressing mode\n");
|
|
|
|
pci_write_config(dev, PCIR_PROGIF, progif | 0x05, 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
progif = pci_read_config(dev, PCIR_PROGIF, 1);
|
2004-04-21 20:19:56 +00:00
|
|
|
type = SYS_RES_IOPORT;
|
2004-06-29 20:25:43 +00:00
|
|
|
if (progif & PCIP_STORAGE_IDE_MODEPRIM) {
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_add_map(bus, dev, PCIR_BAR(0), rl, force,
|
2005-12-30 19:28:26 +00:00
|
|
|
prefetchmask & (1 << 0));
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_add_map(bus, dev, PCIR_BAR(1), rl, force,
|
2005-12-30 19:28:26 +00:00
|
|
|
prefetchmask & (1 << 1));
|
2005-10-28 05:56:50 +00:00
|
|
|
} else {
|
2004-04-21 20:19:56 +00:00
|
|
|
rid = PCIR_BAR(0);
|
|
|
|
resource_list_add(rl, type, rid, 0x1f0, 0x1f7, 8);
|
2009-12-09 21:52:53 +00:00
|
|
|
r = resource_list_reserve(rl, bus, dev, type, &rid, 0x1f0,
|
|
|
|
0x1f7, 8, 0);
|
2004-04-21 20:19:56 +00:00
|
|
|
rid = PCIR_BAR(1);
|
|
|
|
resource_list_add(rl, type, rid, 0x3f6, 0x3f6, 1);
|
2009-12-09 21:52:53 +00:00
|
|
|
r = resource_list_reserve(rl, bus, dev, type, &rid, 0x3f6,
|
|
|
|
0x3f6, 1, 0);
|
2004-06-29 20:25:43 +00:00
|
|
|
}
|
|
|
|
if (progif & PCIP_STORAGE_IDE_MODESEC) {
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_add_map(bus, dev, PCIR_BAR(2), rl, force,
|
2005-12-30 19:28:26 +00:00
|
|
|
prefetchmask & (1 << 2));
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_add_map(bus, dev, PCIR_BAR(3), rl, force,
|
2005-12-30 19:28:26 +00:00
|
|
|
prefetchmask & (1 << 3));
|
2005-10-28 05:56:50 +00:00
|
|
|
} else {
|
2004-04-21 20:19:56 +00:00
|
|
|
rid = PCIR_BAR(2);
|
|
|
|
resource_list_add(rl, type, rid, 0x170, 0x177, 8);
|
2009-12-09 21:52:53 +00:00
|
|
|
r = resource_list_reserve(rl, bus, dev, type, &rid, 0x170,
|
|
|
|
0x177, 8, 0);
|
2004-04-21 20:19:56 +00:00
|
|
|
rid = PCIR_BAR(3);
|
|
|
|
resource_list_add(rl, type, rid, 0x376, 0x376, 1);
|
2009-12-09 21:52:53 +00:00
|
|
|
r = resource_list_reserve(rl, bus, dev, type, &rid, 0x376,
|
|
|
|
0x376, 1, 0);
|
2004-04-21 20:19:56 +00:00
|
|
|
}
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_add_map(bus, dev, PCIR_BAR(4), rl, force,
|
2005-12-30 19:28:26 +00:00
|
|
|
prefetchmask & (1 << 4));
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_add_map(bus, dev, PCIR_BAR(5), rl, force,
|
2005-12-30 19:28:26 +00:00
|
|
|
prefetchmask & (1 << 5));
|
2004-04-21 20:19:56 +00:00
|
|
|
}
|
|
|
|
|
2005-09-29 15:04:41 +00:00
|
|
|
static void
|
|
|
|
pci_assign_interrupt(device_t bus, device_t dev, int force_route)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
char tunable_name[64];
|
|
|
|
int irq;
|
|
|
|
|
|
|
|
/* Has to have an intpin to have an interrupt. */
|
|
|
|
if (cfg->intpin == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Let the user override the IRQ with a tunable. */
|
|
|
|
irq = PCI_INVALID_IRQ;
|
2007-09-30 11:05:18 +00:00
|
|
|
snprintf(tunable_name, sizeof(tunable_name),
|
|
|
|
"hw.pci%d.%d.%d.INT%c.irq",
|
|
|
|
cfg->domain, cfg->bus, cfg->slot, cfg->intpin + 'A' - 1);
|
2005-09-29 15:04:41 +00:00
|
|
|
if (TUNABLE_INT_FETCH(tunable_name, &irq) && (irq >= 255 || irq <= 0))
|
|
|
|
irq = PCI_INVALID_IRQ;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we didn't get an IRQ via the tunable, then we either use the
|
|
|
|
* IRQ value in the intline register or we ask the bus to route an
|
|
|
|
* interrupt for us. If force_route is true, then we only use the
|
|
|
|
* value in the intline register if the bus was unable to assign an
|
|
|
|
* IRQ.
|
|
|
|
*/
|
|
|
|
if (!PCI_INTERRUPT_VALID(irq)) {
|
|
|
|
if (!PCI_INTERRUPT_VALID(cfg->intline) || force_route)
|
|
|
|
irq = PCI_ASSIGN_INTERRUPT(bus, dev);
|
|
|
|
if (!PCI_INTERRUPT_VALID(irq))
|
|
|
|
irq = cfg->intline;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If after all that we don't have an IRQ, just bail. */
|
|
|
|
if (!PCI_INTERRUPT_VALID(irq))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Update the config register if it changed. */
|
|
|
|
if (irq != cfg->intline) {
|
|
|
|
cfg->intline = irq;
|
|
|
|
pci_write_config(dev, PCIR_INTLINE, irq, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Add this IRQ as rid 0 interrupt resource. */
|
|
|
|
resource_list_add(&dinfo->resources, SYS_RES_IRQ, 0, irq, irq, 1);
|
|
|
|
}
|
|
|
|
|
2009-10-15 20:07:08 +00:00
|
|
|
/* Perform early OHCI takeover from SMM. */
|
|
|
|
static void
|
|
|
|
ohci_early_takeover(device_t self)
|
|
|
|
{
|
|
|
|
struct resource *res;
|
|
|
|
uint32_t ctl;
|
|
|
|
int rid;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
rid = PCIR_BAR(0);
|
|
|
|
res = bus_alloc_resource_any(self, SYS_RES_MEMORY, &rid, RF_ACTIVE);
|
|
|
|
if (res == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ctl = bus_read_4(res, OHCI_CONTROL);
|
|
|
|
if (ctl & OHCI_IR) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("ohci early: "
|
|
|
|
"SMM active, request owner change\n");
|
|
|
|
bus_write_4(res, OHCI_COMMAND_STATUS, OHCI_OCR);
|
|
|
|
for (i = 0; (i < 100) && (ctl & OHCI_IR); i++) {
|
|
|
|
DELAY(1000);
|
|
|
|
ctl = bus_read_4(res, OHCI_CONTROL);
|
|
|
|
}
|
|
|
|
if (ctl & OHCI_IR) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("ohci early: "
|
|
|
|
"SMM does not respond, resetting\n");
|
|
|
|
bus_write_4(res, OHCI_CONTROL, OHCI_HCFS_RESET);
|
|
|
|
}
|
2009-11-25 20:50:43 +00:00
|
|
|
/* Disable interrupts */
|
|
|
|
bus_write_4(res, OHCI_INTERRUPT_DISABLE, OHCI_ALL_INTRS);
|
2009-10-15 20:07:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bus_release_resource(self, SYS_RES_MEMORY, rid, res);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Perform early UHCI takeover from SMM. */
|
|
|
|
static void
|
|
|
|
uhci_early_takeover(device_t self)
|
|
|
|
{
|
2009-11-25 20:50:43 +00:00
|
|
|
struct resource *res;
|
|
|
|
int rid;
|
|
|
|
|
2009-10-15 20:07:08 +00:00
|
|
|
/*
|
|
|
|
* Set the PIRQD enable bit and switch off all the others. We don't
|
|
|
|
* want legacy support to interfere with us XXX Does this also mean
|
|
|
|
* that the BIOS won't touch the keyboard anymore if it is connected
|
|
|
|
* to the ports of the root hub?
|
|
|
|
*/
|
|
|
|
pci_write_config(self, PCI_LEGSUP, PCI_LEGSUP_USBPIRQDEN, 2);
|
2009-11-25 20:50:43 +00:00
|
|
|
|
|
|
|
/* Disable interrupts */
|
|
|
|
rid = PCI_UHCI_BASE_REG;
|
|
|
|
res = bus_alloc_resource_any(self, SYS_RES_IOPORT, &rid, RF_ACTIVE);
|
|
|
|
if (res != NULL) {
|
|
|
|
bus_write_2(res, UHCI_INTR, 0);
|
|
|
|
bus_release_resource(self, SYS_RES_IOPORT, rid, res);
|
|
|
|
}
|
2009-10-15 20:07:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Perform early EHCI takeover from SMM. */
|
|
|
|
static void
|
|
|
|
ehci_early_takeover(device_t self)
|
|
|
|
{
|
|
|
|
struct resource *res;
|
|
|
|
uint32_t cparams;
|
|
|
|
uint32_t eec;
|
|
|
|
uint8_t eecp;
|
|
|
|
uint8_t bios_sem;
|
2009-11-25 20:50:43 +00:00
|
|
|
uint8_t offs;
|
2009-10-15 20:07:08 +00:00
|
|
|
int rid;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
rid = PCIR_BAR(0);
|
|
|
|
res = bus_alloc_resource_any(self, SYS_RES_MEMORY, &rid, RF_ACTIVE);
|
|
|
|
if (res == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
cparams = bus_read_4(res, EHCI_HCCPARAMS);
|
|
|
|
|
|
|
|
/* Synchronise with the BIOS if it owns the controller. */
|
|
|
|
for (eecp = EHCI_HCC_EECP(cparams); eecp != 0;
|
|
|
|
eecp = EHCI_EECP_NEXT(eec)) {
|
|
|
|
eec = pci_read_config(self, eecp, 4);
|
|
|
|
if (EHCI_EECP_ID(eec) != EHCI_EC_LEGSUP) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
bios_sem = pci_read_config(self, eecp +
|
|
|
|
EHCI_LEGSUP_BIOS_SEM, 1);
|
|
|
|
if (bios_sem == 0) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (bootverbose)
|
|
|
|
printf("ehci early: "
|
|
|
|
"SMM active, request owner change\n");
|
|
|
|
|
|
|
|
pci_write_config(self, eecp + EHCI_LEGSUP_OS_SEM, 1, 1);
|
|
|
|
|
|
|
|
for (i = 0; (i < 100) && (bios_sem != 0); i++) {
|
|
|
|
DELAY(1000);
|
|
|
|
bios_sem = pci_read_config(self, eecp +
|
|
|
|
EHCI_LEGSUP_BIOS_SEM, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bios_sem != 0) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("ehci early: "
|
|
|
|
"SMM does not respond\n");
|
|
|
|
}
|
2009-11-25 20:50:43 +00:00
|
|
|
/* Disable interrupts */
|
2010-10-25 15:51:43 +00:00
|
|
|
offs = EHCI_CAPLENGTH(bus_read_4(res, EHCI_CAPLEN_HCIVERSION));
|
2009-11-25 20:50:43 +00:00
|
|
|
bus_write_4(res, offs + EHCI_USBINTR, 0);
|
2009-10-15 20:07:08 +00:00
|
|
|
}
|
|
|
|
bus_release_resource(self, SYS_RES_MEMORY, rid, res);
|
|
|
|
}
|
|
|
|
|
2011-07-22 15:37:23 +00:00
|
|
|
/* Perform early XHCI takeover from SMM. */
|
|
|
|
static void
|
|
|
|
xhci_early_takeover(device_t self)
|
|
|
|
{
|
|
|
|
struct resource *res;
|
|
|
|
uint32_t cparams;
|
|
|
|
uint32_t eec;
|
|
|
|
uint8_t eecp;
|
|
|
|
uint8_t bios_sem;
|
|
|
|
uint8_t offs;
|
|
|
|
int rid;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
rid = PCIR_BAR(0);
|
|
|
|
res = bus_alloc_resource_any(self, SYS_RES_MEMORY, &rid, RF_ACTIVE);
|
|
|
|
if (res == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
cparams = bus_read_4(res, XHCI_HCSPARAMS0);
|
|
|
|
|
|
|
|
eec = -1;
|
|
|
|
|
|
|
|
/* Synchronise with the BIOS if it owns the controller. */
|
|
|
|
for (eecp = XHCI_HCS0_XECP(cparams) << 2; eecp != 0 && XHCI_XECP_NEXT(eec);
|
|
|
|
eecp += XHCI_XECP_NEXT(eec) << 2) {
|
|
|
|
eec = bus_read_4(res, eecp);
|
|
|
|
|
|
|
|
if (XHCI_XECP_ID(eec) != XHCI_ID_USB_LEGACY)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
bios_sem = bus_read_1(res, eecp + XHCI_XECP_BIOS_SEM);
|
|
|
|
if (bios_sem == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (bootverbose)
|
|
|
|
printf("xhci early: "
|
|
|
|
"SMM active, request owner change\n");
|
|
|
|
|
|
|
|
bus_write_1(res, eecp + XHCI_XECP_OS_SEM, 1);
|
|
|
|
|
|
|
|
/* wait a maximum of 5 second */
|
|
|
|
|
|
|
|
for (i = 0; (i < 5000) && (bios_sem != 0); i++) {
|
|
|
|
DELAY(1000);
|
|
|
|
bios_sem = bus_read_1(res, eecp +
|
|
|
|
XHCI_XECP_BIOS_SEM);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (bios_sem != 0) {
|
|
|
|
if (bootverbose)
|
|
|
|
printf("xhci early: "
|
|
|
|
"SMM does not respond\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Disable interrupts */
|
|
|
|
offs = bus_read_1(res, XHCI_CAPLENGTH);
|
|
|
|
bus_write_4(res, offs + XHCI_USBCMD, 0);
|
|
|
|
bus_read_4(res, offs + XHCI_USBSTS);
|
|
|
|
}
|
|
|
|
bus_release_resource(self, SYS_RES_MEMORY, rid, res);
|
|
|
|
}
|
|
|
|
|
2005-12-30 19:28:26 +00:00
|
|
|
void
|
|
|
|
pci_add_resources(device_t bus, device_t dev, int force, uint32_t prefetchmask)
|
1999-10-28 08:06:59 +00:00
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(dev);
|
2000-08-28 21:48:13 +00:00
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
1999-10-28 08:06:59 +00:00
|
|
|
struct resource_list *rl = &dinfo->resources;
|
|
|
|
struct pci_quirk *q;
|
2009-04-14 18:32:37 +00:00
|
|
|
int i;
|
2004-04-21 20:19:56 +00:00
|
|
|
|
2004-06-29 20:25:43 +00:00
|
|
|
/* ATA devices needs special map treatment */
|
|
|
|
if ((pci_get_class(dev) == PCIC_STORAGE) &&
|
|
|
|
(pci_get_subclass(dev) == PCIS_STORAGE_IDE) &&
|
2007-02-17 16:56:39 +00:00
|
|
|
((pci_get_progif(dev) & PCIP_STORAGE_IDE_MASTERDEV) ||
|
|
|
|
(!pci_read_config(dev, PCIR_BAR(0), 4) &&
|
|
|
|
!pci_read_config(dev, PCIR_BAR(2), 4))) )
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_ata_maps(bus, dev, rl, force, prefetchmask);
|
2004-04-21 20:19:56 +00:00
|
|
|
else
|
|
|
|
for (i = 0; i < cfg->nummaps;)
|
2009-04-14 18:32:37 +00:00
|
|
|
i += pci_add_map(bus, dev, PCIR_BAR(i), rl, force,
|
|
|
|
prefetchmask & (1 << i));
|
1999-10-28 08:06:59 +00:00
|
|
|
|
2005-12-30 19:28:26 +00:00
|
|
|
/*
|
|
|
|
* Add additional, quirked resources.
|
|
|
|
*/
|
1999-10-28 08:06:59 +00:00
|
|
|
for (q = &pci_quirks[0]; q->devid; q++) {
|
|
|
|
if (q->devid == ((cfg->device << 16) | cfg->vendor)
|
|
|
|
&& q->type == PCI_QUIRK_MAP_REG)
|
2009-04-14 18:32:37 +00:00
|
|
|
pci_add_map(bus, dev, q->arg1, rl, force, 0);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
1999-10-28 08:06:59 +00:00
|
|
|
|
2002-06-01 05:48:58 +00:00
|
|
|
if (cfg->intpin > 0 && PCI_INTERRUPT_VALID(cfg->intline)) {
|
2006-01-01 21:04:31 +00:00
|
|
|
#ifdef __PCI_REROUTE_INTERRUPT
|
2001-10-05 10:33:42 +00:00
|
|
|
/*
|
2003-06-07 15:00:19 +00:00
|
|
|
* Try to re-route interrupts. Sometimes the BIOS or
|
|
|
|
* firmware may leave bogus values in these registers.
|
|
|
|
* If the re-route fails, then just stick with what we
|
|
|
|
* have.
|
2001-10-05 10:33:42 +00:00
|
|
|
*/
|
2005-09-29 15:04:41 +00:00
|
|
|
pci_assign_interrupt(bus, dev, 1);
|
|
|
|
#else
|
|
|
|
pci_assign_interrupt(bus, dev, 0);
|
2001-10-05 10:33:42 +00:00
|
|
|
#endif
|
|
|
|
}
|
2009-10-15 20:07:08 +00:00
|
|
|
|
|
|
|
if (pci_usb_takeover && pci_get_class(dev) == PCIC_SERIALBUS &&
|
|
|
|
pci_get_subclass(dev) == PCIS_SERIALBUS_USB) {
|
2011-07-22 15:37:23 +00:00
|
|
|
if (pci_get_progif(dev) == PCIP_SERIALBUS_USB_XHCI)
|
|
|
|
xhci_early_takeover(dev);
|
|
|
|
else if (pci_get_progif(dev) == PCIP_SERIALBUS_USB_EHCI)
|
2009-10-15 20:07:08 +00:00
|
|
|
ehci_early_takeover(dev);
|
|
|
|
else if (pci_get_progif(dev) == PCIP_SERIALBUS_USB_OHCI)
|
|
|
|
ohci_early_takeover(dev);
|
|
|
|
else if (pci_get_progif(dev) == PCIP_SERIALBUS_USB_UHCI)
|
|
|
|
uhci_early_takeover(dev);
|
|
|
|
}
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2002-08-26 15:23:52 +00:00
|
|
|
void
|
2007-09-30 11:05:18 +00:00
|
|
|
pci_add_children(device_t dev, int domain, int busno, size_t dinfo_size)
|
1999-04-16 21:22:55 +00:00
|
|
|
{
|
2006-12-14 16:53:48 +00:00
|
|
|
#define REG(n, w) PCIB_READ_CONFIG(pcib, busno, s, f, n, w)
|
2000-08-28 21:48:13 +00:00
|
|
|
device_t pcib = device_get_parent(dev);
|
2002-08-26 15:23:52 +00:00
|
|
|
struct pci_devinfo *dinfo;
|
2000-08-28 21:48:13 +00:00
|
|
|
int maxslots;
|
2002-08-26 15:23:52 +00:00
|
|
|
int s, f, pcifunchigh;
|
2003-08-22 03:11:53 +00:00
|
|
|
uint8_t hdrtype;
|
1999-05-20 15:33:33 +00:00
|
|
|
|
2002-08-26 15:23:52 +00:00
|
|
|
KASSERT(dinfo_size >= sizeof(struct pci_devinfo),
|
|
|
|
("dinfo_size too small"));
|
2006-11-07 18:55:51 +00:00
|
|
|
maxslots = PCIB_MAXSLOTS(pcib);
|
2000-08-28 21:48:13 +00:00
|
|
|
for (s = 0; s <= maxslots; s++) {
|
2002-08-26 15:23:52 +00:00
|
|
|
pcifunchigh = 0;
|
2003-06-22 02:26:17 +00:00
|
|
|
f = 0;
|
2005-10-25 06:53:45 +00:00
|
|
|
DELAY(1);
|
2003-08-28 21:22:25 +00:00
|
|
|
hdrtype = REG(PCIR_HDRTYPE, 1);
|
|
|
|
if ((hdrtype & PCIM_HDRTYPE) > PCI_MAXHDRTYPE)
|
2003-06-22 02:26:17 +00:00
|
|
|
continue;
|
|
|
|
if (hdrtype & PCIM_MFDEV)
|
|
|
|
pcifunchigh = PCI_FUNCMAX;
|
2000-08-28 21:48:13 +00:00
|
|
|
for (f = 0; f <= pcifunchigh; f++) {
|
2007-09-30 11:05:18 +00:00
|
|
|
dinfo = pci_read_device(pcib, domain, busno, s, f,
|
|
|
|
dinfo_size);
|
1999-04-16 21:22:55 +00:00
|
|
|
if (dinfo != NULL) {
|
2002-08-26 15:23:52 +00:00
|
|
|
pci_add_child(dev, dinfo);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-06-22 02:26:17 +00:00
|
|
|
#undef REG
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2002-08-26 15:23:52 +00:00
|
|
|
void
|
|
|
|
pci_add_child(device_t bus, struct pci_devinfo *dinfo)
|
|
|
|
{
|
|
|
|
dinfo->cfg.dev = device_add_child(bus, NULL, -1);
|
|
|
|
device_set_ivars(dinfo->cfg.dev, dinfo);
|
2005-03-18 05:19:50 +00:00
|
|
|
resource_list_init(&dinfo->resources);
|
2004-04-09 15:44:34 +00:00
|
|
|
pci_cfg_save(dinfo->cfg.dev, dinfo, 0);
|
|
|
|
pci_cfg_restore(dinfo->cfg.dev, dinfo);
|
2002-08-26 15:23:52 +00:00
|
|
|
pci_print_verbose(dinfo);
|
2005-12-30 19:28:26 +00:00
|
|
|
pci_add_resources(bus, dinfo->cfg.dev, 0, 0);
|
2002-08-26 15:23:52 +00:00
|
|
|
}
|
|
|
|
|
1999-04-16 21:22:55 +00:00
|
|
|
static int
|
2000-08-28 21:48:13 +00:00
|
|
|
pci_probe(device_t dev)
|
1999-04-16 21:22:55 +00:00
|
|
|
{
|
|
|
|
|
1999-08-23 20:59:21 +00:00
|
|
|
device_set_desc(dev, "PCI bus");
|
2000-08-28 21:48:13 +00:00
|
|
|
|
2002-08-26 15:23:52 +00:00
|
|
|
/* Allow other subclasses to override this driver. */
|
2009-01-20 00:05:43 +00:00
|
|
|
return (BUS_PROBE_GENERIC);
|
2002-08-26 15:23:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
pci_attach(device_t dev)
|
|
|
|
{
|
2007-09-30 11:05:18 +00:00
|
|
|
int busno, domain;
|
2000-08-28 21:48:13 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Since there can be multiple independantly numbered PCI
|
2006-05-11 22:13:21 +00:00
|
|
|
* busses on systems with multiple PCI domains, we can't use
|
|
|
|
* the unit number to decide which bus we are probing. We ask
|
2007-09-30 11:05:18 +00:00
|
|
|
* the parent pcib what our domain and bus numbers are.
|
2000-08-28 21:48:13 +00:00
|
|
|
*/
|
2007-09-30 11:05:18 +00:00
|
|
|
domain = pcib_get_domain(dev);
|
2000-10-09 00:43:45 +00:00
|
|
|
busno = pcib_get_bus(dev);
|
2002-08-26 15:23:52 +00:00
|
|
|
if (bootverbose)
|
2007-09-30 11:05:18 +00:00
|
|
|
device_printf(dev, "domain=%d, physical bus=%d\n",
|
|
|
|
domain, busno);
|
|
|
|
pci_add_children(dev, domain, busno, sizeof(struct pci_devinfo));
|
2002-08-26 15:23:52 +00:00
|
|
|
return (bus_generic_attach(dev));
|
|
|
|
}
|
|
|
|
|
2010-10-15 21:39:51 +00:00
|
|
|
static void
|
|
|
|
pci_set_power_children(device_t dev, device_t *devlist, int numdevs,
|
|
|
|
int state)
|
|
|
|
{
|
|
|
|
device_t child, pcib;
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
int dstate, i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the device to the given state. If the firmware suggests
|
|
|
|
* a different power state, use it instead. If power management
|
|
|
|
* is not present, the firmware is responsible for managing
|
|
|
|
* device power. Skip children who aren't attached since they
|
2010-10-19 17:15:22 +00:00
|
|
|
* are handled separately.
|
2010-10-15 21:39:51 +00:00
|
|
|
*/
|
|
|
|
pcib = device_get_parent(dev);
|
|
|
|
for (i = 0; i < numdevs; i++) {
|
|
|
|
child = devlist[i];
|
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
dstate = state;
|
|
|
|
if (device_is_attached(child) &&
|
|
|
|
PCIB_POWER_FOR_SLEEP(pcib, dev, &dstate) == 0)
|
|
|
|
pci_set_powerstate(child, dstate);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
int
|
|
|
|
pci_suspend(device_t dev)
|
|
|
|
{
|
2010-10-15 21:39:51 +00:00
|
|
|
device_t child, *devlist;
|
2004-04-09 15:44:34 +00:00
|
|
|
struct pci_devinfo *dinfo;
|
2010-10-15 21:39:51 +00:00
|
|
|
int error, i, numdevs;
|
2004-04-09 15:44:34 +00:00
|
|
|
|
|
|
|
/*
|
2004-12-02 08:07:12 +00:00
|
|
|
* Save the PCI configuration space for each child and set the
|
|
|
|
* device in the appropriate power state for this sleep state.
|
2004-04-09 15:44:34 +00:00
|
|
|
*/
|
2008-08-23 07:23:52 +00:00
|
|
|
if ((error = device_get_children(dev, &devlist, &numdevs)) != 0)
|
|
|
|
return (error);
|
2004-04-09 15:44:34 +00:00
|
|
|
for (i = 0; i < numdevs; i++) {
|
|
|
|
child = devlist[i];
|
2010-10-15 21:41:59 +00:00
|
|
|
dinfo = device_get_ivars(child);
|
2004-04-09 15:44:34 +00:00
|
|
|
pci_cfg_save(child, dinfo, 0);
|
|
|
|
}
|
2004-12-02 08:07:12 +00:00
|
|
|
|
|
|
|
/* Suspend devices before potentially powering them down. */
|
|
|
|
error = bus_generic_suspend(dev);
|
2005-03-15 22:53:31 +00:00
|
|
|
if (error) {
|
|
|
|
free(devlist, M_TEMP);
|
2004-12-02 08:07:12 +00:00
|
|
|
return (error);
|
2005-03-15 22:53:31 +00:00
|
|
|
}
|
2010-10-20 16:47:09 +00:00
|
|
|
if (pci_do_power_suspend)
|
|
|
|
pci_set_power_children(dev, devlist, numdevs,
|
|
|
|
PCI_POWERSTATE_D3);
|
2004-04-09 15:44:34 +00:00
|
|
|
free(devlist, M_TEMP);
|
2004-12-02 08:07:12 +00:00
|
|
|
return (0);
|
2004-04-09 15:44:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
pci_resume(device_t dev)
|
|
|
|
{
|
2010-10-15 21:39:51 +00:00
|
|
|
device_t child, *devlist;
|
2004-04-09 15:44:34 +00:00
|
|
|
struct pci_devinfo *dinfo;
|
2010-10-15 21:39:51 +00:00
|
|
|
int error, i, numdevs;
|
2004-04-09 15:44:34 +00:00
|
|
|
|
|
|
|
/*
|
2004-12-02 08:07:12 +00:00
|
|
|
* Set each child to D0 and restore its PCI configuration space.
|
2004-04-09 15:44:34 +00:00
|
|
|
*/
|
2008-08-23 07:23:52 +00:00
|
|
|
if ((error = device_get_children(dev, &devlist, &numdevs)) != 0)
|
|
|
|
return (error);
|
2010-10-19 17:05:51 +00:00
|
|
|
if (pci_do_power_resume)
|
|
|
|
pci_set_power_children(dev, devlist, numdevs,
|
|
|
|
PCI_POWERSTATE_D0);
|
2010-10-15 21:39:51 +00:00
|
|
|
|
|
|
|
/* Now the device is powered up, restore its config space. */
|
2004-04-09 15:44:34 +00:00
|
|
|
for (i = 0; i < numdevs; i++) {
|
|
|
|
child = devlist[i];
|
2010-10-15 21:39:51 +00:00
|
|
|
dinfo = device_get_ivars(child);
|
2004-12-02 08:07:12 +00:00
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
pci_cfg_restore(child, dinfo);
|
2010-05-22 03:19:30 +00:00
|
|
|
if (!device_is_attached(child))
|
|
|
|
pci_cfg_save(child, dinfo, 1);
|
2004-04-09 15:44:34 +00:00
|
|
|
}
|
2010-11-22 21:58:00 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Resume critical devices first, then everything else later.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < numdevs; i++) {
|
|
|
|
child = devlist[i];
|
|
|
|
switch (pci_get_class(child)) {
|
|
|
|
case PCIC_DISPLAY:
|
|
|
|
case PCIC_MEMORY:
|
|
|
|
case PCIC_BRIDGE:
|
|
|
|
case PCIC_BASEPERIPH:
|
|
|
|
DEVICE_RESUME(child);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
for (i = 0; i < numdevs; i++) {
|
|
|
|
child = devlist[i];
|
|
|
|
switch (pci_get_class(child)) {
|
|
|
|
case PCIC_DISPLAY:
|
|
|
|
case PCIC_MEMORY:
|
|
|
|
case PCIC_BRIDGE:
|
|
|
|
case PCIC_BASEPERIPH:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
DEVICE_RESUME(child);
|
|
|
|
}
|
|
|
|
}
|
2004-04-09 15:44:34 +00:00
|
|
|
free(devlist, M_TEMP);
|
2010-11-22 21:58:00 +00:00
|
|
|
return (0);
|
2004-04-09 15:44:34 +00:00
|
|
|
}
|
|
|
|
|
2002-09-04 03:13:16 +00:00
|
|
|
static void
|
2002-08-26 15:23:52 +00:00
|
|
|
pci_load_vendor_data(void)
|
|
|
|
{
|
2011-02-13 19:26:51 +00:00
|
|
|
caddr_t data;
|
|
|
|
void *ptr;
|
|
|
|
size_t sz;
|
|
|
|
|
|
|
|
data = preload_search_by_type("pci_vendor_data");
|
|
|
|
if (data != NULL) {
|
|
|
|
ptr = preload_fetch_addr(data);
|
|
|
|
sz = preload_fetch_size(data);
|
|
|
|
if (ptr != NULL && sz != 0) {
|
|
|
|
pci_vendordata = ptr;
|
|
|
|
pci_vendordata_size = sz;
|
|
|
|
/* terminate the database */
|
|
|
|
pci_vendordata[pci_vendordata_size] = '\n';
|
|
|
|
}
|
1999-08-23 20:59:21 +00:00
|
|
|
}
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
void
|
|
|
|
pci_driver_added(device_t dev, driver_t *driver)
|
|
|
|
{
|
|
|
|
int numdevs;
|
|
|
|
device_t *devlist;
|
|
|
|
device_t child;
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
int i;
|
|
|
|
|
2004-05-21 06:03:26 +00:00
|
|
|
if (bootverbose)
|
|
|
|
device_printf(dev, "driver added\n");
|
2004-04-09 15:44:34 +00:00
|
|
|
DEVICE_IDENTIFY(driver, dev);
|
2008-08-23 07:23:52 +00:00
|
|
|
if (device_get_children(dev, &devlist, &numdevs) != 0)
|
|
|
|
return;
|
2004-04-09 15:44:34 +00:00
|
|
|
for (i = 0; i < numdevs; i++) {
|
|
|
|
child = devlist[i];
|
|
|
|
if (device_get_state(child) != DS_NOTPRESENT)
|
|
|
|
continue;
|
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
pci_print_verbose(dinfo);
|
2004-05-21 06:03:26 +00:00
|
|
|
if (bootverbose)
|
2009-06-01 20:30:00 +00:00
|
|
|
pci_printf(&dinfo->cfg, "reprobing on driver added\n");
|
2004-04-09 15:44:34 +00:00
|
|
|
pci_cfg_restore(child, dinfo);
|
|
|
|
if (device_probe_and_attach(child) != 0)
|
|
|
|
pci_cfg_save(child, dinfo, 1);
|
|
|
|
}
|
|
|
|
free(devlist, M_TEMP);
|
|
|
|
}
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
int
|
|
|
|
pci_setup_intr(device_t dev, device_t child, struct resource *irq, int flags,
|
|
|
|
driver_filter_t *filter, driver_intr_t *intr, void *arg, void **cookiep)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
struct msix_table_entry *mte;
|
|
|
|
struct msix_vector *mv;
|
|
|
|
uint64_t addr;
|
|
|
|
uint32_t data;
|
|
|
|
void *cookie;
|
|
|
|
int error, rid;
|
|
|
|
|
|
|
|
error = bus_generic_setup_intr(dev, child, irq, flags, filter, intr,
|
|
|
|
arg, &cookie);
|
|
|
|
if (error)
|
|
|
|
return (error);
|
|
|
|
|
2009-03-04 18:23:48 +00:00
|
|
|
/* If this is not a direct child, just bail out. */
|
|
|
|
if (device_get_parent(child) != dev) {
|
|
|
|
*cookiep = cookie;
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
rid = rman_get_rid(irq);
|
2009-03-04 18:23:48 +00:00
|
|
|
if (rid == 0) {
|
|
|
|
/* Make sure that INTx is enabled */
|
|
|
|
pci_clear_command_bit(dev, child, PCIM_CMD_INTxDIS);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Check to see if the interrupt is MSI or MSI-X.
|
|
|
|
* Ask our parent to map the MSI and give
|
|
|
|
* us the address and data register values.
|
|
|
|
* If we fail for some reason, teardown the
|
|
|
|
* interrupt handler.
|
|
|
|
*/
|
2007-05-02 17:50:36 +00:00
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
if (dinfo->cfg.msi.msi_alloc > 0) {
|
|
|
|
if (dinfo->cfg.msi.msi_addr == 0) {
|
|
|
|
KASSERT(dinfo->cfg.msi.msi_handlers == 0,
|
|
|
|
("MSI has handlers, but vectors not mapped"));
|
|
|
|
error = PCIB_MAP_MSI(device_get_parent(dev),
|
|
|
|
child, rman_get_start(irq), &addr, &data);
|
|
|
|
if (error)
|
|
|
|
goto bad;
|
|
|
|
dinfo->cfg.msi.msi_addr = addr;
|
|
|
|
dinfo->cfg.msi.msi_data = data;
|
|
|
|
}
|
2009-06-22 20:08:06 +00:00
|
|
|
if (dinfo->cfg.msi.msi_handlers == 0)
|
|
|
|
pci_enable_msi(child, dinfo->cfg.msi.msi_addr,
|
|
|
|
dinfo->cfg.msi.msi_data);
|
2007-05-02 17:50:36 +00:00
|
|
|
dinfo->cfg.msi.msi_handlers++;
|
|
|
|
} else {
|
|
|
|
KASSERT(dinfo->cfg.msix.msix_alloc > 0,
|
|
|
|
("No MSI or MSI-X interrupts allocated"));
|
|
|
|
KASSERT(rid <= dinfo->cfg.msix.msix_table_len,
|
|
|
|
("MSI-X index too high"));
|
|
|
|
mte = &dinfo->cfg.msix.msix_table[rid - 1];
|
|
|
|
KASSERT(mte->mte_vector != 0, ("no message vector"));
|
|
|
|
mv = &dinfo->cfg.msix.msix_vectors[mte->mte_vector - 1];
|
|
|
|
KASSERT(mv->mv_irq == rman_get_start(irq),
|
|
|
|
("IRQ mismatch"));
|
|
|
|
if (mv->mv_address == 0) {
|
|
|
|
KASSERT(mte->mte_handlers == 0,
|
|
|
|
("MSI-X table entry has handlers, but vector not mapped"));
|
|
|
|
error = PCIB_MAP_MSI(device_get_parent(dev),
|
|
|
|
child, rman_get_start(irq), &addr, &data);
|
|
|
|
if (error)
|
|
|
|
goto bad;
|
|
|
|
mv->mv_address = addr;
|
|
|
|
mv->mv_data = data;
|
|
|
|
}
|
|
|
|
if (mte->mte_handlers == 0) {
|
|
|
|
pci_enable_msix(child, rid - 1, mv->mv_address,
|
|
|
|
mv->mv_data);
|
|
|
|
pci_unmask_msix(child, rid - 1);
|
|
|
|
}
|
|
|
|
mte->mte_handlers++;
|
|
|
|
}
|
2009-03-04 18:23:48 +00:00
|
|
|
|
|
|
|
/* Make sure that INTx is disabled if we are using MSI/MSIX */
|
2009-03-02 19:00:41 +00:00
|
|
|
pci_set_command_bit(dev, child, PCIM_CMD_INTxDIS);
|
2007-05-02 17:50:36 +00:00
|
|
|
bad:
|
|
|
|
if (error) {
|
|
|
|
(void)bus_generic_teardown_intr(dev, child, irq,
|
|
|
|
cookie);
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
*cookiep = cookie;
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
pci_teardown_intr(device_t dev, device_t child, struct resource *irq,
|
|
|
|
void *cookie)
|
|
|
|
{
|
|
|
|
struct msix_table_entry *mte;
|
|
|
|
struct resource_list_entry *rle;
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
int error, rid;
|
|
|
|
|
|
|
|
if (irq == NULL || !(rman_get_flags(irq) & RF_ACTIVE))
|
|
|
|
return (EINVAL);
|
2009-03-04 18:23:48 +00:00
|
|
|
|
|
|
|
/* If this isn't a direct child, just bail out */
|
|
|
|
if (device_get_parent(child) != dev)
|
|
|
|
return(bus_generic_teardown_intr(dev, child, irq, cookie));
|
|
|
|
|
2007-05-02 17:50:36 +00:00
|
|
|
rid = rman_get_rid(irq);
|
2009-03-06 11:24:42 +00:00
|
|
|
if (rid == 0) {
|
2009-03-04 18:23:48 +00:00
|
|
|
/* Mask INTx */
|
|
|
|
pci_set_command_bit(dev, child, PCIM_CMD_INTxDIS);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Check to see if the interrupt is MSI or MSI-X. If so,
|
|
|
|
* decrement the appropriate handlers count and mask the
|
|
|
|
* MSI-X message, or disable MSI messages if the count
|
|
|
|
* drops to 0.
|
|
|
|
*/
|
2007-05-02 17:50:36 +00:00
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
rle = resource_list_find(&dinfo->resources, SYS_RES_IRQ, rid);
|
|
|
|
if (rle->res != irq)
|
|
|
|
return (EINVAL);
|
|
|
|
if (dinfo->cfg.msi.msi_alloc > 0) {
|
|
|
|
KASSERT(rid <= dinfo->cfg.msi.msi_alloc,
|
|
|
|
("MSI-X index too high"));
|
|
|
|
if (dinfo->cfg.msi.msi_handlers == 0)
|
|
|
|
return (EINVAL);
|
|
|
|
dinfo->cfg.msi.msi_handlers--;
|
|
|
|
if (dinfo->cfg.msi.msi_handlers == 0)
|
|
|
|
pci_disable_msi(child);
|
|
|
|
} else {
|
|
|
|
KASSERT(dinfo->cfg.msix.msix_alloc > 0,
|
|
|
|
("No MSI or MSI-X interrupts allocated"));
|
|
|
|
KASSERT(rid <= dinfo->cfg.msix.msix_table_len,
|
|
|
|
("MSI-X index too high"));
|
|
|
|
mte = &dinfo->cfg.msix.msix_table[rid - 1];
|
|
|
|
if (mte->mte_handlers == 0)
|
|
|
|
return (EINVAL);
|
|
|
|
mte->mte_handlers--;
|
|
|
|
if (mte->mte_handlers == 0)
|
|
|
|
pci_mask_msix(child, rid - 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
error = bus_generic_teardown_intr(dev, child, irq, cookie);
|
2009-03-04 18:23:48 +00:00
|
|
|
if (rid > 0)
|
2007-05-02 17:50:36 +00:00
|
|
|
KASSERT(error == 0,
|
|
|
|
("%s: generic teardown failed for MSI/MSI-X", __func__));
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
int
|
1999-04-16 21:22:55 +00:00
|
|
|
pci_print_child(device_t dev, device_t child)
|
|
|
|
{
|
1999-05-08 20:28:01 +00:00
|
|
|
struct pci_devinfo *dinfo;
|
2000-01-08 10:12:21 +00:00
|
|
|
struct resource_list *rl;
|
1999-07-29 01:03:04 +00:00
|
|
|
int retval = 0;
|
1999-05-08 20:28:01 +00:00
|
|
|
|
|
|
|
dinfo = device_get_ivars(child);
|
2000-01-08 10:12:21 +00:00
|
|
|
rl = &dinfo->resources;
|
1999-07-29 01:03:04 +00:00
|
|
|
|
|
|
|
retval += bus_print_child_header(dev, child);
|
|
|
|
|
2001-12-21 21:49:57 +00:00
|
|
|
retval += resource_list_print_type(rl, "port", SYS_RES_IOPORT, "%#lx");
|
|
|
|
retval += resource_list_print_type(rl, "mem", SYS_RES_MEMORY, "%#lx");
|
|
|
|
retval += resource_list_print_type(rl, "irq", SYS_RES_IRQ, "%ld");
|
2000-01-08 10:12:21 +00:00
|
|
|
if (device_get_flags(dev))
|
|
|
|
retval += printf(" flags %#x", device_get_flags(dev));
|
|
|
|
|
1999-07-29 01:03:04 +00:00
|
|
|
retval += printf(" at device %d.%d", pci_get_slot(child),
|
2002-06-01 03:41:02 +00:00
|
|
|
pci_get_function(child));
|
1999-07-29 01:03:04 +00:00
|
|
|
|
|
|
|
retval += bus_print_child_footer(dev, child);
|
|
|
|
|
|
|
|
return (retval);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
static struct
|
|
|
|
{
|
|
|
|
int class;
|
|
|
|
int subclass;
|
|
|
|
char *desc;
|
|
|
|
} pci_nomatch_tab[] = {
|
|
|
|
{PCIC_OLD, -1, "old"},
|
|
|
|
{PCIC_OLD, PCIS_OLD_NONVGA, "non-VGA display device"},
|
|
|
|
{PCIC_OLD, PCIS_OLD_VGA, "VGA-compatible display device"},
|
|
|
|
{PCIC_STORAGE, -1, "mass storage"},
|
|
|
|
{PCIC_STORAGE, PCIS_STORAGE_SCSI, "SCSI"},
|
|
|
|
{PCIC_STORAGE, PCIS_STORAGE_IDE, "ATA"},
|
|
|
|
{PCIC_STORAGE, PCIS_STORAGE_FLOPPY, "floppy disk"},
|
|
|
|
{PCIC_STORAGE, PCIS_STORAGE_IPI, "IPI"},
|
|
|
|
{PCIC_STORAGE, PCIS_STORAGE_RAID, "RAID"},
|
2008-11-13 19:57:33 +00:00
|
|
|
{PCIC_STORAGE, PCIS_STORAGE_ATA_ADMA, "ATA (ADMA)"},
|
|
|
|
{PCIC_STORAGE, PCIS_STORAGE_SATA, "SATA"},
|
|
|
|
{PCIC_STORAGE, PCIS_STORAGE_SAS, "SAS"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{PCIC_NETWORK, -1, "network"},
|
|
|
|
{PCIC_NETWORK, PCIS_NETWORK_ETHERNET, "ethernet"},
|
|
|
|
{PCIC_NETWORK, PCIS_NETWORK_TOKENRING, "token ring"},
|
|
|
|
{PCIC_NETWORK, PCIS_NETWORK_FDDI, "fddi"},
|
|
|
|
{PCIC_NETWORK, PCIS_NETWORK_ATM, "ATM"},
|
2005-03-26 20:31:09 +00:00
|
|
|
{PCIC_NETWORK, PCIS_NETWORK_ISDN, "ISDN"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{PCIC_DISPLAY, -1, "display"},
|
|
|
|
{PCIC_DISPLAY, PCIS_DISPLAY_VGA, "VGA"},
|
|
|
|
{PCIC_DISPLAY, PCIS_DISPLAY_XGA, "XGA"},
|
2005-03-26 20:31:09 +00:00
|
|
|
{PCIC_DISPLAY, PCIS_DISPLAY_3D, "3D"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{PCIC_MULTIMEDIA, -1, "multimedia"},
|
|
|
|
{PCIC_MULTIMEDIA, PCIS_MULTIMEDIA_VIDEO, "video"},
|
|
|
|
{PCIC_MULTIMEDIA, PCIS_MULTIMEDIA_AUDIO, "audio"},
|
2005-03-26 20:31:09 +00:00
|
|
|
{PCIC_MULTIMEDIA, PCIS_MULTIMEDIA_TELE, "telephony"},
|
2008-10-21 21:53:55 +00:00
|
|
|
{PCIC_MULTIMEDIA, PCIS_MULTIMEDIA_HDA, "HDA"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{PCIC_MEMORY, -1, "memory"},
|
|
|
|
{PCIC_MEMORY, PCIS_MEMORY_RAM, "RAM"},
|
|
|
|
{PCIC_MEMORY, PCIS_MEMORY_FLASH, "flash"},
|
|
|
|
{PCIC_BRIDGE, -1, "bridge"},
|
|
|
|
{PCIC_BRIDGE, PCIS_BRIDGE_HOST, "HOST-PCI"},
|
|
|
|
{PCIC_BRIDGE, PCIS_BRIDGE_ISA, "PCI-ISA"},
|
|
|
|
{PCIC_BRIDGE, PCIS_BRIDGE_EISA, "PCI-EISA"},
|
|
|
|
{PCIC_BRIDGE, PCIS_BRIDGE_MCA, "PCI-MCA"},
|
|
|
|
{PCIC_BRIDGE, PCIS_BRIDGE_PCI, "PCI-PCI"},
|
|
|
|
{PCIC_BRIDGE, PCIS_BRIDGE_PCMCIA, "PCI-PCMCIA"},
|
|
|
|
{PCIC_BRIDGE, PCIS_BRIDGE_NUBUS, "PCI-NuBus"},
|
|
|
|
{PCIC_BRIDGE, PCIS_BRIDGE_CARDBUS, "PCI-CardBus"},
|
2005-03-26 20:31:09 +00:00
|
|
|
{PCIC_BRIDGE, PCIS_BRIDGE_RACEWAY, "PCI-RACEway"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{PCIC_SIMPLECOMM, -1, "simple comms"},
|
|
|
|
{PCIC_SIMPLECOMM, PCIS_SIMPLECOMM_UART, "UART"}, /* could detect 16550 */
|
|
|
|
{PCIC_SIMPLECOMM, PCIS_SIMPLECOMM_PAR, "parallel port"},
|
2005-03-26 20:31:09 +00:00
|
|
|
{PCIC_SIMPLECOMM, PCIS_SIMPLECOMM_MULSER, "multiport serial"},
|
|
|
|
{PCIC_SIMPLECOMM, PCIS_SIMPLECOMM_MODEM, "generic modem"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{PCIC_BASEPERIPH, -1, "base peripheral"},
|
|
|
|
{PCIC_BASEPERIPH, PCIS_BASEPERIPH_PIC, "interrupt controller"},
|
|
|
|
{PCIC_BASEPERIPH, PCIS_BASEPERIPH_DMA, "DMA controller"},
|
|
|
|
{PCIC_BASEPERIPH, PCIS_BASEPERIPH_TIMER, "timer"},
|
|
|
|
{PCIC_BASEPERIPH, PCIS_BASEPERIPH_RTC, "realtime clock"},
|
2005-03-26 20:31:09 +00:00
|
|
|
{PCIC_BASEPERIPH, PCIS_BASEPERIPH_PCIHOT, "PCI hot-plug controller"},
|
2008-10-21 20:55:41 +00:00
|
|
|
{PCIC_BASEPERIPH, PCIS_BASEPERIPH_SDHC, "SD host controller"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{PCIC_INPUTDEV, -1, "input device"},
|
|
|
|
{PCIC_INPUTDEV, PCIS_INPUTDEV_KEYBOARD, "keyboard"},
|
|
|
|
{PCIC_INPUTDEV, PCIS_INPUTDEV_DIGITIZER,"digitizer"},
|
|
|
|
{PCIC_INPUTDEV, PCIS_INPUTDEV_MOUSE, "mouse"},
|
2005-03-26 20:31:09 +00:00
|
|
|
{PCIC_INPUTDEV, PCIS_INPUTDEV_SCANNER, "scanner"},
|
|
|
|
{PCIC_INPUTDEV, PCIS_INPUTDEV_GAMEPORT, "gameport"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{PCIC_DOCKING, -1, "docking station"},
|
|
|
|
{PCIC_PROCESSOR, -1, "processor"},
|
|
|
|
{PCIC_SERIALBUS, -1, "serial bus"},
|
|
|
|
{PCIC_SERIALBUS, PCIS_SERIALBUS_FW, "FireWire"},
|
2006-11-07 18:55:51 +00:00
|
|
|
{PCIC_SERIALBUS, PCIS_SERIALBUS_ACCESS, "AccessBus"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{PCIC_SERIALBUS, PCIS_SERIALBUS_SSA, "SSA"},
|
|
|
|
{PCIC_SERIALBUS, PCIS_SERIALBUS_USB, "USB"},
|
|
|
|
{PCIC_SERIALBUS, PCIS_SERIALBUS_FC, "Fibre Channel"},
|
|
|
|
{PCIC_SERIALBUS, PCIS_SERIALBUS_SMBUS, "SMBus"},
|
2005-03-26 20:31:09 +00:00
|
|
|
{PCIC_WIRELESS, -1, "wireless controller"},
|
|
|
|
{PCIC_WIRELESS, PCIS_WIRELESS_IRDA, "iRDA"},
|
|
|
|
{PCIC_WIRELESS, PCIS_WIRELESS_IR, "IR"},
|
|
|
|
{PCIC_WIRELESS, PCIS_WIRELESS_RF, "RF"},
|
|
|
|
{PCIC_INTELLIIO, -1, "intelligent I/O controller"},
|
|
|
|
{PCIC_INTELLIIO, PCIS_INTELLIIO_I2O, "I2O"},
|
|
|
|
{PCIC_SATCOM, -1, "satellite communication"},
|
|
|
|
{PCIC_SATCOM, PCIS_SATCOM_TV, "sat TV"},
|
|
|
|
{PCIC_SATCOM, PCIS_SATCOM_AUDIO, "sat audio"},
|
|
|
|
{PCIC_SATCOM, PCIS_SATCOM_VOICE, "sat voice"},
|
|
|
|
{PCIC_SATCOM, PCIS_SATCOM_DATA, "sat data"},
|
|
|
|
{PCIC_CRYPTO, -1, "encrypt/decrypt"},
|
|
|
|
{PCIC_CRYPTO, PCIS_CRYPTO_NETCOMP, "network/computer crypto"},
|
2006-09-20 06:47:14 +00:00
|
|
|
{PCIC_CRYPTO, PCIS_CRYPTO_ENTERTAIN, "entertainment crypto"},
|
2005-03-26 20:31:09 +00:00
|
|
|
{PCIC_DASP, -1, "dasp"},
|
|
|
|
{PCIC_DASP, PCIS_DASP_DPIO, "DPIO module"},
|
2000-12-08 22:11:23 +00:00
|
|
|
{0, 0, NULL}
|
|
|
|
};
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
void
|
1999-07-27 04:28:14 +00:00
|
|
|
pci_probe_nomatch(device_t dev, device_t child)
|
|
|
|
{
|
2000-12-08 22:11:23 +00:00
|
|
|
int i;
|
|
|
|
char *cp, *scp, *device;
|
2006-11-07 18:55:51 +00:00
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
/*
|
|
|
|
* Look for a listing for this device in a loaded device database.
|
|
|
|
*/
|
|
|
|
if ((device = pci_describe_device(child)) != NULL) {
|
2000-12-09 09:15:38 +00:00
|
|
|
device_printf(dev, "<%s>", device);
|
2000-12-08 22:11:23 +00:00
|
|
|
free(device, M_DEVBUF);
|
|
|
|
} else {
|
2002-06-01 03:41:02 +00:00
|
|
|
/*
|
|
|
|
* Scan the class/subclass descriptions for a general
|
|
|
|
* description.
|
|
|
|
*/
|
|
|
|
cp = "unknown";
|
|
|
|
scp = NULL;
|
|
|
|
for (i = 0; pci_nomatch_tab[i].desc != NULL; i++) {
|
|
|
|
if (pci_nomatch_tab[i].class == pci_get_class(child)) {
|
|
|
|
if (pci_nomatch_tab[i].subclass == -1) {
|
|
|
|
cp = pci_nomatch_tab[i].desc;
|
|
|
|
} else if (pci_nomatch_tab[i].subclass ==
|
|
|
|
pci_get_subclass(child)) {
|
|
|
|
scp = pci_nomatch_tab[i].desc;
|
|
|
|
}
|
|
|
|
}
|
2000-12-08 22:11:23 +00:00
|
|
|
}
|
2006-11-07 18:55:51 +00:00
|
|
|
device_printf(dev, "<%s%s%s>",
|
2002-09-28 17:47:51 +00:00
|
|
|
cp ? cp : "",
|
|
|
|
((cp != NULL) && (scp != NULL)) ? ", " : "",
|
|
|
|
scp ? scp : "");
|
2000-12-08 22:11:23 +00:00
|
|
|
}
|
2001-09-01 23:06:14 +00:00
|
|
|
printf(" at device %d.%d (no driver attached)\n",
|
2002-06-01 03:41:02 +00:00
|
|
|
pci_get_slot(child), pci_get_function(child));
|
2010-10-15 21:41:59 +00:00
|
|
|
pci_cfg_save(child, device_get_ivars(child), 1);
|
2000-12-08 22:11:23 +00:00
|
|
|
return;
|
|
|
|
}
|
1999-11-22 03:34:43 +00:00
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
/*
|
2006-11-07 18:55:51 +00:00
|
|
|
* Parse the PCI device database, if loaded, and return a pointer to a
|
2000-12-08 22:11:23 +00:00
|
|
|
* description of the device.
|
|
|
|
*
|
|
|
|
* The database is flat text formatted as follows:
|
|
|
|
*
|
|
|
|
* Any line not in a valid format is ignored.
|
|
|
|
* Lines are terminated with newline '\n' characters.
|
2006-11-07 18:55:51 +00:00
|
|
|
*
|
2000-12-08 22:11:23 +00:00
|
|
|
* A VENDOR line consists of the 4 digit (hex) vendor code, a TAB, then
|
|
|
|
* the vendor name.
|
2006-11-07 18:55:51 +00:00
|
|
|
*
|
2000-12-08 22:11:23 +00:00
|
|
|
* A DEVICE line is entered immediately below the corresponding VENDOR ID.
|
|
|
|
* - devices cannot be listed without a corresponding VENDOR line.
|
|
|
|
* A DEVICE line consists of a TAB, the 4 digit (hex) device code,
|
2006-11-07 18:55:51 +00:00
|
|
|
* another TAB, then the device name.
|
2000-12-08 22:11:23 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Assuming (ptr) points to the beginning of a line in the database,
|
|
|
|
* return the vendor or device and description of the next entry.
|
|
|
|
* The value of (vendor) or (device) inappropriate for the entry type
|
|
|
|
* is set to -1. Returns nonzero at the end of the database.
|
|
|
|
*
|
|
|
|
* Note that this is slightly unrobust in the face of corrupt data;
|
|
|
|
* we attempt to safeguard against this by spamming the end of the
|
|
|
|
* database with a newline when we initialise.
|
|
|
|
*/
|
|
|
|
static int
|
2006-11-07 18:55:51 +00:00
|
|
|
pci_describe_parse_line(char **ptr, int *vendor, int *device, char **desc)
|
2000-12-08 22:11:23 +00:00
|
|
|
{
|
|
|
|
char *cp = *ptr;
|
2000-12-09 09:15:38 +00:00
|
|
|
int left;
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
*device = -1;
|
|
|
|
*vendor = -1;
|
2000-12-09 09:15:38 +00:00
|
|
|
**desc = '\0';
|
2000-12-08 22:11:23 +00:00
|
|
|
for (;;) {
|
2000-12-09 09:15:38 +00:00
|
|
|
left = pci_vendordata_size - (cp - pci_vendordata);
|
|
|
|
if (left <= 0) {
|
|
|
|
*ptr = cp;
|
2000-12-08 22:11:23 +00:00
|
|
|
return(1);
|
2000-12-09 09:15:38 +00:00
|
|
|
}
|
2000-12-08 22:11:23 +00:00
|
|
|
|
|
|
|
/* vendor entry? */
|
2002-06-01 03:41:02 +00:00
|
|
|
if (*cp != '\t' &&
|
|
|
|
sscanf(cp, "%x\t%80[^\n]", vendor, *desc) == 2)
|
2000-12-08 22:11:23 +00:00
|
|
|
break;
|
|
|
|
/* device entry? */
|
2002-06-01 03:41:02 +00:00
|
|
|
if (*cp == '\t' &&
|
|
|
|
sscanf(cp, "%x\t%80[^\n]", device, *desc) == 2)
|
2000-12-08 22:11:23 +00:00
|
|
|
break;
|
2006-11-07 18:55:51 +00:00
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
/* skip to next line */
|
2000-12-09 09:15:38 +00:00
|
|
|
while (*cp != '\n' && left > 0) {
|
|
|
|
cp++;
|
|
|
|
left--;
|
|
|
|
}
|
|
|
|
if (*cp == '\n') {
|
2000-12-08 22:11:23 +00:00
|
|
|
cp++;
|
2000-12-09 09:15:38 +00:00
|
|
|
left--;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* skip to next line */
|
|
|
|
while (*cp != '\n' && left > 0) {
|
2000-12-08 22:11:23 +00:00
|
|
|
cp++;
|
2000-12-09 09:15:38 +00:00
|
|
|
left--;
|
2000-02-22 21:44:39 +00:00
|
|
|
}
|
2000-12-09 09:15:38 +00:00
|
|
|
if (*cp == '\n' && left > 0)
|
|
|
|
cp++;
|
2000-12-08 22:11:23 +00:00
|
|
|
*ptr = cp;
|
|
|
|
return(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *
|
|
|
|
pci_describe_device(device_t dev)
|
|
|
|
{
|
|
|
|
int vendor, device;
|
|
|
|
char *desc, *vp, *dp, *line;
|
|
|
|
|
|
|
|
desc = vp = dp = NULL;
|
2006-11-07 18:55:51 +00:00
|
|
|
|
2000-12-08 22:11:23 +00:00
|
|
|
/*
|
|
|
|
* If we have no vendor data, we can't do anything.
|
|
|
|
*/
|
|
|
|
if (pci_vendordata == NULL)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan the vendor data looking for this device
|
|
|
|
*/
|
|
|
|
line = pci_vendordata;
|
|
|
|
if ((vp = malloc(80, M_DEVBUF, M_NOWAIT)) == NULL)
|
|
|
|
goto out;
|
|
|
|
for (;;) {
|
|
|
|
if (pci_describe_parse_line(&line, &vendor, &device, &vp))
|
|
|
|
goto out;
|
|
|
|
if (vendor == pci_get_vendor(dev))
|
|
|
|
break;
|
2000-02-22 21:44:39 +00:00
|
|
|
}
|
2000-12-08 22:11:23 +00:00
|
|
|
if ((dp = malloc(80, M_DEVBUF, M_NOWAIT)) == NULL)
|
|
|
|
goto out;
|
|
|
|
for (;;) {
|
2000-12-09 09:15:38 +00:00
|
|
|
if (pci_describe_parse_line(&line, &vendor, &device, &dp)) {
|
|
|
|
*dp = 0;
|
|
|
|
break;
|
|
|
|
}
|
2000-12-08 22:11:23 +00:00
|
|
|
if (vendor != -1) {
|
|
|
|
*dp = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (device == pci_get_device(dev))
|
|
|
|
break;
|
1999-07-27 04:28:14 +00:00
|
|
|
}
|
2000-12-09 09:15:38 +00:00
|
|
|
if (dp[0] == '\0')
|
|
|
|
snprintf(dp, 80, "0x%x", pci_get_device(dev));
|
2002-06-01 03:41:02 +00:00
|
|
|
if ((desc = malloc(strlen(vp) + strlen(dp) + 3, M_DEVBUF, M_NOWAIT)) !=
|
|
|
|
NULL)
|
2000-12-09 09:15:38 +00:00
|
|
|
sprintf(desc, "%s, %s", vp, dp);
|
2000-12-08 22:11:23 +00:00
|
|
|
out:
|
|
|
|
if (vp != NULL)
|
|
|
|
free(vp, M_DEVBUF);
|
|
|
|
if (dp != NULL)
|
|
|
|
free(dp, M_DEVBUF);
|
|
|
|
return(desc);
|
1999-07-27 04:28:14 +00:00
|
|
|
}
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
int
|
2000-04-30 10:01:56 +00:00
|
|
|
pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
|
1999-04-16 21:22:55 +00:00
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
pcicfgregs *cfg;
|
|
|
|
|
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
cfg = &dinfo->cfg;
|
|
|
|
|
|
|
|
switch (which) {
|
2002-11-27 06:41:28 +00:00
|
|
|
case PCI_IVAR_ETHADDR:
|
|
|
|
/*
|
|
|
|
* The generic accessor doesn't deal with failure, so
|
|
|
|
* we set the return value, then return an error.
|
|
|
|
*/
|
2003-08-22 03:11:53 +00:00
|
|
|
*((uint8_t **) result) = NULL;
|
2002-11-27 06:41:28 +00:00
|
|
|
return (EINVAL);
|
1999-04-16 21:22:55 +00:00
|
|
|
case PCI_IVAR_SUBVENDOR:
|
|
|
|
*result = cfg->subvendor;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_SUBDEVICE:
|
|
|
|
*result = cfg->subdevice;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_VENDOR:
|
|
|
|
*result = cfg->vendor;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_DEVICE:
|
|
|
|
*result = cfg->device;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_DEVID:
|
|
|
|
*result = (cfg->device << 16) | cfg->vendor;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_CLASS:
|
|
|
|
*result = cfg->baseclass;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_SUBCLASS:
|
|
|
|
*result = cfg->subclass;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_PROGIF:
|
|
|
|
*result = cfg->progif;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_REVID:
|
|
|
|
*result = cfg->revid;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_INTPIN:
|
|
|
|
*result = cfg->intpin;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_IRQ:
|
|
|
|
*result = cfg->intline;
|
|
|
|
break;
|
2007-09-30 11:05:18 +00:00
|
|
|
case PCI_IVAR_DOMAIN:
|
|
|
|
*result = cfg->domain;
|
|
|
|
break;
|
1999-04-16 21:22:55 +00:00
|
|
|
case PCI_IVAR_BUS:
|
|
|
|
*result = cfg->bus;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_SLOT:
|
|
|
|
*result = cfg->slot;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_FUNCTION:
|
|
|
|
*result = cfg->func;
|
|
|
|
break;
|
2005-09-11 03:22:03 +00:00
|
|
|
case PCI_IVAR_CMDREG:
|
|
|
|
*result = cfg->cmdreg;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_CACHELNSZ:
|
|
|
|
*result = cfg->cachelnsz;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_MINGNT:
|
|
|
|
*result = cfg->mingnt;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_MAXLAT:
|
|
|
|
*result = cfg->maxlat;
|
|
|
|
break;
|
|
|
|
case PCI_IVAR_LATTIMER:
|
|
|
|
*result = cfg->lattimer;
|
|
|
|
break;
|
1999-04-16 21:22:55 +00:00
|
|
|
default:
|
2002-06-01 05:44:45 +00:00
|
|
|
return (ENOENT);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
2002-06-01 05:44:45 +00:00
|
|
|
return (0);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
int
|
1999-04-16 21:22:55 +00:00
|
|
|
pci_write_ivar(device_t dev, device_t child, int which, uintptr_t value)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
|
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
|
|
|
|
switch (which) {
|
2003-07-01 13:54:10 +00:00
|
|
|
case PCI_IVAR_INTPIN:
|
|
|
|
dinfo->cfg.intpin = value;
|
|
|
|
return (0);
|
2002-11-27 06:41:28 +00:00
|
|
|
case PCI_IVAR_ETHADDR:
|
1999-04-16 21:22:55 +00:00
|
|
|
case PCI_IVAR_SUBVENDOR:
|
|
|
|
case PCI_IVAR_SUBDEVICE:
|
|
|
|
case PCI_IVAR_VENDOR:
|
|
|
|
case PCI_IVAR_DEVICE:
|
|
|
|
case PCI_IVAR_DEVID:
|
|
|
|
case PCI_IVAR_CLASS:
|
|
|
|
case PCI_IVAR_SUBCLASS:
|
|
|
|
case PCI_IVAR_PROGIF:
|
|
|
|
case PCI_IVAR_REVID:
|
|
|
|
case PCI_IVAR_IRQ:
|
2007-09-30 11:05:18 +00:00
|
|
|
case PCI_IVAR_DOMAIN:
|
1999-04-16 21:22:55 +00:00
|
|
|
case PCI_IVAR_BUS:
|
|
|
|
case PCI_IVAR_SLOT:
|
|
|
|
case PCI_IVAR_FUNCTION:
|
2002-06-01 05:44:45 +00:00
|
|
|
return (EINVAL); /* disallow for now */
|
1999-04-16 21:22:55 +00:00
|
|
|
|
|
|
|
default:
|
2002-06-01 05:44:45 +00:00
|
|
|
return (ENOENT);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2002-08-28 10:02:59 +00:00
|
|
|
|
|
|
|
#include "opt_ddb.h"
|
|
|
|
#ifdef DDB
|
|
|
|
#include <ddb/ddb.h>
|
|
|
|
#include <sys/cons.h>
|
|
|
|
|
|
|
|
/*
|
|
|
|
* List resources based on pci map registers, used for within ddb
|
|
|
|
*/
|
|
|
|
|
|
|
|
DB_SHOW_COMMAND(pciregs, db_pci_dump)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
struct devlist *devlist_head;
|
|
|
|
struct pci_conf *p;
|
|
|
|
const char *name;
|
2006-07-12 21:22:44 +00:00
|
|
|
int i, error, none_count;
|
2002-08-28 10:02:59 +00:00
|
|
|
|
|
|
|
none_count = 0;
|
|
|
|
/* get the head of the device queue */
|
|
|
|
devlist_head = &pci_devq;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Go through the list of devices and print out devices
|
|
|
|
*/
|
2006-07-12 21:22:44 +00:00
|
|
|
for (error = 0, i = 0,
|
2002-08-28 10:02:59 +00:00
|
|
|
dinfo = STAILQ_FIRST(devlist_head);
|
2006-07-12 21:22:44 +00:00
|
|
|
(dinfo != NULL) && (error == 0) && (i < pci_numdevs) && !db_pager_quit;
|
2002-08-28 10:02:59 +00:00
|
|
|
dinfo = STAILQ_NEXT(dinfo, pci_links), i++) {
|
|
|
|
|
|
|
|
/* Populate pd_name and pd_unit */
|
|
|
|
name = NULL;
|
|
|
|
if (dinfo->cfg.dev)
|
|
|
|
name = device_get_name(dinfo->cfg.dev);
|
|
|
|
|
|
|
|
p = &dinfo->conf;
|
2007-09-30 11:05:18 +00:00
|
|
|
db_printf("%s%d@pci%d:%d:%d:%d:\tclass=0x%06x card=0x%08x "
|
2002-08-28 10:02:59 +00:00
|
|
|
"chip=0x%08x rev=0x%02x hdr=0x%02x\n",
|
|
|
|
(name && *name) ? name : "none",
|
|
|
|
(name && *name) ? (int)device_get_unit(dinfo->cfg.dev) :
|
|
|
|
none_count++,
|
2007-09-30 11:05:18 +00:00
|
|
|
p->pc_sel.pc_domain, p->pc_sel.pc_bus, p->pc_sel.pc_dev,
|
2002-08-28 10:02:59 +00:00
|
|
|
p->pc_sel.pc_func, (p->pc_class << 16) |
|
|
|
|
(p->pc_subclass << 8) | p->pc_progif,
|
|
|
|
(p->pc_subdevice << 16) | p->pc_subvendor,
|
|
|
|
(p->pc_device << 16) | p->pc_vendor,
|
|
|
|
p->pc_revid, p->pc_hdr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif /* DDB */
|
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
static struct resource *
|
2009-12-09 21:52:53 +00:00
|
|
|
pci_reserve_map(device_t dev, device_t child, int type, int *rid,
|
2004-04-09 15:44:34 +00:00
|
|
|
u_long start, u_long end, u_long count, u_int flags)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
struct resource_list *rl = &dinfo->resources;
|
|
|
|
struct resource_list_entry *rle;
|
|
|
|
struct resource *res;
|
2011-03-31 13:22:12 +00:00
|
|
|
struct pci_map *pm;
|
2006-10-30 19:18:46 +00:00
|
|
|
pci_addr_t map, testval;
|
2009-04-14 18:32:37 +00:00
|
|
|
int mapsize;
|
2004-04-09 15:44:34 +00:00
|
|
|
|
2004-04-13 19:31:57 +00:00
|
|
|
res = NULL;
|
2011-03-31 13:22:12 +00:00
|
|
|
pm = pci_find_bar(child, *rid);
|
|
|
|
if (pm != NULL) {
|
|
|
|
/* This is a BAR that we failed to allocate earlier. */
|
|
|
|
mapsize = pm->pm_size;
|
|
|
|
map = pm->pm_value;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Weed out the bogons, and figure out how large the
|
|
|
|
* BAR/map is. BARs that read back 0 here are bogus
|
|
|
|
* and unimplemented. Note: atapci in legacy mode are
|
|
|
|
* special and handled elsewhere in the code. If you
|
|
|
|
* have a atapci device in legacy mode and it fails
|
|
|
|
* here, that other code is broken.
|
|
|
|
*/
|
|
|
|
pci_read_bar(child, *rid, &map, &testval);
|
2009-03-03 16:38:59 +00:00
|
|
|
|
2011-03-31 13:22:12 +00:00
|
|
|
/*
|
|
|
|
* Determine the size of the BAR and ignore BARs with a size
|
|
|
|
* of 0. Device ROM BARs use a different mask value.
|
|
|
|
*/
|
|
|
|
if (PCIR_IS_BIOS(&dinfo->cfg, *rid))
|
|
|
|
mapsize = pci_romsize(testval);
|
|
|
|
else
|
|
|
|
mapsize = pci_mapsize(testval);
|
|
|
|
if (mapsize == 0)
|
|
|
|
goto out;
|
|
|
|
pm = pci_add_bar(child, *rid, map, mapsize);
|
|
|
|
}
|
2007-07-29 02:44:41 +00:00
|
|
|
|
2011-03-31 13:22:12 +00:00
|
|
|
if (PCI_BAR_MEM(map) || PCIR_IS_BIOS(&dinfo->cfg, *rid)) {
|
2004-04-21 20:19:56 +00:00
|
|
|
if (type != SYS_RES_MEMORY) {
|
2005-04-11 02:08:05 +00:00
|
|
|
if (bootverbose)
|
2005-09-11 03:22:03 +00:00
|
|
|
device_printf(dev,
|
|
|
|
"child %s requested type %d for rid %#x,"
|
|
|
|
" but the BAR says it is an memio\n",
|
|
|
|
device_get_nameunit(child), type, *rid);
|
2004-04-21 20:19:56 +00:00
|
|
|
goto out;
|
2004-04-13 19:31:57 +00:00
|
|
|
}
|
2004-04-21 20:19:56 +00:00
|
|
|
} else {
|
|
|
|
if (type != SYS_RES_IOPORT) {
|
2005-04-11 02:08:05 +00:00
|
|
|
if (bootverbose)
|
2005-09-11 03:22:03 +00:00
|
|
|
device_printf(dev,
|
|
|
|
"child %s requested type %d for rid %#x,"
|
|
|
|
" but the BAR says it is an ioport\n",
|
|
|
|
device_get_nameunit(child), type, *rid);
|
2004-04-21 20:19:56 +00:00
|
|
|
goto out;
|
|
|
|
}
|
2004-04-13 19:31:57 +00:00
|
|
|
}
|
2009-04-14 18:32:37 +00:00
|
|
|
|
2004-04-21 20:19:56 +00:00
|
|
|
/*
|
|
|
|
* For real BARs, we need to override the size that
|
|
|
|
* the driver requests, because that's what the BAR
|
|
|
|
* actually uses and we would otherwise have a
|
|
|
|
* situation where we might allocate the excess to
|
|
|
|
* another driver, which won't work.
|
|
|
|
*/
|
2011-02-23 12:58:50 +00:00
|
|
|
count = (pci_addr_t)1 << mapsize;
|
2004-04-21 20:19:56 +00:00
|
|
|
if (RF_ALIGNMENT(flags) < mapsize)
|
|
|
|
flags = (flags & ~RF_ALIGNMENT_MASK) | RF_ALIGNMENT_LOG2(mapsize);
|
2011-03-31 13:22:12 +00:00
|
|
|
if (PCI_BAR_MEM(map) && (map & PCIM_BAR_MEM_PREFETCH))
|
2009-03-05 15:28:46 +00:00
|
|
|
flags |= RF_PREFETCHABLE;
|
2006-11-07 18:55:51 +00:00
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
/*
|
|
|
|
* Allocate enough resource, and then write back the
|
2011-03-31 13:22:12 +00:00
|
|
|
* appropriate BAR for that resource.
|
2004-04-09 15:44:34 +00:00
|
|
|
*/
|
|
|
|
res = BUS_ALLOC_RESOURCE(device_get_parent(dev), child, type, rid,
|
2009-03-03 16:38:59 +00:00
|
|
|
start, end, count, flags & ~RF_ACTIVE);
|
2004-04-09 15:44:34 +00:00
|
|
|
if (res == NULL) {
|
2005-11-09 03:37:52 +00:00
|
|
|
device_printf(child,
|
|
|
|
"%#lx bytes of rid %#x res %d failed (%#lx, %#lx).\n",
|
|
|
|
count, *rid, type, start, end);
|
2004-04-13 19:31:57 +00:00
|
|
|
goto out;
|
2004-04-09 15:44:34 +00:00
|
|
|
}
|
|
|
|
resource_list_add(rl, type, *rid, start, end, count);
|
|
|
|
rle = resource_list_find(rl, type, *rid);
|
|
|
|
if (rle == NULL)
|
2009-12-09 21:52:53 +00:00
|
|
|
panic("pci_reserve_map: unexpectedly can't find resource.");
|
2004-04-09 15:44:34 +00:00
|
|
|
rle->res = res;
|
2005-10-29 05:52:17 +00:00
|
|
|
rle->start = rman_get_start(res);
|
|
|
|
rle->end = rman_get_end(res);
|
|
|
|
rle->count = count;
|
2009-12-09 21:52:53 +00:00
|
|
|
rle->flags = RLE_RESERVED;
|
2004-05-21 06:03:26 +00:00
|
|
|
if (bootverbose)
|
|
|
|
device_printf(child,
|
|
|
|
"Lazy allocation of %#lx bytes rid %#x type %d at %#lx\n",
|
|
|
|
count, *rid, type, rman_get_start(res));
|
2004-04-13 19:31:57 +00:00
|
|
|
map = rman_get_start(res);
|
2011-03-31 13:22:12 +00:00
|
|
|
pci_write_bar(child, pm, map);
|
2009-03-03 16:38:59 +00:00
|
|
|
out:;
|
2004-04-09 15:44:34 +00:00
|
|
|
return (res);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
struct resource *
|
1999-10-14 21:38:33 +00:00
|
|
|
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
|
|
|
|
u_long start, u_long end, u_long count, u_int flags)
|
1999-04-16 21:22:55 +00:00
|
|
|
{
|
1999-10-14 21:38:33 +00:00
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
struct resource_list *rl = &dinfo->resources;
|
2004-04-09 15:44:34 +00:00
|
|
|
struct resource_list_entry *rle;
|
2009-03-03 16:38:59 +00:00
|
|
|
struct resource *res;
|
2000-10-16 07:24:00 +00:00
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
|
2009-03-03 16:38:59 +00:00
|
|
|
if (device_get_parent(child) != dev)
|
|
|
|
return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child,
|
|
|
|
type, rid, start, end, count, flags));
|
|
|
|
|
2000-10-16 07:24:00 +00:00
|
|
|
/*
|
|
|
|
* Perform lazy resource allocation
|
|
|
|
*/
|
2009-03-03 16:38:59 +00:00
|
|
|
switch (type) {
|
|
|
|
case SYS_RES_IRQ:
|
|
|
|
/*
|
|
|
|
* Can't alloc legacy interrupt once MSI messages have
|
|
|
|
* been allocated.
|
|
|
|
*/
|
|
|
|
if (*rid == 0 && (cfg->msi.msi_alloc > 0 ||
|
|
|
|
cfg->msix.msix_alloc > 0))
|
|
|
|
return (NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the child device doesn't have an interrupt
|
|
|
|
* routed and is deserving of an interrupt, try to
|
|
|
|
* assign it one.
|
|
|
|
*/
|
|
|
|
if (*rid == 0 && !PCI_INTERRUPT_VALID(cfg->intline) &&
|
|
|
|
(cfg->intpin != 0))
|
|
|
|
pci_assign_interrupt(dev, child, 0);
|
|
|
|
break;
|
|
|
|
case SYS_RES_IOPORT:
|
|
|
|
case SYS_RES_MEMORY:
|
2011-05-03 17:37:24 +00:00
|
|
|
#ifdef NEW_PCIB
|
|
|
|
/*
|
|
|
|
* PCI-PCI bridge I/O window resources are not BARs.
|
|
|
|
* For those allocations just pass the request up the
|
|
|
|
* tree.
|
|
|
|
*/
|
|
|
|
if (cfg->hdrtype == PCIM_HDRTYPE_BRIDGE) {
|
|
|
|
switch (*rid) {
|
|
|
|
case PCIR_IOBASEL_1:
|
|
|
|
case PCIR_MEMBASE_1:
|
|
|
|
case PCIR_PMBASEL_1:
|
|
|
|
/*
|
|
|
|
* XXX: Should we bother creating a resource
|
|
|
|
* list entry?
|
|
|
|
*/
|
|
|
|
return (bus_generic_alloc_resource(dev, child,
|
|
|
|
type, rid, start, end, count, flags));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
2009-12-09 21:52:53 +00:00
|
|
|
/* Reserve resources for this BAR if needed. */
|
2009-03-03 16:38:59 +00:00
|
|
|
rle = resource_list_find(rl, type, *rid);
|
|
|
|
if (rle == NULL) {
|
2009-12-09 21:52:53 +00:00
|
|
|
res = pci_reserve_map(dev, child, type, rid, start, end,
|
2009-03-03 16:38:59 +00:00
|
|
|
count, flags);
|
|
|
|
if (res == NULL)
|
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
|
|
|
return (NULL);
|
2004-04-09 15:44:34 +00:00
|
|
|
}
|
2000-10-16 07:24:00 +00:00
|
|
|
}
|
2002-06-01 05:44:45 +00:00
|
|
|
return (resource_list_alloc(rl, dev, child, type, rid,
|
|
|
|
start, end, count, flags));
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2009-03-03 16:38:59 +00:00
|
|
|
int
|
|
|
|
pci_activate_resource(device_t dev, device_t child, int type, int rid,
|
|
|
|
struct resource *r)
|
|
|
|
{
|
2011-03-31 13:22:12 +00:00
|
|
|
struct pci_devinfo *dinfo;
|
2009-03-03 16:38:59 +00:00
|
|
|
int error;
|
|
|
|
|
|
|
|
error = bus_generic_activate_resource(dev, child, type, rid, r);
|
|
|
|
if (error)
|
|
|
|
return (error);
|
|
|
|
|
|
|
|
/* Enable decoding in the command register when activating BARs. */
|
|
|
|
if (device_get_parent(child) == dev) {
|
2009-12-30 20:47:14 +00:00
|
|
|
/* Device ROMs need their decoding explicitly enabled. */
|
2011-03-31 13:22:12 +00:00
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
if (PCIR_IS_BIOS(&dinfo->cfg, rid))
|
|
|
|
pci_write_bar(child, pci_find_bar(child, rid),
|
|
|
|
rman_get_start(r) | PCIM_BIOS_ENABLE);
|
2009-03-03 16:38:59 +00:00
|
|
|
switch (type) {
|
|
|
|
case SYS_RES_IOPORT:
|
|
|
|
case SYS_RES_MEMORY:
|
|
|
|
error = PCI_ENABLE_IO(dev, child, type);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return (error);
|
|
|
|
}
|
|
|
|
|
2009-12-30 20:47:14 +00:00
|
|
|
int
|
|
|
|
pci_deactivate_resource(device_t dev, device_t child, int type,
|
|
|
|
int rid, struct resource *r)
|
|
|
|
{
|
2011-03-31 13:22:12 +00:00
|
|
|
struct pci_devinfo *dinfo;
|
2009-12-30 20:47:14 +00:00
|
|
|
int error;
|
|
|
|
|
|
|
|
error = bus_generic_deactivate_resource(dev, child, type, rid, r);
|
|
|
|
if (error)
|
|
|
|
return (error);
|
|
|
|
|
2011-03-31 13:22:12 +00:00
|
|
|
/* Disable decoding for device ROMs. */
|
|
|
|
if (device_get_parent(child) == dev) {
|
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
if (PCIR_IS_BIOS(&dinfo->cfg, rid))
|
|
|
|
pci_write_bar(child, pci_find_bar(child, rid),
|
|
|
|
rman_get_start(r));
|
|
|
|
}
|
2009-12-30 20:47:14 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2010-01-05 20:42:25 +00:00
|
|
|
void
|
|
|
|
pci_delete_child(device_t dev, device_t child)
|
|
|
|
{
|
|
|
|
struct resource_list_entry *rle;
|
|
|
|
struct resource_list *rl;
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
|
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
rl = &dinfo->resources;
|
|
|
|
|
|
|
|
if (device_is_attached(child))
|
|
|
|
device_detach(child);
|
|
|
|
|
|
|
|
/* Turn off access to resources we're about to free */
|
|
|
|
pci_write_config(child, PCIR_COMMAND, pci_read_config(child,
|
|
|
|
PCIR_COMMAND, 2) & ~(PCIM_CMD_MEMEN | PCIM_CMD_PORTEN), 2);
|
|
|
|
|
|
|
|
/* Free all allocated resources */
|
|
|
|
STAILQ_FOREACH(rle, rl, link) {
|
|
|
|
if (rle->res) {
|
|
|
|
if (rman_get_flags(rle->res) & RF_ACTIVE ||
|
|
|
|
resource_list_busy(rl, rle->type, rle->rid)) {
|
|
|
|
pci_printf(&dinfo->cfg,
|
|
|
|
"Resource still owned, oops. "
|
|
|
|
"(type=%d, rid=%d, addr=%lx)\n",
|
|
|
|
rle->type, rle->rid,
|
|
|
|
rman_get_start(rle->res));
|
|
|
|
bus_release_resource(child, rle->type, rle->rid,
|
|
|
|
rle->res);
|
|
|
|
}
|
|
|
|
resource_list_unreserve(rl, dev, child, rle->type,
|
|
|
|
rle->rid);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
resource_list_free(rl);
|
|
|
|
|
|
|
|
device_delete_child(dev, child);
|
|
|
|
pci_freecfg(dinfo);
|
|
|
|
}
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
void
|
2000-11-28 07:12:12 +00:00
|
|
|
pci_delete_resource(device_t dev, device_t child, int type, int rid)
|
1999-04-16 21:22:55 +00:00
|
|
|
{
|
2002-02-27 05:09:14 +00:00
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
struct resource_list *rl;
|
|
|
|
struct resource_list_entry *rle;
|
|
|
|
|
|
|
|
if (device_get_parent(child) != dev)
|
|
|
|
return;
|
|
|
|
|
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
rl = &dinfo->resources;
|
|
|
|
rle = resource_list_find(rl, type, rid);
|
2009-03-03 16:38:59 +00:00
|
|
|
if (rle == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (rle->res) {
|
2009-12-09 21:52:53 +00:00
|
|
|
if (rman_get_flags(rle->res) & RF_ACTIVE ||
|
|
|
|
resource_list_busy(rl, type, rid)) {
|
2009-03-03 16:38:59 +00:00
|
|
|
device_printf(dev, "delete_resource: "
|
|
|
|
"Resource still owned by child, oops. "
|
|
|
|
"(type=%d, rid=%d, addr=%lx)\n",
|
2009-12-09 21:52:53 +00:00
|
|
|
type, rid, rman_get_start(rle->res));
|
2009-03-03 16:38:59 +00:00
|
|
|
return;
|
2002-02-27 05:09:14 +00:00
|
|
|
}
|
2009-03-03 16:38:59 +00:00
|
|
|
|
2009-07-21 19:06:39 +00:00
|
|
|
#ifndef __PCI_BAR_ZERO_VALID
|
2009-03-03 16:38:59 +00:00
|
|
|
/*
|
|
|
|
* If this is a BAR, clear the BAR so it stops
|
|
|
|
* decoding before releasing the resource.
|
|
|
|
*/
|
|
|
|
switch (type) {
|
|
|
|
case SYS_RES_IOPORT:
|
|
|
|
case SYS_RES_MEMORY:
|
2011-03-31 13:22:12 +00:00
|
|
|
pci_write_bar(child, pci_find_bar(child, rid), 0);
|
2009-03-03 16:38:59 +00:00
|
|
|
break;
|
|
|
|
}
|
2009-07-21 19:06:39 +00:00
|
|
|
#endif
|
2009-12-09 21:52:53 +00:00
|
|
|
resource_list_unreserve(rl, dev, child, type, rid);
|
2002-02-27 05:09:14 +00:00
|
|
|
}
|
2009-03-03 16:38:59 +00:00
|
|
|
resource_list_delete(rl, type, rid);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
struct resource_list *
|
2000-11-28 07:12:12 +00:00
|
|
|
pci_get_resource_list (device_t dev, device_t child)
|
1999-04-16 21:22:55 +00:00
|
|
|
{
|
2004-04-09 15:44:34 +00:00
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
1999-04-16 21:22:55 +00:00
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
return (&dinfo->resources);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2003-08-22 03:11:53 +00:00
|
|
|
uint32_t
|
1999-04-16 21:22:55 +00:00
|
|
|
pci_read_config_method(device_t dev, device_t child, int reg, int width)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
2000-08-28 21:48:13 +00:00
|
|
|
|
2002-06-01 05:44:45 +00:00
|
|
|
return (PCIB_READ_CONFIG(device_get_parent(dev),
|
|
|
|
cfg->bus, cfg->slot, cfg->func, reg, width));
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2002-02-27 05:09:14 +00:00
|
|
|
void
|
2006-11-07 18:55:51 +00:00
|
|
|
pci_write_config_method(device_t dev, device_t child, int reg,
|
2003-08-22 03:11:53 +00:00
|
|
|
uint32_t val, int width)
|
1999-04-16 21:22:55 +00:00
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
2000-08-28 21:48:13 +00:00
|
|
|
|
|
|
|
PCIB_WRITE_CONFIG(device_get_parent(dev),
|
2002-06-01 03:41:02 +00:00
|
|
|
cfg->bus, cfg->slot, cfg->func, reg, val, width);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
|
|
|
|
2003-02-17 21:20:35 +00:00
|
|
|
int
|
2004-04-09 15:44:34 +00:00
|
|
|
pci_child_location_str_method(device_t dev, device_t child, char *buf,
|
2003-02-17 21:20:35 +00:00
|
|
|
size_t buflen)
|
|
|
|
{
|
|
|
|
|
|
|
|
snprintf(buf, buflen, "slot=%d function=%d", pci_get_slot(child),
|
|
|
|
pci_get_function(child));
|
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
2004-04-09 15:44:34 +00:00
|
|
|
pci_child_pnpinfo_str_method(device_t dev, device_t child, char *buf,
|
2003-02-17 21:20:35 +00:00
|
|
|
size_t buflen)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo;
|
|
|
|
pcicfgregs *cfg;
|
|
|
|
|
|
|
|
dinfo = device_get_ivars(child);
|
|
|
|
cfg = &dinfo->cfg;
|
|
|
|
snprintf(buf, buflen, "vendor=0x%04x device=0x%04x subvendor=0x%04x "
|
2003-02-18 03:25:57 +00:00
|
|
|
"subdevice=0x%04x class=0x%02x%02x%02x", cfg->vendor, cfg->device,
|
|
|
|
cfg->subvendor, cfg->subdevice, cfg->baseclass, cfg->subclass,
|
|
|
|
cfg->progif);
|
2003-02-17 21:20:35 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
2003-07-01 14:08:33 +00:00
|
|
|
int
|
|
|
|
pci_assign_interrupt_method(device_t dev, device_t child)
|
|
|
|
{
|
|
|
|
struct pci_devinfo *dinfo = device_get_ivars(child);
|
|
|
|
pcicfgregs *cfg = &dinfo->cfg;
|
|
|
|
|
|
|
|
return (PCIB_ROUTE_INTERRUPT(device_get_parent(dev), child,
|
|
|
|
cfg->intpin));
|
|
|
|
}
|
|
|
|
|
1999-04-16 21:22:55 +00:00
|
|
|
static int
|
|
|
|
pci_modevent(module_t mod, int what, void *arg)
|
|
|
|
{
|
2004-06-16 09:47:26 +00:00
|
|
|
static struct cdev *pci_cdev;
|
2002-09-04 03:13:16 +00:00
|
|
|
|
1999-04-16 21:22:55 +00:00
|
|
|
switch (what) {
|
|
|
|
case MOD_LOAD:
|
1999-05-09 15:54:04 +00:00
|
|
|
STAILQ_INIT(&pci_devq);
|
2000-12-13 01:25:11 +00:00
|
|
|
pci_generation = 0;
|
2002-09-04 03:13:16 +00:00
|
|
|
pci_cdev = make_dev(&pcicdev, 0, UID_ROOT, GID_WHEEL, 0644,
|
|
|
|
"pci");
|
|
|
|
pci_load_vendor_data();
|
1999-04-16 21:22:55 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case MOD_UNLOAD:
|
2002-09-04 03:13:16 +00:00
|
|
|
destroy_dev(pci_cdev);
|
1999-04-16 21:22:55 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2002-06-01 05:44:45 +00:00
|
|
|
return (0);
|
1999-04-16 21:22:55 +00:00
|
|
|
}
|
2003-09-17 08:32:44 +00:00
|
|
|
|
2005-02-28 01:14:15 +00:00
|
|
|
void
|
2004-04-09 15:44:34 +00:00
|
|
|
pci_cfg_restore(device_t dev, struct pci_devinfo *dinfo)
|
2003-09-17 08:32:44 +00:00
|
|
|
{
|
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
/*
|
2004-04-11 07:02:49 +00:00
|
|
|
* Only do header type 0 devices. Type 1 devices are bridges,
|
|
|
|
* which we know need special treatment. Type 2 devices are
|
|
|
|
* cardbus bridges which also require special treatment.
|
|
|
|
* Other types are unknown, and we err on the side of safety
|
|
|
|
* by ignoring them.
|
2004-04-09 15:44:34 +00:00
|
|
|
*/
|
2010-07-29 20:42:38 +00:00
|
|
|
if ((dinfo->cfg.hdrtype & PCIM_HDRTYPE) != PCIM_HDRTYPE_NORMAL)
|
2004-04-09 15:44:34 +00:00
|
|
|
return;
|
2004-05-21 06:39:09 +00:00
|
|
|
|
2004-04-11 07:02:49 +00:00
|
|
|
/*
|
|
|
|
* Restore the device to full power mode. We must do this
|
|
|
|
* before we restore the registers because moving from D3 to
|
|
|
|
* D0 will cause the chip's BARs and some other registers to
|
|
|
|
* be reset to some unknown power on reset values. Cut down
|
|
|
|
* the noise on boot by doing nothing if we are already in
|
|
|
|
* state D0.
|
|
|
|
*/
|
2010-10-15 21:41:59 +00:00
|
|
|
if (pci_get_powerstate(dev) != PCI_POWERSTATE_D0)
|
2004-04-09 20:41:18 +00:00
|
|
|
pci_set_powerstate(dev, PCI_POWERSTATE_D0);
|
2011-03-31 13:22:12 +00:00
|
|
|
pci_restore_bars(dev);
|
2004-04-09 15:44:34 +00:00
|
|
|
pci_write_config(dev, PCIR_COMMAND, dinfo->cfg.cmdreg, 2);
|
|
|
|
pci_write_config(dev, PCIR_INTLINE, dinfo->cfg.intline, 1);
|
|
|
|
pci_write_config(dev, PCIR_INTPIN, dinfo->cfg.intpin, 1);
|
|
|
|
pci_write_config(dev, PCIR_MINGNT, dinfo->cfg.mingnt, 1);
|
|
|
|
pci_write_config(dev, PCIR_MAXLAT, dinfo->cfg.maxlat, 1);
|
|
|
|
pci_write_config(dev, PCIR_CACHELNSZ, dinfo->cfg.cachelnsz, 1);
|
|
|
|
pci_write_config(dev, PCIR_LATTIMER, dinfo->cfg.lattimer, 1);
|
2004-05-21 06:36:36 +00:00
|
|
|
pci_write_config(dev, PCIR_PROGIF, dinfo->cfg.progif, 1);
|
|
|
|
pci_write_config(dev, PCIR_REVID, dinfo->cfg.revid, 1);
|
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
|
|
|
/* Restore MSI and MSI-X configurations if they are present. */
|
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
|
|
|
if (dinfo->cfg.msi.msi_location != 0)
|
|
|
|
pci_resume_msi(dev);
|
2007-05-02 17:50:36 +00:00
|
|
|
if (dinfo->cfg.msix.msix_location != 0)
|
|
|
|
pci_resume_msix(dev);
|
2004-04-09 15:44:34 +00:00
|
|
|
}
|
2003-09-17 08:32:44 +00:00
|
|
|
|
2005-02-28 01:14:15 +00:00
|
|
|
void
|
2004-04-09 15:44:34 +00:00
|
|
|
pci_cfg_save(device_t dev, struct pci_devinfo *dinfo, int setstate)
|
|
|
|
{
|
|
|
|
uint32_t cls;
|
2004-04-11 07:02:49 +00:00
|
|
|
int ps;
|
2003-09-17 08:32:44 +00:00
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
/*
|
|
|
|
* Only do header type 0 devices. Type 1 devices are bridges, which
|
|
|
|
* we know need special treatment. Type 2 devices are cardbus bridges
|
|
|
|
* which also require special treatment. Other types are unknown, and
|
|
|
|
* we err on the side of safety by ignoring them. Powering down
|
|
|
|
* bridges should not be undertaken lightly.
|
|
|
|
*/
|
2010-07-29 20:42:38 +00:00
|
|
|
if ((dinfo->cfg.hdrtype & PCIM_HDRTYPE) != PCIM_HDRTYPE_NORMAL)
|
2004-04-09 15:44:34 +00:00
|
|
|
return;
|
2003-09-17 08:32:44 +00:00
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
/*
|
2004-12-08 04:35:19 +00:00
|
|
|
* Some drivers apparently write to these registers w/o updating our
|
2005-01-29 19:45:31 +00:00
|
|
|
* cached copy. No harm happens if we update the copy, so do so here
|
2004-12-08 04:35:19 +00:00
|
|
|
* so we can restore them. The COMMAND register is modified by the
|
|
|
|
* bus w/o updating the cache. This should represent the normally
|
|
|
|
* writable portion of the 'defined' part of type 0 headers. In
|
|
|
|
* theory we also need to save/restore the PCI capability structures
|
|
|
|
* we know about, but apart from power we don't know any that are
|
|
|
|
* writable.
|
2004-04-09 15:44:34 +00:00
|
|
|
*/
|
2004-05-21 06:36:36 +00:00
|
|
|
dinfo->cfg.subvendor = pci_read_config(dev, PCIR_SUBVEND_0, 2);
|
|
|
|
dinfo->cfg.subdevice = pci_read_config(dev, PCIR_SUBDEV_0, 2);
|
|
|
|
dinfo->cfg.vendor = pci_read_config(dev, PCIR_VENDOR, 2);
|
|
|
|
dinfo->cfg.device = pci_read_config(dev, PCIR_DEVICE, 2);
|
2004-04-09 15:44:34 +00:00
|
|
|
dinfo->cfg.cmdreg = pci_read_config(dev, PCIR_COMMAND, 2);
|
|
|
|
dinfo->cfg.intline = pci_read_config(dev, PCIR_INTLINE, 1);
|
|
|
|
dinfo->cfg.intpin = pci_read_config(dev, PCIR_INTPIN, 1);
|
|
|
|
dinfo->cfg.mingnt = pci_read_config(dev, PCIR_MINGNT, 1);
|
|
|
|
dinfo->cfg.maxlat = pci_read_config(dev, PCIR_MAXLAT, 1);
|
|
|
|
dinfo->cfg.cachelnsz = pci_read_config(dev, PCIR_CACHELNSZ, 1);
|
|
|
|
dinfo->cfg.lattimer = pci_read_config(dev, PCIR_LATTIMER, 1);
|
2004-05-21 06:36:36 +00:00
|
|
|
dinfo->cfg.baseclass = pci_read_config(dev, PCIR_CLASS, 1);
|
|
|
|
dinfo->cfg.subclass = pci_read_config(dev, PCIR_SUBCLASS, 1);
|
|
|
|
dinfo->cfg.progif = pci_read_config(dev, PCIR_PROGIF, 1);
|
|
|
|
dinfo->cfg.revid = pci_read_config(dev, PCIR_REVID, 1);
|
2003-09-17 08:32:44 +00:00
|
|
|
|
2004-04-09 15:44:34 +00:00
|
|
|
/*
|
2004-12-08 04:35:19 +00:00
|
|
|
* don't set the state for display devices, base peripherals and
|
|
|
|
* memory devices since bad things happen when they are powered down.
|
|
|
|
* We should (a) have drivers that can easily detach and (b) use
|
|
|
|
* generic drivers for these devices so that some device actually
|
|
|
|
* attaches. We need to make sure that when we implement (a) we don't
|
|
|
|
* power the device down on a reattach.
|
2004-04-09 15:44:34 +00:00
|
|
|
*/
|
|
|
|
cls = pci_get_class(dev);
|
2005-09-11 04:09:44 +00:00
|
|
|
if (!setstate)
|
|
|
|
return;
|
2005-09-21 19:47:00 +00:00
|
|
|
switch (pci_do_power_nodriver)
|
2005-09-11 04:09:44 +00:00
|
|
|
{
|
|
|
|
case 0: /* NO powerdown at all */
|
|
|
|
return;
|
|
|
|
case 1: /* Conservative about what to power down */
|
|
|
|
if (cls == PCIC_STORAGE)
|
|
|
|
return;
|
|
|
|
/*FALLTHROUGH*/
|
|
|
|
case 2: /* Agressive about what to power down */
|
|
|
|
if (cls == PCIC_DISPLAY || cls == PCIC_MEMORY ||
|
|
|
|
cls == PCIC_BASEPERIPH)
|
|
|
|
return;
|
|
|
|
/*FALLTHROUGH*/
|
|
|
|
case 3: /* Power down everything */
|
|
|
|
break;
|
2004-04-09 15:44:34 +00:00
|
|
|
}
|
2005-09-11 04:09:44 +00:00
|
|
|
/*
|
|
|
|
* PCI spec says we can only go into D3 state from D0 state.
|
|
|
|
* Transition from D[12] into D0 before going to D3 state.
|
|
|
|
*/
|
|
|
|
ps = pci_get_powerstate(dev);
|
|
|
|
if (ps != PCI_POWERSTATE_D0 && ps != PCI_POWERSTATE_D3)
|
|
|
|
pci_set_powerstate(dev, PCI_POWERSTATE_D0);
|
|
|
|
if (pci_get_powerstate(dev) != PCI_POWERSTATE_D3)
|
|
|
|
pci_set_powerstate(dev, PCI_POWERSTATE_D3);
|
2003-09-17 08:32:44 +00:00
|
|
|
}
|