d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
a4acc8c3df
freebsd-dev/sys/dev/pci/pci_pci.c

1424 lines
39 KiB
C
Raw Normal View History

Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
/*-
* Copyright (c) 1994,1995 Stefan Esser, Wolfgang StanglMeier
* Copyright (c) 2000 Michael Smith <msmith@freebsd.org>
* Copyright (c) 2000 BSDi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
Use __FBSDID(). Also some minor style cleanups.
2003-08-24 17:55:58 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
/*
* PCI:PCI bridge support.
*/
#include <sys/param.h>
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#include <sys/bus.h>
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
#include <sys/kernel.h>
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#include <sys/malloc.h>
Add some missing <sys/module.h> includes which are masked by the one on death-row in <sys/kernel.h>
2004-05-30 17:57:46 +00:00
#include <sys/module.h>
Properly account for prefetchable memory when a request is being made. We allow the request to go through if it matches either a prefetchable or a non-prefetchable part of the bridge. We do not check to make sure it is the right kind of memory because most drivers to not yet properly set RF_PREFETCHABLE (only cardbus seems to do so, and I'm not entirely sure it does it right). RF_PREFETCHABLE was invented for cardbus, so hasn't been properly documented yet. This is still overridable by hw.pci.allow_unsupported_io_ranges, but the need for that is greatly reduced, especially for the nvida driver. Approved by: re Reviewed by: jhb and many testers Submitted by: Matt Emmerton (although this has been reworked somewhat)
2002-12-03 08:34:20 +00:00
#include <sys/rman.h>
Convert kernel compile option PCI_ALLOW_UNSUPPORTED_IO_RANGE to a loader tunable hw.pci.allow_unsupported_io_range. Submitted by: Hiten Pandya <hiten@angelica.unixdaemons.com> Approved by: re (murray)
2002-11-13 09:42:25 +00:00
#include <sys/sysctl.h>
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#include <sys/systm.h>
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
Prefer new location of pci include files (which have only been in the tree for two or more years now), except in a few places where there's code to be compatible with older versions of FreeBSD.
2003-08-22 06:42:59 +00:00
#include <dev/pci/pcivar.h>
#include <dev/pci/pcireg.h>
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
#include <dev/pci/pci_private.h>
Prefer new location of pci include files (which have only been in the tree for two or more years now), except in a few places where there's code to be compatible with older versions of FreeBSD.
2003-08-22 06:42:59 +00:00
#include <dev/pci/pcib_private.h>
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
#include "pcib_if.h"
static int pcib_probe(device_t dev);
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
static int pcib_suspend(device_t dev);
static int pcib_resume(device_t dev);
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
static int pcib_power_for_sleep(device_t pcib, device_t dev,
int *pstate);
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
static device_method_t pcib_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, pcib_probe),
DEVMETHOD(device_attach, pcib_attach),
Add a detach for pci bridge and pci bus drivers. This allows one to theoretically unload pci bridges or pci drivers. It will also allow detach to work if one needed to detach a subtree. This is inspired by looking at the p4 commits from bms to his 5.4 tree, but I didn't look at the final results.
2005-04-29 06:22:41 +00:00
DEVMETHOD(device_detach, bus_generic_detach),
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
DEVMETHOD(device_shutdown, bus_generic_shutdown),
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
DEVMETHOD(device_suspend, pcib_suspend),
DEVMETHOD(device_resume, pcib_resume),
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
/* Bus interface */
DEVMETHOD(bus_read_ivar, pcib_read_ivar),
DEVMETHOD(bus_write_ivar, pcib_write_ivar),
DEVMETHOD(bus_alloc_resource, pcib_alloc_resource),
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#ifdef NEW_PCIB
DEVMETHOD(bus_adjust_resource, pcib_adjust_resource),
DEVMETHOD(bus_release_resource, pcib_release_resource),
#else
Add implementations of BUS_ADJUST_RESOURCE() to the PCI bus driver, generic PCI-PCI bridge driver, x86 nexus driver, and x86 Host to PCI bridge drivers.
2011-05-02 14:13:12 +00:00
DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
DEVMETHOD(bus_release_resource, bus_generic_release_resource),
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#endif
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
DEVMETHOD(bus_setup_intr, bus_generic_setup_intr),
DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr),
/* pcib interface */
DEVMETHOD(pcib_maxslots, pcib_maxslots),
DEVMETHOD(pcib_read_config, pcib_read_config),
DEVMETHOD(pcib_write_config, pcib_write_config),
DEVMETHOD(pcib_route_interrupt, pcib_route_interrupt),
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
DEVMETHOD(pcib_alloc_msi, pcib_alloc_msi),
DEVMETHOD(pcib_release_msi, pcib_release_msi),
DEVMETHOD(pcib_alloc_msix, pcib_alloc_msix),
DEVMETHOD(pcib_release_msix, pcib_release_msix),
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
DEVMETHOD(pcib_map_msi, pcib_map_msi),
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
DEVMETHOD(pcib_power_for_sleep, pcib_power_for_sleep),
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
- There's no need to overwrite the default device method with the default one. Interestingly, these are actually the default for quite some time (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9) since r52045) but even recently added device drivers do this unnecessarily. Discussed with: jhb, marcel - While at it, use DEVMETHOD_END. Discussed with: jhb - Also while at it, use __FBSDID.
2011-11-22 21:28:20 +00:00
DEVMETHOD_END
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
};
- Make pcib_devclass private to sys/dev/pci/pci_pci.c and change all the various pcib drivers to use their own private devclass_t variables for their modules. - Use the DEFINE_CLASS_0() macro to declare drivers for the various pcib drivers while I'm here.
2006-01-06 19:22:19 +00:00
static devclass_t pcib_devclass;
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
- Make pcib_devclass private to sys/dev/pci/pci_pci.c and change all the various pcib drivers to use their own private devclass_t variables for their modules. - Use the DEFINE_CLASS_0() macro to declare drivers for the various pcib drivers while I'm here.
2006-01-06 19:22:19 +00:00
DEFINE_CLASS_0(pcib, pcib_driver, pcib_methods, sizeof(struct pcib_softc));
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
DRIVER_MODULE(pcib, pci, pcib_driver, pcib_devclass, 0, 0);
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#ifdef NEW_PCIB
/*
* XXX Todo:
* - properly handle the ISA enable bit. If it is set, we should change
* the behavior of the I/O window resource and rman to not allocate the
* blocked ranges (upper 768 bytes of each 1K in the first 64k of the
* I/O port address space).
*/
/*
* Is a resource from a child device sub-allocated from one of our
* resource managers?
*/
static int
pcib_is_resource_managed(struct pcib_softc *sc, int type, struct resource *r)
{
switch (type) {
case SYS_RES_IOPORT:
return (rman_is_region_manager(r, &sc->io.rman));
case SYS_RES_MEMORY:
/* Prefetchable resources may live in either memory rman. */
if (rman_get_flags(r) & RF_PREFETCHABLE &&
rman_is_region_manager(r, &sc->pmem.rman))
return (1);
return (rman_is_region_manager(r, &sc->mem.rman));
}
return (0);
}
static int
pcib_is_window_open(struct pcib_window *pw)
{
return (pw->valid && pw->base < pw->limit);
}
/*
* XXX: If RF_ACTIVE did not also imply allocating a bus space tag and
* handle for the resource, we could pass RF_ACTIVE up to the PCI bus
* when allocating the resource windows and rely on the PCI bus driver
* to do this for us.
*/
static void
pcib_activate_window(struct pcib_softc *sc, int type)
{
PCI_ENABLE_IO(device_get_parent(sc->dev), sc->dev, type);
}
static void
pcib_write_windows(struct pcib_softc *sc, int mask)
{
device_t dev;
uint32_t val;
dev = sc->dev;
if (sc->io.valid && mask & WIN_IO) {
val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
if ((val & PCIM_BRIO_MASK) == PCIM_BRIO_32) {
pci_write_config(dev, PCIR_IOBASEH_1,
sc->io.base >> 16, 2);
pci_write_config(dev, PCIR_IOLIMITH_1,
sc->io.limit >> 16, 2);
}
pci_write_config(dev, PCIR_IOBASEL_1, sc->io.base >> 8, 1);
pci_write_config(dev, PCIR_IOLIMITL_1, sc->io.limit >> 8, 1);
}
if (mask & WIN_MEM) {
pci_write_config(dev, PCIR_MEMBASE_1, sc->mem.base >> 16, 2);
pci_write_config(dev, PCIR_MEMLIMIT_1, sc->mem.limit >> 16, 2);
}
if (sc->pmem.valid && mask & WIN_PMEM) {
val = pci_read_config(dev, PCIR_PMBASEL_1, 2);
if ((val & PCIM_BRPM_MASK) == PCIM_BRPM_64) {
pci_write_config(dev, PCIR_PMBASEH_1,
sc->pmem.base >> 32, 4);
pci_write_config(dev, PCIR_PMLIMITH_1,
sc->pmem.limit >> 32, 4);
}
pci_write_config(dev, PCIR_PMBASEL_1, sc->pmem.base >> 16, 2);
pci_write_config(dev, PCIR_PMLIMITL_1, sc->pmem.limit >> 16, 2);
}
}
static void
pcib_alloc_window(struct pcib_softc *sc, struct pcib_window *w, int type,
int flags, pci_addr_t max_address)
{
char buf[64];
int error, rid;
if (max_address != (u_long)max_address)
max_address = ~0ul;
w->rman.rm_start = 0;
w->rman.rm_end = max_address;
w->rman.rm_type = RMAN_ARRAY;
snprintf(buf, sizeof(buf), "%s %s window",
device_get_nameunit(sc->dev), w->name);
w->rman.rm_descr = strdup(buf, M_DEVBUF);
error = rman_init(&w->rman);
if (error)
panic("Failed to initialize %s %s rman",
device_get_nameunit(sc->dev), w->name);
if (!pcib_is_window_open(w))
return;
if (w->base > max_address || w->limit > max_address) {
device_printf(sc->dev,
"initial %s window has too many bits, ignoring\n", w->name);
return;
}
rid = w->reg;
w->res = bus_alloc_resource(sc->dev, type, &rid, w->base, w->limit,
w->limit - w->base + 1, flags);
if (w->res == NULL) {
device_printf(sc->dev,
"failed to allocate initial %s window: %#jx-%#jx\n",
w->name, (uintmax_t)w->base, (uintmax_t)w->limit);
w->base = max_address;
w->limit = 0;
pcib_write_windows(sc, w->mask);
return;
}
pcib_activate_window(sc, type);
error = rman_manage_region(&w->rman, rman_get_start(w->res),
rman_get_end(w->res));
if (error)
panic("Failed to initialize rman with resource");
}
/*
* Initialize I/O windows.
*/
static void
pcib_probe_windows(struct pcib_softc *sc)
{
pci_addr_t max;
device_t dev;
uint32_t val;
dev = sc->dev;
/* Determine if the I/O port window is implemented. */
val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
if (val == 0) {
/*
* If 'val' is zero, then only 16-bits of I/O space
* are supported.
*/
pci_write_config(dev, PCIR_IOBASEL_1, 0xff, 1);
if (pci_read_config(dev, PCIR_IOBASEL_1, 1) != 0) {
sc->io.valid = 1;
pci_write_config(dev, PCIR_IOBASEL_1, 0, 1);
}
} else
sc->io.valid = 1;
/* Read the existing I/O port window. */
if (sc->io.valid) {
sc->io.reg = PCIR_IOBASEL_1;
sc->io.step = 12;
sc->io.mask = WIN_IO;
sc->io.name = "I/O port";
if ((val & PCIM_BRIO_MASK) == PCIM_BRIO_32) {
sc->io.base = PCI_PPBIOBASE(
pci_read_config(dev, PCIR_IOBASEH_1, 2), val);
sc->io.limit = PCI_PPBIOLIMIT(
pci_read_config(dev, PCIR_IOLIMITH_1, 2),
pci_read_config(dev, PCIR_IOLIMITL_1, 1));
max = 0xffffffff;
} else {
sc->io.base = PCI_PPBIOBASE(0, val);
sc->io.limit = PCI_PPBIOLIMIT(0,
pci_read_config(dev, PCIR_IOLIMITL_1, 1));
max = 0xffff;
}
pcib_alloc_window(sc, &sc->io, SYS_RES_IOPORT, 0, max);
}
/* Read the existing memory window. */
sc->mem.valid = 1;
sc->mem.reg = PCIR_MEMBASE_1;
sc->mem.step = 20;
sc->mem.mask = WIN_MEM;
sc->mem.name = "memory";
sc->mem.base = PCI_PPBMEMBASE(0,
pci_read_config(dev, PCIR_MEMBASE_1, 2));
sc->mem.limit = PCI_PPBMEMLIMIT(0,
pci_read_config(dev, PCIR_MEMLIMIT_1, 2));
pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0, 0xffffffff);
/* Determine if the prefetchable memory window is implemented. */
val = pci_read_config(dev, PCIR_PMBASEL_1, 2);
if (val == 0) {
/*
* If 'val' is zero, then only 32-bits of memory space
* are supported.
*/
pci_write_config(dev, PCIR_PMBASEL_1, 0xffff, 2);
if (pci_read_config(dev, PCIR_PMBASEL_1, 2) != 0) {
sc->pmem.valid = 1;
pci_write_config(dev, PCIR_PMBASEL_1, 0, 2);
}
} else
sc->pmem.valid = 1;
/* Read the existing prefetchable memory window. */
if (sc->pmem.valid) {
sc->pmem.reg = PCIR_PMBASEL_1;
sc->pmem.step = 20;
sc->pmem.mask = WIN_PMEM;
sc->pmem.name = "prefetch";
if ((val & PCIM_BRPM_MASK) == PCIM_BRPM_64) {
sc->pmem.base = PCI_PPBMEMBASE(
pci_read_config(dev, PCIR_PMBASEH_1, 4), val);
sc->pmem.limit = PCI_PPBMEMLIMIT(
pci_read_config(dev, PCIR_PMLIMITH_1, 4),
pci_read_config(dev, PCIR_PMLIMITL_1, 2));
max = 0xffffffffffffffff;
} else {
sc->pmem.base = PCI_PPBMEMBASE(0, val);
sc->pmem.limit = PCI_PPBMEMLIMIT(0,
pci_read_config(dev, PCIR_PMLIMITL_1, 2));
max = 0xffffffff;
}
pcib_alloc_window(sc, &sc->pmem, SYS_RES_MEMORY,
RF_PREFETCHABLE, max);
}
}
#else
More fully support 64-bit bars. Prior to this commit, we supported only those bars that had addresses assigned by the BIOS and where the bridges were properly programmed. Now even unprogrammed ones work. This was needed for sun4v. We still only implement up to 2GB memory ranges, even for 64-bit bars. PCI standards at least through 2.2 say that this is the max (or 1GB is, I only know it is < 32bits). o Always define pci_addr_t as uint64_t. A pci address is always 64-bits, but some hosts can't address all of them. o Preserve the upper half of the 64-bit word during resource probing. o Test to make sure that 64-bit values can fit in a u_long (true on some platforms, but not others). Don't use those that can't. o minor pedantry about data sizes. o Better bridge resource reporting in bootverbose case. o Minor formatting changes to cope with different data types on different platforms. Submitted by: jmg, with many changes by me to fully support 64-bit addresses.
2006-10-30 19:18:46 +00:00
/*
* Is the prefetch window open (eg, can we allocate memory in it?)
*/
static int
pcib_is_prefetch_open(struct pcib_softc *sc)
{
return (sc->pmembase > 0 && sc->pmembase < sc->pmemlimit);
}
/*
* Is the nonprefetch window open (eg, can we allocate memory in it?)
*/
static int
pcib_is_nonprefetch_open(struct pcib_softc *sc)
{
return (sc->membase > 0 && sc->membase < sc->memlimit);
}
/*
* Is the io window open (eg, can we allocate ports in it?)
*/
static int
pcib_is_io_open(struct pcib_softc *sc)
{
return (sc->iobase > 0 && sc->iobase < sc->iolimit);
}
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
/*
* Get current I/O decode.
*/
static void
pcib_get_io_decode(struct pcib_softc *sc)
{
device_t dev;
uint32_t iolow;
dev = sc->dev;
iolow = pci_read_config(dev, PCIR_IOBASEL_1, 1);
if ((iolow & PCIM_BRIO_MASK) == PCIM_BRIO_32)
sc->iobase = PCI_PPBIOBASE(
pci_read_config(dev, PCIR_IOBASEH_1, 2), iolow);
else
sc->iobase = PCI_PPBIOBASE(0, iolow);
iolow = pci_read_config(dev, PCIR_IOLIMITL_1, 1);
if ((iolow & PCIM_BRIO_MASK) == PCIM_BRIO_32)
sc->iolimit = PCI_PPBIOLIMIT(
pci_read_config(dev, PCIR_IOLIMITH_1, 2), iolow);
else
sc->iolimit = PCI_PPBIOLIMIT(0, iolow);
}
/*
* Get current memory decode.
*/
static void
pcib_get_mem_decode(struct pcib_softc *sc)
{
device_t dev;
pci_addr_t pmemlow;
dev = sc->dev;
sc->membase = PCI_PPBMEMBASE(0,
pci_read_config(dev, PCIR_MEMBASE_1, 2));
sc->memlimit = PCI_PPBMEMLIMIT(0,
pci_read_config(dev, PCIR_MEMLIMIT_1, 2));
pmemlow = pci_read_config(dev, PCIR_PMBASEL_1, 2);
if ((pmemlow & PCIM_BRPM_MASK) == PCIM_BRPM_64)
sc->pmembase = PCI_PPBMEMBASE(
pci_read_config(dev, PCIR_PMBASEH_1, 4), pmemlow);
else
sc->pmembase = PCI_PPBMEMBASE(0, pmemlow);
pmemlow = pci_read_config(dev, PCIR_PMLIMITL_1, 2);
if ((pmemlow & PCIM_BRPM_MASK) == PCIM_BRPM_64)
sc->pmemlimit = PCI_PPBMEMLIMIT(
pci_read_config(dev, PCIR_PMLIMITH_1, 4), pmemlow);
else
sc->pmemlimit = PCI_PPBMEMLIMIT(0, pmemlow);
}
/*
* Restore previous I/O decode.
*/
static void
pcib_set_io_decode(struct pcib_softc *sc)
{
device_t dev;
uint32_t iohi;
dev = sc->dev;
iohi = sc->iobase >> 16;
if (iohi > 0)
pci_write_config(dev, PCIR_IOBASEH_1, iohi, 2);
pci_write_config(dev, PCIR_IOBASEL_1, sc->iobase >> 8, 1);
iohi = sc->iolimit >> 16;
if (iohi > 0)
pci_write_config(dev, PCIR_IOLIMITH_1, iohi, 2);
pci_write_config(dev, PCIR_IOLIMITL_1, sc->iolimit >> 8, 1);
}
/*
* Restore previous memory decode.
*/
static void
pcib_set_mem_decode(struct pcib_softc *sc)
{
device_t dev;
pci_addr_t pmemhi;
dev = sc->dev;
pci_write_config(dev, PCIR_MEMBASE_1, sc->membase >> 16, 2);
pci_write_config(dev, PCIR_MEMLIMIT_1, sc->memlimit >> 16, 2);
pmemhi = sc->pmembase >> 32;
if (pmemhi > 0)
pci_write_config(dev, PCIR_PMBASEH_1, pmemhi, 4);
pci_write_config(dev, PCIR_PMBASEL_1, sc->pmembase >> 16, 2);
pmemhi = sc->pmemlimit >> 32;
if (pmemhi > 0)
pci_write_config(dev, PCIR_PMLIMITH_1, pmemhi, 4);
pci_write_config(dev, PCIR_PMLIMITL_1, sc->pmemlimit >> 16, 2);
}
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#endif
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
/*
* Get current bridge configuration.
*/
static void
pcib_cfg_save(struct pcib_softc *sc)
{
device_t dev;
dev = sc->dev;
sc->command = pci_read_config(dev, PCIR_COMMAND, 2);
sc->pribus = pci_read_config(dev, PCIR_PRIBUS_1, 1);
sc->secbus = pci_read_config(dev, PCIR_SECBUS_1, 1);
sc->subbus = pci_read_config(dev, PCIR_SUBBUS_1, 1);
sc->bridgectl = pci_read_config(dev, PCIR_BRIDGECTL_1, 2);
sc->seclat = pci_read_config(dev, PCIR_SECLAT_1, 1);
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#ifndef NEW_PCIB
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
if (sc->command & PCIM_CMD_PORTEN)
pcib_get_io_decode(sc);
if (sc->command & PCIM_CMD_MEMEN)
pcib_get_mem_decode(sc);
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#endif
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
}
/*
* Restore previous bridge configuration.
*/
static void
pcib_cfg_restore(struct pcib_softc *sc)
{
device_t dev;
dev = sc->dev;
pci_write_config(dev, PCIR_COMMAND, sc->command, 2);
pci_write_config(dev, PCIR_PRIBUS_1, sc->pribus, 1);
pci_write_config(dev, PCIR_SECBUS_1, sc->secbus, 1);
pci_write_config(dev, PCIR_SUBBUS_1, sc->subbus, 1);
pci_write_config(dev, PCIR_BRIDGECTL_1, sc->bridgectl, 2);
pci_write_config(dev, PCIR_SECLAT_1, sc->seclat, 1);
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#ifdef NEW_PCIB
pcib_write_windows(sc, WIN_IO | WIN_MEM | WIN_PMEM);
#else
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
if (sc->command & PCIM_CMD_PORTEN)
pcib_set_io_decode(sc);
if (sc->command & PCIM_CMD_MEMEN)
pcib_set_mem_decode(sc);
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#endif
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
}
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
/*
* Generic device interface
*/
static int
pcib_probe(device_t dev)
{
if ((pci_get_class(dev) == PCIC_BRIDGE) &&
(pci_get_subclass(dev) == PCIS_BRIDGE_PCI)) {
device_set_desc(dev, "PCI-PCI bridge");
return(-10000);
}
return(ENXIO);
}
Export a few symbols as globals to allow subclassing of this driver. In OOP speak, you would mark these as 'protected' members. Specifically: - Make the pcib_softc struct public so it can be used by subclasses. - Make pcib_{read,write}_ivar(), pcib_alloc_resource(), pcib_maxslots(), and pcib_{read,write}_config() globals that can be used by subclasses. - Make the pcib devclass a global variable. - Move most of the pcib_attach() function into a global pcib_attach_common() function that can be called by the attach routines of subclasses. Tested on: i386, alpha, sparc64, ia64
2002-08-26 15:57:08 +00:00
void
pcib_attach_common(device_t dev)
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
{
struct pcib_softc *sc;
Add some sysctl reporting for most pci_pci bridges. We now report domain, pribus (the primary bus, eg the bus that this chip is on), secbus (the secondary bus, eg the bus immediately behind this chip) and subbus (the number of the highest bus behind this chip). Normally, this information is reported via bootverbose parameters, but that's hard to use for debugging in some cases. This adds reading of pribus to make this happen. In addition, change the narrow types to u_int to allow for easier reporting via sysctl for domain, secbus and subbus. This should have no effect, but if it does, please let me know.
2008-08-16 20:18:40 +00:00
struct sysctl_ctx_list *sctx;
struct sysctl_oid *soid;
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
sc = device_get_softc(dev);
sc->dev = dev;
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
/*
* Get current bridge configuration.
*/
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
sc->domain = pci_get_domain(dev);
sc->secstat = pci_read_config(dev, PCIR_SECSTAT_1, 2);
pcib_cfg_save(sc);
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
Add some sysctl reporting for most pci_pci bridges. We now report domain, pribus (the primary bus, eg the bus that this chip is on), secbus (the secondary bus, eg the bus immediately behind this chip) and subbus (the number of the highest bus behind this chip). Normally, this information is reported via bootverbose parameters, but that's hard to use for debugging in some cases. This adds reading of pribus to make this happen. In addition, change the narrow types to u_int to allow for easier reporting via sysctl for domain, secbus and subbus. This should have no effect, but if it does, please let me know.
2008-08-16 20:18:40 +00:00
/*
* Setup sysctl reporting nodes
*/
sctx = device_get_sysctl_ctx(dev);
soid = device_get_sysctl_tree(dev);
SYSCTL_ADD_UINT(sctx, SYSCTL_CHILDREN(soid), OID_AUTO, "domain",
Style nit. Continued lines are indented 2 spaces in this file.
2008-09-03 06:57:21 +00:00
CTLFLAG_RD, &sc->domain, 0, "Domain number");
Add some sysctl reporting for most pci_pci bridges. We now report domain, pribus (the primary bus, eg the bus that this chip is on), secbus (the secondary bus, eg the bus immediately behind this chip) and subbus (the number of the highest bus behind this chip). Normally, this information is reported via bootverbose parameters, but that's hard to use for debugging in some cases. This adds reading of pribus to make this happen. In addition, change the narrow types to u_int to allow for easier reporting via sysctl for domain, secbus and subbus. This should have no effect, but if it does, please let me know.
2008-08-16 20:18:40 +00:00
SYSCTL_ADD_UINT(sctx, SYSCTL_CHILDREN(soid), OID_AUTO, "pribus",
Style nit. Continued lines are indented 2 spaces in this file.
2008-09-03 06:57:21 +00:00
CTLFLAG_RD, &sc->pribus, 0, "Primary bus number");
Add some sysctl reporting for most pci_pci bridges. We now report domain, pribus (the primary bus, eg the bus that this chip is on), secbus (the secondary bus, eg the bus immediately behind this chip) and subbus (the number of the highest bus behind this chip). Normally, this information is reported via bootverbose parameters, but that's hard to use for debugging in some cases. This adds reading of pribus to make this happen. In addition, change the narrow types to u_int to allow for easier reporting via sysctl for domain, secbus and subbus. This should have no effect, but if it does, please let me know.
2008-08-16 20:18:40 +00:00
SYSCTL_ADD_UINT(sctx, SYSCTL_CHILDREN(soid), OID_AUTO, "secbus",
Style nit. Continued lines are indented 2 spaces in this file.
2008-09-03 06:57:21 +00:00
CTLFLAG_RD, &sc->secbus, 0, "Secondary bus number");
Add some sysctl reporting for most pci_pci bridges. We now report domain, pribus (the primary bus, eg the bus that this chip is on), secbus (the secondary bus, eg the bus immediately behind this chip) and subbus (the number of the highest bus behind this chip). Normally, this information is reported via bootverbose parameters, but that's hard to use for debugging in some cases. This adds reading of pribus to make this happen. In addition, change the narrow types to u_int to allow for easier reporting via sysctl for domain, secbus and subbus. This should have no effect, but if it does, please let me know.
2008-08-16 20:18:40 +00:00
SYSCTL_ADD_UINT(sctx, SYSCTL_CHILDREN(soid), OID_AUTO, "subbus",
Style nit. Continued lines are indented 2 spaces in this file.
2008-09-03 06:57:21 +00:00
CTLFLAG_RD, &sc->subbus, 0, "Subordinate bus number");
Add some sysctl reporting for most pci_pci bridges. We now report domain, pribus (the primary bus, eg the bus that this chip is on), secbus (the secondary bus, eg the bus immediately behind this chip) and subbus (the number of the highest bus behind this chip). Normally, this information is reported via bootverbose parameters, but that's hard to use for debugging in some cases. This adds reading of pribus to make this happen. In addition, change the narrow types to u_int to allow for easier reporting via sysctl for domain, secbus and subbus. This should have no effect, but if it does, please let me know.
2008-08-16 20:18:40 +00:00
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
/*
* Quirk handling.
*/
switch (pci_get_devid(dev)) {
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
case 0x12258086: /* Intel 82454KX/GX (Orion) */
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
{
Prefer the uintXX_t to the u_intXX_t names.
2003-08-22 03:11:53 +00:00
uint8_t supbus;
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
supbus = pci_read_config(dev, 0x41, 1);
if (supbus != 0xff) {
sc->secbus = supbus + 1;
sc->subbus = supbus + 1;
}
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
break;
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
}
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
/*
* The i82380FB mobile docking controller is a PCI-PCI bridge,
* and it is a subtractive bridge. However, the ProgIf is wrong
* so the normal setting of PCIB_SUBTRACTIVE bit doesn't
* happen. There's also a Toshiba bridge that behaves this
* way.
*/
case 0x124b8086: /* Intel 82380FB Mobile */
case 0x060513d7: /* Toshiba ???? */
sc->flags |= PCIB_SUBTRACTIVE;
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
break;
fix CardBus issue for Compaq R3000 series laptop Approved by: anholt (mentor)
2005-08-26 23:39:44 +00:00
/* Compaq R3000 BIOS sets wrong subordinate bus number. */
case 0x00dd10de:
{
char *cp;
Free allocated environment variables after use. Coverity ID: 366 Found by: Coverity Prevent
2006-04-21 19:35:03 +00:00
if ((cp = getenv("smbios.planar.maker")) == NULL)
fix CardBus issue for Compaq R3000 series laptop Approved by: anholt (mentor)
2005-08-26 23:39:44 +00:00
break;
Free allocated environment variables after use. Coverity ID: 366 Found by: Coverity Prevent
2006-04-21 19:35:03 +00:00
if (strncmp(cp, "Compal", 6) != 0) {
freeenv(cp);
fix CardBus issue for Compaq R3000 series laptop Approved by: anholt (mentor)
2005-08-26 23:39:44 +00:00
break;
Free allocated environment variables after use. Coverity ID: 366 Found by: Coverity Prevent
2006-04-21 19:35:03 +00:00
}
freeenv(cp);
if ((cp = getenv("smbios.planar.product")) == NULL)
break;
if (strncmp(cp, "08A0", 4) != 0) {
freeenv(cp);
break;
}
freeenv(cp);
fix CardBus issue for Compaq R3000 series laptop Approved by: anholt (mentor)
2005-08-26 23:39:44 +00:00
if (sc->subbus < 0xa) {
pci_write_config(dev, PCIR_SUBBUS_1, 0xa, 1);
sc->subbus = pci_read_config(dev, PCIR_SUBBUS_1, 1);
}
break;
}
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
}
- Add a new flag to the PCI-PCI driver to disable MSI on devices behind the bridge if it doesn't pass MSI messages up correctly. We set the flag in pcib_attach() if the device ID is disabled via a PCI quirk. - Disable MSI for devices behind the AMD 8131 HT-PCIX bridge. Linux has the same quirk. Tested by: no one despite repeated calls for testers
2007-01-13 04:57:37 +00:00
if (pci_msi_device_blacklisted(dev))
sc->flags |= PCIB_DISABLE_MSI;
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
/*
* Intel 815, 845 and other chipsets say they are PCI-PCI bridges,
* but have a ProgIF of 0x80. The 82801 family (AA, AB, BAM/CAM,
* BA/CA/DB and E) PCI bridges are HUB-PCI bridges, in Intelese.
* This means they act as if they were subtractively decoding
* bridges and pass all transactions. Mark them and real ProgIf 1
* parts as subtractive.
*/
if ((pci_get_devid(dev) & 0xff00ffff) == 0x24008086 ||
- Add missing constants for subclasses. - Add a few progif constants as well.
2007-03-31 20:41:00 +00:00
pci_read_config(dev, PCIR_PROGIF, 1) == PCIP_BRIDGE_PCI_SUBTRACTIVE)
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
sc->flags |= PCIB_SUBTRACTIVE;
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#ifdef NEW_PCIB
pcib_probe_windows(sc);
#endif
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
if (bootverbose) {
Make the PCI code aware of PCI domains (aka PCI segments) so we can support machines having multiple independently numbered PCI domains and don't support reenumeration without ambiguity amongst the devices as seen by the OS and represented by PCI location strings. This includes introducing a function pci_find_dbsf(9) which works like pci_find_bsf(9) but additionally takes a domain number argument and limiting pci_find_bsf(9) to only search devices in domain 0 (the only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order to no longer report false positives when searching for siblings and dupe devices in the same domain respectively. Along with this change the sole host-PCI bridge driver converted to actually make use of PCI domain support is uninorth(4), the others continue to use domain 0 only for now and need to be converted as appropriate later on. Note that this means that the format of the location strings as used by pciconf(8) has been changed and that consumers of <sys/pciio.h> potentially need to be recompiled. Suggested by: jhb Reviewed by: grehan, jhb, marcel Approved by: re (kensmith), jhb (PCI maintainer hat)
2007-09-30 11:05:18 +00:00
device_printf(dev, " domain %d\n", sc->domain);
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
device_printf(dev, " secondary bus %d\n", sc->secbus);
device_printf(dev, " subordinate bus %d\n", sc->subbus);
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#ifdef NEW_PCIB
if (pcib_is_window_open(&sc->io))
device_printf(dev, " I/O decode 0x%jx-0x%jx\n",
(uintmax_t)sc->io.base, (uintmax_t)sc->io.limit);
if (pcib_is_window_open(&sc->mem))
device_printf(dev, " memory decode 0x%jx-0x%jx\n",
(uintmax_t)sc->mem.base, (uintmax_t)sc->mem.limit);
if (pcib_is_window_open(&sc->pmem))
device_printf(dev, " prefetched decode 0x%jx-0x%jx\n",
(uintmax_t)sc->pmem.base, (uintmax_t)sc->pmem.limit);
#else
if (pcib_is_io_open(sc))
device_printf(dev, " I/O decode 0x%x-0x%x\n",
sc->iobase, sc->iolimit);
More fully support 64-bit bars. Prior to this commit, we supported only those bars that had addresses assigned by the BIOS and where the bridges were properly programmed. Now even unprogrammed ones work. This was needed for sun4v. We still only implement up to 2GB memory ranges, even for 64-bit bars. PCI standards at least through 2.2 say that this is the max (or 1GB is, I only know it is < 32bits). o Always define pci_addr_t as uint64_t. A pci address is always 64-bits, but some hosts can't address all of them. o Preserve the upper half of the 64-bit word during resource probing. o Test to make sure that 64-bit values can fit in a u_long (true on some platforms, but not others). Don't use those that can't. o minor pedantry about data sizes. o Better bridge resource reporting in bootverbose case. o Minor formatting changes to cope with different data types on different platforms. Submitted by: jmg, with many changes by me to fully support 64-bit addresses.
2006-10-30 19:18:46 +00:00
if (pcib_is_nonprefetch_open(sc))
device_printf(dev, " memory decode 0x%jx-0x%jx\n",
(uintmax_t)sc->membase, (uintmax_t)sc->memlimit);
if (pcib_is_prefetch_open(sc))
device_printf(dev, " prefetched decode 0x%jx-0x%jx\n",
(uintmax_t)sc->pmembase, (uintmax_t)sc->pmemlimit);
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#endif
More fully support 64-bit bars. Prior to this commit, we supported only those bars that had addresses assigned by the BIOS and where the bridges were properly programmed. Now even unprogrammed ones work. This was needed for sun4v. We still only implement up to 2GB memory ranges, even for 64-bit bars. PCI standards at least through 2.2 say that this is the max (or 1GB is, I only know it is < 32bits). o Always define pci_addr_t as uint64_t. A pci address is always 64-bits, but some hosts can't address all of them. o Preserve the upper half of the 64-bit word during resource probing. o Test to make sure that 64-bit values can fit in a u_long (true on some platforms, but not others). Don't use those that can't. o minor pedantry about data sizes. o Better bridge resource reporting in bootverbose case. o Minor formatting changes to cope with different data types on different platforms. Submitted by: jmg, with many changes by me to fully support 64-bit addresses.
2006-10-30 19:18:46 +00:00
else
device_printf(dev, " no prefetched decode\n");
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
if (sc->flags & PCIB_SUBTRACTIVE)
device_printf(dev, " Subtractively decoded bridge.\n");
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
}
/*
* XXX If the secondary bus number is zero, we should assign a bus number
Update a comment about not numbering pci busses. This may soon be OBE, but was sitting around in one of my trees for a while...
2008-08-17 17:34:07 +00:00
* since the BIOS hasn't, then initialise the bridge. A simple
* bus_alloc_resource with the a couple of busses seems like the right
* approach, but we don't know what busses the BIOS might have already
* assigned to other bridges on this bus that probe later than we do.
*
* If the subordinate bus number is less than the secondary bus number,
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
* we should pick a better value. One sensible alternative would be to
* pick 255; the only tradeoff here is that configuration transactions
Update a comment about not numbering pci busses. This may soon be OBE, but was sitting around in one of my trees for a while...
2008-08-17 17:34:07 +00:00
* would be more widely routed than absolutely necessary. We could
* then do a walk of the tree later and fix it.
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
*/
Explicitly enable busmastering on PCI-PCI bridges. Transactions initiated on the secondary side of a bridge will not be propagated to the primary bus unless this is enabled. Busmastering is not enabled by default (we have relied on firmware to set this bit to date). The OS needs to set it for any bridges not configured by system firmware. Tested by: Steve Polyack korvus comcast net MFC after: 2 weeks
2012-08-06 19:49:57 +00:00
/*
* Always enable busmastering on bridges so that transactions
* initiated on the secondary bus are passed through to the
* primary bus.
*/
pci_enable_busmaster(dev);
Export a few symbols as globals to allow subclassing of this driver. In OOP speak, you would mark these as 'protected' members. Specifically: - Make the pcib_softc struct public so it can be used by subclasses. - Make pcib_{read,write}_ivar(), pcib_alloc_resource(), pcib_maxslots(), and pcib_{read,write}_config() globals that can be used by subclasses. - Make the pcib devclass a global variable. - Move most of the pcib_attach() function into a global pcib_attach_common() function that can be called by the attach routines of subclasses. Tested on: i386, alpha, sparc64, ia64
2002-08-26 15:57:08 +00:00
}
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
Export pcib_attach() as a "protected" for use in subclasses of the PCI-PCI bridge driver.
2002-09-06 22:14:00 +00:00
int
Export a few symbols as globals to allow subclassing of this driver. In OOP speak, you would mark these as 'protected' members. Specifically: - Make the pcib_softc struct public so it can be used by subclasses. - Make pcib_{read,write}_ivar(), pcib_alloc_resource(), pcib_maxslots(), and pcib_{read,write}_config() globals that can be used by subclasses. - Make the pcib devclass a global variable. - Move most of the pcib_attach() function into a global pcib_attach_common() function that can be called by the attach routines of subclasses. Tested on: i386, alpha, sparc64, ia64
2002-08-26 15:57:08 +00:00
pcib_attach(device_t dev)
{
struct pcib_softc *sc;
device_t child;
pcib_attach_common(dev);
sc = device_get_softc(dev);
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
if (sc->secbus != 0) {
Prefer the physical bus number of the PCI bus as the unit of the pciX device created.
2002-09-06 16:09:07 +00:00
child = device_add_child(dev, "pci", sc->secbus);
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
if (child != NULL)
return(bus_generic_attach(dev));
Update a comment about not numbering pci busses. This may soon be OBE, but was sitting around in one of my trees for a while...
2008-08-17 17:34:07 +00:00
}
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
/* no secondary bus; we should have fixed this */
return(0);
}
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
int
pcib_suspend(device_t dev)
{
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
device_t pcib;
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
int dstate, error;
pcib_cfg_save(device_get_softc(dev));
error = bus_generic_suspend(dev);
Introduce a new tunable 'hw.pci.do_power_suspend'. This tunable lets you avoid PCI power state transition from D0 to D3 for suspending case. Default is 1 or enabled.
2010-10-20 16:47:09 +00:00
if (error == 0 && pci_do_power_suspend) {
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
dstate = PCI_POWERSTATE_D3;
pcib = device_get_parent(device_get_parent(dev));
if (PCIB_POWER_FOR_SLEEP(pcib, dev, &dstate) == 0)
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
pci_set_powerstate(dev, dstate);
}
return (error);
}
int
pcib_resume(device_t dev)
{
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
device_t pcib;
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
if (pci_do_power_resume) {
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
pcib = device_get_parent(device_get_parent(dev));
if (PCIB_POWER_FOR_SLEEP(pcib, dev, NULL) == 0)
Implement a rudimentary suspend/resume methods for PCI P2P bridge. Reviewed by: jhb, imp
2009-12-10 01:01:53 +00:00
pci_set_powerstate(dev, PCI_POWERSTATE_D0);
}
pcib_cfg_restore(device_get_softc(dev));
return (bus_generic_resume(dev));
}
Export a few symbols as globals to allow subclassing of this driver. In OOP speak, you would mark these as 'protected' members. Specifically: - Make the pcib_softc struct public so it can be used by subclasses. - Make pcib_{read,write}_ivar(), pcib_alloc_resource(), pcib_maxslots(), and pcib_{read,write}_config() globals that can be used by subclasses. - Make the pcib devclass a global variable. - Move most of the pcib_attach() function into a global pcib_attach_common() function that can be called by the attach routines of subclasses. Tested on: i386, alpha, sparc64, ia64
2002-08-26 15:57:08 +00:00
int
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pcib_softc *sc = device_get_softc(dev);
switch (which) {
Make the PCI code aware of PCI domains (aka PCI segments) so we can support machines having multiple independently numbered PCI domains and don't support reenumeration without ambiguity amongst the devices as seen by the OS and represented by PCI location strings. This includes introducing a function pci_find_dbsf(9) which works like pci_find_bsf(9) but additionally takes a domain number argument and limiting pci_find_bsf(9) to only search devices in domain 0 (the only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order to no longer report false positives when searching for siblings and dupe devices in the same domain respectively. Along with this change the sole host-PCI bridge driver converted to actually make use of PCI domain support is uninorth(4), the others continue to use domain 0 only for now and need to be converted as appropriate later on. Note that this means that the format of the location strings as used by pciconf(8) has been changed and that consumers of <sys/pciio.h> potentially need to be recompiled. Suggested by: jhb Reviewed by: grehan, jhb, marcel Approved by: re (kensmith), jhb (PCI maintainer hat)
2007-09-30 11:05:18 +00:00
case PCIB_IVAR_DOMAIN:
*result = sc->domain;
return(0);
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
case PCIB_IVAR_BUS:
*result = sc->secbus;
return(0);
}
return(ENOENT);
}
Export a few symbols as globals to allow subclassing of this driver. In OOP speak, you would mark these as 'protected' members. Specifically: - Make the pcib_softc struct public so it can be used by subclasses. - Make pcib_{read,write}_ivar(), pcib_alloc_resource(), pcib_maxslots(), and pcib_{read,write}_config() globals that can be used by subclasses. - Make the pcib devclass a global variable. - Move most of the pcib_attach() function into a global pcib_attach_common() function that can be called by the attach routines of subclasses. Tested on: i386, alpha, sparc64, ia64
2002-08-26 15:57:08 +00:00
int
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
pcib_write_ivar(device_t dev, device_t child, int which, uintptr_t value)
{
struct pcib_softc *sc = device_get_softc(dev);
switch (which) {
Make the PCI code aware of PCI domains (aka PCI segments) so we can support machines having multiple independently numbered PCI domains and don't support reenumeration without ambiguity amongst the devices as seen by the OS and represented by PCI location strings. This includes introducing a function pci_find_dbsf(9) which works like pci_find_bsf(9) but additionally takes a domain number argument and limiting pci_find_bsf(9) to only search devices in domain 0 (the only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order to no longer report false positives when searching for siblings and dupe devices in the same domain respectively. Along with this change the sole host-PCI bridge driver converted to actually make use of PCI domain support is uninorth(4), the others continue to use domain 0 only for now and need to be converted as appropriate later on. Note that this means that the format of the location strings as used by pciconf(8) has been changed and that consumers of <sys/pciio.h> potentially need to be recompiled. Suggested by: jhb Reviewed by: grehan, jhb, marcel Approved by: re (kensmith), jhb (PCI maintainer hat)
2007-09-30 11:05:18 +00:00
case PCIB_IVAR_DOMAIN:
return(EINVAL);
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
case PCIB_IVAR_BUS:
sc->secbus = value;
Make the PCI code aware of PCI domains (aka PCI segments) so we can support machines having multiple independently numbered PCI domains and don't support reenumeration without ambiguity amongst the devices as seen by the OS and represented by PCI location strings. This includes introducing a function pci_find_dbsf(9) which works like pci_find_bsf(9) but additionally takes a domain number argument and limiting pci_find_bsf(9) to only search devices in domain 0 (the only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order to no longer report false positives when searching for siblings and dupe devices in the same domain respectively. Along with this change the sole host-PCI bridge driver converted to actually make use of PCI domain support is uninorth(4), the others continue to use domain 0 only for now and need to be converted as appropriate later on. Note that this means that the format of the location strings as used by pciconf(8) has been changed and that consumers of <sys/pciio.h> potentially need to be recompiled. Suggested by: jhb Reviewed by: grehan, jhb, marcel Approved by: re (kensmith), jhb (PCI maintainer hat)
2007-09-30 11:05:18 +00:00
return(0);
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
}
return(ENOENT);
}
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#ifdef NEW_PCIB
/*
* Attempt to allocate a resource from the existing resources assigned
* to a window.
*/
static struct resource *
pcib_suballoc_resource(struct pcib_softc *sc, struct pcib_window *w,
device_t child, int type, int *rid, u_long start, u_long end, u_long count,
u_int flags)
{
struct resource *res;
if (!pcib_is_window_open(w))
return (NULL);
res = rman_reserve_resource(&w->rman, start, end, count,
flags & ~RF_ACTIVE, child);
if (res == NULL)
return (NULL);
if (bootverbose)
device_printf(sc->dev,
"allocated %s range (%#lx-%#lx) for rid %x of %s\n",
w->name, rman_get_start(res), rman_get_end(res), *rid,
pcib_child_name(child));
rman_set_rid(res, *rid);
/*
* If the resource should be active, pass that request up the
* tree. This assumes the parent drivers can handle
* activating sub-allocated resources.
*/
if (flags & RF_ACTIVE) {
if (bus_activate_resource(child, type, *rid, res) != 0) {
rman_release_resource(res);
return (NULL);
}
}
return (res);
}
/*
* Attempt to grow a window to make room for a given resource request.
* The 'step' parameter is log_2 of the desired I/O window's alignment.
*/
static int
pcib_grow_window(struct pcib_softc *sc, struct pcib_window *w, int type,
u_long start, u_long end, u_long count, u_int flags)
{
Add a 'wmask' variable to hold the expression '(1ul << w->step) - 1' in pcib_grow_window(). This makes the code slightly easier to read and prevents the type of bug fixed in r237271. MFC after: 3 days
2012-06-19 16:06:27 +00:00
u_long align, start_free, end_free, front, back, wmask;
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
int error, rid;
/*
* Clamp the desired resource range to the maximum address
* this window supports. Reject impossible requests.
*/
if (!w->valid)
return (EINVAL);
if (end > w->rman.rm_end)
end = w->rman.rm_end;
if (start + count - 1 > end || start + count < start)
return (EINVAL);
Add a 'wmask' variable to hold the expression '(1ul << w->step) - 1' in pcib_grow_window(). This makes the code slightly easier to read and prevents the type of bug fixed in r237271. MFC after: 3 days
2012-06-19 16:06:27 +00:00
wmask = (1ul << w->step) - 1;
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
/*
* If there is no resource at all, just try to allocate enough
* aligned space for this resource.
*/
if (w->res == NULL) {
if (RF_ALIGNMENT(flags) < w->step) {
flags &= ~RF_ALIGNMENT_MASK;
flags |= RF_ALIGNMENT_LOG2(w->step);
}
Add a 'wmask' variable to hold the expression '(1ul << w->step) - 1' in pcib_grow_window(). This makes the code slightly easier to read and prevents the type of bug fixed in r237271. MFC after: 3 days
2012-06-19 16:06:27 +00:00
start &= ~wmask;
end |= wmask;
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
count = roundup2(count, 1ul << w->step);
rid = w->reg;
w->res = bus_alloc_resource(sc->dev, type, &rid, start, end,
count, flags & ~RF_ACTIVE);
if (w->res == NULL) {
if (bootverbose)
device_printf(sc->dev,
"failed to allocate initial %s window (%#lx-%#lx,%#lx)\n",
w->name, start, end, count);
return (ENXIO);
}
if (bootverbose)
device_printf(sc->dev,
"allocated initial %s window of %#lx-%#lx\n",
w->name, rman_get_start(w->res),
rman_get_end(w->res));
error = rman_manage_region(&w->rman, rman_get_start(w->res),
rman_get_end(w->res));
if (error) {
if (bootverbose)
device_printf(sc->dev,
"failed to add initial %s window to rman\n",
w->name);
bus_release_resource(sc->dev, type, w->reg, w->res);
w->res = NULL;
return (error);
}
pcib_activate_window(sc, type);
goto updatewin;
}
/*
* See if growing the window would help. Compute the minimum
* amount of address space needed on both the front and back
* ends of the existing window to satisfy the allocation.
*
* For each end, build a candidate region adjusting for the
* required alignment, etc. If there is a free region at the
* edge of the window, grow from the inner edge of the free
* region. Otherwise grow from the window boundary.
*
* XXX: Special case: if w->res is completely empty and the
* request size is larger than w->res, we should find the
* optimal aligned buffer containing w->res and allocate that.
*/
if (bootverbose)
device_printf(sc->dev,
"attempting to grow %s window for (%#lx-%#lx,%#lx)\n",
w->name, start, end, count);
align = 1ul << RF_ALIGNMENT(flags);
if (start < rman_get_start(w->res)) {
if (rman_first_free_region(&w->rman, &start_free, &end_free) !=
0 || start_free != rman_get_start(w->res))
Fix a couple of bugs that prevented windows in PCI-PCI bridges from growing "downward" (moving the start address down). First, an off by one error caused the end address to be moved down an extra alignment chunk unnecessarily. Second, when aligning the new candidate starting address, the wrong bits were masked off. Tested by: Andrey Zonov andrey zonov org MFC after: 3 days
2012-06-13 15:04:50 +00:00
end_free = rman_get_start(w->res);
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
if (end_free > end)
Fix a couple of bugs that prevented windows in PCI-PCI bridges from growing "downward" (moving the start address down). First, an off by one error caused the end address to be moved down an extra alignment chunk unnecessarily. Second, when aligning the new candidate starting address, the wrong bits were masked off. Tested by: Andrey Zonov andrey zonov org MFC after: 3 days
2012-06-13 15:04:50 +00:00
end_free = end + 1;
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
/* Move end_free down until it is properly aligned. */
end_free &= ~(align - 1);
Fix some off-by-one errors with the ending address of candidate regions when attempting to grow a window.
2011-06-10 13:24:56 +00:00
end_free--;
front = end_free - (count - 1);
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
/*
* The resource would now be allocated at (front,
* end_free). Ensure that fits in the (start, end)
* bounds. end_free is checked above. If 'front' is
* ok, ensure it is properly aligned for this window.
* Also check for underflow.
*/
if (front >= start && front <= end_free) {
if (bootverbose)
printf("\tfront candidate range: %#lx-%#lx\n",
front, end_free);
Add a 'wmask' variable to hold the expression '(1ul << w->step) - 1' in pcib_grow_window(). This makes the code slightly easier to read and prevents the type of bug fixed in r237271. MFC after: 3 days
2012-06-19 16:06:27 +00:00
front &= ~wmask;
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
front = rman_get_start(w->res) - front;
} else
front = 0;
} else
front = 0;
if (end > rman_get_end(w->res)) {
if (rman_last_free_region(&w->rman, &start_free, &end_free) !=
0 || end_free != rman_get_end(w->res))
start_free = rman_get_end(w->res) + 1;
if (start_free < start)
start_free = start;
/* Move start_free up until it is properly aligned. */
start_free = roundup2(start_free, align);
Fix some off-by-one errors with the ending address of candidate regions when attempting to grow a window.
2011-06-10 13:24:56 +00:00
back = start_free + count - 1;
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
/*
* The resource would now be allocated at (start_free,
* back). Ensure that fits in the (start, end)
* bounds. start_free is checked above. If 'back' is
* ok, ensure it is properly aligned for this window.
* Also check for overflow.
*/
if (back <= end && start_free <= back) {
if (bootverbose)
printf("\tback candidate range: %#lx-%#lx\n",
start_free, back);
Add a 'wmask' variable to hold the expression '(1ul << w->step) - 1' in pcib_grow_window(). This makes the code slightly easier to read and prevents the type of bug fixed in r237271. MFC after: 3 days
2012-06-19 16:06:27 +00:00
back |= wmask;
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
back -= rman_get_end(w->res);
} else
back = 0;
} else
back = 0;
/*
* Try to allocate the smallest needed region first.
* If that fails, fall back to the other region.
*/
error = ENOSPC;
while (front != 0 || back != 0) {
if (front != 0 && (front <= back || back == 0)) {
error = bus_adjust_resource(sc->dev, type, w->res,
rman_get_start(w->res) - front,
rman_get_end(w->res));
if (error == 0)
break;
front = 0;
} else {
error = bus_adjust_resource(sc->dev, type, w->res,
rman_get_start(w->res),
rman_get_end(w->res) + back);
if (error == 0)
break;
back = 0;
}
}
if (error)
return (error);
if (bootverbose)
device_printf(sc->dev, "grew %s window to %#lx-%#lx\n",
w->name, rman_get_start(w->res), rman_get_end(w->res));
/* Add the newly allocated region to the resource manager. */
if (w->base != rman_get_start(w->res)) {
KASSERT(w->limit == rman_get_end(w->res), ("both ends moved"));
error = rman_manage_region(&w->rman, rman_get_start(w->res),
w->base - 1);
} else {
KASSERT(w->limit != rman_get_end(w->res),
("neither end moved"));
error = rman_manage_region(&w->rman, w->limit + 1,
rman_get_end(w->res));
}
if (error) {
if (bootverbose)
device_printf(sc->dev,
"failed to expand %s resource manager\n", w->name);
bus_adjust_resource(sc->dev, type, w->res, w->base, w->limit);
return (error);
}
updatewin:
/* Save the new window. */
w->base = rman_get_start(w->res);
w->limit = rman_get_end(w->res);
Add a 'wmask' variable to hold the expression '(1ul << w->step) - 1' in pcib_grow_window(). This makes the code slightly easier to read and prevents the type of bug fixed in r237271. MFC after: 3 days
2012-06-19 16:06:27 +00:00
KASSERT((w->base & wmask) == 0, ("start address is not aligned"));
KASSERT((w->limit & wmask) == wmask, ("end address is not aligned"));
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
pcib_write_windows(sc, w->mask);
return (0);
}
/*
* We have to trap resource allocation requests and ensure that the bridge
* is set up to, or capable of handling them.
*/
struct resource *
pcib_alloc_resource(device_t dev, device_t child, int type, int *rid,
u_long start, u_long end, u_long count, u_int flags)
{
struct pcib_softc *sc;
struct resource *r;
sc = device_get_softc(dev);
/*
* VGA resources are decoded iff the VGA enable bit is set in
* the bridge control register. VGA resources do not fall into
* the resource windows and are passed up to the parent.
*/
if ((type == SYS_RES_IOPORT && pci_is_vga_ioport_range(start, end)) ||
(type == SYS_RES_MEMORY && pci_is_vga_memory_range(start, end))) {
if (sc->bridgectl & PCIB_BCR_VGA_ENABLE)
return (bus_generic_alloc_resource(dev, child, type,
rid, start, end, count, flags));
else
return (NULL);
}
switch (type) {
case SYS_RES_IOPORT:
r = pcib_suballoc_resource(sc, &sc->io, child, type, rid, start,
end, count, flags);
For subtractively decoding bridges, don't try to grow windows but pass the request up the tree in order to be on the safe side. Growing windows in this case would mean to switch resources to positive decoding and it's unclear how to correctly handle this. At least with ALi/ULi M5249 PCI-PCI bridges, this also just doesn't work out of the box. Reviewed by: jhb MFC after: 3 days
2012-06-27 22:17:52 +00:00
if (r != NULL || (sc->flags & PCIB_SUBTRACTIVE) != 0)
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
break;
if (pcib_grow_window(sc, &sc->io, type, start, end, count,
flags) == 0)
r = pcib_suballoc_resource(sc, &sc->io, child, type,
rid, start, end, count, flags);
break;
case SYS_RES_MEMORY:
/*
* For prefetchable resources, prefer the prefetchable
* memory window, but fall back to the regular memory
* window if that fails. Try both windows before
* attempting to grow a window in case the firmware
* has used a range in the regular memory window to
* map a prefetchable BAR.
*/
if (flags & RF_PREFETCHABLE) {
r = pcib_suballoc_resource(sc, &sc->pmem, child, type,
rid, start, end, count, flags);
if (r != NULL)
break;
}
r = pcib_suballoc_resource(sc, &sc->mem, child, type, rid,
start, end, count, flags);
For subtractively decoding bridges, don't try to grow windows but pass the request up the tree in order to be on the safe side. Growing windows in this case would mean to switch resources to positive decoding and it's unclear how to correctly handle this. At least with ALi/ULi M5249 PCI-PCI bridges, this also just doesn't work out of the box. Reviewed by: jhb MFC after: 3 days
2012-06-27 22:17:52 +00:00
if (r != NULL || (sc->flags & PCIB_SUBTRACTIVE) != 0)
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
break;
if (flags & RF_PREFETCHABLE) {
if (pcib_grow_window(sc, &sc->pmem, type, start, end,
count, flags) == 0) {
r = pcib_suballoc_resource(sc, &sc->pmem, child,
type, rid, start, end, count, flags);
if (r != NULL)
break;
}
}
if (pcib_grow_window(sc, &sc->mem, type, start, end, count,
flags & ~RF_PREFETCHABLE) == 0)
r = pcib_suballoc_resource(sc, &sc->mem, child, type,
rid, start, end, count, flags);
break;
default:
return (bus_generic_alloc_resource(dev, child, type, rid,
start, end, count, flags));
}
/*
* If attempts to suballocate from the window fail but this is a
* subtractive bridge, pass the request up the tree.
*/
if (sc->flags & PCIB_SUBTRACTIVE && r == NULL)
return (bus_generic_alloc_resource(dev, child, type, rid,
start, end, count, flags));
return (r);
}
int
pcib_adjust_resource(device_t bus, device_t child, int type, struct resource *r,
u_long start, u_long end)
{
struct pcib_softc *sc;
sc = device_get_softc(bus);
if (pcib_is_resource_managed(sc, type, r))
return (rman_adjust_resource(r, start, end));
return (bus_generic_adjust_resource(bus, child, type, r, start, end));
}
int
pcib_release_resource(device_t dev, device_t child, int type, int rid,
struct resource *r)
{
struct pcib_softc *sc;
int error;
sc = device_get_softc(dev);
if (pcib_is_resource_managed(sc, type, r)) {
if (rman_get_flags(r) & RF_ACTIVE) {
error = bus_deactivate_resource(child, type, rid, r);
if (error)
return (error);
}
return (rman_release_resource(r));
}
return (bus_generic_release_resource(dev, child, type, rid, r));
}
#else
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
/*
* We have to trap resource allocation requests and ensure that the bridge
* is set up to, or capable of handling them.
*/
Export a few symbols as globals to allow subclassing of this driver. In OOP speak, you would mark these as 'protected' members. Specifically: - Make the pcib_softc struct public so it can be used by subclasses. - Make pcib_{read,write}_ivar(), pcib_alloc_resource(), pcib_maxslots(), and pcib_{read,write}_config() globals that can be used by subclasses. - Make the pcib devclass a global variable. - Move most of the pcib_attach() function into a global pcib_attach_common() function that can be called by the attach routines of subclasses. Tested on: i386, alpha, sparc64, ia64
2002-08-26 15:57:08 +00:00
struct resource *
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
pcib_alloc_resource(device_t dev, device_t child, int type, int *rid,
For the I/O port case, we need to set ok to 1 if we have what looks like a valid range. We already do this in the memory case (although the code there is somewhat different than the I/o case because we have to deal with different kinds of memory). Since most laptops don't have non-subtractive bridges, this wasn't seen in practice. Evidentally the Compaq R3000 hits this problem with PC Cards. Some minor style fixes while I'm here. Submitted by: Jung-uk Kim
2005-02-18 17:35:03 +00:00
u_long start, u_long end, u_long count, u_int flags)
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
{
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
struct pcib_softc *sc = device_get_softc(dev);
Don't try to print a NULL string during boot. If a device doesn't have a valid name yet, just omit the name during the bootverbose printfs. MFC after: 1 week
2006-11-09 18:04:53 +00:00
const char *name, *suffix;
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
int ok;
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
/*
* Fail the allocation for this range if it's not supported.
*/
Don't try to print a NULL string during boot. If a device doesn't have a valid name yet, just omit the name during the bootverbose printfs. MFC after: 1 week
2006-11-09 18:04:53 +00:00
name = device_get_nameunit(child);
if (name == NULL) {
name = "";
suffix = "";
} else
suffix = " ";
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
switch (type) {
case SYS_RES_IOPORT:
Properly account for prefetchable memory when a request is being made. We allow the request to go through if it matches either a prefetchable or a non-prefetchable part of the bridge. We do not check to make sure it is the right kind of memory because most drivers to not yet properly set RF_PREFETCHABLE (only cardbus seems to do so, and I'm not entirely sure it does it right). RF_PREFETCHABLE was invented for cardbus, so hasn't been properly documented yet. This is still overridable by hw.pci.allow_unsupported_io_ranges, but the need for that is greatly reduced, especially for the nvida driver. Approved by: re Reviewed by: jhb and many testers Submitted by: Matt Emmerton (although this has been reworked somewhat)
2002-12-03 08:34:20 +00:00
ok = 0;
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
if (!pcib_is_io_open(sc))
break;
ok = (start >= sc->iobase && end <= sc->iolimit);
In pcib_alloc_resource() check if the resource allocation request is for the VGA I/O or memory ranges, when it's not within the default ranges decoded by the bridge. When allocation for VGA addresses is attempted, check that the bridge has the VGA Enable bit set before allowing it. As such, newbusified VGA drivers can allocate their resources when the VGA adapter is behind a PCI-to-PCI bridge. Reviewed by: imp@, jhb@
2005-04-29 02:15:40 +00:00
/*
* Make sure we allow access to VGA I/O addresses when the
* bridge has the "VGA Enable" bit set.
*/
if (!ok && pci_is_vga_ioport_range(start, end))
ok = (sc->bridgectl & PCIB_BCR_VGA_ENABLE) ? 1 : 0;
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
if ((sc->flags & PCIB_SUBTRACTIVE) == 0) {
if (!ok) {
if (start < sc->iobase)
start = sc->iobase;
if (end > sc->iolimit)
end = sc->iolimit;
For the I/O port case, we need to set ok to 1 if we have what looks like a valid range. We already do this in the memory case (although the code there is somewhat different than the I/o case because we have to deal with different kinds of memory). Since most laptops don't have non-subtractive bridges, this wasn't seen in practice. Evidentally the Compaq R3000 hits this problem with PC Cards. Some minor style fixes while I'm here. Submitted by: Jung-uk Kim
2005-02-18 17:35:03 +00:00
if (start < end)
ok = 1;
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
}
Convert kernel compile option PCI_ALLOW_UNSUPPORTED_IO_RANGE to a loader tunable hw.pci.allow_unsupported_io_range. Submitted by: Hiten Pandya <hiten@angelica.unixdaemons.com> Approved by: re (murray)
2002-11-13 09:42:25 +00:00
} else {
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
ok = 1;
Don't adjust ranges at all for subtractive bridges. The simple-minded stuff we're doing is too simple-minded, so back it out for now.
2009-03-15 06:40:57 +00:00
#if 0
Two fixes: (1) Fix pcib_read/write_config prototypes. (2) When contrainting a resource request for a 'subtractive' bridge, it is important to select a range outside the base/limit registers, since those are the only values known to not possibly work. On my HP laptop, the base bridge excludes I/O ports 0xa000-0xafff, however that was the range we were passing up the tree. Instead, when a range spans the "hole" we now arbitrarily pick the range just above the hole to allocate from. All of my rl and xl cards, at a minimum, started working again on this laptop with those fixes.
2009-03-14 14:08:53 +00:00
/*
* If we overlap with the subtractive range, then
* pick the upper range to use.
*/
if (start < sc->iolimit && end > sc->iobase)
start = sc->iolimit + 1;
Don't adjust ranges at all for subtractive bridges. The simple-minded stuff we're doing is too simple-minded, so back it out for now.
2009-03-15 06:40:57 +00:00
#endif
Convert kernel compile option PCI_ALLOW_UNSUPPORTED_IO_RANGE to a loader tunable hw.pci.allow_unsupported_io_range. Submitted by: Hiten Pandya <hiten@angelica.unixdaemons.com> Approved by: re (murray)
2002-11-13 09:42:25 +00:00
}
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
if (end < start) {
For the I/O port case, we need to set ok to 1 if we have what looks like a valid range. We already do this in the memory case (although the code there is somewhat different than the I/o case because we have to deal with different kinds of memory). Since most laptops don't have non-subtractive bridges, this wasn't seen in practice. Evidentally the Compaq R3000 hits this problem with PC Cards. Some minor style fixes while I'm here. Submitted by: Jung-uk Kim
2005-02-18 17:35:03 +00:00
device_printf(dev, "ioport: end (%lx) < start (%lx)\n",
end, start);
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
start = 0;
end = 0;
ok = 0;
}
if (!ok) {
Don't try to print a NULL string during boot. If a device doesn't have a valid name yet, just omit the name during the bootverbose printfs. MFC after: 1 week
2006-11-09 18:04:53 +00:00
device_printf(dev, "%s%srequested unsupported I/O "
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
"range 0x%lx-0x%lx (decoding 0x%x-0x%x)\n",
Don't try to print a NULL string during boot. If a device doesn't have a valid name yet, just omit the name during the bootverbose printfs. MFC after: 1 week
2006-11-09 18:04:53 +00:00
name, suffix, start, end, sc->iobase, sc->iolimit);
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
return (NULL);
}
if (bootverbose)
For the I/O port case, we need to set ok to 1 if we have what looks like a valid range. We already do this in the memory case (although the code there is somewhat different than the I/o case because we have to deal with different kinds of memory). Since most laptops don't have non-subtractive bridges, this wasn't seen in practice. Evidentally the Compaq R3000 hits this problem with PC Cards. Some minor style fixes while I'm here. Submitted by: Jung-uk Kim
2005-02-18 17:35:03 +00:00
device_printf(dev,
Don't try to print a NULL string during boot. If a device doesn't have a valid name yet, just omit the name during the bootverbose printfs. MFC after: 1 week
2006-11-09 18:04:53 +00:00
"%s%srequested I/O range 0x%lx-0x%lx: in range\n",
name, suffix, start, end);
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
break;
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
case SYS_RES_MEMORY:
Properly account for prefetchable memory when a request is being made. We allow the request to go through if it matches either a prefetchable or a non-prefetchable part of the bridge. We do not check to make sure it is the right kind of memory because most drivers to not yet properly set RF_PREFETCHABLE (only cardbus seems to do so, and I'm not entirely sure it does it right). RF_PREFETCHABLE was invented for cardbus, so hasn't been properly documented yet. This is still overridable by hw.pci.allow_unsupported_io_ranges, but the need for that is greatly reduced, especially for the nvida driver. Approved by: re Reviewed by: jhb and many testers Submitted by: Matt Emmerton (although this has been reworked somewhat)
2002-12-03 08:34:20 +00:00
ok = 0;
if (pcib_is_nonprefetch_open(sc))
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
ok = ok || (start >= sc->membase && end <= sc->memlimit);
Properly account for prefetchable memory when a request is being made. We allow the request to go through if it matches either a prefetchable or a non-prefetchable part of the bridge. We do not check to make sure it is the right kind of memory because most drivers to not yet properly set RF_PREFETCHABLE (only cardbus seems to do so, and I'm not entirely sure it does it right). RF_PREFETCHABLE was invented for cardbus, so hasn't been properly documented yet. This is still overridable by hw.pci.allow_unsupported_io_ranges, but the need for that is greatly reduced, especially for the nvida driver. Approved by: re Reviewed by: jhb and many testers Submitted by: Matt Emmerton (although this has been reworked somewhat)
2002-12-03 08:34:20 +00:00
if (pcib_is_prefetch_open(sc))
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
ok = ok || (start >= sc->pmembase && end <= sc->pmemlimit);
In pcib_alloc_resource() check if the resource allocation request is for the VGA I/O or memory ranges, when it's not within the default ranges decoded by the bridge. When allocation for VGA addresses is attempted, check that the bridge has the VGA Enable bit set before allowing it. As such, newbusified VGA drivers can allocate their resources when the VGA adapter is behind a PCI-to-PCI bridge. Reviewed by: imp@, jhb@
2005-04-29 02:15:40 +00:00
/*
* Make sure we allow access to VGA memory addresses when the
* bridge has the "VGA Enable" bit set.
*/
if (!ok && pci_is_vga_memory_range(start, end))
ok = (sc->bridgectl & PCIB_BCR_VGA_ENABLE) ? 1 : 0;
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
if ((sc->flags & PCIB_SUBTRACTIVE) == 0) {
if (!ok) {
ok = 1;
if (flags & RF_PREFETCHABLE) {
if (pcib_is_prefetch_open(sc)) {
if (start < sc->pmembase)
start = sc->pmembase;
if (end > sc->pmemlimit)
end = sc->pmemlimit;
} else {
ok = 0;
}
} else { /* non-prefetchable */
if (pcib_is_nonprefetch_open(sc)) {
if (start < sc->membase)
start = sc->membase;
if (end > sc->memlimit)
end = sc->memlimit;
} else {
ok = 0;
}
}
Properly account for prefetchable memory when a request is being made. We allow the request to go through if it matches either a prefetchable or a non-prefetchable part of the bridge. We do not check to make sure it is the right kind of memory because most drivers to not yet properly set RF_PREFETCHABLE (only cardbus seems to do so, and I'm not entirely sure it does it right). RF_PREFETCHABLE was invented for cardbus, so hasn't been properly documented yet. This is still overridable by hw.pci.allow_unsupported_io_ranges, but the need for that is greatly reduced, especially for the nvida driver. Approved by: re Reviewed by: jhb and many testers Submitted by: Matt Emmerton (although this has been reworked somewhat)
2002-12-03 08:34:20 +00:00
}
} else if (!ok) {
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
ok = 1; /* subtractive bridge: always ok */
Don't adjust ranges at all for subtractive bridges. The simple-minded stuff we're doing is too simple-minded, so back it out for now.
2009-03-15 06:40:57 +00:00
#if 0
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
if (pcib_is_nonprefetch_open(sc)) {
Two fixes: (1) Fix pcib_read/write_config prototypes. (2) When contrainting a resource request for a 'subtractive' bridge, it is important to select a range outside the base/limit registers, since those are the only values known to not possibly work. On my HP laptop, the base bridge excludes I/O ports 0xa000-0xafff, however that was the range we were passing up the tree. Instead, when a range spans the "hole" we now arbitrarily pick the range just above the hole to allocate from. All of my rl and xl cards, at a minimum, started working again on this laptop with those fixes.
2009-03-14 14:08:53 +00:00
if (start < sc->memlimit && end > sc->membase)
start = sc->memlimit + 1;
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
}
if (pcib_is_prefetch_open(sc)) {
Two fixes: (1) Fix pcib_read/write_config prototypes. (2) When contrainting a resource request for a 'subtractive' bridge, it is important to select a range outside the base/limit registers, since those are the only values known to not possibly work. On my HP laptop, the base bridge excludes I/O ports 0xa000-0xafff, however that was the range we were passing up the tree. Instead, when a range spans the "hole" we now arbitrarily pick the range just above the hole to allocate from. All of my rl and xl cards, at a minimum, started working again on this laptop with those fixes.
2009-03-14 14:08:53 +00:00
if (start < sc->pmemlimit && end > sc->pmembase)
start = sc->pmemlimit + 1;
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
}
Don't adjust ranges at all for subtractive bridges. The simple-minded stuff we're doing is too simple-minded, so back it out for now.
2009-03-15 06:40:57 +00:00
#endif
Convert kernel compile option PCI_ALLOW_UNSUPPORTED_IO_RANGE to a loader tunable hw.pci.allow_unsupported_io_range. Submitted by: Hiten Pandya <hiten@angelica.unixdaemons.com> Approved by: re (murray)
2002-11-13 09:42:25 +00:00
}
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
if (end < start) {
For the I/O port case, we need to set ok to 1 if we have what looks like a valid range. We already do this in the memory case (although the code there is somewhat different than the I/o case because we have to deal with different kinds of memory). Since most laptops don't have non-subtractive bridges, this wasn't seen in practice. Evidentally the Compaq R3000 hits this problem with PC Cards. Some minor style fixes while I'm here. Submitted by: Jung-uk Kim
2005-02-18 17:35:03 +00:00
device_printf(dev, "memory: end (%lx) < start (%lx)\n",
end, start);
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
start = 0;
end = 0;
ok = 0;
}
if (!ok && bootverbose)
device_printf(dev,
Don't try to print a NULL string during boot. If a device doesn't have a valid name yet, just omit the name during the bootverbose printfs. MFC after: 1 week
2006-11-09 18:04:53 +00:00
"%s%srequested unsupported memory range %#lx-%#lx "
More fully support 64-bit bars. Prior to this commit, we supported only those bars that had addresses assigned by the BIOS and where the bridges were properly programmed. Now even unprogrammed ones work. This was needed for sun4v. We still only implement up to 2GB memory ranges, even for 64-bit bars. PCI standards at least through 2.2 say that this is the max (or 1GB is, I only know it is < 32bits). o Always define pci_addr_t as uint64_t. A pci address is always 64-bits, but some hosts can't address all of them. o Preserve the upper half of the 64-bit word during resource probing. o Test to make sure that 64-bit values can fit in a u_long (true on some platforms, but not others). Don't use those that can't. o minor pedantry about data sizes. o Better bridge resource reporting in bootverbose case. o Minor formatting changes to cope with different data types on different platforms. Submitted by: jmg, with many changes by me to fully support 64-bit addresses.
2006-10-30 19:18:46 +00:00
"(decoding %#jx-%#jx, %#jx-%#jx)\n",
Don't try to print a NULL string during boot. If a device doesn't have a valid name yet, just omit the name during the bootverbose printfs. MFC after: 1 week
2006-11-09 18:04:53 +00:00
name, suffix, start, end,
More fully support 64-bit bars. Prior to this commit, we supported only those bars that had addresses assigned by the BIOS and where the bridges were properly programmed. Now even unprogrammed ones work. This was needed for sun4v. We still only implement up to 2GB memory ranges, even for 64-bit bars. PCI standards at least through 2.2 say that this is the max (or 1GB is, I only know it is < 32bits). o Always define pci_addr_t as uint64_t. A pci address is always 64-bits, but some hosts can't address all of them. o Preserve the upper half of the 64-bit word during resource probing. o Test to make sure that 64-bit values can fit in a u_long (true on some platforms, but not others). Don't use those that can't. o minor pedantry about data sizes. o Better bridge resource reporting in bootverbose case. o Minor formatting changes to cope with different data types on different platforms. Submitted by: jmg, with many changes by me to fully support 64-bit addresses.
2006-10-30 19:18:46 +00:00
(uintmax_t)sc->membase, (uintmax_t)sc->memlimit,
(uintmax_t)sc->pmembase, (uintmax_t)sc->pmemlimit);
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
if (!ok)
return (NULL);
if (bootverbose)
Don't try to print a NULL string during boot. If a device doesn't have a valid name yet, just omit the name during the bootverbose printfs. MFC after: 1 week
2006-11-09 18:04:53 +00:00
device_printf(dev,"%s%srequested memory range "
For the I/O port case, we need to set ok to 1 if we have what looks like a valid range. We already do this in the memory case (although the code there is somewhat different than the I/o case because we have to deal with different kinds of memory). Since most laptops don't have non-subtractive bridges, this wasn't seen in practice. Evidentally the Compaq R3000 hits this problem with PC Cards. Some minor style fixes while I'm here. Submitted by: Jung-uk Kim
2005-02-18 17:35:03 +00:00
"0x%lx-0x%lx: good\n",
Don't try to print a NULL string during boot. If a device doesn't have a valid name yet, just omit the name during the bootverbose printfs. MFC after: 1 week
2006-11-09 18:04:53 +00:00
name, suffix, start, end);
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
break;
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
default:
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
break;
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
}
Add support for subtractive decoding bridges. These bridges pass all signals to addresses to the child busses. Typically, ProgIf of 1 means a subtractive bridge. However, Intel has a whole lot of ones with a ProgIf of 80 that are also subtractive. We cope with these bridges too. This eliminates hw.pci.allow_unsupported_io_range because that had almost the same effect as these patches (almost means 'buggy'). Remove the bogus checks for ISA bus locations: these cycles aren't special and are only passed by transparent bridges. We allow any range to succeed. If the range is a superset of the range that's decoded, trim the resource to that range. Otherwise, pass the range unchanged. This will change the location that PC Card and CardBus cards are attached. This might bogusly cause some overlapping allocation that wasn't present before, but the overlapping fixes need to be in the pci level. There's also a few formatting changes here.
2004-01-11 06:52:31 +00:00
/*
* Bridge is OK decoding this resource, so pass it up.
*/
For the I/O port case, we need to set ok to 1 if we have what looks like a valid range. We already do this in the memory case (although the code there is somewhat different than the I/o case because we have to deal with different kinds of memory). Since most laptops don't have non-subtractive bridges, this wasn't seen in practice. Evidentally the Compaq R3000 hits this problem with PC Cards. Some minor style fixes while I'm here. Submitted by: Jung-uk Kim
2005-02-18 17:35:03 +00:00
return (bus_generic_alloc_resource(dev, child, type, rid, start, end,
count, flags));
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
}
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
2011-05-03 17:37:24 +00:00
#endif
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
/*
* PCIB interface.
*/
Export a few symbols as globals to allow subclassing of this driver. In OOP speak, you would mark these as 'protected' members. Specifically: - Make the pcib_softc struct public so it can be used by subclasses. - Make pcib_{read,write}_ivar(), pcib_alloc_resource(), pcib_maxslots(), and pcib_{read,write}_config() globals that can be used by subclasses. - Make the pcib devclass a global variable. - Move most of the pcib_attach() function into a global pcib_attach_common() function that can be called by the attach routines of subclasses. Tested on: i386, alpha, sparc64, ia64
2002-08-26 15:57:08 +00:00
int
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
pcib_maxslots(device_t dev)
{
- We have access to our own device_t here, so use pci_read_config rather than finding our parent pcib and using its PCI_READ_CONFIG method. - Fix the defines for the 32-bit I/O decode registers, and properly process the 16-bit versions. Now we will correctly check that I/O resources behind the bridge are going to be decoded. - Bring the quirk for the Orion PCI:PCI bridge in here (since it seems to want to set the secondary/supplementary bus numbers). - Use PCI_SLOTMAX rather than a magic number.
2000-12-12 13:20:35 +00:00
return(PCI_SLOTMAX);
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
}
/*
* Since we are a child of a PCI bus, its parent must support the pcib interface.
*/
Prefer the uintXX_t to the u_intXX_t names.
2003-08-22 03:11:53 +00:00
uint32_t
Two fixes: (1) Fix pcib_read/write_config prototypes. (2) When contrainting a resource request for a 'subtractive' bridge, it is important to select a range outside the base/limit registers, since those are the only values known to not possibly work. On my HP laptop, the base bridge excludes I/O ports 0xa000-0xafff, however that was the range we were passing up the tree. Instead, when a range spans the "hole" we now arbitrarily pick the range just above the hole to allocate from. All of my rl and xl cards, at a minimum, started working again on this laptop with those fixes.
2009-03-14 14:08:53 +00:00
pcib_read_config(device_t dev, u_int b, u_int s, u_int f, u_int reg, int width)
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
{
return(PCIB_READ_CONFIG(device_get_parent(device_get_parent(dev)), b, s, f, reg, width));
}
Export a few symbols as globals to allow subclassing of this driver. In OOP speak, you would mark these as 'protected' members. Specifically: - Make the pcib_softc struct public so it can be used by subclasses. - Make pcib_{read,write}_ivar(), pcib_alloc_resource(), pcib_maxslots(), and pcib_{read,write}_config() globals that can be used by subclasses. - Make the pcib devclass a global variable. - Move most of the pcib_attach() function into a global pcib_attach_common() function that can be called by the attach routines of subclasses. Tested on: i386, alpha, sparc64, ia64
2002-08-26 15:57:08 +00:00
void
Two fixes: (1) Fix pcib_read/write_config prototypes. (2) When contrainting a resource request for a 'subtractive' bridge, it is important to select a range outside the base/limit registers, since those are the only values known to not possibly work. On my HP laptop, the base bridge excludes I/O ports 0xa000-0xafff, however that was the range we were passing up the tree. Instead, when a range spans the "hole" we now arbitrarily pick the range just above the hole to allocate from. All of my rl and xl cards, at a minimum, started working again on this laptop with those fixes.
2009-03-14 14:08:53 +00:00
pcib_write_config(device_t dev, u_int b, u_int s, u_int f, u_int reg, uint32_t val, int width)
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
{
PCIB_WRITE_CONFIG(device_get_parent(device_get_parent(dev)), b, s, f, reg, val, width);
}
/*
* Route an interrupt across a PCI bridge.
*/
Make the base pcib_route_interrupt method available to other pci-pci bridge sub-classes. This allows the powerpc kernel to build again. Forgotten by: benno Spotted by: grehan
2003-01-14 11:37:56 +00:00
int
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
pcib_route_interrupt(device_t pcib, device_t dev, int pin)
{
device_t bus;
int parent_intpin;
int intnum;
/*
*
* The PCI standard defines a swizzle of the child-side device/intpin to
* the parent-side intpin as follows.
*
* device = device on child bus
* child_intpin = intpin on child bus slot (0-3)
* parent_intpin = intpin on parent bus slot (0-3)
*
* parent_intpin = (device + child_intpin) % 4
*/
Calculate routed interrupts using the slot number from the device and not that of the bridge. Approved by: re (jhb)
2003-05-22 17:45:26 +00:00
parent_intpin = (pci_get_slot(dev) + (pin - 1)) % 4;
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
/*
* Our parent is a PCI bus. Its parent must export the pcib interface
* which includes the ability to route interrupts.
*/
bus = device_get_parent(pcib);
intnum = PCIB_ROUTE_INTERRUPT(device_get_parent(bus), pcib, parent_intpin + 1);
Trim a few things from the dmesg output and stick them under bootverbose to cut down on the clutter including PCI interrupt routing, MTRR, pcibios, etc. Discussed with: USENIX Cabal
2004-07-01 07:46:29 +00:00
if (PCI_INTERRUPT_VALID(intnum) && bootverbose) {
Make the printf messages when routing interrupts more consistent in the various PCI bridge drivers.
2002-09-05 17:08:35 +00:00
device_printf(pcib, "slot %d INT%c is routed to irq %d\n",
pci_get_slot(dev), 'A' + pin - 1, intnum);
Don't claim to have routed an interrupt when the method actually returned an error.
2002-02-12 01:28:49 +00:00
}
Next phase in the PCI subsystem cleanup. - Move PCI core code to dev/pci. - Split bridge code out into separate modules. - Remove the descriptive strings from the bridge drivers. If you want to know what a device is, use pciconf. Add support for broadly identifying devices based on class/subclass, and for parsing a preloaded device identification database so that if you want to waste the memory, you can identify *anything* we know about. - Remove machine-dependant code from the core PCI code. APIC interrupt mapping is performed by shadowing the intline register in machine- dependant code. - Bring interrupt routing support to the Alpha (although many platforms don't yet support routing or mapping interrupts entirely correctly). This resulted in spamming <sys/bus.h> into more places than it really should have gone. - Put sys/dev on the kernel/modules include path. This avoids having to change *all* the pci*.h includes.
2000-12-08 22:11:23 +00:00
return(intnum);
}
Add a function host_pcib_get_bnsno() that attempts to determine the bus number of the child bus of a host to PCI bridge by reading from proprietary configuration registers in the host to PCI bridge devices. Approved by: re
2002-11-22 17:50:47 +00:00
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
/* Pass request to alloc MSI/MSI-X messages up to the parent bridge. */
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
int
pcib_alloc_msi(device_t pcib, device_t dev, int count, int maxcount, int *irqs)
{
Fix a typo in pcib_alloc_msi{x} which resulted in the device's, not the bridge's, softc to be used to check the PCIB_DISABLE_MSI flag. This resulted in randomly allowing or denying MSI interrupts based on whatever value the driver happened to store at sizeof(device_t) bytes into its softc. I noticed this when I stopped getting MSI interrupts after slighly re-arranging mxge's softc yesterday.
2007-05-23 15:31:00 +00:00
struct pcib_softc *sc = device_get_softc(pcib);
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
device_t bus;
- Add a new flag to the PCI-PCI driver to disable MSI on devices behind the bridge if it doesn't pass MSI messages up correctly. We set the flag in pcib_attach() if the device ID is disabled via a PCI quirk. - Disable MSI for devices behind the AMD 8131 HT-PCIX bridge. Linux has the same quirk. Tested by: no one despite repeated calls for testers
2007-01-13 04:57:37 +00:00
if (sc->flags & PCIB_DISABLE_MSI)
return (ENXIO);
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
bus = device_get_parent(pcib);
return (PCIB_ALLOC_MSI(device_get_parent(bus), dev, count, maxcount,
irqs));
}
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
/* Pass request to release MSI/MSI-X messages up to the parent bridge. */
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
int
pcib_release_msi(device_t pcib, device_t dev, int count, int *irqs)
{
device_t bus;
bus = device_get_parent(pcib);
return (PCIB_RELEASE_MSI(device_get_parent(bus), dev, count, irqs));
}
/* Pass request to alloc an MSI-X message up to the parent bridge. */
int
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
pcib_alloc_msix(device_t pcib, device_t dev, int *irq)
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
{
Fix a typo in pcib_alloc_msi{x} which resulted in the device's, not the bridge's, softc to be used to check the PCIB_DISABLE_MSI flag. This resulted in randomly allowing or denying MSI interrupts based on whatever value the driver happened to store at sizeof(device_t) bytes into its softc. I noticed this when I stopped getting MSI interrupts after slighly re-arranging mxge's softc yesterday.
2007-05-23 15:31:00 +00:00
struct pcib_softc *sc = device_get_softc(pcib);
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
device_t bus;
- Add a new flag to the PCI-PCI driver to disable MSI on devices behind the bridge if it doesn't pass MSI messages up correctly. We set the flag in pcib_attach() if the device ID is disabled via a PCI quirk. - Disable MSI for devices behind the AMD 8131 HT-PCIX bridge. Linux has the same quirk. Tested by: no one despite repeated calls for testers
2007-01-13 04:57:37 +00:00
if (sc->flags & PCIB_DISABLE_MSI)
return (ENXIO);
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
bus = device_get_parent(pcib);
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
return (PCIB_ALLOC_MSIX(device_get_parent(bus), dev, irq));
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
}
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
/* Pass request to release an MSI-X message up to the parent bridge. */
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support. - First off, device drivers really do need to know if they are allocating MSI or MSI-X messages. MSI requires allocating powerof2() messages for example where MSI-X does not. To address this, split out the MSI-X support from pci_msi_count() and pci_alloc_msi() into new driver-visible functions pci_msix_count() and pci_alloc_msix(). As a result, pci_msi_count() now just returns a count of the max supported MSI messages for the device, and pci_alloc_msi() only tries to allocate MSI messages. To get a count of the max supported MSI-X messages, use pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix(). pci_release_msi() still handles both MSI and MSI-X messages, however. As a result of this change, drivers using the existing API will only use MSI messages and will no longer try to use MSI-X messages. - Because MSI-X allows for each message to have its own data and address values (and thus does not require all of the messages to have their MD vectors allocated as a group), some devices allow for "sparse" use of MSI-X message slots. For example, if a device supports 8 messages but the OS is only able to allocate 2 messages, the device may make the best use of 2 IRQs if it enables the messages at slots 1 and 4 rather than default of using the first N slots (or indicies) at 1 and 2. To support this, add a new pci_remap_msix() function that a driver may call after a successful pci_alloc_msix() (but before allocating any of the SYS_RES_IRQ resources) to allow the allocated IRQ resources to be assigned to different message indices. For example, from the earlier example, after pci_alloc_msix() returned a value of 2, the driver would call pci_remap_msix() passing in array of integers { 1, 4 } as the new message indices to use. The rid's for the SYS_RES_IRQ resources will always match the message indices. Thus, after the call to pci_remap_msix() the driver would be able to access the first message in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based rather than 0-based so that they will always correspond to the rid values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt). To support this API, a new PCIB_REMAP_MSIX() method was added to the pcib interface to change the message index for a single IRQ. Tested by: scottl
2007-01-22 21:48:44 +00:00
int
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
pcib_release_msix(device_t pcib, device_t dev, int irq)
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support. - First off, device drivers really do need to know if they are allocating MSI or MSI-X messages. MSI requires allocating powerof2() messages for example where MSI-X does not. To address this, split out the MSI-X support from pci_msi_count() and pci_alloc_msi() into new driver-visible functions pci_msix_count() and pci_alloc_msix(). As a result, pci_msi_count() now just returns a count of the max supported MSI messages for the device, and pci_alloc_msi() only tries to allocate MSI messages. To get a count of the max supported MSI-X messages, use pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix(). pci_release_msi() still handles both MSI and MSI-X messages, however. As a result of this change, drivers using the existing API will only use MSI messages and will no longer try to use MSI-X messages. - Because MSI-X allows for each message to have its own data and address values (and thus does not require all of the messages to have their MD vectors allocated as a group), some devices allow for "sparse" use of MSI-X message slots. For example, if a device supports 8 messages but the OS is only able to allocate 2 messages, the device may make the best use of 2 IRQs if it enables the messages at slots 1 and 4 rather than default of using the first N slots (or indicies) at 1 and 2. To support this, add a new pci_remap_msix() function that a driver may call after a successful pci_alloc_msix() (but before allocating any of the SYS_RES_IRQ resources) to allow the allocated IRQ resources to be assigned to different message indices. For example, from the earlier example, after pci_alloc_msix() returned a value of 2, the driver would call pci_remap_msix() passing in array of integers { 1, 4 } as the new message indices to use. The rid's for the SYS_RES_IRQ resources will always match the message indices. Thus, after the call to pci_remap_msix() the driver would be able to access the first message in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based rather than 0-based so that they will always correspond to the rid values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt). To support this API, a new PCIB_REMAP_MSIX() method was added to the pcib interface to change the message index for a single IRQ. Tested by: scottl
2007-01-22 21:48:44 +00:00
{
device_t bus;
bus = device_get_parent(pcib);
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
return (PCIB_RELEASE_MSIX(device_get_parent(bus), dev, irq));
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support. - First off, device drivers really do need to know if they are allocating MSI or MSI-X messages. MSI requires allocating powerof2() messages for example where MSI-X does not. To address this, split out the MSI-X support from pci_msi_count() and pci_alloc_msi() into new driver-visible functions pci_msix_count() and pci_alloc_msix(). As a result, pci_msi_count() now just returns a count of the max supported MSI messages for the device, and pci_alloc_msi() only tries to allocate MSI messages. To get a count of the max supported MSI-X messages, use pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix(). pci_release_msi() still handles both MSI and MSI-X messages, however. As a result of this change, drivers using the existing API will only use MSI messages and will no longer try to use MSI-X messages. - Because MSI-X allows for each message to have its own data and address values (and thus does not require all of the messages to have their MD vectors allocated as a group), some devices allow for "sparse" use of MSI-X message slots. For example, if a device supports 8 messages but the OS is only able to allocate 2 messages, the device may make the best use of 2 IRQs if it enables the messages at slots 1 and 4 rather than default of using the first N slots (or indicies) at 1 and 2. To support this, add a new pci_remap_msix() function that a driver may call after a successful pci_alloc_msix() (but before allocating any of the SYS_RES_IRQ resources) to allow the allocated IRQ resources to be assigned to different message indices. For example, from the earlier example, after pci_alloc_msix() returned a value of 2, the driver would call pci_remap_msix() passing in array of integers { 1, 4 } as the new message indices to use. The rid's for the SYS_RES_IRQ resources will always match the message indices. Thus, after the call to pci_remap_msix() the driver would be able to access the first message in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based rather than 0-based so that they will always correspond to the rid values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt). To support this API, a new PCIB_REMAP_MSIX() method was added to the pcib interface to change the message index for a single IRQ. Tested by: scottl
2007-01-22 21:48:44 +00:00
}
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
/* Pass request to map MSI/MSI-X message up to parent bridge. */
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
int
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
pcib_map_msi(device_t pcib, device_t dev, int irq, uint64_t *addr,
uint32_t *data)
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
{
device_t bus;
SATA device on some nForce based boards could get confused if MSI is not used but MSI to HyperTransport IRQ mapping is enabled, and would act as if MSI is turned on, resulting in interrupt loss. This commit will, 1. enable MSI mapping on a device only when MSI is enabled for that device and the MSI address matches the HT mapping window. 2. enable MSI mapping on a bridge only when a downstream device is allocated an MSI address in the mapping window PR: kern/118842 Reviewed by: jhb MFC after: 1 week
2008-07-23 09:44:36 +00:00
int error;
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
bus = device_get_parent(pcib);
SATA device on some nForce based boards could get confused if MSI is not used but MSI to HyperTransport IRQ mapping is enabled, and would act as if MSI is turned on, resulting in interrupt loss. This commit will, 1. enable MSI mapping on a device only when MSI is enabled for that device and the MSI address matches the HT mapping window. 2. enable MSI mapping on a bridge only when a downstream device is allocated an MSI address in the mapping window PR: kern/118842 Reviewed by: jhb MFC after: 1 week
2008-07-23 09:44:36 +00:00
error = PCIB_MAP_MSI(device_get_parent(bus), dev, irq, addr, data);
if (error)
return (error);
pci_ht_map_msi(pcib, *addr);
return (0);
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
}
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
/* Pass request for device power state up to parent bridge. */
int
pcib_power_for_sleep(device_t pcib, device_t dev, int *pstate)
{
device_t bus;
bus = device_get_parent(pcib);
return (PCIB_POWER_FOR_SLEEP(bus, dev, pstate));
}
Reference in New Issue Copy Permalink