History log of /freebsd/sys/dev/pci/pci_pci.c (Results 51 – 75 of 319)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


12345678910>>...13