d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
94140f4781
freebsd-dev/sys/dev/acpica/acpi_pci.c

483 lines
13 KiB
C
Raw Normal View History

Start each of the license/copyright comments with /*-, minor shuffle of lines
2005-01-06 01:43:34 +00:00
/*-
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
* Copyright (c) 1997, Stefan Esser <se@freebsd.org>
* Copyright (c) 2000, Michael Smith <msmith@freebsd.org>
* Copyright (c) 2000, BSDi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice unmodified, this list of conditions, and the following
* disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
Use __FBSDID(). Also some minor style cleanups.
2003-08-24 17:55:58 +00:00
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-28 13:33:29 +00:00
#include "opt_acpi.h"
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/bus.h>
#include <sys/kernel.h>
#include <sys/malloc.h>
#include <sys/module.h>
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>
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
#include <dev/acpica/acpivar.h>
Associate device_t objects with ACPI handles via PCI_CHILD_ADDED(). Previously, the ACPI PCI bus driver did a single pass over the devices in the namespace that were a child of a given PCI bus to associate the PCI bus-enumerated device_t devices with the corresponding ACPI handles. However, this meant that handles were only established at runtime for devices found during the initial PCI bus scan. PCI_IOV adds devices that show up after the initial PCI bus scan, and coming changes to add a bus rescan can also add devices after the initial scan. This change adds a pci_child_added() callback to the ACPI PCI bus that walks the namespace to find the ACPI handle for each device that is added. Using a callback means that the handle is correctly set for any device no matter how it is added (initial scan, IOV, or a bus rescan).
2016-04-07 17:15:16 +00:00
#include <dev/acpica/acpi_pcivar.h>
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
#include <sys/pciio.h>
#include <dev/pci/pcireg.h>
#include <dev/pci/pcivar.h>
#include <dev/pci/pci_private.h>
#include "pcib_if.h"
#include "pci_if.h"
Style cleanups, don't set the device description before the probe routine has completed successfully.
2004-05-29 04:32:50 +00:00
/* Hooks for the ACPI CA debugging infrastructure. */
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
#define _COMPONENT ACPI_BUS
ACPI_MODULE_NAME("PCI")
struct acpi_pci_devinfo {
Style cleanups, don't set the device description before the probe routine has completed successfully.
2004-05-29 04:32:50 +00:00
struct pci_devinfo ap_dinfo;
ACPI_HANDLE ap_handle;
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;
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
};
MPSAFE locking * Serialize access to acpi_pci_set_powerstate_method().
2004-08-13 06:21:58 +00:00
ACPI_SERIAL_DECL(pci_powerstate, "ACPI PCI power methods");
Instead of translating PCI to ACPI power states, just use a CTASSERT that they are equivalent.
2004-11-29 18:48:51 +00:00
/* Be sure that ACPI and PCI power states are equivalent. */
CTASSERT(ACPI_STATE_D0 == PCI_POWERSTATE_D0);
CTASSERT(ACPI_STATE_D1 == PCI_POWERSTATE_D1);
CTASSERT(ACPI_STATE_D2 == PCI_POWERSTATE_D2);
CTASSERT(ACPI_STATE_D3 == PCI_POWERSTATE_D3);
Add a new PCI bus interface method to alloc the ivars (dinfo) for a device. The ACPI and OFW PCI bus drivers as well as CardBus override this to allocate the larger ivars to hold additional info beyond the stock PCI ivars. This removes the need to pass the size to functions like pci_add_iov_child() and pci_read_device() simplifying IOV and bus rescanning implementations. As a result of this and earlier changes, the ACPI PCI bus driver no longer needs its own device_attach and pci_create_iov_child methods but can use the methods in the stock PCI bus driver instead. Differential Revision: https://reviews.freebsd.org/D5891
2016-04-15 03:42:12 +00:00
static struct pci_devinfo *acpi_pci_alloc_devinfo(device_t dev);
Support hot insertion and removal of PCI devices on EC2. Install ACPI notify handlers on PCI devices with an _EJ0 method. This handler is invoked when devices are added or removed. - When an ACPI_NOTIFY_DEVICE_CHECK event posts, rescan the parent bus device. Note that strictly speaking we only need to rescan the specified device, but BUS_RESCAN is what is available, so we rescan the entire bus. - When an ACPI_NOTIFY_EJECT_REQUEST event posts, detach the device associated with the ACPI handle, invoke the _EJ0 method, and then delete the device. Eventually this might be changed to vector notify events to devd in userspace where devctl can be used instead to permit more complex actions such as graceful unmounting of filesystems. Tested by: cperciva Reviewed by: cperciva, imp, scottl MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 19:04:39 +00:00
static int acpi_pci_attach(device_t dev);
Convert pci_delete_child() to a bus_child_deleted() method. Instead of providing a wrapper around device_delete_child() that the PCI bus and child bus drivers must call explicitly, move the bulk of the logic from pci_delete_child() into a bus_child_deleted() method (pci_child_deleted()). This allows PCI devices to be safely deleted via device_delete_child(). - Add a bus_child_deleted method to the ACPI PCI bus which clears the device_t associated with the corresponding ACPI handle in addition to the normal PCI bus cleanup. - Change cardbus_detach_card to call device_delete_children() and move CardBus-specific delete logic into a new cardbus_child_deleted() method. - Use device_delete_child() instead of pci_delete_child() in the SRIOV code. - Add a bus_child_deleted method to the OpenFirmware PCI bus drivers which frees the OpenFirmware device info for each PCI device. Reviewed by: imp Tested on: amd64 (CardBus and PCI-e hotplug) Differential Revision: https://reviews.freebsd.org/D5831
2016-04-06 04:10:22 +00:00
static void acpi_pci_child_deleted(device_t dev, device_t child);
Add ACPI path in location string for ACPI namespace aware PCI device.
2004-03-31 17:27:19 +00:00
static int acpi_pci_child_location_str_method(device_t cbdev,
Style cleanups, don't set the device description before the probe routine has completed successfully.
2004-05-29 04:32:50 +00:00
device_t child, char *buf, size_t buflen);
Support hot insertion and removal of PCI devices on EC2. Install ACPI notify handlers on PCI devices with an _EJ0 method. This handler is invoked when devices are added or removed. - When an ACPI_NOTIFY_DEVICE_CHECK event posts, rescan the parent bus device. Note that strictly speaking we only need to rescan the specified device, but BUS_RESCAN is what is available, so we rescan the entire bus. - When an ACPI_NOTIFY_EJECT_REQUEST event posts, detach the device associated with the ACPI handle, invoke the _EJ0 method, and then delete the device. Eventually this might be changed to vector notify events to devd in userspace where devctl can be used instead to permit more complex actions such as graceful unmounting of filesystems. Tested by: cperciva Reviewed by: cperciva, imp, scottl MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 19:04:39 +00:00
static int acpi_pci_detach(device_t dev);
Now that we associate a device_t with ACPI device handles, lookup the device associated with any PCI devices that are enumerated in the ACPI tree when adding children to an ACPI PCI bus and remove the duplicate ACPI-only device_t and replace the device_t associated with the handle with the ACPI and PCI aware device_t.
2004-06-23 15:08:40 +00:00
static int acpi_pci_probe(device_t dev);
static int acpi_pci_read_ivar(device_t dev, device_t child, int which,
uintptr_t *result);
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
static int acpi_pci_write_ivar(device_t dev, device_t child, int which,
uintptr_t value);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
static ACPI_STATUS acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 level,
Style cleanups, don't set the device description before the probe routine has completed successfully.
2004-05-29 04:32:50 +00:00
void *context, void **status);
Now that we associate a device_t with ACPI device handles, lookup the device associated with any PCI devices that are enumerated in the ACPI tree when adding children to an ACPI PCI bus and remove the duplicate ACPI-only device_t and replace the device_t associated with the handle with the ACPI and PCI aware device_t.
2004-06-23 15:08:40 +00:00
static int acpi_pci_set_powerstate_method(device_t dev, device_t child,
int state);
static void acpi_pci_update_device(ACPI_HANDLE handle, device_t pci_child);
Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-28 13:33:29 +00:00
static bus_dma_tag_t acpi_pci_get_dma_tag(device_t bus, device_t child);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
static device_method_t acpi_pci_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, acpi_pci_probe),
Support hot insertion and removal of PCI devices on EC2. Install ACPI notify handlers on PCI devices with an _EJ0 method. This handler is invoked when devices are added or removed. - When an ACPI_NOTIFY_DEVICE_CHECK event posts, rescan the parent bus device. Note that strictly speaking we only need to rescan the specified device, but BUS_RESCAN is what is available, so we rescan the entire bus. - When an ACPI_NOTIFY_EJECT_REQUEST event posts, detach the device associated with the ACPI handle, invoke the _EJ0 method, and then delete the device. Eventually this might be changed to vector notify events to devd in userspace where devctl can be used instead to permit more complex actions such as graceful unmounting of filesystems. Tested by: cperciva Reviewed by: cperciva, imp, scottl MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 19:04:39 +00:00
DEVMETHOD(device_attach, acpi_pci_attach),
DEVMETHOD(device_detach, acpi_pci_detach),
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
/* Bus interface */
DEVMETHOD(bus_read_ivar, acpi_pci_read_ivar),
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
DEVMETHOD(bus_write_ivar, acpi_pci_write_ivar),
Convert pci_delete_child() to a bus_child_deleted() method. Instead of providing a wrapper around device_delete_child() that the PCI bus and child bus drivers must call explicitly, move the bulk of the logic from pci_delete_child() into a bus_child_deleted() method (pci_child_deleted()). This allows PCI devices to be safely deleted via device_delete_child(). - Add a bus_child_deleted method to the ACPI PCI bus which clears the device_t associated with the corresponding ACPI handle in addition to the normal PCI bus cleanup. - Change cardbus_detach_card to call device_delete_children() and move CardBus-specific delete logic into a new cardbus_child_deleted() method. - Use device_delete_child() instead of pci_delete_child() in the SRIOV code. - Add a bus_child_deleted method to the OpenFirmware PCI bus drivers which frees the OpenFirmware device info for each PCI device. Reviewed by: imp Tested on: amd64 (CardBus and PCI-e hotplug) Differential Revision: https://reviews.freebsd.org/D5831
2016-04-06 04:10:22 +00:00
DEVMETHOD(bus_child_deleted, acpi_pci_child_deleted),
Add ACPI path in location string for ACPI namespace aware PCI device.
2004-03-31 17:27:19 +00:00
DEVMETHOD(bus_child_location_str, acpi_pci_child_location_str_method),
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_get_cpus),
Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-28 13:33:29 +00:00
DEVMETHOD(bus_get_dma_tag, acpi_pci_get_dma_tag),
Add a bus method to fetch the VM domain for the given device/bus. * Add a bus_if.m method - get_domain() - returning the VM domain or ENOENT if the device isn't in a VM domain; * Add bus methods to print out the domain of the device if appropriate; * Add code in srat.c to save the PXM -> VM domain mapping that's done and expose a function to translate VM domain -> PXM; * Add ACPI and ACPI PCI methods to check if the bus has a _PXM attribute and if so map it to the VM domain; * (.. yes, this works recursively.) * Have the pci bus glue print out the device VM domain if present. Note: this is just the plumbing to start enumerating information - it doesn't at all modify behaviour. Differential Revision: D906 Reviewed by: jhb Sponsored by: Norse Corp
2014-10-09 05:33:25 +00:00
DEVMETHOD(bus_get_domain, acpi_get_domain),
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
/* PCI interface */
Add a new PCI bus interface method to alloc the ivars (dinfo) for a device. The ACPI and OFW PCI bus drivers as well as CardBus override this to allocate the larger ivars to hold additional info beyond the stock PCI ivars. This removes the need to pass the size to functions like pci_add_iov_child() and pci_read_device() simplifying IOV and bus rescanning implementations. As a result of this and earlier changes, the ACPI PCI bus driver no longer needs its own device_attach and pci_create_iov_child methods but can use the methods in the stock PCI bus driver instead. Differential Revision: https://reviews.freebsd.org/D5891
2016-04-15 03:42:12 +00:00
DEVMETHOD(pci_alloc_devinfo, acpi_pci_alloc_devinfo),
Associate device_t objects with ACPI handles via PCI_CHILD_ADDED(). Previously, the ACPI PCI bus driver did a single pass over the devices in the namespace that were a child of a given PCI bus to associate the PCI bus-enumerated device_t devices with the corresponding ACPI handles. However, this meant that handles were only established at runtime for devices found during the initial PCI bus scan. PCI_IOV adds devices that show up after the initial PCI bus scan, and coming changes to add a bus rescan can also add devices after the initial scan. This change adds a pci_child_added() callback to the ACPI PCI bus that walks the namespace to find the ACPI handle for each device that is added. Using a callback means that the handle is correctly set for any device no matter how it is added (initial scan, IOV, or a bus rescan).
2016-04-07 17:15:16 +00:00
DEVMETHOD(pci_child_added, acpi_pci_child_added),
Implement an ACPI-aware pci_set_powerstate() method for PCI busses that are enumerated in the ACPI device tree. In addition to the normal PCI powerstate functionality, the ACPI _PSx methods are executed and ACPI PowerResources are switched on and off via the acpi_pwr_switch_consumer() function. Glanced at by: imp, njl
2004-04-07 19:42:21 +00:00
DEVMETHOD(pci_set_powerstate, acpi_pci_set_powerstate_method),
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on device_method_t arrays Reviewed by: cognet Approved by: cognet
2013-01-30 18:01:20 +00:00
DEVMETHOD_END
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
};
Make the ACPI and OpenFirmware PCI bus drivers subclasses of the generic PCI bus driver.
2006-01-20 22:01:34 +00:00
static devclass_t pci_devclass;
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
- Add a bus_dma tag to each PCI bus that is a child of a Host-PCI bridge. The tag enforces a single restriction that all DMA transactions must not cross a 4GB boundary. Note that while this restriction technically only applies to PCI-express, this change applies it to all PCI devices as it is simpler to implement that way and errs on the side of caution. - Add a softc structure for PCI bus devices to hold the bus_dma tag and a new pci_attach_common() routine that performs actions common to the attach phase of all PCI bus drivers. Right now this only consists of a bootverbose printf and the allocate of a bus_dma tag if necessary. - Adjust all PCI bus drivers to allocate a PCI bus softc and to call pci_attach_common() from their attach routines. MFC after: 2 weeks
2012-03-02 20:38:04 +00:00
DEFINE_CLASS_1(pci, acpi_pci_driver, acpi_pci_methods, sizeof(struct pci_softc),
pci_driver);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
DRIVER_MODULE(acpi_pci, pcib, acpi_pci_driver, pci_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_pci, acpi, 1, 1, 1);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
MODULE_DEPEND(acpi_pci, pci, 1, 1, 1);
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_VERSION(acpi_pci, 1);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
Add a new PCI bus interface method to alloc the ivars (dinfo) for a device. The ACPI and OFW PCI bus drivers as well as CardBus override this to allocate the larger ivars to hold additional info beyond the stock PCI ivars. This removes the need to pass the size to functions like pci_add_iov_child() and pci_read_device() simplifying IOV and bus rescanning implementations. As a result of this and earlier changes, the ACPI PCI bus driver no longer needs its own device_attach and pci_create_iov_child methods but can use the methods in the stock PCI bus driver instead. Differential Revision: https://reviews.freebsd.org/D5891
2016-04-15 03:42:12 +00:00
static struct pci_devinfo *
acpi_pci_alloc_devinfo(device_t dev)
{
struct acpi_pci_devinfo *dinfo;
dinfo = malloc(sizeof(*dinfo), M_DEVBUF, M_WAITOK | M_ZERO);
return (&dinfo->ap_dinfo);
}
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
static int
acpi_pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct acpi_pci_devinfo *dinfo;
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
dinfo = device_get_ivars(child);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
switch (which) {
Staticize pnp methods, style fixes. Remove unused variable to unbreak kernel build.
2004-03-31 17:35:28 +00:00
case ACPI_IVAR_HANDLE:
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
*result = (uintptr_t)dinfo->ap_handle;
Staticize pnp methods, style fixes. Remove unused variable to unbreak kernel build.
2004-03-31 17:35:28 +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)dinfo->ap_flags;
return (0);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
}
Staticize pnp methods, style fixes. Remove unused variable to unbreak kernel build.
2004-03-31 17:35:28 +00:00
return (pci_read_ivar(dev, child, which, result));
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
}
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
static int
acpi_pci_write_ivar(device_t dev, device_t child, int which, uintptr_t value)
{
struct acpi_pci_devinfo *dinfo;
dinfo = device_get_ivars(child);
switch (which) {
case ACPI_IVAR_HANDLE:
dinfo->ap_handle = (ACPI_HANDLE)value;
return (0);
case ACPI_IVAR_FLAGS:
dinfo->ap_flags = (int)value;
return (0);
}
return (pci_write_ivar(dev, child, which, value));
}
Convert pci_delete_child() to a bus_child_deleted() method. Instead of providing a wrapper around device_delete_child() that the PCI bus and child bus drivers must call explicitly, move the bulk of the logic from pci_delete_child() into a bus_child_deleted() method (pci_child_deleted()). This allows PCI devices to be safely deleted via device_delete_child(). - Add a bus_child_deleted method to the ACPI PCI bus which clears the device_t associated with the corresponding ACPI handle in addition to the normal PCI bus cleanup. - Change cardbus_detach_card to call device_delete_children() and move CardBus-specific delete logic into a new cardbus_child_deleted() method. - Use device_delete_child() instead of pci_delete_child() in the SRIOV code. - Add a bus_child_deleted method to the OpenFirmware PCI bus drivers which frees the OpenFirmware device info for each PCI device. Reviewed by: imp Tested on: amd64 (CardBus and PCI-e hotplug) Differential Revision: https://reviews.freebsd.org/D5831
2016-04-06 04:10:22 +00:00
static void
acpi_pci_child_deleted(device_t dev, device_t child)
{
struct acpi_pci_devinfo *dinfo = device_get_ivars(child);
if (acpi_get_device(dinfo->ap_handle) == child)
AcpiDetachData(dinfo->ap_handle, acpi_fake_objhandler);
pci_child_deleted(dev, child);
}
Add ACPI path in location string for ACPI namespace aware PCI device.
2004-03-31 17:27:19 +00:00
static int
acpi_pci_child_location_str_method(device_t cbdev, device_t child, char *buf,
size_t buflen)
{
struct acpi_pci_devinfo *dinfo = device_get_ivars(child);
Populate the device info string with _PXM (proximity domain) information. This is primarily useful for debugging right now - it'll show up in devinfo. Reviewed by: jhb
2014-09-20 04:31:12 +00:00
int pxm;
char buf2[32];
Staticize pnp methods, style fixes. Remove unused variable to unbreak kernel build.
2004-03-31 17:35:28 +00:00
Add ACPI path in location string for ACPI namespace aware PCI device.
2004-03-31 17:27:19 +00:00
pci_child_location_str_method(cbdev, child, buf, buflen);
Populate the device info string with _PXM (proximity domain) information. This is primarily useful for debugging right now - it'll show up in devinfo. Reviewed by: jhb
2014-09-20 04:31:12 +00:00
Staticize pnp methods, style fixes. Remove unused variable to unbreak kernel build.
2004-03-31 17:35:28 +00:00
if (dinfo->ap_handle) {
Populate the device info string with _PXM (proximity domain) information. This is primarily useful for debugging right now - it'll show up in devinfo. Reviewed by: jhb
2014-09-20 04:31:12 +00:00
strlcat(buf, " handle=", buflen);
strlcat(buf, acpi_name(dinfo->ap_handle), buflen);
if (ACPI_SUCCESS(acpi_GetInteger(dinfo->ap_handle, "_PXM", &pxm))) {
snprintf(buf2, 32, " _PXM=%d", pxm);
strlcat(buf, buf2, buflen);
}
Add ACPI path in location string for ACPI namespace aware PCI device.
2004-03-31 17:27:19 +00:00
}
return (0);
}
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
/*
* PCI power manangement
*/
static int
acpi_pci_set_powerstate_method(device_t dev, device_t child, int state)
{
Only try to set the ACPI power state if the handle is valid. There was probably no problem with this except it may have had the side effect of registering a NULL consumer.
2004-04-14 17:46:21 +00:00
ACPI_HANDLE h;
Implement an ACPI-aware pci_set_powerstate() method for PCI busses that are enumerated in the ACPI device tree. In addition to the normal PCI powerstate functionality, the ACPI _PSx methods are executed and ACPI PowerResources are switched on and off via the acpi_pwr_switch_consumer() function. Glanced at by: imp, njl
2004-04-07 19:42:21 +00:00
ACPI_STATUS status;
Instead of translating PCI to ACPI power states, just use a CTASSERT that they are equivalent.
2004-11-29 18:48:51 +00:00
int old_state, error;
Implement an ACPI-aware pci_set_powerstate() method for PCI busses that are enumerated in the ACPI device tree. In addition to the normal PCI powerstate functionality, the ACPI _PSx methods are executed and ACPI PowerResources are switched on and off via the acpi_pwr_switch_consumer() function. Glanced at by: imp, njl
2004-04-07 19:42:21 +00:00
MPSAFE locking * Serialize access to acpi_pci_set_powerstate_method().
2004-08-13 06:21:58 +00:00
error = 0;
Instead of translating PCI to ACPI power states, just use a CTASSERT that they are equivalent.
2004-11-29 18:48:51 +00:00
if (state < ACPI_STATE_D0 || state > ACPI_STATE_D3)
Implement an ACPI-aware pci_set_powerstate() method for PCI busses that are enumerated in the ACPI device tree. In addition to the normal PCI powerstate functionality, the ACPI _PSx methods are executed and ACPI PowerResources are switched on and off via the acpi_pwr_switch_consumer() function. Glanced at by: imp, njl
2004-04-07 19:42:21 +00:00
return (EINVAL);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
Implement an ACPI-aware pci_set_powerstate() method for PCI busses that are enumerated in the ACPI device tree. In addition to the normal PCI powerstate functionality, the ACPI _PSx methods are executed and ACPI PowerResources are switched on and off via the acpi_pwr_switch_consumer() function. Glanced at by: imp, njl
2004-04-07 19:42:21 +00:00
/*
* We set the state using PCI Power Management outside of setting
* the ACPI state. This means that when powering down a device, we
* first shut it down using PCI, and then using ACPI, which lets ACPI
* try to power down any Power Resources that are now no longer used.
* When powering up a device, we let ACPI set the state first so that
* it can enable any needed Power Resources before changing the PCI
* power state.
*/
MPSAFE locking * Serialize access to acpi_pci_set_powerstate_method().
2004-08-13 06:21:58 +00:00
ACPI_SERIAL_BEGIN(pci_powerstate);
Implement an ACPI-aware pci_set_powerstate() method for PCI busses that are enumerated in the ACPI device tree. In addition to the normal PCI powerstate functionality, the ACPI _PSx methods are executed and ACPI PowerResources are switched on and off via the acpi_pwr_switch_consumer() function. Glanced at by: imp, njl
2004-04-07 19:42:21 +00:00
old_state = pci_get_powerstate(child);
Introduce a new tunable 'hw.pci.do_power_suspend'. This tunable lets you avoid PCI power state transition from D0 to D3 for suspending case. Default is 1 or enabled.
2010-10-20 16:47:09 +00:00
if (old_state < state && pci_do_power_suspend) {
Implement an ACPI-aware pci_set_powerstate() method for PCI busses that are enumerated in the ACPI device tree. In addition to the normal PCI powerstate functionality, the ACPI _PSx methods are executed and ACPI PowerResources are switched on and off via the acpi_pwr_switch_consumer() function. Glanced at by: imp, njl
2004-04-07 19:42:21 +00:00
error = pci_set_powerstate_method(dev, child, state);
if (error)
MPSAFE locking * Serialize access to acpi_pci_set_powerstate_method().
2004-08-13 06:21:58 +00:00
goto out;
Implement an ACPI-aware pci_set_powerstate() method for PCI busses that are enumerated in the ACPI device tree. In addition to the normal PCI powerstate functionality, the ACPI _PSx methods are executed and ACPI PowerResources are switched on and off via the acpi_pwr_switch_consumer() function. Glanced at by: imp, njl
2004-04-07 19:42:21 +00:00
}
Remove accidental change.
2004-06-07 21:44:01 +00:00
h = acpi_get_handle(child);
Instead of translating PCI to ACPI power states, just use a CTASSERT that they are equivalent.
2004-11-29 18:48:51 +00:00
status = acpi_pwr_switch_consumer(h, state);
Remove PCI_SET_POWERSTATE method from acpi.c and eradicate all PCI-specific knowledges from the file. All PCI devices enumerated in ACPI tree must use correct one from acpi_pci.c any way. Reduce duplicate codes as we did for pci.c in r213905. Do not return ESRCH from PCIB_POWER_FOR_SLEEP method. When the method is not found, just return zero without modifying the given default value as it is completely optional. As a side effect, the return state must not be NULL. Note there is actually no functional change by removing ESRCH because acpi_pcib_power_for_sleep() always returns zero. Adjust debugging messages and add new ones under bootverbose to help debugging device power state related issues. Reviewed by: jhb, imp (earlier versions)
2010-10-19 19:53:06 +00:00
if (ACPI_SUCCESS(status)) {
if (bootverbose)
device_printf(dev, "set ACPI power state D%d on %s\n",
state, acpi_name(h));
} else if (status != AE_NOT_FOUND)
Avoid printing extraneous warning messages when trying to switch a device which doesn't support ACPI power states. Return AE_NOT_FOUND for these cases and don't print the warning message. Also, print the name of the handle instead of device when unable to switch states. The device is often not attached at this point and so its name is NULL, which doesn't help debugging.
2004-06-07 21:39:15 +00:00
device_printf(dev,
Remove PCI_SET_POWERSTATE method from acpi.c and eradicate all PCI-specific knowledges from the file. All PCI devices enumerated in ACPI tree must use correct one from acpi_pci.c any way. Reduce duplicate codes as we did for pci.c in r213905. Do not return ESRCH from PCIB_POWER_FOR_SLEEP method. When the method is not found, just return zero without modifying the given default value as it is completely optional. As a side effect, the return state must not be NULL. Note there is actually no functional change by removing ESRCH because acpi_pcib_power_for_sleep() always returns zero. Adjust debugging messages and add new ones under bootverbose to help debugging device power state related issues. Reviewed by: jhb, imp (earlier versions)
2010-10-19 19:53:06 +00:00
"failed to set ACPI power state D%d on %s: %s\n",
Instead of translating PCI to ACPI power states, just use a CTASSERT that they are equivalent.
2004-11-29 18:48:51 +00:00
state, acpi_name(h), AcpiFormatException(status));
Make any PCI devices enumerated in ACPI tree honor do_power_resume as well.
2010-10-19 18:43:11 +00:00
if (old_state > state && pci_do_power_resume)
MPSAFE locking * Serialize access to acpi_pci_set_powerstate_method().
2004-08-13 06:21:58 +00:00
error = pci_set_powerstate_method(dev, child, state);
out:
ACPI_SERIAL_END(pci_powerstate);
return (error);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
}
Now that we associate a device_t with ACPI device handles, lookup the device associated with any PCI devices that are enumerated in the ACPI tree when adding children to an ACPI PCI bus and remove the duplicate ACPI-only device_t and replace the device_t associated with the handle with the ACPI and PCI aware device_t.
2004-06-23 15:08:40 +00:00
static void
acpi_pci_update_device(ACPI_HANDLE handle, device_t pci_child)
{
ACPI_STATUS status;
device_t child;
/*
Don't create a device_t object or parse current resources (via _CRS) for ACPI Device() objects that do not have any device IDs available via the _HID or _CID methods. Without a device ID a device driver cannot attach to the device anyway. Namespace objects that are devices but not of type ACPI_TYPE_DEVICE are not affected. A few BIOSes have also attached a _CRS method to a PCI device to allocate resources that are not managed via a BAR. With the previous code those resources are allocated from acpi0 directly which can interfere with the new PCI-PCI bridge driver (since the PCI device in question may be behind a bridge and its resources should be allocated from that bridge's windows instead). The resources were also orphaned and and would end up associated with some other random device whose device_t reused the pointer of the original ACPI-enumerated device (after it was free'd by the ACPI PCI bus driver) in devinfo output which was confusing. If we want to handle _CRS on PCI devices we can adjust the ACPI PCI bus driver to do that in the future and associate the resources with the proper device object respecting PCI-PCI bridges, etc. Note that with this change the ACPI PCI bus driver no longer has to delete ACPI-enumerated device_t devices that mirror PCI devices since they should in general not exist. There are rare cases when a BIOS will give a PCI device a _HID (e.g. I've seen a PCI-ISA bridge given a _HID for a system resource device). In that case we leave both the ACPI and PCI-enumerated device_t objects around just as in the previous code.
2011-06-17 21:19:01 +00:00
* Occasionally a PCI device may show up as an ACPI device
* with a _HID. (For example, the TabletPC TC1000 has a
* second PCI-ISA bridge that has a _HID for an
* acpi_sysresource device.) In that case, leave ACPI-CA's
* device data pointing at the ACPI-enumerated device.
Now that we associate a device_t with ACPI device handles, lookup the device associated with any PCI devices that are enumerated in the ACPI tree when adding children to an ACPI PCI bus and remove the duplicate ACPI-only device_t and replace the device_t associated with the handle with the ACPI and PCI aware device_t.
2004-06-23 15:08:40 +00:00
*/
child = acpi_get_device(handle);
if (child != NULL) {
KASSERT(device_get_parent(child) ==
devclass_get_device(devclass_find("acpi"), 0),
("%s: child (%s)'s parent is not acpi0", __func__,
acpi_name(handle)));
Don't create a device_t object or parse current resources (via _CRS) for ACPI Device() objects that do not have any device IDs available via the _HID or _CID methods. Without a device ID a device driver cannot attach to the device anyway. Namespace objects that are devices but not of type ACPI_TYPE_DEVICE are not affected. A few BIOSes have also attached a _CRS method to a PCI device to allocate resources that are not managed via a BAR. With the previous code those resources are allocated from acpi0 directly which can interfere with the new PCI-PCI bridge driver (since the PCI device in question may be behind a bridge and its resources should be allocated from that bridge's windows instead). The resources were also orphaned and and would end up associated with some other random device whose device_t reused the pointer of the original ACPI-enumerated device (after it was free'd by the ACPI PCI bus driver) in devinfo output which was confusing. If we want to handle _CRS on PCI devices we can adjust the ACPI PCI bus driver to do that in the future and associate the resources with the proper device object respecting PCI-PCI bridges, etc. Note that with this change the ACPI PCI bus driver no longer has to delete ACPI-enumerated device_t devices that mirror PCI devices since they should in general not exist. There are rare cases when a BIOS will give a PCI device a _HID (e.g. I've seen a PCI-ISA bridge given a _HID for a system resource device). In that case we leave both the ACPI and PCI-enumerated device_t objects around just as in the previous code.
2011-06-17 21:19:01 +00:00
return;
Now that we associate a device_t with ACPI device handles, lookup the device associated with any PCI devices that are enumerated in the ACPI tree when adding children to an ACPI PCI bus and remove the duplicate ACPI-only device_t and replace the device_t associated with the handle with the ACPI and PCI aware device_t.
2004-06-23 15:08:40 +00:00
}
/*
* Update ACPI-CA to use the PCI enumerated device_t for this handle.
*/
Attach the correct handle, not the one that was just deleted. Also, remove some duplicated code.
2004-06-24 01:57:31 +00:00
status = AcpiAttachData(handle, acpi_fake_objhandler, pci_child);
Now that we associate a device_t with ACPI device handles, lookup the device associated with any PCI devices that are enumerated in the ACPI tree when adding children to an ACPI PCI bus and remove the duplicate ACPI-only device_t and replace the device_t associated with the handle with the ACPI and PCI aware device_t.
2004-06-23 15:08:40 +00:00
if (ACPI_FAILURE(status))
printf("WARNING: Unable to attach object data to %s - %s\n",
acpi_name(handle), AcpiFormatException(status));
}
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
static ACPI_STATUS
acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 level, void *context,
void **status)
{
struct acpi_pci_devinfo *dinfo;
Associate device_t objects with ACPI handles via PCI_CHILD_ADDED(). Previously, the ACPI PCI bus driver did a single pass over the devices in the namespace that were a child of a given PCI bus to associate the PCI bus-enumerated device_t devices with the corresponding ACPI handles. However, this meant that handles were only established at runtime for devices found during the initial PCI bus scan. PCI_IOV adds devices that show up after the initial PCI bus scan, and coming changes to add a bus rescan can also add devices after the initial scan. This change adds a pci_child_added() callback to the ACPI PCI bus that walks the namespace to find the ACPI handle for each device that is added. Using a callback means that the handle is correctly set for any device no matter how it is added (initial scan, IOV, or a bus rescan).
2016-04-07 17:15:16 +00:00
device_t child;
int func, slot;
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
UINT32 address;
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
Associate device_t objects with ACPI handles via PCI_CHILD_ADDED(). Previously, the ACPI PCI bus driver did a single pass over the devices in the namespace that were a child of a given PCI bus to associate the PCI bus-enumerated device_t devices with the corresponding ACPI handles. However, this meant that handles were only established at runtime for devices found during the initial PCI bus scan. PCI_IOV adds devices that show up after the initial PCI bus scan, and coming changes to add a bus rescan can also add devices after the initial scan. This change adds a pci_child_added() callback to the ACPI PCI bus that walks the namespace to find the ACPI handle for each device that is added. Using a callback means that the handle is correctly set for any device no matter how it is added (initial scan, IOV, or a bus rescan).
2016-04-07 17:15:16 +00:00
child = context;
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
if (ACPI_FAILURE(acpi_GetInteger(handle, "_ADR", &address)))
Style cleanups, don't set the device description before the probe routine has completed successfully.
2004-05-29 04:32:50 +00:00
return_ACPI_STATUS (AE_OK);
Add a couple of macros to extract the PCI slot (device) and function from an ACPI _ADR value and use that rather than inlining the same shifts and masks everywhere.
2004-09-22 15:46:16 +00:00
slot = ACPI_ADR_PCI_SLOT(address);
func = ACPI_ADR_PCI_FUNC(address);
Associate device_t objects with ACPI handles via PCI_CHILD_ADDED(). Previously, the ACPI PCI bus driver did a single pass over the devices in the namespace that were a child of a given PCI bus to associate the PCI bus-enumerated device_t devices with the corresponding ACPI handles. However, this meant that handles were only established at runtime for devices found during the initial PCI bus scan. PCI_IOV adds devices that show up after the initial PCI bus scan, and coming changes to add a bus rescan can also add devices after the initial scan. This change adds a pci_child_added() callback to the ACPI PCI bus that walks the namespace to find the ACPI handle for each device that is added. Using a callback means that the handle is correctly set for any device no matter how it is added (initial scan, IOV, or a bus rescan).
2016-04-07 17:15:16 +00:00
dinfo = device_get_ivars(child);
if (dinfo->ap_dinfo.cfg.func == func &&
dinfo->ap_dinfo.cfg.slot == slot) {
dinfo->ap_handle = handle;
acpi_pci_update_device(handle, child);
return_ACPI_STATUS (AE_CTRL_TERMINATE);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
}
Style cleanups, don't set the device description before the probe routine has completed successfully.
2004-05-29 04:32:50 +00:00
return_ACPI_STATUS (AE_OK);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
}
Associate device_t objects with ACPI handles via PCI_CHILD_ADDED(). Previously, the ACPI PCI bus driver did a single pass over the devices in the namespace that were a child of a given PCI bus to associate the PCI bus-enumerated device_t devices with the corresponding ACPI handles. However, this meant that handles were only established at runtime for devices found during the initial PCI bus scan. PCI_IOV adds devices that show up after the initial PCI bus scan, and coming changes to add a bus rescan can also add devices after the initial scan. This change adds a pci_child_added() callback to the ACPI PCI bus that walks the namespace to find the ACPI handle for each device that is added. Using a callback means that the handle is correctly set for any device no matter how it is added (initial scan, IOV, or a bus rescan).
2016-04-07 17:15:16 +00:00
void
acpi_pci_child_added(device_t dev, device_t child)
{
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
/*
Associate device_t objects with ACPI handles via PCI_CHILD_ADDED(). Previously, the ACPI PCI bus driver did a single pass over the devices in the namespace that were a child of a given PCI bus to associate the PCI bus-enumerated device_t devices with the corresponding ACPI handles. However, this meant that handles were only established at runtime for devices found during the initial PCI bus scan. PCI_IOV adds devices that show up after the initial PCI bus scan, and coming changes to add a bus rescan can also add devices after the initial scan. This change adds a pci_child_added() callback to the ACPI PCI bus that walks the namespace to find the ACPI handle for each device that is added. Using a callback means that the handle is correctly set for any device no matter how it is added (initial scan, IOV, or a bus rescan).
2016-04-07 17:15:16 +00:00
* PCI devices are added via the bus scan in the normal PCI
* bus driver. As each device is added, the
* acpi_pci_child_added() callback walks the ACPI namespace
* under the bridge driver to save ACPI handles to all the
* devices that appear in the ACPI namespace as immediate
* descendants of the bridge.
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
*
* XXX: Sometimes PCI devices show up in the ACPI namespace that
* pci_add_children() doesn't find. We currently just ignore
* these devices.
*/
Add a new PCI bus interface method to alloc the ivars (dinfo) for a device. The ACPI and OFW PCI bus drivers as well as CardBus override this to allocate the larger ivars to hold additional info beyond the stock PCI ivars. This removes the need to pass the size to functions like pci_add_iov_child() and pci_read_device() simplifying IOV and bus rescanning implementations. As a result of this and earlier changes, the ACPI PCI bus driver no longer needs its own device_attach and pci_create_iov_child methods but can use the methods in the stock PCI bus driver instead. Differential Revision: https://reviews.freebsd.org/D5891
2016-04-15 03:42:12 +00:00
AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1,
acpi_pci_save_handle, NULL, child, NULL);
}
static int
acpi_pci_probe(device_t dev)
{
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
Add a new PCI bus interface method to alloc the ivars (dinfo) for a device. The ACPI and OFW PCI bus drivers as well as CardBus override this to allocate the larger ivars to hold additional info beyond the stock PCI ivars. This removes the need to pass the size to functions like pci_add_iov_child() and pci_read_device() simplifying IOV and bus rescanning implementations. As a result of this and earlier changes, the ACPI PCI bus driver no longer needs its own device_attach and pci_create_iov_child methods but can use the methods in the stock PCI bus driver instead. Differential Revision: https://reviews.freebsd.org/D5891
2016-04-15 03:42:12 +00:00
if (acpi_get_handle(dev) == NULL)
return (ENXIO);
device_set_desc(dev, "ACPI PCI bus");
return (BUS_PROBE_DEFAULT);
Add an ACPI PCI bus driver that is a subclass of the generic PCI bus driver. This driver overrides the probe, attach, and read_ivar methods. If the parent bridge is an ACPI PCI bridge, then the probe routine will match, otherwise it will fail. It tests this by seeing if it can get the ACPI_HANDLE ivar from the bridge device. In the attach routine, it uses pci_add_children() to add all the child devices (but with a slightly larger ivar so it can store ACPI_HANDLE's for child devices) and then walks through the ACPI namespace below the bus device to cache ACPI_HANDLE's for all child devices present in the namespace. It does this by comparing the pci slot and function to the address encoded in _ADR of the devices in the ACPI namespace. The read_ivar routine passes most requests off to pci_read_ivar() and adds a new request so that the ACPI_HANDLE for a child device can be read. To add proper power support the power methods can be overridden as well, but that is not currently implemented. Also, there are cases where a device may show in the ACPI namespace as a PCI device that the PCI probe does not find. Currently such devices are ignored. Tested on: i386, ia64
2002-08-26 17:55:42 +00:00
}
Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-28 13:33:29 +00:00
Install an ACPI PCI bus notify handler. Rescan a PCI bus when the ACPI_NOTIFY_BUS_CHECK event is posted to a PCI bus. Reviewed by: scottl MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 19:12:09 +00:00
static void
acpi_pci_bus_notify_handler(ACPI_HANDLE h, UINT32 notify, void *context)
{
device_t dev;
dev = context;
switch (notify) {
case ACPI_NOTIFY_BUS_CHECK:
mtx_lock(&Giant);
BUS_RESCAN(dev);
mtx_unlock(&Giant);
break;
default:
device_printf(dev, "unknown notify %#x\n", notify);
break;
}
}
Support hot insertion and removal of PCI devices on EC2. Install ACPI notify handlers on PCI devices with an _EJ0 method. This handler is invoked when devices are added or removed. - When an ACPI_NOTIFY_DEVICE_CHECK event posts, rescan the parent bus device. Note that strictly speaking we only need to rescan the specified device, but BUS_RESCAN is what is available, so we rescan the entire bus. - When an ACPI_NOTIFY_EJECT_REQUEST event posts, detach the device associated with the ACPI handle, invoke the _EJ0 method, and then delete the device. Eventually this might be changed to vector notify events to devd in userspace where devctl can be used instead to permit more complex actions such as graceful unmounting of filesystems. Tested by: cperciva Reviewed by: cperciva, imp, scottl MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 19:04:39 +00:00
static void
acpi_pci_device_notify_handler(ACPI_HANDLE h, UINT32 notify, void *context)
{
device_t child, dev;
ACPI_STATUS status;
int error;
dev = context;
switch (notify) {
case ACPI_NOTIFY_DEVICE_CHECK:
mtx_lock(&Giant);
BUS_RESCAN(dev);
mtx_unlock(&Giant);
break;
case ACPI_NOTIFY_EJECT_REQUEST:
child = acpi_get_device(h);
if (child == NULL) {
device_printf(dev, "no device to eject for %s\n",
acpi_name(h));
return;
}
mtx_lock(&Giant);
error = device_detach(child);
if (error) {
mtx_unlock(&Giant);
device_printf(dev, "failed to detach %s: %d\n",
device_get_nameunit(child), error);
return;
}
status = acpi_SetInteger(h, "_EJ0", 1);
if (ACPI_FAILURE(status)) {
mtx_unlock(&Giant);
device_printf(dev, "failed to eject %s: %s\n",
acpi_name(h), AcpiFormatException(status));
return;
}
BUS_RESCAN(dev);
mtx_unlock(&Giant);
break;
default:
device_printf(dev, "unknown notify %#x for %s\n", notify,
acpi_name(h));
break;
}
}
static ACPI_STATUS
acpi_pci_install_device_notify_handler(ACPI_HANDLE handle, UINT32 level,
void *context, void **status)
{
ACPI_HANDLE h;
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
if (ACPI_FAILURE(AcpiGetHandle(handle, "_EJ0", &h)))
return_ACPI_STATUS (AE_OK);
AcpiInstallNotifyHandler(handle, ACPI_SYSTEM_NOTIFY,
acpi_pci_device_notify_handler, context);
return_ACPI_STATUS (AE_OK);
}
static int
acpi_pci_attach(device_t dev)
{
int error;
error = pci_attach(dev);
if (error)
return (error);
Install an ACPI PCI bus notify handler. Rescan a PCI bus when the ACPI_NOTIFY_BUS_CHECK event is posted to a PCI bus. Reviewed by: scottl MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 19:12:09 +00:00
AcpiInstallNotifyHandler(acpi_get_handle(dev), ACPI_SYSTEM_NOTIFY,
acpi_pci_bus_notify_handler, dev);
Support hot insertion and removal of PCI devices on EC2. Install ACPI notify handlers on PCI devices with an _EJ0 method. This handler is invoked when devices are added or removed. - When an ACPI_NOTIFY_DEVICE_CHECK event posts, rescan the parent bus device. Note that strictly speaking we only need to rescan the specified device, but BUS_RESCAN is what is available, so we rescan the entire bus. - When an ACPI_NOTIFY_EJECT_REQUEST event posts, detach the device associated with the ACPI handle, invoke the _EJ0 method, and then delete the device. Eventually this might be changed to vector notify events to devd in userspace where devctl can be used instead to permit more complex actions such as graceful unmounting of filesystems. Tested by: cperciva Reviewed by: cperciva, imp, scottl MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 19:04:39 +00:00
AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1,
acpi_pci_install_device_notify_handler, NULL, dev, NULL);
return (0);
}
static ACPI_STATUS
acpi_pci_remove_notify_handler(ACPI_HANDLE handle, UINT32 level, void *context,
void **status)
{
ACPI_HANDLE h;
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
if (ACPI_FAILURE(AcpiGetHandle(handle, "_EJ0", &h)))
return_ACPI_STATUS (AE_OK);
AcpiRemoveNotifyHandler(handle, ACPI_SYSTEM_NOTIFY,
acpi_pci_device_notify_handler);
return_ACPI_STATUS (AE_OK);
}
static int
acpi_pci_detach(device_t dev)
{
AcpiWalkNamespace(ACPI_TYPE_DEVICE, acpi_get_handle(dev), 1,
acpi_pci_remove_notify_handler, NULL, dev, NULL);
Install an ACPI PCI bus notify handler. Rescan a PCI bus when the ACPI_NOTIFY_BUS_CHECK event is posted to a PCI bus. Reviewed by: scottl MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 19:12:09 +00:00
AcpiRemoveNotifyHandler(acpi_get_handle(dev), ACPI_SYSTEM_NOTIFY,
acpi_pci_bus_notify_handler);
Support hot insertion and removal of PCI devices on EC2. Install ACPI notify handlers on PCI devices with an _EJ0 method. This handler is invoked when devices are added or removed. - When an ACPI_NOTIFY_DEVICE_CHECK event posts, rescan the parent bus device. Note that strictly speaking we only need to rescan the specified device, but BUS_RESCAN is what is available, so we rescan the entire bus. - When an ACPI_NOTIFY_EJECT_REQUEST event posts, detach the device associated with the ACPI handle, invoke the _EJ0 method, and then delete the device. Eventually this might be changed to vector notify events to devd in userspace where devctl can be used instead to permit more complex actions such as graceful unmounting of filesystems. Tested by: cperciva Reviewed by: cperciva, imp, scottl MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 19:04:39 +00:00
return (pci_detach(dev));
}
Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-28 13:33:29 +00:00
#ifdef ACPI_DMAR
Rename dmar_get_dma_tag() to acpi_iommu_get_dma_tag(). This is needed for a new IOMMU controller support. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D24943
2020-05-26 16:40:40 +00:00
bus_dma_tag_t acpi_iommu_get_dma_tag(device_t dev, device_t child);
Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-28 13:33:29 +00:00
static bus_dma_tag_t
acpi_pci_get_dma_tag(device_t bus, device_t child)
{
bus_dma_tag_t tag;
if (device_get_parent(child) == bus) {
Rename dmar_get_dma_tag() to acpi_iommu_get_dma_tag(). This is needed for a new IOMMU controller support. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D24943
2020-05-26 16:40:40 +00:00
/* try iommu and return if it works */
tag = acpi_iommu_get_dma_tag(bus, child);
Import the driver for VT-d DMAR hardware, as specified in the revision 1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture Specification. The Extended Context and PASIDs from the rev. 2.2 are not supported, but I am not aware of any released hardware which implements them. Code does not use queued invalidation, see comments for the reason, and does not provide interrupt remapping services. Code implements the management of the guest address space per domain and allows to establish and tear down arbitrary mappings, but not partial unmapping. The superpages are created as needed, but not promoted. Faults are recorded, fault records could be obtained programmatically, and printed on the console. Implement the busdma(9) using DMARs. This busdma backend avoids bouncing and provides security against misbehaving hardware and driver bad programming, preventing leaks and corruption of the memory by wild DMA accesses. By default, the implementation is compiled into amd64 GENERIC kernel but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is written to work on i386, but testing there was low priority, and driver is not enabled in GENERIC. Even with the DMAR turned on, individual devices could be directed to use the bounce busdma with the hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If DMARs are capable of the pass-through translations, it is used, otherwise, an identity-mapping page table is constructed. The driver was tested on Xeon 5400/5500 chipset legacy machine, Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4), ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also works with em(4) and igb(4), but there some fixes are needed for drivers, which are not committed yet. Intel GPUs do not work with DMAR (yet). Many thanks to John Baldwin, who explained me the newbus integration; Peter Holm, who did all testing and helped me to discover and understand several incredible bugs; and to Jim Harris for the access to the EDS and BWG and for listening when I have to explain my findings to somebody. Sponsored by: The FreeBSD Foundation MFC after: 1 month
2013-10-28 13:33:29 +00:00
} else
tag = NULL;
if (tag == NULL)
tag = pci_get_dma_tag(bus, child);
return (tag);
}
#else
static bus_dma_tag_t
acpi_pci_get_dma_tag(device_t bus, device_t child)
{
return (pci_get_dma_tag(bus, child));
}
#endif
Implement interface to create SR-IOV Virtual Functions Implement the interace to create SR-IOV Virtual Functions (VFs). When a driver registers that they support SR-IOV by calling pci_setup_iov(), the SR-IOV code creates a new node in /dev/iov for that device. An ioctl can be invoked on that device to create VFs and have the driver initialize them. At this point, allocating memory I/O windows (BARs) is not supported. Differential Revision: https://reviews.freebsd.org/D76 Reviewed by: jhb MFC after: 1 month Sponsored by: Sandvine Inc.
2015-03-01 00:40:09 +00:00
Reference in New Issue Copy Permalink