#
9dbf5b0e |
|
13-Mar-2024 |
John Baldwin <jhb@FreeBSD.org> |
new-bus: Remove the 'rid' and 'type' arguments from BUS_RELEASE_RESOURCE The public bus_release_resource() API still accepts both forms, but the internal kobj method no longer passes the arguments. Implementations which need the rid or type now use rman_get_rid() or rman_get_type() to fetch the value from the allocated resource. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44131
|
#
2baed46e |
|
13-Mar-2024 |
John Baldwin <jhb@FreeBSD.org> |
new-bus: Remove the 'rid' and 'type' arguments from BUS_*ACTIVATE_RESOURCE The public bus_activate/deactivate_resource() API still accepts both forms, but the internal kobj methods no longer pass the arguments. Implementations which need the rid or type now use rman_get_rid() or rman_get_type() to fetch the value from the allocated resource. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44130
|
#
fef01f04 |
|
13-Mar-2024 |
John Baldwin <jhb@FreeBSD.org> |
new-bus: Remove the 'type' argument from BUS_ADJUST_RESOURCE The public bus_adjust_resource() API still accepts both forms, but the internal kobj method no longer passes the argument. Implementations which need the type now use rman_get_type() to fetch the value from the allocated resource. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D44128
|
#
c2d4fef6 |
|
23-Jan-2024 |
John Baldwin <jhb@FreeBSD.org> |
acpi_pcib: Use pci_domain_[de]activate_bus for PCI_RES_BUS resources Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D43428
|
#
1587a9db |
|
29-Nov-2023 |
John Baldwin <jhb@FreeBSD.org> |
pci_cfgreg: Add a PCI domain argument to the low-level register API This commit changes the API of pci_cfgreg(read|write) to add a domain argument (referred to as a segment in ACPI parlance) (note that this is not the same as a NUMA domain, but something PCI-specific). This does not yet enable access to domains other than 0, but updates the API to support domains. Places that use hard-coded bus/slot/function addresses have been updated to hardcode a domain of 0. A few places that have the PCI domain (segment) available such as the acpi_pcib_acpi.c Host-PCI bridge driver pass the PCI domain. The hpt27xx(4) and hptnr(4) drivers fail to attach to a device not on domain 0 since they provide APIs to their binary blobs that only permit bus/slot/function addressing. The x86 non-ACPI PCI bus drivers all hardcode a domain of 0 as they do not support multiple domains. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D42827
|
#
f6c2774f |
|
20-Oct-2023 |
John Baldwin <jhb@FreeBSD.org> |
acpi_pcib: Rename decoded_bus_range to get_decoded_bus_range While here, change the return value to bool. Discussed by: gibbs
|
#
22a6678b |
|
16-Oct-2023 |
John Baldwin <jhb@FreeBSD.org> |
acpi_pcib: Trust decoded bus range from _CRS over _BBN Currently if _BBN doesn't match the first bus in the decoded bus range from _CRS for a Host to PCI bridge, the driver fails to attach as a defensive measure. There is now firmware in the field where these do not match, and the _BBN values are clearly wrong, so rather than failing attach, trust the range from _CRS over _BBN. Co-authored-by: Justin Gibbs <gibbs@FreeBSD.org> Reported by: gibbs Reviewed by: imp (earlier version) Differential Revision: https://reviews.freebsd.org/D42231
|
#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
109abf74 |
|
07-Mar-2023 |
Yuri <yuri@aetern.org> |
acpica: do not print warning for missing _ADR Started seeing the following after updating to VMware ESXi 8.0: pcib2: <ACPI Host-PCI bridge> on acpi0 pcib2: could not evaluate _ADR - AE_NOT_FOUND pci2: <ACPI PCI bus> on pcib2 vmx0: <VMware VMXNET3 Ethernet Adapter> ... The virtual NIC works fine, and the code comment suggests that missing _ADR is not something fatal, skip printing the message if status is AE_NOT_FOUND. Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/682
|
#
916a5d8a |
|
19-Apr-2022 |
John Baldwin <jhb@FreeBSD.org> |
acpi: Remove unused devclass arguments to DRIVER_MODULE.
|
#
4cee4598 |
|
26-Jun-2020 |
Alexander Motin <mav@FreeBSD.org> |
Add mostly dummy hw.pci.enable_aspm tunable. The only thing this tunable enables now is reporting to ACPI _OSC that Active State Power Management and Clock Power Management Capability are "supported" by the OS. I've found that at least some Supermicro server boards do not allow OS to support native PCIe hot-plug unless it reports those capabilities. After spending significant time in PCIe specs I have found very little motivation for that, and none of it applies to those motherboards, not enabling ASPM themselves. So unless OS explicitly wants to save power, I see nothing for it to do there actually. I guess it may get sense to support ASPM when we get Thunderbolt support. Otherwise I have no system with PCIe hot-plug where power saving matters. It would be nice to enable this by default, but I worry that it affect power saving of some laptops, even though I haven't noticed that myself.
|
#
4e38d474 |
|
26-Aug-2019 |
Alexander Motin <mav@FreeBSD.org> |
Announce PCI Segment Groups supported to PCI host _OSC. According to ACPI 6.3 specification: The OS sets this bit to 1 if it supports PCI Segment Groups as defined by the _SEG object, and access to the configuration space of devices in PCI Segment Groups as described by this specification. Otherwise, the OS sets this bit to 0. As far as I see we support both of those as PCI domains for quite a while. MFC after: 2 months
|
#
6f4acaf4 |
|
12-Jan-2018 |
Jeff Roberson <jeff@FreeBSD.org> |
Add support for NUMA domains to bus dma tags. This causes all memory allocated with a tag to come from the specified domain if it meets the other constraints provided by the tag. Automatically create a tag at the root of each bus specifying the domain local to that bus if available. Reviewed by: jhb, kib Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13545
|
#
554e6778 |
|
09-May-2017 |
Sepherosa Ziehau <sephe@FreeBSD.org> |
hyperv/vmbus: Reorganize vmbus device tree For GEN1 Hyper-V, vmbus is attached to pcib0, which contains the resources for PCI passthrough and SR-IOV. There is no acpi_syscontainer0 on GEN1 Hyper-V. For GEN2 Hyper-V, vmbus is attached to acpi_syscontainer0, which contains the resources for PCI passthrough and SR-IOV. There is no pcib0 on GEN2 Hyper-V. The ACPI VMBUS device now only holds its _CRS, which is empty as of this commit; its existence is mainly for upward compatibility. Device tree structure is suggested by jhb@. Tested-by: dexuan@ Collabrated-wth: dexuan@ MFC after: 1 week Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D10565
|
#
1ffd07bd |
|
27-Apr-2017 |
John Baldwin <jhb@FreeBSD.org> |
Various fixes for PCI _OSC handling so HotPlug works again. - Rename the default implementation of 'pcib_request_feature' and add a pcib_request_feature() wrapper function (as is often done for new-bus APIs implemented via kobj) that accepts a single function. Previously the call to pcib_request_feature() ended up invoking the method on the great-great-grandparent of the bridge device instead of the grandparent. For a bridge that was a direct child of pci0 on x86 this resulted in the method skipping over the Host-PCI bridge driver and being invoked against nexus0 - When invoking _OSC from a Host-PCI bridge driver, invoke device_get_softc() against the Host-PCI bridge device instead of the child bridge that is requesting HotPlug. Using the wrong softc data resulted in garbage being passed for the ACPI handle causing the _OSC call to fail. - While here, perform some other cleanups to _OSC handling in the ACPI Host-PCI bridge driver: - Don't invoke _OSC when requesting a control that has already been granted by the firmware. - Don't set the first word of the capability array before invoking _OSC. This word is always set explicitly by acpi_EvaluateOSC() since it is UUID-independent. - Don't modify the set of granted controls unless _OSC doesn't exist (which is treated as always successful), or the _OSC method doesn't fail. - Don't require an _OSC status of 0 for success. _OSC always returns the updated control mask even if it returns a non-zero status in the first word. - Whine if _OSC ever tries to revoke a previously-granted control. (It is not supposed to do that.) - While here, add constants for the _OSC status word in acpivar.h (though currently unused). Reported by: adrian Reviewed by: imp MFC after: 1 week Tested on: Lenovo x220 Differential Revision: https://reviews.freebsd.org/D10520
|
#
28586889 |
|
24-Feb-2017 |
Warner Losh <imp@FreeBSD.org> |
Convert PCIe Hot Plug to using pci_request_feature Convert PCIe hot plug support over to asking the firmware, if any, for permission to use the HotPlug hardware. Implement pci_request_feature for ACPI. All other host pci connections to allowing all valid feature requests. Sponsored by: Netflix
|
#
c21a6664 |
|
15-Feb-2017 |
Warner Losh <imp@FreeBSD.org> |
Use symbolic constants for OSC support / control negotiations. Differential Revision: https://reviews.freebsd.org/D9604
|
#
a1eff92b |
|
05-Dec-2016 |
John Baldwin <jhb@FreeBSD.org> |
Don't attach to Host-PCI bridges with a bad bus number. If the bus number assigned to a Host-PCI bridge doesn't match the first bus number in the associated producer range from _CRS, print a warning and fail to attach rather than panicking due to an assertion failure. At least one single-socket Dell machine leaves a "ghost" Host-PCI bridge device in the ACPI namespace that seems to correspond to the I/O hub in the second socket of a two-socket machine. However, the BIOS doesn't configure the settings for this "ghost" bridge correctly, nor does it have any PCI devices behind it. Tested by: royger MFC after: 2 weeks
|
#
8d791e5a |
|
09-May-2016 |
John Baldwin <jhb@FreeBSD.org> |
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).
|
#
82cb5c3b |
|
05-May-2016 |
John Baldwin <jhb@FreeBSD.org> |
Native PCI-express HotPlug support. PCI-express HotPlug support is implemented via bits in the slot registers of the PCI-express capability of the downstream port along with an interrupt that triggers when bits in the slot status register change. This is implemented for FreeBSD by adding HotPlug support to the PCI-PCI bridge driver which attaches to the virtual PCI-PCI bridges representing downstream ports on HotPlug slots. The PCI-PCI bridge driver registers an interrupt handler to receive HotPlug events. It also uses the slot registers to determine the current HotPlug state and drive an internal HotPlug state machine. For simplicty of implementation, the PCI-PCI bridge device detaches and deletes the child PCI device when a card is removed from a slot and creates and attaches a PCI child device when a card is inserted into the slot. The PCI-PCI bridge driver provides a bus_child_present which claims that child devices are present on HotPlug-capable slots only when a card is inserted. Rather than requiring a timeout in the RC for config accesses to not-present children, the pcib_read/write_config methods fail all requests when a card is not present (or not yet ready). These changes include support for various optional HotPlug capabilities such as a power controller, mechanical latch, electro-mechanical interlock, indicators, and an attention button. It also includes support for devices which require waiting for command completion events before initiating a subsequent HotPlug command. However, it has only been tested on ExpressCard systems which support surprise removal and have none of these optional capabilities. PCI-express HotPlug support is conditional on the PCI_HP option which is enabled by default on arm64, x86, and powerpc. Reviewed by: adrian, imp, vangyzen (older versions) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D6136
|
#
8a08b7d3 |
|
02-May-2016 |
John Baldwin <jhb@FreeBSD.org> |
Revert bus_get_cpus() for now. I really thought I had run this through the tinderbox before committing, but many places need <sys/types.h> -> <sys/param.h> for <sys/bus.h> now.
|
#
bc153c69 |
|
02-May-2016 |
John Baldwin <jhb@FreeBSD.org> |
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. Reviewed by: wblock (manpage) Differential Revision: https://reviews.freebsd.org/D5519
|
#
67e7d085 |
|
27-Apr-2016 |
John Baldwin <jhb@FreeBSD.org> |
Add a pcib_attach_child() method to manage adding the child "pci" device. This allows the PCI-PCI bridge driver to save a reference to the child device in its softc. Note that this required moving the "pci" device creation out of acpi_pcib_attach(). Instead, acpi_pcib_attach() is renamed to acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI interrupt routing table. Differential Revision: https://reviews.freebsd.org/D6021
|
#
4c26ac69 |
|
22-Apr-2016 |
John Baldwin <jhb@FreeBSD.org> |
Optionally return the output capabilities list from _OSC. Both of the callers were expecting the input cap_set to be modified. This fixes them to request cap_set to be updated with the returned buffer. Reviewed by: jkim Differential Revision: https://reviews.freebsd.org/D6040
|
#
cad6d222 |
|
20-Apr-2016 |
Jung-uk Kim <jkim@FreeBSD.org> |
Remove query flag from acpi_EvaluateOSC(). This function does not support return buffer (yet).
|
#
508c21b6 |
|
20-Apr-2016 |
John Baldwin <jhb@FreeBSD.org> |
Invoke _OSC on Host-PCI bridges. Tell the firmware that we support PCI-express config space access and MSI. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6023
|
#
2dd1bdf1 |
|
26-Jan-2016 |
Justin Hibbits <jhibbits@FreeBSD.org> |
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
|
#
4edef187 |
|
11-Feb-2014 |
John Baldwin <jhb@FreeBSD.org> |
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
|
#
8f4c2e52 |
|
03-Jul-2013 |
John Baldwin <jhb@FreeBSD.org> |
Don't perform the acpi_DeviceIsPresent() check for PCI-PCI bridges. If we are probing a PCI-PCI bridge it is because we found one by enumerating the devices on a PCI bus, so the bridge is definitely present. A few BIOSes report incorrect status (_STA) for some bridges that claimed they were not present when in fact they were. While here, move this check earlier for Host-PCI bridges so attach fails before doing any work that needs to be torn down. PR: kern/91594 Tested by: Jack Vogel @ Intel MFC after: 1 week
|
#
0c10b85a |
|
26-Jun-2013 |
Jung-uk Kim <jkim@FreeBSD.org> |
Consistently cast ACPICA 64-bit integer types when we print them.
|
#
796b98aa |
|
09-Oct-2012 |
Neel Natu <neel@FreeBSD.org> |
Grab the softc from the ACPI host-pci bridge device instead of from the pci endpoint device. Reviewed by: jhb
|
#
af0d1ee9 |
|
09-Oct-2012 |
Neel Natu <neel@FreeBSD.org> |
Grab the softc from the ACPI host-pci bridge device instead of from the pci endpoint device. Reviewed by: jhb
|
#
0d95597c |
|
29-Mar-2012 |
John Baldwin <jhb@FreeBSD.org> |
Use a more proper fix for enabling HT MSI mapping windows on Host-PCI bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
|
#
a74d6952 |
|
29-Dec-2011 |
John Baldwin <jhb@FreeBSD.org> |
Further relax the strictness of enforcing allocations to only come from decoded ranges. Pass any request for a specific range that fails because it is not in a decoded range for an ACPI Host-PCI bridge up to the parent to see if it can still be allocated. This is based on the assumption that many BIOSes are inconsistent/broken and that settings programmed into BARs or resources assigned to other built-in components are more trustworthy than the list of decoded resource ranges in _CRS. This effectively limits the decoded ranges to only being used for "wildcard" ranges when allocating fresh resources for a BAR, etc. At some point I would like to only be this permissive during an early scan of firmware-assigned resources during boot and to be strict about all later allocations, but that isn't viable currently. MFC after: 2 weeks
|
#
4b7ec270 |
|
22-Nov-2011 |
Marius Strobl <marius@FreeBSD.org> |
- There's no need to overwrite the default device method with the default one. Interestingly, these are actually the default for quite some time (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9) since r52045) but even recently added device drivers do this unnecessarily. Discussed with: jhb, marcel - While at it, use DEVMETHOD_END. Discussed with: jhb - Also while at it, use __FBSDID.
|
#
5d0d779b |
|
12-Oct-2011 |
John Baldwin <jhb@FreeBSD.org> |
If an allocation for a specific resource range fails because it is not in a decoded range for an ACPI Host-PCI bridge, try to allocate it from the ACPI system resource range. If that works, permit the resource allocation regardless. MFC after: 1 week
|
#
e9f91b2b |
|
21-Jul-2011 |
John Baldwin <jhb@FreeBSD.org> |
Allow non-fixed endpoints for a producer address range if the length of the resource covers the entire range. Some BIOSes appear to mark endpoints as non-fixed incorrectly (non-fixed endpoints are supposed to be used in _PRS when OSPM is allowed to allocate a certain chunk of address space within a larger range, I don't believe it is supposed to be used for _CRS). Approved by: re (kib)
|
#
30ee9e61 |
|
16-Jul-2011 |
John Baldwin <jhb@FreeBSD.org> |
Don't ignore negatively decoded address ranges. Reported by: scottl
|
#
34ff71ee |
|
15-Jul-2011 |
John Baldwin <jhb@FreeBSD.org> |
Respect the BIOS/firmware's notion of acceptable address ranges for PCI resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
|
#
38d7a61b |
|
22-Jun-2011 |
John Baldwin <jhb@FreeBSD.org> |
Add a helper routine to conditionally modify the start address of a resource allocation from an x86 Host-PCI bridge driver so that it can be reused by the ACPI Host-PCI bridge driver (and eventually the MPTable Host-PCI bridge driver) instead of duplicating the same logic. Note that this means that hw.acpi.host_mem_start is now replaced with the hw.pci.host_mem_start tunable that was already used in the non-ACPI case. This also removes hw.acpi.host_mem_start on ia64 where it was not applicable (the implementation was very x86-specific). While here, adjust the logic to apply the new start address on any "wildcard" allocation even if that allocation comes from a subset of the allowable address range. Reviewed by: imp (1)
|
#
83c41143 |
|
03-May-2011 |
John Baldwin <jhb@FreeBSD.org> |
Reimplement how PCI-PCI bridges manage their I/O windows. Previously the driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
|
#
24c93a6f |
|
02-May-2011 |
John Baldwin <jhb@FreeBSD.org> |
The ACPI Host-PCI bridge driver actually supports multiple domains via the optional _SEG function. Return that value (ap->segment) rather than 0 for the pcib domain ivar.
|
#
d2c9344f |
|
02-May-2011 |
John Baldwin <jhb@FreeBSD.org> |
Add implementations of BUS_ADJUST_RESOURCE() to the PCI bus driver, generic PCI-PCI bridge driver, x86 nexus driver, and x86 Host to PCI bridge drivers.
|
#
a7d5f7eb |
|
19-Oct-2010 |
Jamie Gritton <jamie@FreeBSD.org> |
A new jail(8) with a configuration file, to replace the work currently done by /etc/rc.d/jail.
|
#
62508c53 |
|
17-Aug-2010 |
John Baldwin <jhb@FreeBSD.org> |
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
|
#
7d23a9b3 |
|
05-Aug-2010 |
John Baldwin <jhb@FreeBSD.org> |
- Retire acpi_pcib_resume(). It is has just been an alias for bus_generic_resume() since the pci_link(4) driver was added. - Change the ACPI PCI-PCI bridge driver to inherit most of its methods from the generic PCI-PCI bridge driver. In particular, this will now restore PCI config registers for ACPI PCI-PCI bridges. Tested by: Oleg Sharoyko osharoiko of gmail
|
#
e21bbd17 |
|
05-Feb-2010 |
Andriy Gapon <avg@FreeBSD.org> |
MFC r197104,197105,197106,197107,197688,198237,199337,199338,200553,200554, 202771,202773: bring acpica version to 20100121 MFC details: r197104 | jkim | 2009-09-12 01:48:53 +0300 (Sat, 12 Sep 2009) | 4 lines MFV: r196804 Import ACPICA 20090903 r197105 | jkim | 2009-09-12 01:49:34 +0300 (Sat, 12 Sep 2009) | 2 lines Catch up with ACPICA 20090903. r197106 | jkim | 2009-09-12 01:50:15 +0300 (Sat, 12 Sep 2009) | 2 lines Catch up with ACPICA 20090903. r197107 | jkim | 2009-09-12 01:56:08 +0300 (Sat, 12 Sep 2009) | 2 lines Canonify include paths for newly added files. r197688 | jkim | 2009-10-01 23:56:15 +0300 (Thu, 01 Oct 2009) | 4 lines Compile ACPI debugger and disassembler for kernel modules unconditionally. These files will generate almost empty object files without ACPI_DEBUG/DDB options. As a result, size of acpi.ko will increase slightly. r198237 | jkim | 2009-10-19 19:12:58 +0300 (Mon, 19 Oct 2009) | 2 lines Merge ACPICA 20091013. r199337 | jkim | 2009-11-16 23:47:12 +0200 (Mon, 16 Nov 2009) | 2 lines Merge ACPICA 20091112. r199338 | jkim | 2009-11-16 23:53:56 +0200 (Mon, 16 Nov 2009) | 2 lines Add a forgotten module Makefile change from the previous commit. r200553 | jkim | 2009-12-15 00:24:04 +0200 (Tue, 15 Dec 2009) | 2 lines Merge ACPICA 20091214. r200554 | jkim | 2009-12-15 00:28:32 +0200 (Tue, 15 Dec 2009) | 3 lines Remove _FDE quirk handling as these quirks are automatically repaired by ACPICA layer since ACPICA 20091214. r202771 | jkim | 2010-01-21 23:14:28 +0200 (Thu, 21 Jan 2010) | 2 lines Merge ACPICA 20100121. r202773 | jkim | 2010-01-21 23:31:39 +0200 (Thu, 21 Jan 2010) | 2 lines Fix a new header inclusion. Discussed with: jkim, jhb No objections from: acpi@
|
#
92488a57 |
|
11-Sep-2009 |
Jung-uk Kim <jkim@FreeBSD.org> |
Catch up with ACPICA 20090903.
|
#
e8c4d3e4 |
|
13-Jul-2009 |
Jung-uk Kim <jkim@FreeBSD.org> |
Match PCI Express root bridge _HID directly instead of relying on _CID. Reviewed by: jhb Approved by: re (kib)
|
#
0668724b |
|
09-Jun-2009 |
John Baldwin <jhb@FreeBSD.org> |
Rework the _BBN handling for Host-PCI bridges. Previously we only trusted a _BBN value of 0 if it was for the first bridge encountered since some older systems returned _BBN of 0 for all bridges. However, some newer systems enumerate bridges with non-zero _BBN before bus 0 which is perfectly valid. Handle both cases by trusting the first bridge that has a _BBN of 0 and falling back to reading from non-standard config registers only for subsequent bridges with a _BBN of 0. We also only perform this check for segment (domain) 0. We assume that _BBN is always correct for segments other than 0. Tested by: Josef Moellers josef.moellers at fujitsu MFC after: 1 week
|
#
129d3046 |
|
05-Jun-2009 |
Jung-uk Kim <jkim@FreeBSD.org> |
Import ACPICA 20090521.
|
#
aaac7452 |
|
02-Jun-2009 |
Jung-uk Kim <jkim@FreeBSD.org> |
Chase ACPICA API changes (for kernel and boot loader).
|
#
1496d4a9 |
|
05-Feb-2009 |
Warner Losh <imp@FreeBSD.org> |
pcib_read_config and pcib_write_config take u_int params.
|
#
d7f03759 |
|
19-Oct-2008 |
Ulf Lilleengen <lulf@FreeBSD.org> |
- Import the HEAD csup code which is the basis for the cvsmode work.
|
#
55aaf894 |
|
30-Sep-2007 |
Marius Strobl <marius@FreeBSD.org> |
Make the PCI code aware of PCI domains (aka PCI segments) so we can support machines having multiple independently numbered PCI domains and don't support reenumeration without ambiguity amongst the devices as seen by the OS and represented by PCI location strings. This includes introducing a function pci_find_dbsf(9) which works like pci_find_bsf(9) but additionally takes a domain number argument and limiting pci_find_bsf(9) to only search devices in domain 0 (the only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order to no longer report false positives when searching for siblings and dupe devices in the same domain respectively. Along with this change the sole host-PCI bridge driver converted to actually make use of PCI domain support is uninorth(4), the others continue to use domain 0 only for now and need to be converted as appropriate later on. Note that this means that the format of the location strings as used by pciconf(8) has been changed and that consumers of <sys/pciio.h> potentially need to be recompiled. Suggested by: jhb Reviewed by: grehan, jhb, marcel Approved by: re (kensmith), jhb (PCI maintainer hat)
|
#
e706f7f0 |
|
02-May-2007 |
John Baldwin <jhb@FreeBSD.org> |
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
|
#
5fe82bca |
|
22-Jan-2007 |
John Baldwin <jhb@FreeBSD.org> |
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
|
#
8964299a |
|
12-Dec-2006 |
John Baldwin <jhb@FreeBSD.org> |
Give Host-PCI bridge drivers their own pcib_alloc_msi() and pcib_alloc_msix() methods instead of using the method from the generic PCI-PCI bridge driver as the PCI-PCI methods will be gaining some PCI-PCI specific logic soon.
|
#
9bf4c9c1 |
|
13-Nov-2006 |
John Baldwin <jhb@FreeBSD.org> |
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
|
#
04dda605 |
|
06-Jan-2006 |
John Baldwin <jhb@FreeBSD.org> |
- Make pcib_devclass private to sys/dev/pci/pci_pci.c and change all the various pcib drivers to use their own private devclass_t variables for their modules. - Use the DEFINE_CLASS_0() macro to declare drivers for the various pcib drivers while I'm here.
|
#
dca20690 |
|
16-Sep-2005 |
Warner Losh <imp@FreeBSD.org> |
Commit a workaround to a problem with resource allocation. This helps with some Dell servers that booted w/o a problem[*] on 5.4, but failed with 6.0-BETA. On the PCI bus, when we do lazy resource allocation, we narrow the range requested as we pass through bridges to reflect how the bridges are programmed and what addresses they pass. However, when we're doing an allocation on a bus that's directly connected to a host bridge, no such translation can take place. We already had a fallback range for memory requests, but none for ioports. As such, provide a fallback for I/O ports so we don't allocate location 0, which will have undesired side effects when the resources are actually used. This fixes a problem with booting a Dell server with usb in the kernel. However, it is an unsatisfying solution. I don't like the hard coded value, and I think we should start narrowing the resources returned to not be in the so-called isa alias area (where the ranage & 0x0300 must be 0 iirc). Doing such filtering will have to wait for another day. This may be a good 6 candidate, maybe after its had a chance to be refined. Tested by: glebius@
|
#
2a191126 |
|
11-Sep-2005 |
David E. O'Brien <obrien@FreeBSD.org> |
Canonize the include of acpi.h.
|
#
dad97fee |
|
02-Mar-2005 |
David E. O'Brien <obrien@FreeBSD.org> |
Fix SCM ID's.
|
#
5e1ba6d4 |
|
23-Nov-2004 |
John Baldwin <jhb@FreeBSD.org> |
Rework the ACPI PCI link code. - Use a new-bus device driver for the ACPI PCI link devices. The devices are called pci_linkX. The driver includes suspend/resume support so that the ACPI bridge drivers no longer have to poke the links to get them to handle suspend/resume. Also, the code to handle which IRQs a link is routed to and choosing an IRQ when a link is not already routed is all contained in the link driver. The PCI bridge drivers now ask the link driver which IRQ to use once they determine that a _PRT entry does not use a hardwired interrupt number. - The new link driver includes support for multiple IRQ resources per link device as well as preserving any non-IRQ resources when adjusting the IRQ that a link is routed to. - The entire approach to routing when using a link device is now link-centric rather than pci bus/device/pin specific. Thus, when using a tunable to override the default IRQ settings, one now uses a single tunable to route an entire link rather than routing a single device that uses the link (which has great foot-shooting potential if the user tries to route the same link to two different IRQs using two different pci bus/device/pin hints). For example, to adjust the IRQ that \_SB_.LNKA uses, one would set 'hw.pci.link.LNKA.irq=10' from the loader. - As a side effect of having the link driver, unused link devices will now be disabled when they are probed. - The algorithm for choosing an IRQ for a link that doesn't already have an IRQ assigned is now much closer to the one used in $PIR routing. When a link is routed via an ISA IRQ, only known-good IRQs that the BIOS has already used are used for routing instead of using probabilities to guess at which IRQs are probably not used by an ISA device. One change from $PIR is that the SCI is always considered a viable ISA IRQ, so that if the BIOS does not setup any IRQs the kernel will degenerate to routing all interrupts over the SCI. For non ISA IRQs, interrupts are picked from the possible pool using a simplistic weighting algorithm. Tested by: ru, scottl, others on acpi@ Reviewed by: njl
|
#
5b8c4719 |
|
09-Nov-2004 |
Nate Lawson <njl@FreeBSD.org> |
unsigned long -> u_long
|
#
b0e1e474 |
|
31-Oct-2004 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Add TUNABLE_LONG and TUNABLE_ULONG, and use the latter for the hw.pci.host_mem_start tunable. Add comments to TUNABLE_INT and TUNABLE_QUAD recommending against their use. MFC after: 3 weeks
|
#
38228f72 |
|
31-Oct-2004 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Whitespace cleanup
|
#
fd492ee0 |
|
11-Oct-2004 |
Warner Losh <imp@FreeBSD.org> |
Make the lower range of the memory area 0x80000000 again. Also introduce hw.{pci,acpi}.host_mem_start tunable to change this. MFC: ASAP
|
#
5cee9db3 |
|
06-Oct-2004 |
Warner Losh <imp@FreeBSD.org> |
For older systems with ACPI which don't have a pci <-> pci bridge, allocate unallocated memory resources from the top 32MB of the address space rather than the top 2GB. While the latter works on some chipsets, it fails badly on others. 32MB is more conservative and matches what cheap harware from this era is hardwired to pass.
|
#
e0a93586 |
|
22-Sep-2004 |
John Baldwin <jhb@FreeBSD.org> |
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.
|
#
e4116e93 |
|
11-Aug-2004 |
Nate Lawson <njl@FreeBSD.org> |
Re-work ACPI PCI IRQ routing (_PRT, link devices). The old approach was incomplete in that the PRT routing was not aware of link programming. Fix this by doing all routing through the link devices. The new algorithm for setting up links is: 1. Read _CRS to get current setting. If invalid (not in _PRS), then set to 0. 2. Attempt to call _DIS on the link. If successful, mark the link as not routed. Otherwise, assume it still is. Then when a routing request occurs: 3. Update weights for all IRQs 4. Attempt to route the initial IRQ if valid 5. If that fails, walk through the sorted list, attempting to route IRQs. 6. Configure the trigger/polarity based on _PRS. Other changes: * Add acpi_pci_find_prt() to look up the PRT entry for a given device and acpi_pci_link_route() to select/route the best IRQ for it. * Remove duplicated code in acpi_pcib_route_interrupt() that picked the first IRQ from _PRS. * Remove unneeded arguments from acpi_pcib_resume() and friends. * Ignore _STA on link devices but report if it seems strange. * Add a prt_source handle to the PRT structure since the ACPI struct ACPI_PCI_ROUTING_TABLE uses a fixed-size entry for it. We'll need to dynamically size this object if we want to use it the same way ACPI-CA does. Null-terminate the source. Tested by: Luo Hong <luohong99_at_mails.tsinghua.edu.cn>, Jeffrey Katcher <jmkatcher_at_yahoo.com> Info from: jhb, Len Brown (Intel)
|
#
dfbaec0a |
|
04-Jul-2004 |
Warner Losh <imp@FreeBSD.org> |
Make the default memory range in the top 2GB of ram in the hopes that this more accurately reflects what the underlying hardware of most acpi machines that don't have children pci busses. We still need a better way to get this information from acpi/hardware.
|
#
d4b9ff91 |
|
30-Jun-2004 |
Nate Lawson <njl@FreeBSD.org> |
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).
|
#
5fcc8a58 |
|
29-Jun-2004 |
Nate Lawson <njl@FreeBSD.org> |
Use the acpi_id_probe() method instead of acpi_MatchHid(), which is now static.
|
#
91233413 |
|
13-Jun-2004 |
Nate Lawson <njl@FreeBSD.org> |
Add support to ACPI to manage its own resources. Previously, resource allocation was passed up to nexus. Now, we probe sysresource objects and manage the resources they describe in a local rman pool. This helps devices which attach/detach varying resources (like the _CST object) and module loads/unloads. The allocation/release routines now check to see if the resource is described in a child sysresource object and if so, allocate from the local rman. Sysresource objects add their resources to the pool and reserve them upon boot. This means sysresources need to be probed before other ACPI devices. Changes include: * Add ordering to the child device probe. The current order is: system resource objects, embedded controllers, then everything else. * Make acpi_MatchHid take a handle instead of a device_t arg. * Replace acpi_{get,set}_resource with the generic equivalents.
|
#
fe12f24b |
|
30-May-2004 |
Poul-Henning Kamp <phk@FreeBSD.org> |
Add missing <sys/module.h> includes
|
#
e3aa81b8 |
|
28-May-2004 |
Nate Lawson <njl@FreeBSD.org> |
Style fixes.
|
#
64278df5 |
|
09-Apr-2004 |
Nate Lawson <njl@FreeBSD.org> |
Add MODULE_DEPEND entries so some of these drivers can eventually be loaded separately from ACPI (i.e., embedded use).
|
#
cd8b53ed |
|
09-Apr-2004 |
Warner Losh <imp@FreeBSD.org> |
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.
|
#
c310653e |
|
03-Mar-2004 |
Nate Lawson <njl@FreeBSD.org> |
Change to acpi_{Get,Set}Integer to provide both methods. Convert all callers to the new API. Submitted by: Mark Santcroos <marks@ripe.net>
|
#
cace7a2a |
|
22-Aug-2003 |
Warner Losh <imp@FreeBSD.org> |
Prefer new location of pci include files (which have only been in the tree for two or more years now), except in a few places where there's code to be compatible with older versions of FreeBSD.
|
#
8b149b51 |
|
07-Aug-2003 |
John Baldwin <jhb@FreeBSD.org> |
Consistently use the BSD u_int and u_short instead of the SYSV uint and ushort. In most of these files, there was a mixture of both styles and this change just makes them self-consistent. Requested by: bde (kern_ktrace.c)
|
#
8745ec57 |
|
25-Nov-2002 |
John Baldwin <jhb@FreeBSD.org> |
- Assume a bus number of zero if evaluating _BBN fails, not if it succeeds. This was effectively rendering _BBN useless. - Cleanup handling of the busok variable a bit. Submitted by: marcel (1) Approved by: re (rwatson)
|
#
9debb532 |
|
22-Nov-2002 |
John Baldwin <jhb@FreeBSD.org> |
According to the ACPI spec, the bus number of the child PCI bus of a host to PCI bridge can be read be evaluating the _BBN method of the host to PCI device. Unfortunately, there appear to be some lazy/ignorant/moronic/ whatever BIOS writers that return 0 for _BBN for all host to PCI bridges in the system. On a system with a single host to PCI bridge this is not a problem as the child bus of that single bridge will be bus 0 anyway. However, on systems with multiple host to PCI bridges and l/i/m/w BIOS writers this is a major problem resulting in all but the first host to PCI bridge failing to attach. So, this adds a workaround. If the _BBN of a host to PCI bridge is zero and pcib0 already exists and is not us, the we use _ADR to look up our PCI function and slot (we currently assume we are on bus 0) and use that to call host_pcib_get_busno() to try and extract our bus number from config registers on the host to PCI bridge device. If that fails, then we make an evil assumption that ACPI's _SB_ namespace lays out the host to PCI bridges in ascending order and use our pcib unit number as our bus number. Approved by: re
|
#
5e0ca577 |
|
04-Oct-2002 |
Mitsuru IWASAKI <iwasaki@FreeBSD.org> |
Make sure that ACPI PCI driver probe routine call pci_cfgregopen() before start accessing PCI config space. Reviewed by: jhb
|
#
ba835e3f |
|
04-Oct-2002 |
Mitsuru IWASAKI <iwasaki@FreeBSD.org> |
Add code for ACPI PCI link object manipulation. This allocate the best IRQ to boot-disable devices (have IRQ 0). Allocated IRQ will be used for PCI interrupt routing when ACPI is enabled. Note that verbose messaging enabled for the time being so that people can easily notice the strange behavior if it happened.
|
#
2ccfc932 |
|
26-Aug-2002 |
John Baldwin <jhb@FreeBSD.org> |
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
|
#
473f1ca9 |
|
26-Aug-2002 |
John Baldwin <jhb@FreeBSD.org> |
In acpi_pcib_route_interrupt(), the code claims to check to see if a PCI LNK device (interrupt source provider sort of) is present before using it, but the code actually tested the status (_STA) of the PCI bridge device doing the routing, not the actual LNK device. Fix it to check the status of the LNK device.
|
#
b4a05238 |
|
19-May-2002 |
Peter Wemm <peter@FreeBSD.org> |
Brutally deal with __func__ being 'const char *' on gcc-3.1.
|
#
0a702a9b |
|
20-Mar-2002 |
Mike Smith <msmith@FreeBSD.org> |
Fix error introduced in the 20020217 update, where GetPossibleResources was spammed with GetCurrentResources. Submitted by: Munehiro Matsuda <haro@h4.dion.ne.jp>
|
#
c1b1f787 |
|
22-Feb-2002 |
Mike Smith <msmith@FreeBSD.org> |
Match namespace cleanup changes in ACPI CA 20020217 update. Use ACPI_SUCCESS/ACPI_FAILURE consistently. The AcpiGetInto* interfaces are obsoleted by ACPI_ALLOCATE_BUFFER. Use _ADR as well as _BBN to get our bus number.
|
#
3273b005 |
|
07-Jan-2002 |
Mike Smith <msmith@FreeBSD.org> |
Staticise devclasses and some unnecessarily global variables.
|
#
a067d210 |
|
07-Oct-2001 |
Doug Rabson <dfr@FreeBSD.org> |
Make the interrupt routing a bit less chatty unless bootverbose is set.
|
#
555143d0 |
|
05-Oct-2001 |
Peter Wemm <peter@FreeBSD.org> |
Fix a stack trashing bug when int != sizeof(pointer) This fixes the ia64 boot! We have scsi disks!
|
#
43896e91 |
|
04-Oct-2001 |
Mike Smith <msmith@FreeBSD.org> |
Update usage of AcpiEnableEvent to reflect a new argument. Fix acpi_DeviceIsPresent to check for valid _STA data and to check the "present" and "functioning" bits. Use acpi_DeviceIsPresent in acpi_pcib rather than rolling our own (also broken) version.
|
#
4c1cdee6 |
|
26-Aug-2001 |
Mike Smith <msmith@FreeBSD.org> |
Updates to match the ACPI CA 20010816 import: - New debug macro (ACPI_DEBUG_PRINT), reducing debug-case code size. - New debug level/subsystem codes.
|
#
d93b034f |
|
03-Aug-2001 |
Mike Smith <msmith@FreeBSD.org> |
Shoud build resources in the _CRS buffer. Oops. Submitted by: "neckpain@nettaxi.com" <neckpain@nettaxi.com>
|
#
f16527bb |
|
30-Jul-2001 |
Mike Smith <msmith@FreeBSD.org> |
The current resource buffer returned from an interrupt link device in the case where there are no interrupts routed for it does not contain enough space to use it to route an interrupt. In the case where we need to route an interrupt, throw away the returned buffer and create a new one containing the interrupt we want.
|
#
bfae45aa |
|
21-Jul-2001 |
Mike Smith <msmith@FreeBSD.org> |
Convert from acpi_strerror() to AcpiFormatException() Fix dangling include of the dear departed acpi_ecreg.h
|
#
8077a62b |
|
07-Jul-2001 |
Mike Smith <msmith@FreeBSD.org> |
Oops, have to use AcpiSetCurrentResources, not invoke the _SRS method directly.
|
#
4fa387b6 |
|
05-Jul-2001 |
Mike Smith <msmith@FreeBSD.org> |
Implement PCI interrupt routing using the ACPI data attached to the PCI bus object. This should deal both with already-routed interrupts as well as devices that need an interrupt routed. Note that it *doesn't* deal with interlocked interrupt dependancies, nor does it select between interrupt options in a smart way. These are optimisations that need further work.
|
#
e71b6381 |
|
29-Jun-2001 |
Mike Smith <msmith@FreeBSD.org> |
Update for new debug layer constant names in the ACPI CA 20010615 import.
|
#
2a4ac806 |
|
29-May-2001 |
Mike Smith <msmith@FreeBSD.org> |
- Updates for new constant naming in the ACPI CA 20010518 update. - Use __func__ instead of __FUNCTION. - Support power-off to S3 or S5 (takawata) - Enable ACPI debugging earlier (with a sysinit) - Fix a deadlock in the EC code (takawata) - Improve arithmetic and reduce the risk of spurious wakeup in AcpiOsSleep. - Add AcpiOsGetThreadId. - Simplify mutex code (still disabled).
|
#
91467fc6 |
|
31-Jan-2001 |
Mike Smith <msmith@FreeBSD.org> |
ACPI_NUMBER becomes ACPI_INTEGER. acpi_EvaluateNumber becomes acpi_EvaluateInteger. Use acpi_EvaluateInteger instead of doing things the hard way where possible. AcpiSetSystemSleepState (unofficial) becomes AcpiEnterSleepState. Use the AcpiGbl_FADT pointer rather than searching for the FADT.
|
#
39a8493a |
|
29-Dec-2000 |
Mike Smith <msmith@FreeBSD.org> |
Hack in interrupt routing support (using the core $PIR support, not using ACPICA properly). This makes it possible to use ACPICA in conjunction with CardBus before I get around to implementing ACPI/PCI interrupt routing.
|
#
0ae55423 |
|
08-Dec-2000 |
Mike Smith <msmith@FreeBSD.org> |
- Convert a lot of homebrew debugging output to use the ACPI CA debugging infrastructure. It's not perfect, but it's a lot better than what we've been using so far. The following rules apply to this: o BSD component names should be capitalised o Layer names should be taken from the non-CA set for now. We may elect to add some new BSD-specific layers later. - Make it possible to turn off selective debugging flags or layers by listing them in debug.acpi.layer or debug.acpi.level prefixed with !. - Fully implement support for avoiding nodes in the ACPI namespace. Nodes may be listed in the debug.acpi.avoid environment variable; these nodes and all their children will be ignored (although still scanned over) by ACPI functions which scan the namespace. Multiple nodes can be specified, separated by whitespace. - Implement support for selectively disabling ACPI subsystem components via the debug.acpi.disable environment variable. The following components can be disabled: o bus creation/scanning of the ACPI 'bus' o children attachment of children to the ACPI 'bus' o button the acpi_button control-method button driver o ec the acpi_ec embedded-controller driver o isa acpi replacement of PnP BIOS for ISA device discovery o lid the control-method lid switch driver o pci pci root-bus discovery o processor CPU power/speed management o thermal system temperature detection and control o timer ACPI timecounter Multiple components may be disabled by specifying their name(s) separated by whitespace. - Add support for ioctl registration. ACPI subsystem components may register ioctl handlers with the /dev/acpi generic ioctl handler, allowing us to avoid the need for a multitude of /dev/acpi* control devices, etc.
|
#
3cd59d7b |
|
01-Dec-2000 |
Scott Long <scottl@FreeBSD.org> |
Revert attach() back to the old behaviour of calling bus_generic_attach(). The new way doesn't seem to work reliably and was causing devices to not be seen. Approved by: msmith
|
#
042283a6 |
|
01-Dec-2000 |
Mike Smith <msmith@FreeBSD.org> |
Update to work with the new ACPI CA snapshot. - Use ACPI_PHYSICAL_ADDRESS - RSDT -> XSDT - FACP -> FADT - No APIC table support - Don't install a global EC handler; this has bad side-effects (it invokes _REG in *all* EC spaces in the namespace!) - Check for PCI bus instances already existing before adding them
|
#
15e32d5d |
|
28-Oct-2000 |
Mike Smith <msmith@FreeBSD.org> |
Initial FreeBSD OSPM (operating system power management) modules for ACPICA. Most of these are still works in progress. Support exists for: - Fixed feature and control method power, lid and sleep buttons. - Detection of ISA PnP devices using ACPI namespace. - Detection of PCI root busses using ACPI namespace. - CPU throttling and sleep states (incomplete) - Thermal monitoring and cooling control (incomplete) - Interface to platform embedded controllers (mostly complete) - ACPI timer (incomplete) - Simple userland control of sleep states. - Shutdown and poweroff.
|