PCI: brcmstb: Enable CRS software visibility after linkup #5889
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Is this something that we'd backport to 6.1? |
|
As we're about to do one final 6.1 release, no - this needs more soak testing with various PCIe not-HAT setups. |
It appears that bits in the Root Control Register are reset with perst_n, which means the PCI layer's call to enable CRS prior to adding/scanning the bus has no effect. Open-code the enable in brcm_pcie_start_link as a workaround. Without CRS visibility, configuration reads issued by the CPU don't retire if the endpoint returns a CRS response - the RC will poll until a (large) timeout is reached. This means the core can stall for a long time during boot. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Feb 13, 2024
See: raspberrypi/linux#5930 kernel: drm/vc4: Disable overrun interrupts See: raspberrypi/linux#5935 kernel: drivers: thermal: step_wise: add support for hysteresis See: raspberrypi/linux#5936 kernel: media: rp1: cfe: Actually use the number of lanes configured See: raspberrypi/linux#5941 kernel: PCI: brcmstb: Enable CRS software visibility after linkup See: raspberrypi/linux#5889 kernel: SDHCI vs EMMC on Pi 5 See: raspberrypi/linux#5937
popcornmix
added a commit
to raspberrypi/rpi-firmware
that referenced
this pull request
Feb 13, 2024
See: raspberrypi/linux#5930 kernel: drm/vc4: Disable overrun interrupts See: raspberrypi/linux#5935 kernel: drivers: thermal: step_wise: add support for hysteresis See: raspberrypi/linux#5936 kernel: media: rp1: cfe: Actually use the number of lanes configured See: raspberrypi/linux#5941 kernel: PCI: brcmstb: Enable CRS software visibility after linkup See: raspberrypi/linux#5889 kernel: SDHCI vs EMMC on Pi 5 See: raspberrypi/linux#5937
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fell out of the discussions around "why does the bootloader nvme probe behave differently to Linux" - as part of aligning the behaviours of both, we should make maximal use of the features offered by the RC.
The RC supports neither Device Readiness nor Function Readiness notifications, therefore we should use a combination of the 100ms grace period after link-up with CRS.
EPs are permitted to issue Retry statuses for up to 1 second, which if CRSSVE=0 will
a) completely stall the CPU until the Ubus/completion timeout is reached (<1s, but some tens of milliseconds)
b) cause the RC to return 0xffffffff for reads of the vendor ID register instead of 0xffff0001 which will cause probe failure instead of retrying up to the 1 second limit.
For some reason the associated root complex register bit is reset by perst_n, so enable it after link-up.