#
348238db |
| 01-Mar-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r314420 through r314481.
|
#
5914c62e |
| 01-Mar-2017 |
Gavin Atkinson <gavin@FreeBSD.org> |
Fix spelling mistake in comment, firmwrae -> firmware
|
#
d630701f |
| 25-Feb-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r314178 through r314269.
|
#
28586889 |
| 25-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 AC
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
show more ...
|
#
8a1926c5 |
| 25-Feb-2017 |
Warner Losh <imp@FreeBSD.org> |
Rename pci_pcie_intr to pci_pcie_intr_hotplug.
Sponsored by: Netflix
|
#
4cb67729 |
| 25-Feb-2017 |
Warner Losh <imp@FreeBSD.org> |
Create pcib_request_feature.
pcib_request_feature allows drivers to request the firmware (ACPI) release certain features it may be using. ACPI normally manages things like hot plug, advanced error r
Create pcib_request_feature.
pcib_request_feature allows drivers to request the firmware (ACPI) release certain features it may be using. ACPI normally manages things like hot plug, advanced error reporting and other features until the OS requests ACPI to relenquish control since it is taking over.
Sponsored by: Netflix
show more ...
|
#
f9edb084 |
| 05-Feb-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r313055 through r313300.
|
#
9b3ece1c |
| 04-Feb-2017 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r313243
|
#
37290148 |
| 04-Feb-2017 |
Eric van Gyzen <vangyzen@FreeBSD.org> |
PCIe HotPlug: remove tests for DL active link capability
As of r313097, the HotPlug code requires the link to support reporting of the data-link status. Remove tests for this capability from code t
PCIe HotPlug: remove tests for DL active link capability
As of r313097, the HotPlug code requires the link to support reporting of the data-link status. Remove tests for this capability from code that can now assume its presence.
Suggested by: jhb Reviewed by: jhb MFC after: 3 days Sponsored by: Dell EMC Differential Revision: https://reviews.freebsd.org/D9431
show more ...
|
#
2ffb582a |
| 02-Feb-2017 |
John Baldwin <jhb@FreeBSD.org> |
Require Data Layer Active reporting for native PCI-e HotPlug.
Some PCI-e bridges report that they support HotPlug in the slot capabilities but do not report support for Data Layer Active events in t
Require Data Layer Active reporting for native PCI-e HotPlug.
Some PCI-e bridges report that they support HotPlug in the slot capabilities but do not report support for Data Layer Active events in the link capabilities register. These bridges do not work correctly when HotPlug is used. Further, while the description of HotPlug in the spec does not mention that DL active events are required, the description of the link capabilities register says that DL active is required for HotPlug. Thanks to Dave Baukus for finding that language in the spec.
PR: 211699 Submitted by: Dave Baukus <daveb@spectralogic.com> Reviewed by: vangyzen MFC after: 3 days
show more ...
|
Revision tags: release/11.0.1, release/11.0.0 |
|
#
ed04e0c3 |
| 25-Aug-2016 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead @ r304815
|
#
65e1b138 |
| 20-Aug-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r304236 through r304536.
|
#
991d431f |
| 17-Aug-2016 |
Eric van Gyzen <vangyzen@FreeBSD.org> |
PCIe HotPlug: Detect bridges that are not really HotPlug capable
Some devices report that they have an MRL when they actually do not. Since they always report that the MRL is open, child devices wo
PCIe HotPlug: Detect bridges that are not really HotPlug capable
Some devices report that they have an MRL when they actually do not. Since they always report that the MRL is open, child devices would be ignored. Try to detect these devices and ignore their claim of HotPlug support. Specifically, if there is an open MRL but the Data Link Layer is active, the MRL is not real.
Revert r303645 to re-enable HotPlug support for slots with power controllers, since it works correctly in my testing.
Start the DLL state-change timer if Presence /or/ MRL state changes, along with other conditions. Previously, we started the timer iff Presence changed. If there is an MRL, it must be closed for power to be turned on, so Presence is unlikely to change on an MRL-close event.
Add a printf() of interesting registers on HotPlug interrupts and commands (one from erj@). These were very useful for debugging. Guard them with bootverbose, since they're spam in normal operation.
In collaboration with: jhb Reviewed by: jhb MFC after: 1 day Relnotes: yes (re-enable HotPlug support for slots with power controllers) Sponsored by: Dell Inc. Differential Revision: https://reviews.freebsd.org/D7509
show more ...
|
#
27067774 |
| 16-Aug-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r303250 through r304235.
|
#
a1566487 |
| 06-Aug-2016 |
Eric van Gyzen <vangyzen@FreeBSD.org> |
Fix some logic in PCIe HotPlug; display EI status
The interpretation of the Electromechanical Interlock Status was inverted, so we disengaged the EI if a card was inserted. Fix it to engage the EI i
Fix some logic in PCIe HotPlug; display EI status
The interpretation of the Electromechanical Interlock Status was inverted, so we disengaged the EI if a card was inserted. Fix it to engage the EI if a card is inserted.
When displaying the slot capabilites/status with pciconf:
- We inverted the sense of the Power Controller Control bit, saying the power was off when it was really on (according to this bit). Fix that.
- Display the status of the Electromechanical Interlock: EI(engaged) EI(disengaged)
Reviewed by: jhb MFC after: 3 days Sponsored by: Dell Inc. Differential Revision: https://reviews.freebsd.org/D7426
show more ...
|
#
2611037c |
| 02-Aug-2016 |
John Baldwin <jhb@FreeBSD.org> |
Disable PCI hotplug support for slots with power controllers.
After further review of the spec, I do not think the current HotPlug code handles slots with power controllers correctly. In particular
Disable PCI hotplug support for slots with power controllers.
After further review of the spec, I do not think the current HotPlug code handles slots with power controllers correctly. In particular, the power state of the slot is to be inferred from other events, not from examining the state of the power control bit in SLOT_CTL. For now, disable PCI hotplug support on such slots.
PR: 211081 Tested by: Jeffrey E Pieper <jeffrey.e.pieper@intel.com> MFC after: 3 days
show more ...
|
#
6ca2d094 |
| 30-Jul-2016 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Try to declare _hw_pci for all sysctl cases needed after r303497.
MFC after: 5 days X-MFC with: r303497
|
#
25a57bd6 |
| 29-Jul-2016 |
John Baldwin <jhb@FreeBSD.org> |
Add a loader tunable (hw.pci.enable_pcie_hp) to disable PCI-e HotPlug.
Some systems and/or devices (such as riser cards) do not include a non-compliant implementation of PCI-e HotPlug that can resul
Add a loader tunable (hw.pci.enable_pcie_hp) to disable PCI-e HotPlug.
Some systems and/or devices (such as riser cards) do not include a non-compliant implementation of PCI-e HotPlug that can result in devices not being attached (e.g. the HotPlug code might assume that a card is being unplugged and will power the slot off and detach it). This tunable can be set to 0 to disable support for PCI-e HotPlug ignoring the incorrect HotPlug state on these slots.
PR: 211081 Reported by: Sergey Renkas <serg_ic@mail.ru> (SuperMicro X7 riser card) Reported by: Jeffrey E Pieper <jeffrey.e.pieper@intel.com> (Intel X520 adapter) MFC after: 1 week Relnotes: yes
show more ...
|
#
6f33eaa5 |
| 20-May-2016 |
John Baldwin <jhb@FreeBSD.org> |
Implement a proper detach method for the PCI-PCI bridge driver.
- Add a pcib_detach() function for the PCI-PCI bridge driver. It tears down the NEW_PCIB and hotplug state including destroying r
Implement a proper detach method for the PCI-PCI bridge driver.
- Add a pcib_detach() function for the PCI-PCI bridge driver. It tears down the NEW_PCIB and hotplug state including destroying resource managers, deleting child devices, and disabling hotplug events. - Add a detach method to the ACPI PCI-PCI bridge driver which calls pcib_detach() and then frees the copy of the _PRT interrupt routing table. - Add a detach method to the PCI-Cardbus bridge driver which frees the PCI bus resources in addition to calling cbb_detach(). - Explicitly clear any pending hotplug events during attach to ensure future events will generate an interrupt. - If a the Command Completed bit is set in the slot status register when the command completion timeout fires, treat it as if the command completed and the completion interrupt was just lost rather than forcing a detach. - Don't wait for a Command Completed notification if Command Completion interrupts are disabled. The spec explicitly says no interrupt is enabled when clearing CCIE, and on my T400 no interrupt is generated when CCIE is changed from cleared to set, either. In addition, the T400 doesn't appear to set the Command Completed bit in the cases where it doesn't generate an interrupt, so don't schedule the timer either. (If the CC bit were always set, one could always set the timer and rely on the logic of treating CC set as a missed interrupt.)
Reviewed by: imp (older version) Differential Revision: https://reviews.freebsd.org/D6424
show more ...
|
#
07454911 |
| 17-May-2016 |
John Baldwin <jhb@FreeBSD.org> |
Rework managing hotplug commands with command completions.
Previously the command completion interrupt would post any pending command immediately before pcib_pcie_hotplug_update() had been run to in
Rework managing hotplug commands with command completions.
Previously the command completion interrupt would post any pending command immediately before pcib_pcie_hotplug_update() had been run to inspect the current status. Now, the command completion interrupt merely clears the flag and stops the timer assuming that the caller is always going to call pcib_pcie_hotplug_update() to generate the next hotplug command if one is needed.
While here, fix a bug for systems with command completion where the old (existing) value was written to the slot control register instead of the new value. This fixes the complaint about a missing hotplug interrupt on my T400.
Differential Revision: https://reviews.freebsd.org/D6363
show more ...
|
#
1e43b18c |
| 16-May-2016 |
Andrew Turner <andrew@FreeBSD.org> |
Add a pcib interface for use by interrupt controllers that need to translate the pci rid to a controller ID. The translation could be based on the 'msi-map' OFW property, a similar ACPI option, or ha
Add a pcib interface for use by interrupt controllers that need to translate the pci rid to a controller ID. The translation could be based on the 'msi-map' OFW property, a similar ACPI option, or hard-coded for hardware lacking the above options.
Reviewed by: wma Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation
show more ...
|
#
d7be980d |
| 16-May-2016 |
Andrew Turner <andrew@FreeBSD.org> |
Re-commit r299467 having fixed the build:
Add a new get_id interface to pci and pcib. This will allow us to both detect failures, and get different PCI IDs.
For the former the interface returns an
Re-commit r299467 having fixed the build:
Add a new get_id interface to pci and pcib. This will allow us to both detect failures, and get different PCI IDs.
For the former the interface returns an int to signal an error. The ID is returned at a uintptr_t * argument.
For the latter there is a type argument that allows selecting the ID type. This only specifies a single type, however a MSI type will be added to handle the need to find the ID the hardware passes to the ARM GICv3 interrupt controller.
A follow up commit will be made to remove pci_get_rid.
Reviewed by: jhb, rstone (previous version) Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D6239
show more ...
|
#
f41be0f0 |
| 12-May-2016 |
Conrad Meyer <cem@FreeBSD.org> |
Revert r299467 to fix the kernel build.
$ svn merge -c -299467 .
Approved by: build being broken for six hours
|
#
9a36a337 |
| 11-May-2016 |
Andrew Turner <andrew@FreeBSD.org> |
Add a new get_id interface to pci and pcib. This will allow us to both detect failures, and get different PCI IDs.
For the former the interface returns an int to signal an error. The ID is returned
Add a new get_id interface to pci and pcib. This will allow us to both detect failures, and get different PCI IDs.
For the former the interface returns an int to signal an error. The ID is returned at a uintptr_t * argument.
For the latter there is a type argument that allows selecting the ID type. This only specifies a single type, however a MSI type will be added to handle the need to find the ID the hardware passes to the ARM GICv3 interrupt controller.
A follow up commit will be made to remove pci_get_rid.
Reviewed by: jhb, rstone Obtained from: ABT Systems Ltd Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D6239
show more ...
|
#
82cb5c3b |
| 06-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 trigge
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
show more ...
|