d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
db2156bc49
freebsd-nq/sys/dev/acpica/acpi_pcib_acpi.c

788 lines
23 KiB
C
Raw Normal View History

Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
/*-
* Copyright (c) 2000 Michael Smith
* 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.
*
* 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.
*/
Fix SCM ID's.
2005-03-02 09:22:34 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
#include "opt_acpi.h"
Native PCI-express HotPlug support. PCI-express HotPlug support is implemented via bits in the slot registers of the PCI-express capability of the downstream port along with an interrupt that triggers when bits in the slot status register change. This is implemented for FreeBSD by adding HotPlug support to the PCI-PCI bridge driver which attaches to the virtual PCI-PCI bridges representing downstream ports on HotPlug slots. The PCI-PCI bridge driver registers an interrupt handler to receive HotPlug events. It also uses the slot registers to determine the current HotPlug state and drive an internal HotPlug state machine. For simplicty of implementation, the PCI-PCI bridge device detaches and deletes the child PCI device when a card is removed from a slot and creates and attaches a PCI child device when a card is inserted into the slot. The PCI-PCI bridge driver provides a bus_child_present which claims that child devices are present on HotPlug-capable slots only when a card is inserted. Rather than requiring a timeout in the RC for config accesses to not-present children, the pcib_read/write_config methods fail all requests when a card is not present (or not yet ready). These changes include support for various optional HotPlug capabilities such as a power controller, mechanical latch, electro-mechanical interlock, indicators, and an attention button. It also includes support for devices which require waiting for command completion events before initiating a subsequent HotPlug command. However, it has only been tested on ExpressCard systems which support surprise removal and have none of these optional capabilities. PCI-express HotPlug support is conditional on the PCI_HP option which is enabled by default on arm64, x86, and powerpc. Reviewed by: adrian, imp, vangyzen (older versions) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D6136
2016-05-05 22:26:23 +00:00
#include "opt_pci.h"
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
#include <sys/param.h>
#include <sys/bus.h>
Implement PCI interrupt routing using the ACPI data attached to the PCI bus object. This should deal both with already-routed interrupts as well as devices that need an interrupt routed. Note that it *doesn't* deal with interlocked interrupt dependancies, nor does it select between interrupt options in a smart way. These are optimisations that need further work.
2001-07-05 07:20:51 +00:00
#include <sys/kernel.h>
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#include <sys/limits.h>
Style fixes.
2004-05-28 16:38:37 +00:00
#include <sys/malloc.h>
Add missing <sys/module.h> includes
2004-05-30 20:08:47 +00:00
#include <sys/module.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/rman.h>
Make the lower range of the memory area 0x80000000 again. Also introduce hw.{pci,acpi}.host_mem_start tunable to change this. MFC: ASAP
2004-10-11 21:10:23 +00:00
#include <sys/sysctl.h>
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
Import ACPICA 20090521.
2009-06-05 18:44:36 +00:00
#include <contrib/dev/acpica/include/acpi.h>
#include <contrib/dev/acpica/include/accommon.h>
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
#include <dev/acpica/acpivar.h>
#include <machine/pci_cfgreg.h>
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#include <dev/pci/pcireg.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:06:16 +00:00
#include <dev/pci/pcivar.h>
#include <dev/pci/pcib_private.h>
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
#include "pcib_if.h"
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
#include <dev/acpica/acpi_pcibvar.h>
Style fixes.
2004-05-28 16:38:37 +00:00
/* Hooks for the ACPI CA debugging infrastructure. */
Update for new debug layer constant names in the ACPI CA 20010615 import.
2001-06-29 20:32:29 +00:00
#define _COMPONENT ACPI_BUS
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
ACPI_MODULE_NAME("PCI_ACPI")
- Convert a lot of homebrew debugging output to use the ACPI CA debugging infrastructure. It's not perfect, but it's a lot better than what we've been using so far. The following rules apply to this: o BSD component names should be capitalised o Layer names should be taken from the non-CA set for now. We may elect to add some new BSD-specific layers later. - Make it possible to turn off selective debugging flags or layers by listing them in debug.acpi.layer or debug.acpi.level prefixed with !. - Fully implement support for avoiding nodes in the ACPI namespace. Nodes may be listed in the debug.acpi.avoid environment variable; these nodes and all their children will be ignored (although still scanned over) by ACPI functions which scan the namespace. Multiple nodes can be specified, separated by whitespace. - Implement support for selectively disabling ACPI subsystem components via the debug.acpi.disable environment variable. The following components can be disabled: o bus creation/scanning of the ACPI 'bus' o children attachment of children to the ACPI 'bus' o button the acpi_button control-method button driver o ec the acpi_ec embedded-controller driver o isa acpi replacement of PnP BIOS for ISA device discovery o lid the control-method lid switch driver o pci pci root-bus discovery o processor CPU power/speed management o thermal system temperature detection and control o timer ACPI timecounter Multiple components may be disabled by specifying their name(s) separated by whitespace. - Add support for ioctl registration. ACPI subsystem components may register ioctl handlers with the /dev/acpi generic ioctl handler, allowing us to avoid the need for a multitude of /dev/acpi* control devices, etc.
2000-12-08 09:16:20 +00:00
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
struct acpi_hpcib_softc {
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
device_t ap_dev;
ACPI_HANDLE ap_handle;
Add support for NUMA domains to bus dma tags. This causes all memory allocated with a tag to come from the specified domain if it meets the other constraints provided by the tag. Automatically create a tag at the root of each bus specifying the domain local to that bus if available. Reviewed by: jhb, kib Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13545
2018-01-12 23:34:16 +00:00
bus_dma_tag_t ap_dma_tag;
Move flags into a private ivar so it can't collide with device flags. Unify the code to disable GPEs with the enable code. Shutdown is handled the same way. ACPI now does all wake/sleep prep for child devices so now they no longer need to call external functions in the suspend/resume path. Add the flags to non-ACPI busses (i.e., pci).
2004-06-30 16:08:03 +00:00
int ap_flags;
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
uint32_t ap_osc_ctl;
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
int ap_segment; /* PCI domain */
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
int ap_bus; /* bios-assigned bus number */
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
int ap_addr; /* device/func of PCI-Host bridge */
Implement PCI interrupt routing using the ACPI data attached to the PCI bus object. This should deal both with already-routed interrupts as well as devices that need an interrupt routed. Note that it *doesn't* deal with interlocked interrupt dependancies, nor does it select between interrupt options in a smart way. These are optimisations that need further work.
2001-07-05 07:20:51 +00:00
ACPI_BUFFER ap_prt; /* interrupt routing table */
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#ifdef NEW_PCIB
struct pcib_host_resources ap_host_res;
#endif
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
};
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
static int acpi_pcib_acpi_probe(device_t bus);
static int acpi_pcib_acpi_attach(device_t bus);
Style fixes.
2004-05-28 16:38:37 +00:00
static int acpi_pcib_read_ivar(device_t dev, device_t child,
int which, uintptr_t *result);
static int acpi_pcib_write_ivar(device_t dev, device_t child,
int which, uintptr_t value);
pcib_read_config and pcib_write_config take u_int params.
2009-02-05 18:40:42 +00:00
static uint32_t acpi_pcib_read_config(device_t dev, u_int bus,
u_int slot, u_int func, u_int reg, int bytes);
static void acpi_pcib_write_config(device_t dev, u_int bus,
u_int slot, u_int func, u_int reg, uint32_t data,
int bytes);
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
static int acpi_pcib_acpi_route_interrupt(device_t pcib,
Style fixes.
2004-05-28 16:38:37 +00:00
device_t dev, int pin);
Give Host-PCI bridge drivers their own pcib_alloc_msi() and pcib_alloc_msix() methods instead of using the method from the generic PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI specific logic soon.
2006-12-12 19:27:01 +00:00
static int acpi_pcib_alloc_msi(device_t pcib, device_t dev,
int count, int maxcount, int *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
static int acpi_pcib_map_msi(device_t pcib, device_t dev,
int irq, uint64_t *addr, uint32_t *data);
Give Host-PCI bridge drivers their own pcib_alloc_msi() and pcib_alloc_msix() methods instead of using the method from the generic PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI specific logic soon.
2006-12-12 19:27:01 +00:00
static int acpi_pcib_alloc_msix(device_t pcib, device_t dev,
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
int *irq);
Omnibus PCI commit: o Save and restore bars for suspend/resume as well as for D3->D0 transitions. o preallocate resources that the PCI devices use to avoid resource conflicts o lazy allocation of resources not allocated by the BIOS. o set unattached drivers to state D3. Set power state to D0 before probe/attach. Right now there's two special cases for this (display and memory devices) that need work in other areas of the tree. Please report any bugs to me.
2004-04-09 15:44:34 +00:00
static struct resource *acpi_pcib_acpi_alloc_resource(device_t dev,
Whitespace cleanup
2004-10-31 15:02:53 +00:00
device_t child, int type, int *rid,
Convert rman to use rman_res_t instead of u_long Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
rman_res_t start, rman_res_t end, rman_res_t count,
Omnibus PCI commit: o Save and restore bars for suspend/resume as well as for D3->D0 transitions. o preallocate resources that the PCI devices use to avoid resource conflicts o lazy allocation of resources not allocated by the BIOS. o set unattached drivers to state D3. Set power state to D0 before probe/attach. Right now there's two special cases for this (display and memory devices) that need work in other areas of the tree. Please report any bugs to me.
2004-04-09 15:44:34 +00:00
u_int flags);
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#ifdef NEW_PCIB
static int acpi_pcib_acpi_adjust_resource(device_t dev,
device_t child, int type, struct resource *r,
Convert rman to use rman_res_t instead of u_long Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
rman_res_t start, rman_res_t end);
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#ifdef PCI_RES_BUS
static int acpi_pcib_acpi_release_resource(device_t dev,
device_t child, int type, int rid,
struct resource *r);
#endif
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#endif
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
static int acpi_pcib_request_feature(device_t pcib, device_t dev,
enum pci_feature feature);
Add support for NUMA domains to bus dma tags. This causes all memory allocated with a tag to come from the specified domain if it meets the other constraints provided by the tag. Automatically create a tag at the root of each bus specifying the domain local to that bus if available. Reviewed by: jhb, kib Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13545
2018-01-12 23:34:16 +00:00
static bus_dma_tag_t acpi_pcib_get_dma_tag(device_t bus, device_t child);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
static device_method_t acpi_pcib_acpi_methods[] = {
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
/* Device interface */
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
DEVMETHOD(device_probe, acpi_pcib_acpi_probe),
DEVMETHOD(device_attach, acpi_pcib_acpi_attach),
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
DEVMETHOD(device_shutdown, bus_generic_shutdown),
DEVMETHOD(device_suspend, bus_generic_suspend),
- Retire acpi_pcib_resume(). It is has just been an alias for bus_generic_resume() since the pci_link(4) driver was added. - Change the ACPI PCI-PCI bridge driver to inherit most of its methods from the generic PCI-PCI bridge driver. In particular, this will now restore PCI config registers for ACPI PCI-PCI bridges. Tested by: Oleg Sharoyko osharoiko of gmail
2010-08-05 16:10:12 +00:00
DEVMETHOD(device_resume, bus_generic_resume),
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
/* Bus interface */
DEVMETHOD(bus_read_ivar, acpi_pcib_read_ivar),
DEVMETHOD(bus_write_ivar, acpi_pcib_write_ivar),
Omnibus PCI commit: o Save and restore bars for suspend/resume as well as for D3->D0 transitions. o preallocate resources that the PCI devices use to avoid resource conflicts o lazy allocation of resources not allocated by the BIOS. o set unattached drivers to state D3. Set power state to D0 before probe/attach. Right now there's two special cases for this (display and memory devices) that need work in other areas of the tree. Please report any bugs to me.
2004-04-09 15:44:34 +00:00
DEVMETHOD(bus_alloc_resource, acpi_pcib_acpi_alloc_resource),
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#ifdef NEW_PCIB
DEVMETHOD(bus_adjust_resource, acpi_pcib_acpi_adjust_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),
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#endif
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#if defined(NEW_PCIB) && defined(PCI_RES_BUS)
DEVMETHOD(bus_release_resource, acpi_pcib_acpi_release_resource),
#else
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
DEVMETHOD(bus_release_resource, bus_generic_release_resource),
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#endif
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
Whitespace cleanup
2004-10-31 15:02:53 +00:00
DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
DEVMETHOD(bus_setup_intr, bus_generic_setup_intr),
DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr),
Add a new bus method to fetch device-specific CPU sets. bus_get_cpus() returns a specified set of CPUs for a device. It accepts an enum for the second parameter that indicates the type of cpuset to request. Currently two valus are supported: - LOCAL_CPUS (on x86 this returns all the CPUs in the package closest to the device when DEVICE_NUMA is enabled) - INTR_CPUS (like LOCAL_CPUS but only returns 1 SMT thread for each core) For systems that do not support NUMA (or if it is not enabled in the kernel config), LOCAL_CPUS fails with EINVAL. INTR_CPUS is mapped to 'all_cpus' by default. The idea is that INTR_CPUS should always return a valid set. Device drivers which want to use per-CPU interrupts should start using INTR_CPUS instead of simply assigning interrupts to all available CPUs. In the future we may wish to add tunables to control the policy of INTR_CPUS (e.g. should it be local-only or global, should it ignore SMT threads or not). The x86 nexus driver exposes the internal set of interrupt CPUs from the the x86 interrupt code via INTR_CPUS. The ACPI bus driver and PCI bridge drivers use _PXM to return a suitable LOCAL_CPUS set when _PXM exists and DEVICE_NUMA is enabled. They also and the global INTR_CPUS set from the nexus driver with the per-domain set from _PXM to generate a local INTR_CPUS set for child devices. Compared to the r298933, this version uses 'struct _cpuset' in <sys/bus.h> instead of 'cpuset_t' to avoid requiring <sys/param.h> (<sys/_cpuset.h> still requires <sys/param.h> for MAXCPU even though <sys/_bitset.h> does not after recent changes).
2016-05-09 20:50:21 +00:00
DEVMETHOD(bus_get_cpus, acpi_pcib_get_cpus),
Add support for NUMA domains to bus dma tags. This causes all memory allocated with a tag to come from the specified domain if it meets the other constraints provided by the tag. Automatically create a tag at the root of each bus specifying the domain local to that bus if available. Reviewed by: jhb, kib Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13545
2018-01-12 23:34:16 +00:00
DEVMETHOD(bus_get_dma_tag, acpi_pcib_get_dma_tag),
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
/* pcib interface */
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
DEVMETHOD(pcib_maxslots, pcib_maxslots),
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
DEVMETHOD(pcib_read_config, acpi_pcib_read_config),
DEVMETHOD(pcib_write_config, acpi_pcib_write_config),
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
DEVMETHOD(pcib_route_interrupt, acpi_pcib_acpi_route_interrupt),
Give Host-PCI bridge drivers their own pcib_alloc_msi() and pcib_alloc_msix() methods instead of using the method from the generic PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI specific logic soon.
2006-12-12 19:27:01 +00:00
DEVMETHOD(pcib_alloc_msi, acpi_pcib_alloc_msi),
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
DEVMETHOD(pcib_release_msi, pcib_release_msi),
Give Host-PCI bridge drivers their own pcib_alloc_msi() and pcib_alloc_msix() methods instead of using the method from the generic PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI specific logic soon.
2006-12-12 19:27:01 +00:00
DEVMETHOD(pcib_alloc_msix, acpi_pcib_alloc_msix),
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
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, acpi_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, acpi_pcib_power_for_sleep),
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
DEVMETHOD(pcib_request_feature, acpi_pcib_request_feature),
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +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
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +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;
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +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, acpi_pcib_acpi_driver, acpi_pcib_acpi_methods,
sizeof(struct acpi_hpcib_softc));
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
DRIVER_MODULE(acpi_pcib, acpi, acpi_pcib_acpi_driver, pcib_devclass, 0, 0);
Add MODULE_DEPEND entries so some of these drivers can eventually be loaded separately from ACPI (i.e., embedded use).
2004-04-09 18:14:32 +00:00
MODULE_DEPEND(acpi_pcib, acpi, 1, 1, 1);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
static int
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
acpi_pcib_acpi_probe(device_t dev)
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
{
Catch up with ACPICA 20090903.
2009-09-11 22:49:34 +00:00
ACPI_DEVICE_INFO *devinfo;
ACPI_HANDLE h;
int root;
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
Catch up with ACPICA 20090903.
2009-09-11 22:49:34 +00:00
if (acpi_disabled("pcib") || (h = acpi_get_handle(dev)) == NULL ||
ACPI_FAILURE(AcpiGetObjectInfo(h, &devinfo)))
Use the acpi_id_probe() method instead of acpi_MatchHid(), which is now static.
2004-06-29 19:02:27 +00:00
return (ENXIO);
Catch up with ACPICA 20090903.
2009-09-11 22:49:34 +00:00
root = (devinfo->Flags & ACPI_PCI_ROOT_BRIDGE) != 0;
AcpiOsFree(devinfo);
if (!root || pci_cfgregopen() == 0)
Use the acpi_id_probe() method instead of acpi_MatchHid(), which is now static.
2004-06-29 19:02:27 +00:00
return (ENXIO);
Catch up with ACPICA 20090903.
2009-09-11 22:49:34 +00:00
Use the acpi_id_probe() method instead of acpi_MatchHid(), which is now static.
2004-06-29 19:02:27 +00:00
device_set_desc(dev, "ACPI Host-PCI bridge");
return (0);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#ifdef NEW_PCIB
static ACPI_STATUS
acpi_pcib_producer_handler(ACPI_RESOURCE *res, void *context)
{
struct acpi_hpcib_softc *sc;
UINT64 length, min, max;
u_int flags;
int error, type;
sc = context;
switch (res->Type) {
case ACPI_RESOURCE_TYPE_START_DEPENDENT:
case ACPI_RESOURCE_TYPE_END_DEPENDENT:
panic("host bridge has depenedent resources");
case ACPI_RESOURCE_TYPE_ADDRESS16:
case ACPI_RESOURCE_TYPE_ADDRESS32:
case ACPI_RESOURCE_TYPE_ADDRESS64:
case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
if (res->Data.Address.ProducerConsumer != ACPI_PRODUCER)
break;
switch (res->Type) {
case ACPI_RESOURCE_TYPE_ADDRESS16:
Merge ACPICA 20150410.
2015-04-11 03:23:41 +00:00
min = res->Data.Address16.Address.Minimum;
max = res->Data.Address16.Address.Maximum;
length = res->Data.Address16.Address.AddressLength;
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
break;
case ACPI_RESOURCE_TYPE_ADDRESS32:
Merge ACPICA 20150410.
2015-04-11 03:23:41 +00:00
min = res->Data.Address32.Address.Minimum;
max = res->Data.Address32.Address.Maximum;
length = res->Data.Address32.Address.AddressLength;
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
break;
case ACPI_RESOURCE_TYPE_ADDRESS64:
Merge ACPICA 20150410.
2015-04-11 03:23:41 +00:00
min = res->Data.Address64.Address.Minimum;
max = res->Data.Address64.Address.Maximum;
length = res->Data.Address64.Address.AddressLength;
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
break;
default:
KASSERT(res->Type ==
ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64,
("should never happen"));
Merge ACPICA 20150410.
2015-04-11 03:23:41 +00:00
min = res->Data.ExtAddress64.Address.Minimum;
max = res->Data.ExtAddress64.Address.Maximum;
length = res->Data.ExtAddress64.Address.AddressLength;
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
break;
}
Allow non-fixed endpoints for a producer address range if the length of the resource covers the entire range. Some BIOSes appear to mark endpoints as non-fixed incorrectly (non-fixed endpoints are supposed to be used in _PRS when OSPM is allowed to allocate a certain chunk of address space within a larger range, I don't believe it is supposed to be used for _CRS). Approved by: re (kib)
2011-07-21 20:43:43 +00:00
if (length == 0)
break;
if (min + length - 1 != max &&
(res->Data.Address.MinAddressFixed != ACPI_ADDRESS_FIXED ||
res->Data.Address.MaxAddressFixed != ACPI_ADDRESS_FIXED))
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
break;
flags = 0;
switch (res->Data.Address.ResourceType) {
case ACPI_MEMORY_RANGE:
type = SYS_RES_MEMORY;
if (res->Type != ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64) {
if (res->Data.Address.Info.Mem.Caching ==
ACPI_PREFETCHABLE_MEMORY)
flags |= RF_PREFETCHABLE;
} else {
/*
* XXX: Parse prefetch flag out of
* TypeSpecific.
*/
}
break;
case ACPI_IO_RANGE:
type = SYS_RES_IOPORT;
break;
#ifdef PCI_RES_BUS
case ACPI_BUS_NUMBER_RANGE:
type = PCI_RES_BUS;
break;
#endif
default:
return (AE_OK);
}
if (min + length - 1 != max)
device_printf(sc->ap_dev,
"Length mismatch for %d range: %jx vs %jx\n", type,
Consistently cast ACPICA 64-bit integer types when we print them.
2013-06-26 23:52:10 +00:00
(uintmax_t)(max - min + 1), (uintmax_t)length);
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#ifdef __i386__
if (min > ULONG_MAX) {
device_printf(sc->ap_dev,
"Ignoring %d range above 4GB (%#jx-%#jx)\n",
type, (uintmax_t)min, (uintmax_t)max);
break;
}
if (max > ULONG_MAX) {
device_printf(sc->ap_dev,
"Truncating end of %d range above 4GB (%#jx-%#jx)\n",
type, (uintmax_t)min, (uintmax_t)max);
max = ULONG_MAX;
}
#endif
error = pcib_host_res_decodes(&sc->ap_host_res, type, min, max,
flags);
if (error)
panic("Failed to manage %d range (%#jx-%#jx): %d",
type, (uintmax_t)min, (uintmax_t)max, error);
break;
default:
break;
}
return (AE_OK);
}
#endif
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#if defined(NEW_PCIB) && defined(PCI_RES_BUS)
static int
Convert rman to use rman_res_t instead of u_long Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
first_decoded_bus(struct acpi_hpcib_softc *sc, rman_res_t *startp)
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
{
struct resource_list_entry *rle;
rle = resource_list_find(&sc->ap_host_res.hr_rl, PCI_RES_BUS, 0);
if (rle == NULL)
return (ENXIO);
*startp = rle->start;
return (0);
}
#endif
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
static int
acpi_pcib_osc(struct acpi_hpcib_softc *sc, uint32_t osc_ctl)
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
{
ACPI_STATUS status;
uint32_t cap_set[3];
static uint8_t pci_host_bridge_uuid[ACPI_UUID_LENGTH] = {
0x5b, 0x4d, 0xdb, 0x33, 0xf7, 0x1f, 0x1c, 0x40,
0x96, 0x57, 0x74, 0x41, 0xc0, 0x3d, 0xd7, 0x66
};
Various fixes for PCI _OSC handling so HotPlug works again. - Rename the default implementation of 'pcib_request_feature' and add a pcib_request_feature() wrapper function (as is often done for new-bus APIs implemented via kobj) that accepts a single function. Previously the call to pcib_request_feature() ended up invoking the method on the great-great-grandparent of the bridge device instead of the grandparent. For a bridge that was a direct child of pci0 on x86 this resulted in the method skipping over the Host-PCI bridge driver and being invoked against nexus0 - When invoking _OSC from a Host-PCI bridge driver, invoke device_get_softc() against the Host-PCI bridge device instead of the child bridge that is requesting HotPlug. Using the wrong softc data resulted in garbage being passed for the ACPI handle causing the _OSC call to fail. - While here, perform some other cleanups to _OSC handling in the ACPI Host-PCI bridge driver: - Don't invoke _OSC when requesting a control that has already been granted by the firmware. - Don't set the first word of the capability array before invoking _OSC. This word is always set explicitly by acpi_EvaluateOSC() since it is UUID-independent. - Don't modify the set of granted controls unless _OSC doesn't exist (which is treated as always successful), or the _OSC method doesn't fail. - Don't require an _OSC status of 0 for success. _OSC always returns the updated control mask even if it returns a non-zero status in the first word. - Whine if _OSC ever tries to revoke a previously-granted control. (It is not supposed to do that.) - While here, add constants for the _OSC status word in acpivar.h (though currently unused). Reported by: adrian Reviewed by: imp MFC after: 1 week Tested on: Lenovo x220 Differential Revision: https://reviews.freebsd.org/D10520
2017-04-27 16:32:42 +00:00
/*
* Don't invoke _OSC if a control is already granted.
* However, always invoke _OSC during attach when 0 is passed.
*/
if (osc_ctl != 0 && (sc->ap_osc_ctl & osc_ctl) == osc_ctl)
return (0);
Use symbolic constants for OSC support / control negotiations. Differential Revision: https://reviews.freebsd.org/D9604
2017-02-15 23:49:28 +00:00
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
/* Support Field: Extended PCI Config Space, MSI */
Use symbolic constants for OSC support / control negotiations. Differential Revision: https://reviews.freebsd.org/D9604
2017-02-15 23:49:28 +00:00
cap_set[PCI_OSC_SUPPORT] = PCIM_OSC_SUPPORT_EXT_PCI_CONF |
PCIM_OSC_SUPPORT_MSI;
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
/* Control Field */
Various fixes for PCI _OSC handling so HotPlug works again. - Rename the default implementation of 'pcib_request_feature' and add a pcib_request_feature() wrapper function (as is often done for new-bus APIs implemented via kobj) that accepts a single function. Previously the call to pcib_request_feature() ended up invoking the method on the great-great-grandparent of the bridge device instead of the grandparent. For a bridge that was a direct child of pci0 on x86 this resulted in the method skipping over the Host-PCI bridge driver and being invoked against nexus0 - When invoking _OSC from a Host-PCI bridge driver, invoke device_get_softc() against the Host-PCI bridge device instead of the child bridge that is requesting HotPlug. Using the wrong softc data resulted in garbage being passed for the ACPI handle causing the _OSC call to fail. - While here, perform some other cleanups to _OSC handling in the ACPI Host-PCI bridge driver: - Don't invoke _OSC when requesting a control that has already been granted by the firmware. - Don't set the first word of the capability array before invoking _OSC. This word is always set explicitly by acpi_EvaluateOSC() since it is UUID-independent. - Don't modify the set of granted controls unless _OSC doesn't exist (which is treated as always successful), or the _OSC method doesn't fail. - Don't require an _OSC status of 0 for success. _OSC always returns the updated control mask even if it returns a non-zero status in the first word. - Whine if _OSC ever tries to revoke a previously-granted control. (It is not supposed to do that.) - While here, add constants for the _OSC status word in acpivar.h (though currently unused). Reported by: adrian Reviewed by: imp MFC after: 1 week Tested on: Lenovo x220 Differential Revision: https://reviews.freebsd.org/D10520
2017-04-27 16:32:42 +00:00
cap_set[PCI_OSC_CTL] = sc->ap_osc_ctl | osc_ctl;
Native PCI-express HotPlug support. PCI-express HotPlug support is implemented via bits in the slot registers of the PCI-express capability of the downstream port along with an interrupt that triggers when bits in the slot status register change. This is implemented for FreeBSD by adding HotPlug support to the PCI-PCI bridge driver which attaches to the virtual PCI-PCI bridges representing downstream ports on HotPlug slots. The PCI-PCI bridge driver registers an interrupt handler to receive HotPlug events. It also uses the slot registers to determine the current HotPlug state and drive an internal HotPlug state machine. For simplicty of implementation, the PCI-PCI bridge device detaches and deletes the child PCI device when a card is removed from a slot and creates and attaches a PCI child device when a card is inserted into the slot. The PCI-PCI bridge driver provides a bus_child_present which claims that child devices are present on HotPlug-capable slots only when a card is inserted. Rather than requiring a timeout in the RC for config accesses to not-present children, the pcib_read/write_config methods fail all requests when a card is not present (or not yet ready). These changes include support for various optional HotPlug capabilities such as a power controller, mechanical latch, electro-mechanical interlock, indicators, and an attention button. It also includes support for devices which require waiting for command completion events before initiating a subsequent HotPlug command. However, it has only been tested on ExpressCard systems which support surprise removal and have none of these optional capabilities. PCI-express HotPlug support is conditional on the PCI_HP option which is enabled by default on arm64, x86, and powerpc. Reviewed by: adrian, imp, vangyzen (older versions) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D6136
2016-05-05 22:26:23 +00:00
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
status = acpi_EvaluateOSC(sc->ap_handle, pci_host_bridge_uuid, 1,
Optionally return the output capabilities list from _OSC. Both of the callers were expecting the input cap_set to be modified. This fixes them to request cap_set to be updated with the returned buffer. Reviewed by: jkim Differential Revision: https://reviews.freebsd.org/D6040
2016-04-22 17:51:19 +00:00
nitems(cap_set), cap_set, cap_set, false);
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
if (ACPI_FAILURE(status)) {
Various fixes for PCI _OSC handling so HotPlug works again. - Rename the default implementation of 'pcib_request_feature' and add a pcib_request_feature() wrapper function (as is often done for new-bus APIs implemented via kobj) that accepts a single function. Previously the call to pcib_request_feature() ended up invoking the method on the great-great-grandparent of the bridge device instead of the grandparent. For a bridge that was a direct child of pci0 on x86 this resulted in the method skipping over the Host-PCI bridge driver and being invoked against nexus0 - When invoking _OSC from a Host-PCI bridge driver, invoke device_get_softc() against the Host-PCI bridge device instead of the child bridge that is requesting HotPlug. Using the wrong softc data resulted in garbage being passed for the ACPI handle causing the _OSC call to fail. - While here, perform some other cleanups to _OSC handling in the ACPI Host-PCI bridge driver: - Don't invoke _OSC when requesting a control that has already been granted by the firmware. - Don't set the first word of the capability array before invoking _OSC. This word is always set explicitly by acpi_EvaluateOSC() since it is UUID-independent. - Don't modify the set of granted controls unless _OSC doesn't exist (which is treated as always successful), or the _OSC method doesn't fail. - Don't require an _OSC status of 0 for success. _OSC always returns the updated control mask even if it returns a non-zero status in the first word. - Whine if _OSC ever tries to revoke a previously-granted control. (It is not supposed to do that.) - While here, add constants for the _OSC status word in acpivar.h (though currently unused). Reported by: adrian Reviewed by: imp MFC after: 1 week Tested on: Lenovo x220 Differential Revision: https://reviews.freebsd.org/D10520
2017-04-27 16:32:42 +00:00
if (status == AE_NOT_FOUND) {
sc->ap_osc_ctl |= osc_ctl;
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
return (0);
Various fixes for PCI _OSC handling so HotPlug works again. - Rename the default implementation of 'pcib_request_feature' and add a pcib_request_feature() wrapper function (as is often done for new-bus APIs implemented via kobj) that accepts a single function. Previously the call to pcib_request_feature() ended up invoking the method on the great-great-grandparent of the bridge device instead of the grandparent. For a bridge that was a direct child of pci0 on x86 this resulted in the method skipping over the Host-PCI bridge driver and being invoked against nexus0 - When invoking _OSC from a Host-PCI bridge driver, invoke device_get_softc() against the Host-PCI bridge device instead of the child bridge that is requesting HotPlug. Using the wrong softc data resulted in garbage being passed for the ACPI handle causing the _OSC call to fail. - While here, perform some other cleanups to _OSC handling in the ACPI Host-PCI bridge driver: - Don't invoke _OSC when requesting a control that has already been granted by the firmware. - Don't set the first word of the capability array before invoking _OSC. This word is always set explicitly by acpi_EvaluateOSC() since it is UUID-independent. - Don't modify the set of granted controls unless _OSC doesn't exist (which is treated as always successful), or the _OSC method doesn't fail. - Don't require an _OSC status of 0 for success. _OSC always returns the updated control mask even if it returns a non-zero status in the first word. - Whine if _OSC ever tries to revoke a previously-granted control. (It is not supposed to do that.) - While here, add constants for the _OSC status word in acpivar.h (though currently unused). Reported by: adrian Reviewed by: imp MFC after: 1 week Tested on: Lenovo x220 Differential Revision: https://reviews.freebsd.org/D10520
2017-04-27 16:32:42 +00:00
}
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
device_printf(sc->ap_dev, "_OSC failed: %s\n",
AcpiFormatException(status));
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
return (EIO);
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
}
Various fixes for PCI _OSC handling so HotPlug works again. - Rename the default implementation of 'pcib_request_feature' and add a pcib_request_feature() wrapper function (as is often done for new-bus APIs implemented via kobj) that accepts a single function. Previously the call to pcib_request_feature() ended up invoking the method on the great-great-grandparent of the bridge device instead of the grandparent. For a bridge that was a direct child of pci0 on x86 this resulted in the method skipping over the Host-PCI bridge driver and being invoked against nexus0 - When invoking _OSC from a Host-PCI bridge driver, invoke device_get_softc() against the Host-PCI bridge device instead of the child bridge that is requesting HotPlug. Using the wrong softc data resulted in garbage being passed for the ACPI handle causing the _OSC call to fail. - While here, perform some other cleanups to _OSC handling in the ACPI Host-PCI bridge driver: - Don't invoke _OSC when requesting a control that has already been granted by the firmware. - Don't set the first word of the capability array before invoking _OSC. This word is always set explicitly by acpi_EvaluateOSC() since it is UUID-independent. - Don't modify the set of granted controls unless _OSC doesn't exist (which is treated as always successful), or the _OSC method doesn't fail. - Don't require an _OSC status of 0 for success. _OSC always returns the updated control mask even if it returns a non-zero status in the first word. - Whine if _OSC ever tries to revoke a previously-granted control. (It is not supposed to do that.) - While here, add constants for the _OSC status word in acpivar.h (though currently unused). Reported by: adrian Reviewed by: imp MFC after: 1 week Tested on: Lenovo x220 Differential Revision: https://reviews.freebsd.org/D10520
2017-04-27 16:32:42 +00:00
/*
* _OSC may return an error in the status word, but will
* update the control mask always. _OSC should not revoke
* previously-granted controls.
*/
if ((cap_set[PCI_OSC_CTL] & sc->ap_osc_ctl) != sc->ap_osc_ctl)
device_printf(sc->ap_dev, "_OSC revoked %#x\n",
(cap_set[PCI_OSC_CTL] & sc->ap_osc_ctl) ^ sc->ap_osc_ctl);
sc->ap_osc_ctl = cap_set[PCI_OSC_CTL];
if ((sc->ap_osc_ctl & osc_ctl) != osc_ctl)
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
return (EIO);
return (0);
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
}
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
static int
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
acpi_pcib_acpi_attach(device_t dev)
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
{
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
struct acpi_hpcib_softc *sc;
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
ACPI_STATUS status;
Rework the _BBN handling for Host-PCI bridges. Previously we only trusted a _BBN value of 0 if it was for the first bridge encountered since some older systems returned _BBN of 0 for all bridges. However, some newer systems enumerate bridges with non-zero _BBN before bus 0 which is perfectly valid. Handle both cases by trusting the first bridge that has a _BBN of 0 and falling back to reading from non-standard config registers only for subsequent bridges with a _BBN of 0. We also only perform this check for segment (domain) 0. We assume that _BBN is always correct for segments other than 0. Tested by: Josef Moellers josef.moellers at fujitsu MFC after: 1 week
2009-06-09 13:44:17 +00:00
static int bus0_seen = 0;
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
u_int slot, func, busok;
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#if defined(NEW_PCIB) && defined(PCI_RES_BUS)
struct resource *bus_res;
Convert rman to use rman_res_t instead of u_long Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
rman_res_t start;
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
int rid;
#endif
Add support for NUMA domains to bus dma tags. This causes all memory allocated with a tag to come from the specified domain if it meets the other constraints provided by the tag. Automatically create a tag at the root of each bus specifying the domain local to that bus if available. Reviewed by: jhb, kib Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13545
2018-01-12 23:34:16 +00:00
int error, domain;
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
uint8_t busno;
- Convert a lot of homebrew debugging output to use the ACPI CA debugging infrastructure. It's not perfect, but it's a lot better than what we've been using so far. The following rules apply to this: o BSD component names should be capitalised o Layer names should be taken from the non-CA set for now. We may elect to add some new BSD-specific layers later. - Make it possible to turn off selective debugging flags or layers by listing them in debug.acpi.layer or debug.acpi.level prefixed with !. - Fully implement support for avoiding nodes in the ACPI namespace. Nodes may be listed in the debug.acpi.avoid environment variable; these nodes and all their children will be ignored (although still scanned over) by ACPI functions which scan the namespace. Multiple nodes can be specified, separated by whitespace. - Implement support for selectively disabling ACPI subsystem components via the debug.acpi.disable environment variable. The following components can be disabled: o bus creation/scanning of the ACPI 'bus' o children attachment of children to the ACPI 'bus' o button the acpi_button control-method button driver o ec the acpi_ec embedded-controller driver o isa acpi replacement of PnP BIOS for ISA device discovery o lid the control-method lid switch driver o pci pci root-bus discovery o processor CPU power/speed management o thermal system temperature detection and control o timer ACPI timecounter Multiple components may be disabled by specifying their name(s) separated by whitespace. - Add support for ioctl registration. ACPI subsystem components may register ioctl handlers with the /dev/acpi generic ioctl handler, allowing us to avoid the need for a multitude of /dev/acpi* control devices, etc.
2000-12-08 09:16:20 +00:00
Brutally deal with __func__ being 'const char *' on gcc-3.1.
2002-05-19 06:16:47 +00:00
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
sc = device_get_softc(dev);
sc->ap_dev = dev;
sc->ap_handle = acpi_get_handle(dev);
Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If we are probing a PCI-PCI bridge it is because we found one by enumerating the devices on a PCI bus, so the bridge is definitely present. A few BIOSes report incorrect status (_STA) for some bridges that claimed they were not present when in fact they were. While here, move this check earlier for Host-PCI bridges so attach fails before doing any work that needs to be torn down. PR: kern/91594 Tested by: Jack Vogel @ Intel MFC after: 1 week
2013-07-03 17:26:05 +00:00
/*
* Don't attach if we're not really there.
*/
if (!acpi_DeviceIsPresent(dev))
return (ENXIO);
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
acpi_pcib_osc(sc, 0);
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
2016-04-20 20:58:30 +00:00
Rework the _BBN handling for Host-PCI bridges. Previously we only trusted a _BBN value of 0 if it was for the first bridge encountered since some older systems returned _BBN of 0 for all bridges. However, some newer systems enumerate bridges with non-zero _BBN before bus 0 which is perfectly valid. Handle both cases by trusting the first bridge that has a _BBN of 0 and falling back to reading from non-standard config registers only for subsequent bridges with a _BBN of 0. We also only perform this check for segment (domain) 0. We assume that _BBN is always correct for segments other than 0. Tested by: Josef Moellers josef.moellers at fujitsu MFC after: 1 week
2009-06-09 13:44:17 +00:00
/*
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
* Get our segment number by evaluating _SEG.
Rework the _BBN handling for Host-PCI bridges. Previously we only trusted a _BBN value of 0 if it was for the first bridge encountered since some older systems returned _BBN of 0 for all bridges. However, some newer systems enumerate bridges with non-zero _BBN before bus 0 which is perfectly valid. Handle both cases by trusting the first bridge that has a _BBN of 0 and falling back to reading from non-standard config registers only for subsequent bridges with a _BBN of 0. We also only perform this check for segment (domain) 0. We assume that _BBN is always correct for segments other than 0. Tested by: Josef Moellers josef.moellers at fujitsu MFC after: 1 week
2009-06-09 13:44:17 +00:00
* It's OK for this to not exist.
*/
status = acpi_GetInteger(sc->ap_handle, "_SEG", &sc->ap_segment);
if (ACPI_FAILURE(status)) {
if (status != AE_NOT_FOUND) {
device_printf(dev, "could not evaluate _SEG - %s\n",
AcpiFormatException(status));
return_VALUE (ENXIO);
}
/* If it's not found, assume 0. */
sc->ap_segment = 0;
}
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
/*
* Get the address (device and function) of the associated
* PCI-Host bridge device from _ADR. Assume we don't have one if
* it doesn't exist.
*/
status = acpi_GetInteger(sc->ap_handle, "_ADR", &sc->ap_addr);
if (ACPI_FAILURE(status)) {
device_printf(dev, "could not evaluate _ADR - %s\n",
AcpiFormatException(status));
sc->ap_addr = -1;
}
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#ifdef NEW_PCIB
/*
* Determine which address ranges this bridge decodes and setup
* resource managers for those ranges.
*/
if (pcib_host_res_init(sc->ap_dev, &sc->ap_host_res) != 0)
panic("failed to init hostb resources");
if (!acpi_disabled("hostres")) {
status = AcpiWalkResources(sc->ap_handle, "_CRS",
acpi_pcib_producer_handler, sc);
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND)
device_printf(sc->ap_dev, "failed to parse resources: %s\n",
AcpiFormatException(status));
}
#endif
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
/*
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
* Get our base bus number by evaluating _BBN.
Match namespace cleanup changes in ACPI CA 20020217 update. Use ACPI_SUCCESS/ACPI_FAILURE consistently. The AcpiGetInto* interfaces are obsoleted by ACPI_ALLOCATE_BUFFER. Use _ADR as well as _BBN to get our bus number.
2002-02-23 05:27:49 +00:00
* If this doesn't work, we assume we're bus number 0.
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
*
Whitespace cleanup
2004-10-31 15:02:53 +00:00
* XXX note that it may also not exist in the case where we are
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
* meant to use a private configuration space mechanism for this bus,
* so we should dig out our resources and check to see if we have
* anything like that. How do we do this?
Update to work with the new ACPI CA snapshot. - Use ACPI_PHYSICAL_ADDRESS - RSDT -> XSDT - FACP -> FADT - No APIC table support - Don't install a global EC handler; this has bad side-effects (it invokes _REG in *all* EC spaces in the namespace!) - Check for PCI bus instances already existing before adding them
2000-12-01 10:18:57 +00:00
* XXX If we have the requisite information, and if we don't think the
* default PCI configuration space handlers can deal with this bus,
* we should attach our own handler.
* XXX invoke _REG on this for the PCI config space address space?
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
* XXX It seems many BIOS's with multiple Host-PCI bridges do not set
* _BBN correctly. They set _BBN to zero for all bridges. Thus,
Rework the _BBN handling for Host-PCI bridges. Previously we only trusted a _BBN value of 0 if it was for the first bridge encountered since some older systems returned _BBN of 0 for all bridges. However, some newer systems enumerate bridges with non-zero _BBN before bus 0 which is perfectly valid. Handle both cases by trusting the first bridge that has a _BBN of 0 and falling back to reading from non-standard config registers only for subsequent bridges with a _BBN of 0. We also only perform this check for segment (domain) 0. We assume that _BBN is always correct for segments other than 0. Tested by: Josef Moellers josef.moellers at fujitsu MFC after: 1 week
2009-06-09 13:44:17 +00:00
* if _BBN is zero and PCI bus 0 already exists, we try to read our
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
* bus number from the configuration registers at address _ADR.
Rework the _BBN handling for Host-PCI bridges. Previously we only trusted a _BBN value of 0 if it was for the first bridge encountered since some older systems returned _BBN of 0 for all bridges. However, some newer systems enumerate bridges with non-zero _BBN before bus 0 which is perfectly valid. Handle both cases by trusting the first bridge that has a _BBN of 0 and falling back to reading from non-standard config registers only for subsequent bridges with a _BBN of 0. We also only perform this check for segment (domain) 0. We assume that _BBN is always correct for segments other than 0. Tested by: Josef Moellers josef.moellers at fujitsu MFC after: 1 week
2009-06-09 13:44:17 +00:00
* We only do this for domain/segment 0 in the hopes that this is
* only needed for old single-domain machines.
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
*/
Change to acpi_{Get,Set}Integer to provide both methods. Convert all callers to the new API. Submitted by: Mark Santcroos <marks@ripe.net>
2004-03-03 18:34:42 +00:00
status = acpi_GetInteger(sc->ap_handle, "_BBN", &sc->ap_bus);
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
if (ACPI_FAILURE(status)) {
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
if (status != AE_NOT_FOUND) {
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
device_printf(dev, "could not evaluate _BBN - %s\n",
AcpiFormatException(status));
Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If we are probing a PCI-PCI bridge it is because we found one by enumerating the devices on a PCI bus, so the bridge is definitely present. A few BIOSes report incorrect status (_STA) for some bridges that claimed they were not present when in fact they were. While here, move this check earlier for Host-PCI bridges so attach fails before doing any work that needs to be torn down. PR: kern/91594 Tested by: Jack Vogel @ Intel MFC after: 1 week
2013-07-03 17:26:05 +00:00
return (ENXIO);
- Assume a bus number of zero if evaluating _BBN fails, not if it succeeds. This was effectively rendering _BBN useless. - Cleanup handling of the busok variable a bit. Submitted by: marcel (1) Approved by: re (rwatson)
2002-11-25 21:55:04 +00:00
} else {
Style fixes.
2004-05-28 16:38:37 +00:00
/* If it's not found, assume 0. */
- Assume a bus number of zero if evaluating _BBN fails, not if it succeeds. This was effectively rendering _BBN useless. - Cleanup handling of the busok variable a bit. Submitted by: marcel (1) Approved by: re (rwatson)
2002-11-25 21:55:04 +00:00
sc->ap_bus = 0;
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
}
/*
Rework the _BBN handling for Host-PCI bridges. Previously we only trusted a _BBN value of 0 if it was for the first bridge encountered since some older systems returned _BBN of 0 for all bridges. However, some newer systems enumerate bridges with non-zero _BBN before bus 0 which is perfectly valid. Handle both cases by trusting the first bridge that has a _BBN of 0 and falling back to reading from non-standard config registers only for subsequent bridges with a _BBN of 0. We also only perform this check for segment (domain) 0. We assume that _BBN is always correct for segments other than 0. Tested by: Josef Moellers josef.moellers at fujitsu MFC after: 1 week
2009-06-09 13:44:17 +00:00
* If this is segment 0, the bus is zero, and PCI bus 0 already
* exists, read the bus number via PCI config space.
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
*/
busok = 1;
Rework the _BBN handling for Host-PCI bridges. Previously we only trusted a _BBN value of 0 if it was for the first bridge encountered since some older systems returned _BBN of 0 for all bridges. However, some newer systems enumerate bridges with non-zero _BBN before bus 0 which is perfectly valid. Handle both cases by trusting the first bridge that has a _BBN of 0 and falling back to reading from non-standard config registers only for subsequent bridges with a _BBN of 0. We also only perform this check for segment (domain) 0. We assume that _BBN is always correct for segments other than 0. Tested by: Josef Moellers josef.moellers at fujitsu MFC after: 1 week
2009-06-09 13:44:17 +00:00
if (sc->ap_segment == 0 && sc->ap_bus == 0 && bus0_seen) {
- Assume a bus number of zero if evaluating _BBN fails, not if it succeeds. This was effectively rendering _BBN useless. - Cleanup handling of the busok variable a bit. Submitted by: marcel (1) Approved by: re (rwatson)
2002-11-25 21:55:04 +00:00
busok = 0;
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
if (sc->ap_addr != -1) {
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
/* XXX: We assume bus 0. */
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
slot = ACPI_ADR_PCI_SLOT(sc->ap_addr);
func = ACPI_ADR_PCI_FUNC(sc->ap_addr);
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
if (bootverbose)
device_printf(dev, "reading config registers from 0:%d:%d\n",
slot, func);
- Assume a bus number of zero if evaluating _BBN fails, not if it succeeds. This was effectively rendering _BBN useless. - Cleanup handling of the busok variable a bit. Submitted by: marcel (1) Approved by: re (rwatson)
2002-11-25 21:55:04 +00:00
if (host_pcib_get_busno(pci_cfgregread, 0, slot, func, &busno) == 0)
Style fixes.
2004-05-28 16:38:37 +00:00
device_printf(dev, "couldn't read bus number from cfg space\n");
- Assume a bus number of zero if evaluating _BBN fails, not if it succeeds. This was effectively rendering _BBN useless. - Cleanup handling of the busok variable a bit. Submitted by: marcel (1) Approved by: re (rwatson)
2002-11-25 21:55:04 +00:00
else {
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
sc->ap_bus = busno;
- Assume a bus number of zero if evaluating _BBN fails, not if it succeeds. This was effectively rendering _BBN useless. - Cleanup handling of the busok variable a bit. Submitted by: marcel (1) Approved by: re (rwatson)
2002-11-25 21:55:04 +00:00
busok = 1;
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
}
Match namespace cleanup changes in ACPI CA 20020217 update. Use ACPI_SUCCESS/ACPI_FAILURE consistently. The AcpiGetInto* interfaces are obsoleted by ACPI_ALLOCATE_BUFFER. Use _ADR as well as _BBN to get our bus number.
2002-02-23 05:27:49 +00:00
}
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#if defined(NEW_PCIB) && defined(PCI_RES_BUS)
/*
* If nothing else worked, hope that ACPI at least lays out the
* Host-PCI bridges in order and that as a result the next free
* bus number is our bus number.
*/
if (busok == 0) {
/*
* If we have a region of bus numbers, use the first
* number for our bus.
*/
if (first_decoded_bus(sc, &start) == 0)
sc->ap_bus = start;
else {
rid = 0;
bus_res = pci_domain_alloc_bus(sc->ap_segment, dev, &rid, 0,
PCI_BUSMAX, 1, 0);
if (bus_res == NULL) {
device_printf(dev,
"could not allocate bus number\n");
pcib_host_res_free(dev, &sc->ap_host_res);
return (ENXIO);
}
sc->ap_bus = rman_get_start(bus_res);
pci_domain_release_bus(sc->ap_segment, dev, rid, bus_res);
}
} else {
Don't attach to Host-PCI bridges with a bad bus number. If the bus number assigned to a Host-PCI bridge doesn't match the first bus number in the associated producer range from _CRS, print a warning and fail to attach rather than panicking due to an assertion failure. At least one single-socket Dell machine leaves a "ghost" Host-PCI bridge device in the ACPI namespace that seems to correspond to the I/O hub in the second socket of a two-socket machine. However, the BIOS doesn't configure the settings for this "ghost" bridge correctly, nor does it have any PCI devices behind it. Tested by: royger MFC after: 2 weeks
2016-12-06 00:36:02 +00:00
/*
* Require the bus number from _BBN to match the start of any
* decoded range.
*/
if (first_decoded_bus(sc, &start) == 0 && sc->ap_bus != start) {
device_printf(dev,
"bus number %d does not match start of decoded range %ju\n",
sc->ap_bus, (uintmax_t)start);
pcib_host_res_free(dev, &sc->ap_host_res);
return (ENXIO);
}
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
}
#else
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
/*
* If nothing else worked, hope that ACPI at least lays out the
* host-PCI bridges in order and that as a result our unit number
* is actually our bus number. There are several reasons this
* might not be true.
*/
if (busok == 0) {
sc->ap_bus = device_get_unit(dev);
device_printf(dev, "trying bus number %d\n", sc->ap_bus);
}
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#endif
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
2002-11-22 18:11:13 +00:00
Rework the _BBN handling for Host-PCI bridges. Previously we only trusted a _BBN value of 0 if it was for the first bridge encountered since some older systems returned _BBN of 0 for all bridges. However, some newer systems enumerate bridges with non-zero _BBN before bus 0 which is perfectly valid. Handle both cases by trusting the first bridge that has a _BBN of 0 and falling back to reading from non-standard config registers only for subsequent bridges with a _BBN of 0. We also only perform this check for segment (domain) 0. We assume that _BBN is always correct for segments other than 0. Tested by: Josef Moellers josef.moellers at fujitsu MFC after: 1 week
2009-06-09 13:44:17 +00:00
/* If this is bus 0 on segment 0, note that it has been seen already. */
if (sc->ap_segment == 0 && sc->ap_bus == 0)
bus0_seen = 1;
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
Add a pcib_attach_child() method to manage adding the child "pci" device. This allows the PCI-PCI bridge driver to save a reference to the child device in its softc. Note that this required moving the "pci" device creation out of acpi_pcib_attach(). Instead, acpi_pcib_attach() is renamed to acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI interrupt routing table. Differential Revision: https://reviews.freebsd.org/D6021
2016-04-27 16:39:05 +00:00
acpi_pcib_fetch_prt(dev, &sc->ap_prt);
Add support for NUMA domains to bus dma tags. This causes all memory allocated with a tag to come from the specified domain if it meets the other constraints provided by the tag. Automatically create a tag at the root of each bus specifying the domain local to that bus if available. Reviewed by: jhb, kib Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13545
2018-01-12 23:34:16 +00:00
error = bus_dma_tag_create(bus_get_dma_tag(dev), 1,
0, BUS_SPACE_MAXADDR, BUS_SPACE_MAXADDR,
NULL, NULL, BUS_SPACE_MAXSIZE, BUS_SPACE_UNRESTRICTED,
BUS_SPACE_MAXSIZE, 0, NULL, NULL, &sc->ap_dma_tag);
if (error != 0)
goto errout;
error = bus_get_domain(dev, &domain);
if (error == 0)
error = bus_dma_tag_set_domain(sc->ap_dma_tag, domain);
/* Don't fail to attach if the domain can't be queried or set. */
error = 0;
hyperv/vmbus: Reorganize vmbus device tree For GEN1 Hyper-V, vmbus is attached to pcib0, which contains the resources for PCI passthrough and SR-IOV. There is no acpi_syscontainer0 on GEN1 Hyper-V. For GEN2 Hyper-V, vmbus is attached to acpi_syscontainer0, which contains the resources for PCI passthrough and SR-IOV. There is no pcib0 on GEN2 Hyper-V. The ACPI VMBUS device now only holds its _CRS, which is empty as of this commit; its existence is mainly for upward compatibility. Device tree structure is suggested by jhb@. Tested-by: dexuan@ Collabrated-wth: dexuan@ MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D10565
2017-05-10 05:28:14 +00:00
bus_generic_probe(dev);
Add a pcib_attach_child() method to manage adding the child "pci" device. This allows the PCI-PCI bridge driver to save a reference to the child device in its softc. Note that this required moving the "pci" device creation out of acpi_pcib_attach(). Instead, acpi_pcib_attach() is renamed to acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI interrupt routing table. Differential Revision: https://reviews.freebsd.org/D6021
2016-04-27 16:39:05 +00:00
if (device_add_child(dev, "pci", -1) == NULL) {
Add support for NUMA domains to bus dma tags. This causes all memory allocated with a tag to come from the specified domain if it meets the other constraints provided by the tag. Automatically create a tag at the root of each bus specifying the domain local to that bus if available. Reviewed by: jhb, kib Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13545
2018-01-12 23:34:16 +00:00
bus_dma_tag_destroy(sc->ap_dma_tag);
sc->ap_dma_tag = NULL;
error = ENXIO;
goto errout;
Add a pcib_attach_child() method to manage adding the child "pci" device. This allows the PCI-PCI bridge driver to save a reference to the child device in its softc. Note that this required moving the "pci" device creation out of acpi_pcib_attach(). Instead, acpi_pcib_attach() is renamed to acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI interrupt routing table. Differential Revision: https://reviews.freebsd.org/D6021
2016-04-27 16:39:05 +00:00
}
return (bus_generic_attach(dev));
Add support for NUMA domains to bus dma tags. This causes all memory allocated with a tag to come from the specified domain if it meets the other constraints provided by the tag. Automatically create a tag at the root of each bus specifying the domain local to that bus if available. Reviewed by: jhb, kib Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13545
2018-01-12 23:34:16 +00:00
errout:
device_printf(device_get_parent(dev), "couldn't attach pci bus\n");
#if defined(NEW_PCIB) && defined(PCI_RES_BUS)
pcib_host_res_free(dev, &sc->ap_host_res);
#endif
return (error);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
Implement PCI interrupt routing using the ACPI data attached to the PCI bus object. This should deal both with already-routed interrupts as well as devices that need an interrupt routed. Note that it *doesn't* deal with interlocked interrupt dependancies, nor does it select between interrupt options in a smart way. These are optimisations that need further work.
2001-07-05 07:20:51 +00:00
/*
* Support for standard PCI bridge ivars.
*/
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
static int
acpi_pcib_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
struct acpi_hpcib_softc *sc = device_get_softc(dev);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
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:
The ACPI Host-PCI bridge driver actually supports multiple domains via the optional _SEG function. Return that value (ap->segment) rather than 0 for the pcib domain ivar.
2011-05-02 19:02:30 +00:00
*result = sc->ap_segment;
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);
Style fixes.
2004-05-28 16:38:37 +00:00
case PCIB_IVAR_BUS:
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
*result = sc->ap_bus;
Style fixes.
2004-05-28 16:38:37 +00:00
return (0);
case ACPI_IVAR_HANDLE:
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
*result = (uintptr_t)sc->ap_handle;
Style fixes.
2004-05-28 16:38:37 +00:00
return (0);
Move flags into a private ivar so it can't collide with device flags. Unify the code to disable GPEs with the enable code. Shutdown is handled the same way. ACPI now does all wake/sleep prep for child devices so now they no longer need to call external functions in the suspend/resume path. Add the flags to non-ACPI busses (i.e., pci).
2004-06-30 16:08:03 +00:00
case ACPI_IVAR_FLAGS:
*result = (uintptr_t)sc->ap_flags;
return (0);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
Style fixes.
2004-05-28 16:38:37 +00:00
return (ENOENT);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
static int
acpi_pcib_write_ivar(device_t dev, device_t child, int which, uintptr_t value)
{
Whitespace cleanup
2004-10-31 15:02:53 +00:00
struct acpi_hpcib_softc *sc = device_get_softc(dev);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
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);
Style fixes.
2004-05-28 16:38:37 +00:00
case PCIB_IVAR_BUS:
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
sc->ap_bus = value;
Style fixes.
2004-05-28 16:38:37 +00:00
return (0);
Move flags into a private ivar so it can't collide with device flags. Unify the code to disable GPEs with the enable code. Shutdown is handled the same way. ACPI now does all wake/sleep prep for child devices so now they no longer need to call external functions in the suspend/resume path. Add the flags to non-ACPI busses (i.e., pci).
2004-06-30 16:08:03 +00:00
case ACPI_IVAR_HANDLE:
sc->ap_handle = (ACPI_HANDLE)value;
return (0);
case ACPI_IVAR_FLAGS:
sc->ap_flags = (int)value;
return (0);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
Style fixes.
2004-05-28 16:38:37 +00:00
return (ENOENT);
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
Style fixes.
2004-05-28 16:38:37 +00:00
static uint32_t
pcib_read_config and pcib_write_config take u_int params.
2009-02-05 18:40:42 +00:00
acpi_pcib_read_config(device_t dev, u_int bus, u_int slot, u_int func,
u_int reg, int bytes)
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
{
Style fixes.
2004-05-28 16:38:37 +00:00
return (pci_cfgregread(bus, slot, func, reg, bytes));
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
static void
pcib_read_config and pcib_write_config take u_int params.
2009-02-05 18:40:42 +00:00
acpi_pcib_write_config(device_t dev, u_int bus, u_int slot, u_int func,
u_int reg, uint32_t data, int bytes)
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
{
pci_cfgregwrite(bus, slot, func, reg, data, bytes);
}
static int
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
acpi_pcib_acpi_route_interrupt(device_t pcib, device_t dev, int pin)
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
{
Rework the ACPI PCI link code. - Use a new-bus device driver for the ACPI PCI link devices. The devices are called pci_linkX. The driver includes suspend/resume support so that the ACPI bridge drivers no longer have to poke the links to get them to handle suspend/resume. Also, the code to handle which IRQs a link is routed to and choosing an IRQ when a link is not already routed is all contained in the link driver. The PCI bridge drivers now ask the link driver which IRQ to use once they determine that a _PRT entry does not use a hardwired interrupt number. - The new link driver includes support for multiple IRQ resources per link device as well as preserving any non-IRQ resources when adjusting the IRQ that a link is routed to. - The entire approach to routing when using a link device is now link-centric rather than pci bus/device/pin specific. Thus, when using a tunable to override the default IRQ settings, one now uses a single tunable to route an entire link rather than routing a single device that uses the link (which has great foot-shooting potential if the user tries to route the same link to two different IRQs using two different pci bus/device/pin hints). For example, to adjust the IRQ that \_SB_.LNKA uses, one would set 'hw.pci.link.LNKA.irq=10' from the loader. - As a side effect of having the link driver, unused link devices will now be disabled when they are probed. - The algorithm for choosing an IRQ for a link that doesn't already have an IRQ assigned is now much closer to the one used in $PIR routing. When a link is routed via an ISA IRQ, only known-good IRQs that the BIOS has already used are used for routing instead of using probabilities to guess at which IRQs are probably not used by an ISA device. One change from $PIR is that the SCI is always considered a viable ISA IRQ, so that if the BIOS does not setup any IRQs the kernel will degenerate to routing all interrupts over the SCI. For non ISA IRQs, interrupts are picked from the possible pool using a simplistic weighting algorithm. Tested by: ru, scottl, others on acpi@ Reviewed by: njl
2004-11-23 22:26:44 +00:00
struct acpi_hpcib_softc *sc = device_get_softc(pcib);
Implement PCI interrupt routing using the ACPI data attached to the PCI bus object. This should deal both with already-routed interrupts as well as devices that need an interrupt routed. Note that it *doesn't* deal with interlocked interrupt dependancies, nor does it select between interrupt options in a smart way. These are optimisations that need further work.
2001-07-05 07:20:51 +00:00
Rework the ACPI PCI link code. - Use a new-bus device driver for the ACPI PCI link devices. The devices are called pci_linkX. The driver includes suspend/resume support so that the ACPI bridge drivers no longer have to poke the links to get them to handle suspend/resume. Also, the code to handle which IRQs a link is routed to and choosing an IRQ when a link is not already routed is all contained in the link driver. The PCI bridge drivers now ask the link driver which IRQ to use once they determine that a _PRT entry does not use a hardwired interrupt number. - The new link driver includes support for multiple IRQ resources per link device as well as preserving any non-IRQ resources when adjusting the IRQ that a link is routed to. - The entire approach to routing when using a link device is now link-centric rather than pci bus/device/pin specific. Thus, when using a tunable to override the default IRQ settings, one now uses a single tunable to route an entire link rather than routing a single device that uses the link (which has great foot-shooting potential if the user tries to route the same link to two different IRQs using two different pci bus/device/pin hints). For example, to adjust the IRQ that \_SB_.LNKA uses, one would set 'hw.pci.link.LNKA.irq=10' from the loader. - As a side effect of having the link driver, unused link devices will now be disabled when they are probed. - The algorithm for choosing an IRQ for a link that doesn't already have an IRQ assigned is now much closer to the one used in $PIR routing. When a link is routed via an ISA IRQ, only known-good IRQs that the BIOS has already used are used for routing instead of using probabilities to guess at which IRQs are probably not used by an ISA device. One change from $PIR is that the SCI is always considered a viable ISA IRQ, so that if the BIOS does not setup any IRQs the kernel will degenerate to routing all interrupts over the SCI. For non ISA IRQs, interrupts are picked from the possible pool using a simplistic weighting algorithm. Tested by: ru, scottl, others on acpi@ Reviewed by: njl
2004-11-23 22:26:44 +00:00
return (acpi_pcib_route_interrupt(pcib, dev, pin, &sc->ap_prt));
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
2000-10-28 06:59:48 +00:00
}
Omnibus PCI commit: o Save and restore bars for suspend/resume as well as for D3->D0 transitions. o preallocate resources that the PCI devices use to avoid resource conflicts o lazy allocation of resources not allocated by the BIOS. o set unattached drivers to state D3. Set power state to D0 before probe/attach. Right now there's two special cases for this (display and memory devices) that need work in other areas of the tree. Please report any bugs to me.
2004-04-09 15:44:34 +00:00
Give Host-PCI bridge drivers their own pcib_alloc_msi() and pcib_alloc_msix() methods instead of using the method from the generic PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI specific logic soon.
2006-12-12 19:27:01 +00:00
static int
acpi_pcib_alloc_msi(device_t pcib, device_t dev, int count, int maxcount,
int *irqs)
{
device_t bus;
bus = device_get_parent(pcib);
return (PCIB_ALLOC_MSI(device_get_parent(bus), dev, count, maxcount,
irqs));
}
static 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
acpi_pcib_alloc_msix(device_t pcib, device_t dev, int *irq)
Give Host-PCI bridge drivers their own pcib_alloc_msi() and pcib_alloc_msix() methods instead of using the method from the generic PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI specific logic soon.
2006-12-12 19:27:01 +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_ALLOC_MSIX(device_get_parent(bus), dev, irq));
}
static int
acpi_pcib_map_msi(device_t pcib, device_t dev, int irq, uint64_t *addr,
uint32_t *data)
{
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
struct acpi_hpcib_softc *sc;
device_t bus, hostb;
int error;
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
bus = device_get_parent(pcib);
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
error = PCIB_MAP_MSI(device_get_parent(bus), dev, irq, addr, data);
if (error)
return (error);
Grab the softc from the ACPI host-pci bridge device instead of from the pci endpoint device. Reviewed by: jhb
2012-10-10 00:06:31 +00:00
sc = device_get_softc(pcib);
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
2012-03-29 19:03:22 +00:00
if (sc->ap_addr == -1)
return (0);
/* XXX: Assumes all bridges are on bus 0. */
hostb = pci_find_dbsf(sc->ap_segment, 0, ACPI_ADR_PCI_SLOT(sc->ap_addr),
ACPI_ADR_PCI_FUNC(sc->ap_addr));
if (hostb != NULL)
pci_ht_map_msi(hostb, *addr);
return (0);
Give Host-PCI bridge drivers their own pcib_alloc_msi() and pcib_alloc_msix() methods instead of using the method from the generic PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI specific logic soon.
2006-12-12 19:27:01 +00:00
}
Omnibus PCI commit: o Save and restore bars for suspend/resume as well as for D3->D0 transitions. o preallocate resources that the PCI devices use to avoid resource conflicts o lazy allocation of resources not allocated by the BIOS. o set unattached drivers to state D3. Set power state to D0 before probe/attach. Right now there's two special cases for this (display and memory devices) that need work in other areas of the tree. Please report any bugs to me.
2004-04-09 15:44:34 +00:00
struct resource *
acpi_pcib_acpi_alloc_resource(device_t dev, device_t child, int type, int *rid,
Convert rman to use rman_res_t instead of u_long Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
rman_res_t start, rman_res_t end, rman_res_t count, u_int flags)
Omnibus PCI commit: o Save and restore bars for suspend/resume as well as for D3->D0 transitions. o preallocate resources that the PCI devices use to avoid resource conflicts o lazy allocation of resources not allocated by the BIOS. o set unattached drivers to state D3. Set power state to D0 before probe/attach. Right now there's two special cases for this (display and memory devices) that need work in other areas of the tree. Please report any bugs to me.
2004-04-09 15:44:34 +00:00
{
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#ifdef NEW_PCIB
struct acpi_hpcib_softc *sc;
If an allocation for a specific resource range fails because it is not in a decoded range for an ACPI Host-PCI bridge, try to allocate it from the ACPI system resource range. If that works, permit the resource allocation regardless. MFC after: 1 week
2011-10-12 14:13:32 +00:00
struct resource *res;
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#endif
Add a helper routine to conditionally modify the start address of a resource allocation from an x86 Host-PCI bridge driver so that it can be reused by the ACPI Host-PCI bridge driver (and eventually the MPTable Host-PCI bridge driver) instead of duplicating the same logic. Note that this means that hw.acpi.host_mem_start is now replaced with the hw.pci.host_mem_start tunable that was already used in the non-ACPI case. This also removes hw.acpi.host_mem_start on ia64 where it was not applicable (the implementation was very x86-specific). While here, adjust the logic to apply the new start address on any "wildcard" allocation even if that allocation comes from a subset of the allowable address range. Reviewed by: imp (1)
2011-06-22 16:15:15 +00:00
#if defined(__i386__) || defined(__amd64__)
start = hostb_alloc_start(type, start, end, count);
#endif
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#ifdef NEW_PCIB
sc = device_get_softc(dev);
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#ifdef PCI_RES_BUS
if (type == PCI_RES_BUS)
return (pci_domain_alloc_bus(sc->ap_segment, child, rid, start, end,
count, flags));
#endif
If an allocation for a specific resource range fails because it is not in a decoded range for an ACPI Host-PCI bridge, try to allocate it from the ACPI system resource range. If that works, permit the resource allocation regardless. MFC after: 1 week
2011-10-12 14:13:32 +00:00
res = pcib_host_res_alloc(&sc->ap_host_res, child, type, rid, start, end,
count, flags);
Further relax the strictness of enforcing allocations to only come from decoded ranges. Pass any request for a specific range that fails because it is not in a decoded range for an ACPI Host-PCI bridge up to the parent to see if it can still be allocated. This is based on the assumption that many BIOSes are inconsistent/broken and that settings programmed into BARs or resources assigned to other built-in components are more trustworthy than the list of decoded resource ranges in _CRS. This effectively limits the decoded ranges to only being used for "wildcard" ranges when allocating fresh resources for a BAR, etc. At some point I would like to only be this permissive during an early scan of firmware-assigned resources during boot and to be strict about all later allocations, but that isn't viable currently. MFC after: 2 weeks
2011-12-29 16:23:14 +00:00
/*
* XXX: If this is a request for a specific range, assume it is
* correct and pass it up to the parent. What we probably want to
* do long-term is explicitly trust any firmware-configured
* resources during the initial bus scan on boot and then disable
* this after that.
*/
If an allocation for a specific resource range fails because it is not in a decoded range for an ACPI Host-PCI bridge, try to allocate it from the ACPI system resource range. If that works, permit the resource allocation regardless. MFC after: 1 week
2011-10-12 14:13:32 +00:00
if (res == NULL && start + count - 1 == end)
Further relax the strictness of enforcing allocations to only come from decoded ranges. Pass any request for a specific range that fails because it is not in a decoded range for an ACPI Host-PCI bridge up to the parent to see if it can still be allocated. This is based on the assumption that many BIOSes are inconsistent/broken and that settings programmed into BARs or resources assigned to other built-in components are more trustworthy than the list of decoded resource ranges in _CRS. This effectively limits the decoded ranges to only being used for "wildcard" ranges when allocating fresh resources for a BAR, etc. At some point I would like to only be this permissive during an early scan of firmware-assigned resources during boot and to be strict about all later allocations, but that isn't viable currently. MFC after: 2 weeks
2011-12-29 16:23:14 +00:00
res = bus_generic_alloc_resource(dev, child, type, rid, start, end,
count, flags);
If an allocation for a specific resource range fails because it is not in a decoded range for an ACPI Host-PCI bridge, try to allocate it from the ACPI system resource range. If that works, permit the resource allocation regardless. MFC after: 1 week
2011-10-12 14:13:32 +00:00
return (res);
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#else
Style fixes.
2004-05-28 16:38:37 +00:00
return (bus_generic_alloc_resource(dev, child, type, rid, start, end,
count, flags));
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#endif
}
#ifdef NEW_PCIB
int
acpi_pcib_acpi_adjust_resource(device_t dev, device_t child, int type,
Convert rman to use rman_res_t instead of u_long Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
struct resource *r, rman_res_t start, rman_res_t end)
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
{
struct acpi_hpcib_softc *sc;
sc = device_get_softc(dev);
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#ifdef PCI_RES_BUS
if (type == PCI_RES_BUS)
return (pci_domain_adjust_bus(sc->ap_segment, child, r, start,
end));
#endif
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
return (pcib_host_res_adjust(&sc->ap_host_res, child, type, r, start,
end));
Omnibus PCI commit: o Save and restore bars for suspend/resume as well as for D3->D0 transitions. o preallocate resources that the PCI devices use to avoid resource conflicts o lazy allocation of resources not allocated by the BIOS. o set unattached drivers to state D3. Set power state to D0 before probe/attach. Right now there's two special cases for this (display and memory devices) that need work in other areas of the tree. Please report any bugs to me.
2004-04-09 15:44:34 +00:00
}
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#ifdef PCI_RES_BUS
int
acpi_pcib_acpi_release_resource(device_t dev, device_t child, int type, int rid,
struct resource *r)
{
struct acpi_hpcib_softc *sc;
sc = device_get_softc(dev);
if (type == PCI_RES_BUS)
return (pci_domain_release_bus(sc->ap_segment, child, rid, r));
return (bus_generic_release_resource(dev, child, type, rid, r));
}
#endif
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
2011-07-15 21:08:58 +00:00
#endif
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
static int
acpi_pcib_request_feature(device_t pcib, device_t dev, enum pci_feature feature)
{
uint32_t osc_ctl;
struct acpi_hpcib_softc *sc;
Various fixes for PCI _OSC handling so HotPlug works again. - Rename the default implementation of 'pcib_request_feature' and add a pcib_request_feature() wrapper function (as is often done for new-bus APIs implemented via kobj) that accepts a single function. Previously the call to pcib_request_feature() ended up invoking the method on the great-great-grandparent of the bridge device instead of the grandparent. For a bridge that was a direct child of pci0 on x86 this resulted in the method skipping over the Host-PCI bridge driver and being invoked against nexus0 - When invoking _OSC from a Host-PCI bridge driver, invoke device_get_softc() against the Host-PCI bridge device instead of the child bridge that is requesting HotPlug. Using the wrong softc data resulted in garbage being passed for the ACPI handle causing the _OSC call to fail. - While here, perform some other cleanups to _OSC handling in the ACPI Host-PCI bridge driver: - Don't invoke _OSC when requesting a control that has already been granted by the firmware. - Don't set the first word of the capability array before invoking _OSC. This word is always set explicitly by acpi_EvaluateOSC() since it is UUID-independent. - Don't modify the set of granted controls unless _OSC doesn't exist (which is treated as always successful), or the _OSC method doesn't fail. - Don't require an _OSC status of 0 for success. _OSC always returns the updated control mask even if it returns a non-zero status in the first word. - Whine if _OSC ever tries to revoke a previously-granted control. (It is not supposed to do that.) - While here, add constants for the _OSC status word in acpivar.h (though currently unused). Reported by: adrian Reviewed by: imp MFC after: 1 week Tested on: Lenovo x220 Differential Revision: https://reviews.freebsd.org/D10520
2017-04-27 16:32:42 +00:00
sc = device_get_softc(pcib);
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
2017-02-25 06:11:59 +00:00
switch (feature) {
case PCI_FEATURE_HP:
osc_ctl = PCIM_OSC_CTL_PCIE_HP;
break;
case PCI_FEATURE_AER:
osc_ctl = PCIM_OSC_CTL_PCIE_AER;
break;
default:
return (EINVAL);
}
return (acpi_pcib_osc(sc, osc_ctl));
}
Add support for NUMA domains to bus dma tags. This causes all memory allocated with a tag to come from the specified domain if it meets the other constraints provided by the tag. Automatically create a tag at the root of each bus specifying the domain local to that bus if available. Reviewed by: jhb, kib Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13545
2018-01-12 23:34:16 +00:00
static bus_dma_tag_t
acpi_pcib_get_dma_tag(device_t bus, device_t child)
{
struct acpi_hpcib_softc *sc;
sc = device_get_softc(bus);
return (sc->ap_dma_tag);
}
Reference in New Issue Copy Permalink