d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
3b8de63481
freebsd-dev/sys/dev/pci/pci_private.h

184 lines
8.1 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
/*-
sys/dev: further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
2017-11-27 14:52:40 +00:00
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
*
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +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.
*
* $FreeBSD$
*
*/
#ifndef _PCI_PRIVATE_H_
Replace #define<space> with #define<tab> so the code is consistent with style(9) and avoids mixing the two formats.
2006-12-14 16:53:48 +00:00
#define _PCI_PRIVATE_H_
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +00:00
/*
* Export definitions of the pci bus so that we can more easily share
"Buses" is the preferred plural of "bus" Replace archaic "busses" with modern form "buses." Intentionally excluded: * Old/random drivers I didn't recognize * Old hardware in general * Use of "busses" in code as identifiers No functional change. http://grammarist.com/spelling/buses-busses/ PR: 216099 Reported by: bltsrc at mail.ru Sponsored by: Dell EMC Isilon
2017-01-15 17:54:01 +00:00
* it with "subclass" buses.
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +00:00
*/
Make the 'pci_devclass' pointer variable private (drivers really shouldn't share devclass pointers, a mistake I've encouraged in the past) and move the declaration of the pci_driver kobj class from cardbus.c to pci_private.h so that other drivers can inherit from pci_driver.
2006-01-20 22:00:50 +00:00
DECLARE_CLASS(pci_driver);
Various changes to make it easier to subclass the PCI bus device. - Make the pci devclass a global variable. - Add child devices in pci_attach() instead of pci_probe(). Change pci_probe() to just check for a valid bus number from the associated bridge and return -1000 if successful. This allows subclasses of the PCI bus driver to override the generic driver. - Move the code to load the vendor data into its own public function. Really though, doing this at attach is just plain wrong. This should really be done in the module load routine instead. As a side effect, the 'busno' variable in pci_attach() is now no longer static (minor bug that was harmless so far.) - Change pci_add_children() to take an extra argument that is the size of the device info structure passed to pci_read_device() and make it public so subclasses of the PCI bus can call it in their attach routines. - Move the bits to attach a probed PCI child to a PCI bus into a global pci_add_child() function. This will allow subclasses that can detect a PCI device not found in the normal PCI probe to add those devices in their own attach routine. (I have seen this in the ACPI tree on my laptop for example.) As a side effect, change the static function pci_add_resources() to get the busno, slot, and func from the passed in dinfo structure instead of requiring them as function arguments. Tested on: i386, alpha, ia64, sparc64
2002-08-26 15:23:52 +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
struct pci_softc {
bus_dma_tag_t sc_dma_tag;
Add support for managing PCI bus numbers. As with BARs and PCI-PCI bridge I/O windows, the default is to preserve the firmware-assigned resources. PCI bus numbers are only managed if NEW_PCIB is enabled and the architecture defines a PCI_RES_BUS resource type. - Add a helper API to create top-level PCI bus resource managers for each PCI domain/segment. Host-PCI bridge drivers use this API to allocate bus numbers from their associated domain. - Change the PCI bus and CardBus drivers to allocate a bus resource for their bus number from the parent PCI bridge device. - Change the PCI-PCI and PCI-CardBus bridge drivers to allocate the full range of bus numbers from secbus to subbus from their parent bridge. The drivers also always program their primary bus register. The bridge drivers also support growing their bus range by extending the bus resource and updating subbus to match the larger range. - Add support for managing PCI bus resources to the Host-PCI bridge drivers used for amd64 and i386 (acpi_pcib, mptable_pcib, legacy_pcib, and qpi_pcib). - Define a PCI_RES_BUS resource type for amd64 and i386. Reviewed by: imp MFC after: 1 month
2014-02-12 04:30:37 +00:00
#ifdef PCI_RES_BUS
struct resource *sc_bus;
#endif
- 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
};
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
extern int pci_do_power_resume;
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
extern int pci_do_power_suspend;
Add a new method to the PCI bridge interface, PCIB_POWER_FOR_SLEEP(). This method is used by the PCI bus driver to query the power management system to determine the proper device state to be used for a device during suspend and resume. For the ACPI PCI bridge drivers this calls acpi_device_pwr_for_sleep(). This removes ACPI-specific knowledge from the PCI and PCI-PCI bridge drivers. Reviewed by: jkim
2010-08-17 15:44:52 +00:00
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
void pci_add_children(device_t dev, int domain, int busno);
Various changes to make it easier to subclass the PCI bus device. - Make the pci devclass a global variable. - Add child devices in pci_attach() instead of pci_probe(). Change pci_probe() to just check for a valid bus number from the associated bridge and return -1000 if successful. This allows subclasses of the PCI bus driver to override the generic driver. - Move the code to load the vendor data into its own public function. Really though, doing this at attach is just plain wrong. This should really be done in the module load routine instead. As a side effect, the 'busno' variable in pci_attach() is now no longer static (minor bug that was harmless so far.) - Change pci_add_children() to take an extra argument that is the size of the device info structure passed to pci_read_device() and make it public so subclasses of the PCI bus can call it in their attach routines. - Move the bits to attach a probed PCI child to a PCI bus into a global pci_add_child() function. This will allow subclasses that can detect a PCI device not found in the normal PCI probe to add those devices in their own attach routine. (I have seen this in the ACPI tree on my laptop for example.) As a side effect, change the static function pci_add_resources() to get the busno, slot, and func from the passed in dinfo structure instead of requiring them as function arguments. Tested on: i386, alpha, ia64, sparc64
2002-08-26 15:23:52 +00:00
void pci_add_child(device_t bus, struct pci_devinfo *dinfo);
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
device_t pci_add_iov_child(device_t bus, device_t pf, uint16_t rid,
uint16_t vid, uint16_t did);
Expose pci_add_resources to the outside world, add a 'force' flag to force allocation of unallocated BARs (cardbus uses this to preallocate everything). Add a prefetchmask to allow for busses that get prefetch hints to set them. Addjust pci_add_map and pci_ata_maps to take a new force flag which pci_add_resources will pass in. Implement 'force' in pci_add_map. Write new value of allocated resource into the bar, if the allocation succeeded (we should have done this before, but with the new force the bug was very obvious).
2005-12-30 19:28:26 +00:00
void pci_add_resources(device_t bus, device_t dev, int force,
uint32_t prefetchmask);
Support for Enhanced Allocation in PCI On some platforms, BAR entries are hardcoded and must not be accessed using standard method. Add functionality to identify this situation and configure the bus based on Enhanced Allocation structure. Obtained from: Semihalf Sponsored by: Cavium Approved by: cognet (mentor) Reviewed by: jhb Differential revision: https://reviews.freebsd.org/D5242
2016-03-02 09:54:58 +00:00
void pci_add_resources_ea(device_t bus, device_t dev, int alloc_iov);
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
struct pci_devinfo *pci_alloc_devinfo_method(device_t dev);
Export pci_attach() and pci_detach(). Reviewed by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 18:58:01 +00:00
int pci_attach(device_t dev);
- 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
int pci_attach_common(device_t dev);
Export pci_attach() and pci_detach(). Reviewed by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21948
2019-10-15 18:58:01 +00:00
int pci_detach(device_t dev);
Implement a PCI bus rescan method. Rescanning a PCI bus uses the following steps: - Fetch the current set of child devices and save it in the 'devlist' array. - Allocate a parallel array 'unchanged' initalized with NULL pointers. - Scan the bus checking each slot (and each function on slots with a multifunction device). - If a valid function is found, look for a matching device in the 'devlist' array. If a device is found, save the pointer in the 'unchanged' array. If a device is not found, add a new device. - After the scan has finished, walk the 'devlist' array deleting any devices that do not have a matching pointer in the 'unchanged' array. - Finally, fetch an updated set of child devices and explicitly attach any devices that are not present in the 'unchanged' array. This builds on the previous changes to move subclass data management into pci_alloc_devinfo(), pci_child_added(), and bus_child_deleted(). Subclasses of the PCI bus use custom rescan logic explicitly override the rescan method to disable rescans. Differential Revision: https://reviews.freebsd.org/D6018
2016-04-27 16:31:12 +00:00
int pci_rescan_method(device_t dev);
Omnibus PCI commit: o Save and restore bars for suspend/resume as well as for D3->D0 transitions. o preallocate resources that the PCI devices use to avoid resource conflicts o lazy allocation of resources not allocated by the BIOS. o set unattached drivers to state D3. Set power state to D0 before probe/attach. Right now there's two special cases for this (display and memory devices) that need work in other areas of the tree. Please report any bugs to me.
2004-04-09 15:44:34 +00:00
void pci_driver_added(device_t dev, driver_t *driver);
Support for Enhanced Allocation in PCI On some platforms, BAR entries are hardcoded and must not be accessed using standard method. Add functionality to identify this situation and configure the bus based on Enhanced Allocation structure. Obtained from: Semihalf Sponsored by: Cavium Approved by: cognet (mentor) Reviewed by: jhb Differential revision: https://reviews.freebsd.org/D5242
2016-03-02 09:54:58 +00:00
int pci_ea_is_enabled(device_t dev, int rid);
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +00:00
int pci_print_child(device_t dev, device_t child);
void pci_probe_nomatch(device_t dev, device_t child);
int pci_read_ivar(device_t dev, device_t child, int which,
uintptr_t *result);
int pci_write_ivar(device_t dev, device_t child, int which,
uintptr_t value);
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
int pci_setup_intr(device_t dev, device_t child,
struct resource *irq, int flags, driver_filter_t *filter,
driver_intr_t *intr, void *arg, void **cookiep);
int pci_teardown_intr(device_t dev, device_t child,
struct resource *irq, void *cookie);
provide routines to access VPD data at the PCI layer... remove sk's own implementation, and use the new calls to get the data... Reviewed by: -arch
2006-10-09 16:15:56 +00:00
int pci_get_vpd_ident_method(device_t dev, device_t child,
const char **identptr);
int pci_get_vpd_readonly_method(device_t dev, device_t child,
const char *kw, const char **vptr);
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +00:00
int pci_set_powerstate_method(device_t dev, device_t child,
int state);
int pci_get_powerstate_method(device_t dev, device_t child);
Prefer the uintXX_t to the u_intXX_t names.
2003-08-22 03:11:53 +00:00
uint32_t pci_read_config_method(device_t dev, device_t child,
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +00:00
int reg, int width);
void pci_write_config_method(device_t dev, device_t child,
Prefer the uintXX_t to the u_intXX_t names.
2003-08-22 03:11:53 +00:00
int reg, uint32_t val, int width);
Return status for PCI methods '{enable,disable}_{io,busmaster}'. Reviewed by: imp
2003-04-16 03:15:08 +00:00
int pci_enable_busmaster_method(device_t dev, device_t child);
int pci_disable_busmaster_method(device_t dev, device_t child);
int pci_enable_io_method(device_t dev, device_t child, int space);
int pci_disable_io_method(device_t dev, device_t child, int space);
Expand the set of APIs available for locating PCI capabilities: - pci_find_extcap() is repurposed to be used for fetching PCI-express extended capabilities (PCIZ_* constants in <dev/pci/pcireg.h>). - pci_find_htcap() can be used to locate a specific HyperTransport capability (PCIM_HTCAP_* constants in <dev/pci/pcireg.h>). - Cache the starting location of the PCI-express capability for PCI-express devices in PCI device ivars.
2012-03-03 18:08:57 +00:00
int pci_find_cap_method(device_t dev, device_t child,
int capability, int *capreg);
Add PCI methods to iterate over the PCI capabilities VirtIO V1 provides configuration in multiple VENDOR capabilities so this allows all of the configuration to be discovered. Reviewed by: jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D14325
2018-02-19 18:41:56 +00:00
int pci_find_next_cap_method(device_t dev, device_t child,
int capability, int start, int *capreg);
Add a new method PCI_FIND_EXTCAP() to the pci bus interface that is used to search for a specific extended capability. If the specified capability is found for the given device, then the function returns success and optionally returns the offset of that capability. If the capability is not found, the function returns an error.
2005-12-20 19:57:47 +00:00
int pci_find_extcap_method(device_t dev, device_t child,
Expand the set of APIs available for locating PCI capabilities: - pci_find_extcap() is repurposed to be used for fetching PCI-express extended capabilities (PCIZ_* constants in <dev/pci/pcireg.h>). - pci_find_htcap() can be used to locate a specific HyperTransport capability (PCIM_HTCAP_* constants in <dev/pci/pcireg.h>). - Cache the starting location of the PCI-express capability for PCI-express devices in PCI device ivars.
2012-03-03 18:08:57 +00:00
int capability, int *capreg);
Add PCI methods to iterate over the PCI capabilities VirtIO V1 provides configuration in multiple VENDOR capabilities so this allows all of the configuration to be discovered. Reviewed by: jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D14325
2018-02-19 18:41:56 +00:00
int pci_find_next_extcap_method(device_t dev, device_t child,
int capability, int start, int *capreg);
Expand the set of APIs available for locating PCI capabilities: - pci_find_extcap() is repurposed to be used for fetching PCI-express extended capabilities (PCIZ_* constants in <dev/pci/pcireg.h>). - pci_find_htcap() can be used to locate a specific HyperTransport capability (PCIM_HTCAP_* constants in <dev/pci/pcireg.h>). - Cache the starting location of the PCI-express capability for PCI-express devices in PCI device ivars.
2012-03-03 18:08:57 +00:00
int pci_find_htcap_method(device_t dev, device_t child,
Add a new method PCI_FIND_EXTCAP() to the pci bus interface that is used to search for a specific extended capability. If the specified capability is found for the given device, then the function returns success and optionally returns the offset of that capability. If the capability is not found, the function returns an error.
2005-12-20 19:57:47 +00:00
int capability, int *capreg);
Add PCI methods to iterate over the PCI capabilities VirtIO V1 provides configuration in multiple VENDOR capabilities so this allows all of the configuration to be discovered. Reviewed by: jhb MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D14325
2018-02-19 18:41:56 +00:00
int pci_find_next_htcap_method(device_t dev, device_t child,
int capability, int start, int *capreg);
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
int pci_alloc_msi_method(device_t dev, device_t child, int *count);
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support. - First off, device drivers really do need to know if they are allocating MSI or MSI-X messages. MSI requires allocating powerof2() messages for example where MSI-X does not. To address this, split out the MSI-X support from pci_msi_count() and pci_alloc_msi() into new driver-visible functions pci_msix_count() and pci_alloc_msix(). As a result, pci_msi_count() now just returns a count of the max supported MSI messages for the device, and pci_alloc_msi() only tries to allocate MSI messages. To get a count of the max supported MSI-X messages, use pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix(). pci_release_msi() still handles both MSI and MSI-X messages, however. As a result of this change, drivers using the existing API will only use MSI messages and will no longer try to use MSI-X messages. - Because MSI-X allows for each message to have its own data and address values (and thus does not require all of the messages to have their MD vectors allocated as a group), some devices allow for "sparse" use of MSI-X message slots. For example, if a device supports 8 messages but the OS is only able to allocate 2 messages, the device may make the best use of 2 IRQs if it enables the messages at slots 1 and 4 rather than default of using the first N slots (or indicies) at 1 and 2. To support this, add a new pci_remap_msix() function that a driver may call after a successful pci_alloc_msix() (but before allocating any of the SYS_RES_IRQ resources) to allow the allocated IRQ resources to be assigned to different message indices. For example, from the earlier example, after pci_alloc_msix() returned a value of 2, the driver would call pci_remap_msix() passing in array of integers { 1, 4 } as the new message indices to use. The rid's for the SYS_RES_IRQ resources will always match the message indices. Thus, after the call to pci_remap_msix() the driver would be able to access the first message in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based rather than 0-based so that they will always correspond to the rid values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt). To support this API, a new PCIB_REMAP_MSIX() method was added to the pcib interface to change the message index for a single IRQ. Tested by: scottl
2007-01-22 21:48:44 +00:00
int pci_alloc_msix_method(device_t dev, device_t child, int *count);
pci: make MSI(-X) enable and disable methods of the PCI bus Make the functions pci_disable_msi, pci_enable_msi and pci_enable_msix methods of the newbus PCI bus. This code should not include any functional change. Sponsored by: Citrix Systems R&D Reviewed by: imp, jhb Differential Revision: https://reviews.freebsd.org/D354 dev/pci/pci.c: - Convert the mentioned functions to newbus methods. - Fix the callers of the converted functions. sys/dev/pci/pci_private.h: dev/pci/pci_if.m: - Declare the new methods. dev/pci/pcivar.h: - Add helpers to call the newbus methods. ofed/include/linux/pci.h: - Add define to prevent the ofed version of pci_enable_msix from clashing with the FreeBSD native version.
2014-08-20 14:57:20 +00:00
void pci_enable_msi_method(device_t dev, device_t child,
uint64_t address, uint16_t data);
void pci_enable_msix_method(device_t dev, device_t child,
u_int index, uint64_t address, uint32_t data);
void pci_disable_msi_method(device_t dev, device_t child);
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support. - First off, device drivers really do need to know if they are allocating MSI or MSI-X messages. MSI requires allocating powerof2() messages for example where MSI-X does not. To address this, split out the MSI-X support from pci_msi_count() and pci_alloc_msi() into new driver-visible functions pci_msix_count() and pci_alloc_msix(). As a result, pci_msi_count() now just returns a count of the max supported MSI messages for the device, and pci_alloc_msi() only tries to allocate MSI messages. To get a count of the max supported MSI-X messages, use pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix(). pci_release_msi() still handles both MSI and MSI-X messages, however. As a result of this change, drivers using the existing API will only use MSI messages and will no longer try to use MSI-X messages. - Because MSI-X allows for each message to have its own data and address values (and thus does not require all of the messages to have their MD vectors allocated as a group), some devices allow for "sparse" use of MSI-X message slots. For example, if a device supports 8 messages but the OS is only able to allocate 2 messages, the device may make the best use of 2 IRQs if it enables the messages at slots 1 and 4 rather than default of using the first N slots (or indicies) at 1 and 2. To support this, add a new pci_remap_msix() function that a driver may call after a successful pci_alloc_msix() (but before allocating any of the SYS_RES_IRQ resources) to allow the allocated IRQ resources to be assigned to different message indices. For example, from the earlier example, after pci_alloc_msix() returned a value of 2, the driver would call pci_remap_msix() passing in array of integers { 1, 4 } as the new message indices to use. The rid's for the SYS_RES_IRQ resources will always match the message indices. Thus, after the call to pci_remap_msix() the driver would be able to access the first message in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based rather than 0-based so that they will always correspond to the rid values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt). To support this API, a new PCIB_REMAP_MSIX() method was added to the pcib interface to change the message index for a single IRQ. Tested by: scottl
2007-01-22 21:48:44 +00:00
int pci_remap_msix_method(device_t dev, device_t child,
Revamp the MSI/MSI-X code a bit to achieve two main goals: - Simplify the amount of work that has be done for each architecture by pushing more of the truly MI code down into the PCI bus driver. - Don't bind MSI-X indicies to IRQs so that we can allow a driver to map multiple MSI-X messages into a single IRQ when handling a message shortage. The changes include: - Add a new pcib_if method: PCIB_MAP_MSI() which is called by the PCI bus to calculate the address and data values for a given MSI/MSI-X IRQ. The x86 nexus drivers map this into a call to a new 'msi_map()' function in msi.c that does the mapping. - Retire the pcib_if method PCIB_REMAP_MSIX() and remove the 'index' parameter from PCIB_ALLOC_MSIX(). MD code no longer has any knowledge of the MSI-X index for a given MSI-X IRQ. - The PCI bus driver now stores more MSI-X state in a child's ivars. Specifically, it now stores an array of IRQs (called "message vectors" in the code) that have associated address and data values, and a small virtual version of the MSI-X table that specifies the message vector that a given MSI-X table entry uses. Sparse mappings are permitted in the virtual table. - The PCI bus driver now configures the MSI and MSI-X address/data registers directly via custom bus_setup_intr() and bus_teardown_intr() methods. pci_setup_intr() invokes PCIB_MAP_MSI() to determine the address and data values for a given message as needed. The MD code no longer has to call back down into the PCI bus code to set these values from the nexus' bus_setup_intr() handler. - The PCI bus code provides a callout (pci_remap_msi_irq()) that the MD code can call to force the PCI bus to re-invoke PCIB_MAP_MSI() to get new values of the address and data fields for a given IRQ. The x86 MSI code uses this when an MSI IRQ is moved to a different CPU, requiring a new value of the 'address' field. - The x86 MSI psuedo-driver loses a lot of code, and in fact the separate MSI/MSI-X pseudo-PICs are collapsed down into a single MSI PIC driver since the only remaining diff between the two is a substring in a bootverbose printf. - The PCI bus driver will now restore MSI-X state (including programming entries in the MSI-X table) on device resume. - The interface for pci_remap_msix() has changed. Instead of accepting indices for the allocated vectors, it accepts a mini-virtual table (with a new length parameter). This table is an array of u_ints, where each value specifies which allocated message vector to use for the corresponding MSI-X message. A vector of 0 forces a message to not have an associated IRQ. The device may choose to only use some of the IRQs assigned, in which case the unused IRQs must be at the "end" and will be released back to the system. This allows a driver to use the same remap table for different shortage values. For example, if a driver wants 4 messages, it can use the same remap table (which only uses the first two messages) for the cases when it only gets 2 or 3 messages and in the latter case the PCI bus will release the 3rd IRQ back to the system. MFC after: 1 month
2007-05-02 17:50:36 +00:00
int count, const u_int *vectors);
First cut at MI support for PCI Message Signalled Interrupts (MSI): - Add 3 new functions to the pci_if interface along with suitable wrappers to provide the device driver visible API: - pci_alloc_msi(dev, int *count) backed by PCI_ALLOC_MSI(). '*count' here is an in and out parameter. The driver stores the desired number of messages in '*count' before calling the function. On success, '*count' holds the number of messages allocated to the device. Also on success, the driver can access the messages as SYS_RES_IRQ resources starting at rid 1. Note that the legacy INTx interrupt resource will not be available when using MSI. Note that this function will allocate either MSI or MSI-X messages depending on the devices capabilities and the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. Also note that the driver should activate the memory resource that holds the MSI-X table and pending bit array (PBA) before calling this function if the device supports MSI-X. - pci_release_msi(dev) backed by PCI_RELEASE_MSI(). This function releases the messages allocated for this device. All of the SYS_RES_IRQ resources need to be released for this function to succeed. - pci_msi_count(dev) backed by PCI_MSI_COUNT(). This function returns the maximum number of MSI or MSI-X messages supported by this device. MSI-X is preferred if present, but this function will honor the 'hw.pci.enable_msix' and 'hw.pci.enable_msi' tunables. This function should return the largest value that pci_alloc_msi() can return (assuming the MD code is able to allocate sufficient backing resources for all of the messages). - Add default implementations for these 3 methods to the pci_driver generic PCI bus driver. (The various other PCI bus drivers such as for ACPI and OFW will inherit these default implementations.) This default implementation depends on 4 new pcib_if methods that bubble up through the PCI bridges to the MD code to allocate IRQ values and perform any needed MD setup code needed: - PCIB_ALLOC_MSI() attempts to allocate a group of MSI messages. - PCIB_RELEASE_MSI() releases a group of MSI messages. - PCIB_ALLOC_MSIX() attempts to allocate a single MSI-X message. - PCIB_RELEASE_MSIX() releases a single MSI-X message. - Add default implementations for these 4 methods that just pass the request up to the parent bus's parent bridge driver and use the default implementation in the various MI PCI bridge drivers. - Add MI functions for use by MD code when managing MSI and MSI-X interrupts: - pci_enable_msi(dev, address, data) programs the MSI capability address and data registers for a group of MSI messages - pci_enable_msix(dev, index, address, data) initializes a single MSI-X message in the MSI-X table - pci_mask_msix(dev, index) masks a single MSI-X message - pci_unmask_msix(dev, index) unmasks a single MSI-X message - pci_pending_msix(dev, index) returns true if the specified MSI-X message is currently pending - Save the MSI capability address and data registers in the pci_cfgreg block in a PCI devices ivars and restore the values when a device is resumed. Note that the MSI-X table is not currently restored during resume. - Add constants for MSI-X register offsets and fields. - Record interesting data about any MSI-X capability blocks we come across in the pci_cfgreg block in the ivars for PCI devices. Tested on: em (i386, MSI), bce (amd64/i386, MSI), mpt (amd64, MSI-X) Reviewed by: scottl, grehan, jfv MFC after: 2 months
2006-11-13 21:47:30 +00:00
int pci_release_msi_method(device_t dev, device_t child);
int pci_msi_count_method(device_t dev, device_t child);
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support. - First off, device drivers really do need to know if they are allocating MSI or MSI-X messages. MSI requires allocating powerof2() messages for example where MSI-X does not. To address this, split out the MSI-X support from pci_msi_count() and pci_alloc_msi() into new driver-visible functions pci_msix_count() and pci_alloc_msix(). As a result, pci_msi_count() now just returns a count of the max supported MSI messages for the device, and pci_alloc_msi() only tries to allocate MSI messages. To get a count of the max supported MSI-X messages, use pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix(). pci_release_msi() still handles both MSI and MSI-X messages, however. As a result of this change, drivers using the existing API will only use MSI messages and will no longer try to use MSI-X messages. - Because MSI-X allows for each message to have its own data and address values (and thus does not require all of the messages to have their MD vectors allocated as a group), some devices allow for "sparse" use of MSI-X message slots. For example, if a device supports 8 messages but the OS is only able to allocate 2 messages, the device may make the best use of 2 IRQs if it enables the messages at slots 1 and 4 rather than default of using the first N slots (or indicies) at 1 and 2. To support this, add a new pci_remap_msix() function that a driver may call after a successful pci_alloc_msix() (but before allocating any of the SYS_RES_IRQ resources) to allow the allocated IRQ resources to be assigned to different message indices. For example, from the earlier example, after pci_alloc_msix() returned a value of 2, the driver would call pci_remap_msix() passing in array of integers { 1, 4 } as the new message indices to use. The rid's for the SYS_RES_IRQ resources will always match the message indices. Thus, after the call to pci_remap_msix() the driver would be able to access the first message in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based rather than 0-based so that they will always correspond to the rid values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt). To support this API, a new PCIB_REMAP_MSIX() method was added to the pcib interface to change the message index for a single IRQ. Tested by: scottl
2007-01-22 21:48:44 +00:00
int pci_msix_count_method(device_t dev, device_t child);
Add accessor methods to fetch the BAR holding the MSI-X table and PBA. While here, explicitly note the requirement that the BAR(s) must be allocated prior to calling pci_alloc_msix(). Reviewed by: andrew, emaste MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D4688
2015-12-23 21:51:10 +00:00
int pci_msix_pba_bar_method(device_t dev, device_t child);
int pci_msix_table_bar_method(device_t dev, device_t child);
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +00:00
struct resource *pci_alloc_resource(device_t dev, device_t child,
Convert rman to use rman_res_t instead of u_long Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
int type, int *rid, rman_res_t start, rman_res_t end,
rman_res_t count, u_int flags);
Properly handle I/O windows in bridges with the ISA enable bit set. These beasts still exist unfortunately. More details can be found in other references, but the short version is that bridges with this bit set ignore I/O port ranges that alias to valid ISA I/O port ranges. In the driver this requires not allocating these alias regions from the parent device (so they are free to be acquired by ISA devices), and ensuring no child devices use resources from these alias regions. - Change the pcib_window structure to allow for an array of backing resources rather than a single resource and update the existing code to cope with this. Some of the coping requires using the saved base and limit values in pcib_window instead of using rman operations on the backing resource. - Add special handling for allocating and adjusting the I/O port window of an ISA-enabled bridge to only allocate the non-alias ranges and add those to the associated resource manager. - Reject I/O port allocations for a fixed request that conflicts with an ISA alias range. - Remove the "no prefected decode" verbose printf during boot. The absence of a "prefetched decode" line is sufficient. - Replace the "subtractively decoded bridge" verbose printf with a single printf that lists all the "special" decoding modes of a bridge: ISA, subtractive, and VGA. - Add a custom bus_release_resource() method to the PCI bus driver so that it can properly free resources for I/O windows of PCI-PCI bridges. (These resources are not stored in the bridge device's resource list.) PR: misc/179033 MFC after: 2 weeks
2013-07-18 15:17:11 +00:00
int pci_release_resource(device_t dev, device_t child, int type,
int rid, struct resource *r);
Further refine the handling of resources for BARs in the PCI bus driver. A while back, Warner changed the PCI bus code to reserve resources when enumerating devices and simply give devices the previously allocated resources when they call bus_alloc_resource(). This ensures that address ranges being decoded by a BAR are always allocated in the nexus0 device (or whatever device the PCI bus gets its address space from) even if a device driver is not attached to the device. This patch extends this behavior further: - To let the PCI bus distinguish between a resource being allocated by a device driver vs. merely being allocated by the bus, use rman_set_device() to assign the device to the bus when it is owned by the bus and to the child device when it is allocated by the child device's driver. We can now prevent a device driver from allocating the same device twice. Doing so could result in odd things like allocating duplicate virtual memory to map the resource on some archs and leaking the original mapping. - When a PCI device driver releases a resource, don't pass the request all the way up the tree and release it in the nexus (or similar device) since the BAR is still active and decoding. Otherwise, another device could later allocate the same range even though it is still in use. Instead, deactivate the resource and assign it back to the PCI bus using rman_set_device(). - pci_delete_resource() will actually completely free a BAR including attemping to disable it. - Disable BAR decoding via the command register when sizing a BAR in pci_alloc_map() which is used to allocate resources for a BAR when the BIOS/firmware did not assign a usable resource range during boot. This mirrors an earlier fix to pci_add_map() which is used when to size BARs during boot. - Move the activation of I/O decoding in the PCI command register into pci_activate_resource() instead of doing it in pci_alloc_resource(). Previously we could actually enable decoding before a BAR was initialized via pci_alloc_map(). Glanced at by: bsdimp
2009-03-03 16:38:59 +00:00
int pci_activate_resource(device_t dev, device_t child, int type,
int rid, struct resource *r);
Teach the PCI bus driver to handle PCIR_BIOS BARs properly and remove special handling for the PCIR_BIOS decoding enable bit from the cardbus driver. The PCIR_BIOS BAR does include type bits like other BARs. Instead, it is always a 32-bit non-prefetchable memory BAR where the low bit is used as a flag to enable decoding. Reviewed by: imp
2009-12-30 20:47:14 +00:00
int pci_deactivate_resource(device_t dev, device_t child, int type,
int rid, struct resource *r);
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +00:00
void pci_delete_resource(device_t dev, device_t child,
int type, int rid);
struct resource_list *pci_get_resource_list (device_t dev, device_t child);
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
struct pci_devinfo *pci_read_device(device_t pcib, device_t bus, int d, int b,
int s, int f);
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +00:00
void pci_print_verbose(struct pci_devinfo *dinfo);
int pci_freecfg(struct pci_devinfo *dinfo);
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
void pci_child_deleted(device_t dev, device_t child);
Make detaching drivers from PCI devices more robust. While here, fix a bug where a PCI device would be powered down if it failed to probe, but not when its driver was detached (e.g. via kldunload). - Add a new helper method resource_list_release_active() which forcefully releases any active resources of a specified type from a resource list. - Add a bus_child_detached method for the PCI bus driver which forces any active resources to be released (and whines to the console if it finds any) and then powers the device down. - Call pci_child_detached() if we fail to probe a device when a driver is kldloaded. This isn't perfect but can avoid leaking resources from a probe() routine in the kldload case. Reviewed by: imp, brooks MFC after: 1 month
2013-06-27 20:21:54 +00:00
void pci_child_detached(device_t dev, device_t child);
Move the pnp and location info into the common pci bus. Make all known pci busses implement this. Also minor comment smithing in cardbus. Fix copyright to this year with my name on it since I've been doing a lot to this file. Reviewed by: jhb
2003-02-17 21:20:35 +00:00
int pci_child_location_str_method(device_t cbdev, device_t child,
char *buf, size_t buflen);
int pci_child_pnpinfo_str_method(device_t cbdev, device_t child,
char *buf, size_t buflen);
Add a new PCI interface method, assign_interrupt, to determine the interrupt to be used for a device. This is intended solely for internal use of PCI bus implementations, and exists so that PCI bus drivers implementing special interrupt assignment methods which require additional work at the bus level to work right can be easily derived from the generic driver (or any other one) without resorting to hacks. It will be used in the sparc64 ofw_pcibus driver, which will be committed shortly. Make use of this method in the generic implementation, and add it to the method table of bus drivers derived from the PCI one. Reviewed by: imp, -hackers
2003-07-01 14:08:33 +00:00
int pci_assign_interrupt_method(device_t dev, device_t child);
Add pci_resume() to reestablish interrupt routing after suspend/resume. Especially after hibernation, interrupt routing went back to initial status on some machines.
2003-09-17 08:32:44 +00:00
int pci_resume(device_t dev);
Stage one of multipass suspend/resume Summary: Add the beginnings of multipass suspend/resume, by introducing BUS_SUSPEND_CHILD/BUS_RESUME_CHILD, and move the PCI driver to this. Reviewers: jhb Reviewed By: jhb Differential Revision: https://reviews.freebsd.org/D590
2014-09-23 02:56:40 +00:00
int pci_resume_child(device_t dev, device_t child);
int pci_suspend_child(device_t dev, device_t child);
Make pci_get_dma_tag() non-static. Since the function is only referenced by pointer, making it non-static should not have even the negligible impact on the existing code. Reviewed by: jhb Sponsored by: The FreeBSD Foundation MFC after: 1 week
2013-10-24 20:29:29 +00:00
bus_dma_tag_t pci_get_dma_tag(device_t bus, device_t dev);
pci: add a new pci_child_added newbus method. This is needed so when running under Xen the calls to pci_child_added can be intercepted and a custom Xen method can be used to register those devices with Xen. This should not include any functional change, since the Xen implementation will be added in a following patch and the native implementation is a noop. Sponsored by: Citrix Systems R&D Reviewed by: jhb dev/pci/pci.c: dev/pci/pci_if.m: dev/pci/pci_private.h: dev/pci/pcivar.h: - Add the pci_child_added newbus method.
2014-08-22 15:05:51 +00:00
void pci_child_added_method(device_t dev, device_t child);
Add some doxygen docs for pci_cfg_{save,restore}.
2007-05-16 18:41:42 +00:00
/** Restore the config register state. The state must be previously
* saved with pci_cfg_save. However, the pci bus driver takes care of
* that. This function will also return the device to PCI_POWERSTATE_D0
* if it is currently in a lower power mode.
*/
Expose pci_cfg_safe/restore for subclasses of pci to use.
2005-02-28 01:14:15 +00:00
void pci_cfg_restore(device_t, struct pci_devinfo *);
Add some doxygen docs for pci_cfg_{save,restore}.
2007-05-16 18:41:42 +00:00
/** Save the config register state. Optionally set the power state to D3
* if the third argument is non-zero.
*/
Expose pci_cfg_safe/restore for subclasses of pci to use.
2005-02-28 01:14:15 +00:00
void pci_cfg_save(device_t, struct pci_devinfo *, int);
Various whitespace cleanups.
2006-11-07 18:55:51 +00:00
Refactor PCI resource allocation Refactor PCI resource allocation code to allow a request for a memory-mapped I/O window that is a multiple of a requested size. This is needed by the SR-IOV code because the VF BARs are all allocated contiguously. We can't just allocate a resource that is a multiple of a single VF BAR because the size of an allocation implies its alignment requirement. Differential Revision: https://reviews.freebsd.org/D71 Reviewed by: jhb MFC after: 1 month Sponsored by: Sandvine Inc.
2015-03-01 00:39:33 +00:00
int pci_mapsize(uint64_t testval);
void pci_read_bar(device_t dev, int reg, pci_addr_t *mapp,
pci_addr_t *testvalp, int *bar64);
struct pci_map *pci_add_bar(device_t dev, int reg, pci_addr_t value,
pci_addr_t size);
struct resource *pci_alloc_multi_resource(device_t dev, device_t child,
Convert rman to use rman_res_t instead of u_long Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
int type, int *rid, rman_res_t start, rman_res_t end,
rman_res_t count, u_long num, u_int flags);
Refactor PCI resource allocation Refactor PCI resource allocation code to allow a request for a memory-mapped I/O window that is a multiple of a requested size. This is needed by the SR-IOV code because the VF BARs are all allocated contiguously. We can't just allocate a resource that is a multiple of a single VF BAR because the size of an allocation implies its alignment requirement. Differential Revision: https://reviews.freebsd.org/D71 Reviewed by: jhb MFC after: 1 month Sponsored by: Sandvine Inc.
2015-03-01 00:39:33 +00:00
Add infrastructure for exporting config schema from PF drivers Differential Revision: https://reviews.freebsd.org/D80 MFC after: 1 month Sponsored by: Sandvine Inc.
2015-03-01 00:40:42 +00:00
int pci_iov_attach_method(device_t bus, device_t dev,
Permit the name of the /dev/iov entry to be set by the driver. The PCI_IOV option creates character devices in /dev/iov for each PF device driver that registers support for creating VFs. By default the character device is named after the PF device (e.g. /dev/iov/foo0). This change adds a variant of pci_iov_attach() called pci_iov_attach_name() that allows the name of the /dev/iov entry to be specified by the driver. Reviewed by: rstone MFC after: 1 month Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D7400
2016-08-03 17:09:12 +00:00
struct nvlist *pf_schema, struct nvlist *vf_schema,
const char *name);
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
int pci_iov_detach_method(device_t bus, device_t dev);
device_t pci_create_iov_child_method(device_t bus, device_t pf,
uint16_t rid, uint16_t vid, uint16_t did);
Allocate PCI I/O memory spaces for VFs When creating VFs, we must size each SR-IOV BAR on the PF and allocate a configuous I/O memory window large enough for every VF. However, the window only needs to be aligned to a boundary equal to the size of the window for a single VF. When a VF attempts to allocate an I/O memory resource, we must intercept the request in the pci driver and pass it off to the SR-IOV code, which will allocate the correct window from the pre-allocated memory space for the PF. Inform the pci driver about the size and address of the BARs on the VF when the VF is created. This is required by pciconf -b and bhyve. Differential Revision: https://reviews.freebsd.org/D78 Reviewed by: jhb MFC after: 1 month Sponsored by: Sandvine Inc.
2015-03-01 00:40:26 +00:00
struct resource *pci_vf_alloc_mem_resource(device_t dev, device_t child,
Convert rman to use rman_res_t instead of u_long Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
2016-01-27 02:23:54 +00:00
int *rid, rman_res_t start, rman_res_t end,
rman_res_t count, u_int flags);
Allocate PCI I/O memory spaces for VFs When creating VFs, we must size each SR-IOV BAR on the PF and allocate a configuous I/O memory window large enough for every VF. However, the window only needs to be aligned to a boundary equal to the size of the window for a single VF. When a VF attempts to allocate an I/O memory resource, we must intercept the request in the pci driver and pass it off to the SR-IOV code, which will allocate the correct window from the pre-allocated memory space for the PF. Inform the pci driver about the size and address of the BARs on the VF when the VF is created. This is required by pciconf -b and bhyve. Differential Revision: https://reviews.freebsd.org/D78 Reviewed by: jhb MFC after: 1 month Sponsored by: Sandvine Inc.
2015-03-01 00:40:26 +00:00
int pci_vf_release_mem_resource(device_t dev, device_t child,
int rid, struct resource *r);
Use the pci.c code wherever possible, rather than copying all the pci code into cardbus and s/pci/cardbus. This exposes a few pci_* functions that are now static. This work is similar to work Justin posted to the mobile list about a year or two ago, which I have neglected since then. This is a subset of his current work with the multiple inheritance newbus architecutre. When completed, that will eliminate the need for pci/pci_private.h. Similar work is needed for the cardbus_cis and pccard_cis code as well.
2002-02-27 05:09:14 +00:00
#endif /* _PCI_PRIVATE_H_ */
Reference in New Issue Copy Permalink