PCI: Release unused bridge resources during resize #6653
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
If autonomous speed negotiation is unreliable then brcm_pcie_set_gen() can be used to override/limit this behaviour. However, setting the limit after the linkup poll means the link can temporarily enter a bad speed which may result in link failure. Move the speed setup to just prior to releasing perst_n. Fixes: 0693b42 ("PCI: brcmstb: Split post-link up initialization to brcm_pcie_start_link()") Signed-off-by: Jonathan Bell <[email protected]>
Using increased bit depth for no reason increases power consumption, and differs from the behaviour prior to the conversion to use the HDMI helper functions. Initialise the state max_bpc and requested_max_bpc to the minimum value supported. This only affects Raspberry Pi, as the other users of the helpers (rockchip/inno_hdmi and sunx4i) only support a bit depth of 8. Signed-off-by: Dave Stevenson <[email protected]>
If an infoframe was ever enabled, duplicate_state would memcpy the infoframe including the "set" flag. The infoframe functions then never cleared it, so once set it was always set. This was most obvious with the HDR infoframe as it resulted in bad colour rendering. Signed-off-by: Dave Stevenson <[email protected]>
Drop from RGB to YUV422 output if RGB couldn't be supported within the defined max_bpc and TMDS rates, and then try dropping max_bpc. Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Giedrius Trainavičius <[email protected]>
Signed-off-by: Giedrius Trainavičius <[email protected]>
Signed-off-by: Giedrius Trainavičius <[email protected]>
"media: i2c: imx477: Add options for slightly modifying the link freq" created a link frequency menu with 2 items in instead of one. Correct this. Signed-off-by: Dave Stevenson <[email protected]>
As per the subject, there was a copy/paste error that caused pio_sm_unclaim from a driver to result in a call to pio_sm_claim. Fix it. Signed-off-by: Phil Elwell <[email protected]>
Passing bad parameters to an API call without a pio pointer will cause a NULL pointer exception when the persistent error is set. Guard against that. Signed-off-by: Phil Elwell <[email protected]>
DSI0 and DSI1 have different widths for the command FIFO (24bit vs 32bit), but the driver was assuming the 32bit width of DSI1 in all cases. DSI0 also wants the data packed as 24bit big endian, so the formatting code needs updating. Handle the difference via the variant structure. Signed-off-by: Dave Stevenson <[email protected]>
Noted setting up a display on CM5IO. Add "dtoverlay=vc4-kms-dsi-ili7881-7inch" fails as it tries to find the regulator/backlight/touch on i2c_csi_dsi, which pointed at i2c_csi_dsi0 by default. Adding the dsi0 override updated to point at dsi0, and pointed the i2c at i2c_csi_dsi0, which all works. The default with i2c_csi_dsi needs to be consistent in using dsi1/csi1 and the corresponding i2c interface (i2c_csi_dsi1). Signed-off-by: Dave Stevenson <[email protected]>
Although VBUS_EN on GPIO42 appears on the CM5's 100-way headers, USB_OC_N on GPIO43 does not. Remove the signal name to avoid further confusion and disappointment. Signed-off-by: Phil Elwell <[email protected]>
The deep link into the website is not that stable, so let's replace it with a textual description where to find the product information. Signed-off-by: Michael Heimpold <[email protected]>
The Raspberry Pi RP1 chip has the Cadence GEM ethernet controller, so add a compatible string for it. Signed-off-by: Dave Stevenson <[email protected]>
The RP1 chip has the Cadence GEM block, but wants the tx_clock to always run at 125MHz, in the same way as sama7g5. Add the relevant configuration. Signed-off-by: Dave Stevenson <[email protected]>
Rather than clearing all the bits in rp1_pll_divider_off and setting PLL_SEC_RST, retain the status of all the other bits. Signed-off-by: Dave Stevenson <[email protected]>
The clock setup had been copied from clk-bcm2835 which had to cope with the firmware having configured clocks, so there were flags of CLK_IS_CRITICAL and CLK_IGNORE_UNUSED dotted around. That isn't the situation with RP1 where only the main PLLs, CLK_SYS, and CLK_SLOW_SYS are critical, so update the configuration to match. Signed-off-by: Dave Stevenson <[email protected]>
Configure RP1's ethernet block to do the correct thing. clk_eth is intended to be fixed at 125MHz, so use a new compatible, and use assigned-clocks to configure the clock appropriately. Signed-off-by: Dave Stevenson <[email protected]>
The DMA block has a clock, but wasn't defined in the driver. This resulted in the parent being disabled as unused, and then DMA stopped working. Signed-off-by: Dave Stevenson <[email protected]>
There should be no issue in disabling the RP1 clocks as long as the kernel knows about all consumers. Signed-off-by: Dave Stevenson <[email protected]>
hclk and pclk of the MAC are connected to clk_sys, so define them as being connected accordingly, rather than having fake fixed clocks for them. Signed-off-by: Dave Stevenson <[email protected]>
This makes the kernel representation of the clock structure match reality. Signed-off-by: Dave Stevenson <[email protected]>
In the move to the upstream bcm2712.dts, the A76 PMU was omitted from the required downstream additions. Link: raspberrypi#6507 Signed-off-by: Phil Elwell <[email protected]>
Following the merging of [1], it is safe to re-enable DMA to UART0 without fear of losing data. Seen while looking at raspberrypi#6507. [1] dmaengine: dw-axi-dmac: Allow client-chosen width Signed-off-by: Phil Elwell <[email protected]>
gpio-direct mode is a modification of the brcmstb GPIO driver that makes it play nicely with the userspace pinctrl utility. The mode forces the drive to read its state from the hardware each time, rather than relying on cached state. Doing so slightly reduces performance, but this is not a heavily used code path. Signed-off-by: Phil Elwell <[email protected]>
Fractional source co-ordinates can be used to setup the scaling filters, so retain the information. Signed-off-by: Dom Cobley <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dave Stevenson <[email protected]>
Apply fractional source co-ordinates into the scaling filters. Signed-off-by: Dom Cobley <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dave Stevenson <[email protected]>
When the margins are changed, the dlist needs to be regenerated with the changed updated dest regions for each of the planes. Setting the zpos_changed flag is sufficient to trigger that without doing a full modeset, therefore set it should the margins be changed. Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dave Stevenson <[email protected]>
Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats. Tested with kmstest and kodi. e.g. kmstest -r 1920x1080@60 -f 400x300-YU24 Note: without the shift of width, only half the chroma is fetched, resulting in correct left half of image and corrupt colours on right half. The increase in width shouldn't affect fetching of Y data, as the hardware will clamp at dest width. Signed-off-by: Dom Cobley <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dave Stevenson <[email protected]>
Commit 0df4a13 upstream Add a modparam for turning off Big/Super Pages to make sure that if an user doesn't want Big/Super Pages enabled, it can disabled it by setting the modparam to false. Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit 9f8e1c9 upstream Add a new V3D parameter to expose the support of Super Pages to userspace. The userspace might want to know this information to apply optimizations that are specific to kernels with Super Pages enabled. Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit d28292a upstream Function drm_gem_shmem_create_with_mnt() creates an object without using the mountpoint if gemfs is NULL. Drop the else branch calling drm_gem_shmem_create(). Signed-off-by: Matthias Brugger <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit e987e22 upstream When the new register addresses were introduced for V3D 7.x, we added new masks for performance counter sources on V3D 7.x. Nevertheless, we never apply these new masks when setting the sources. Fix the performance counter source settings on V3D 7.x by introducing a new macro, `V3D_SET_FIELD_VER`, which allows fields setting to vary by version. Using this macro, we can provide different values for source mask based on the V3D version, ensuring that sources are correctly configure on V3D 7.x. Fixes: 0ad5bc1 ("drm/v3d: fix up register addresses for V3D 7.x") Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit 21f1435 upstream If the active performance monitor (`v3d->active_perfmon`) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the `v3d->active_perfmon` pointer stale. This can lead to undefined behavior and instability. This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd36 ("drm/v3d: Stop the active perfmon before being destroyed"). Cc: [email protected] # v5.15+ Fixes: 26a4dc2 ("drm/v3d: Expose performance counters to userspace") Signed-off-by: Christian Gmeiner <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit c6eabba upstream Add a new ioctl, DRM_IOCTL_V3D_PERFMON_SET_GLOBAL, to allow configuration of a global performance monitor (perfmon). Use the global perfmon for all jobs to ensure consistent performance tracking across submissions. This feature is needed to implement a Perfetto datasources in user-space. Signed-off-by: Christian Gmeiner <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit 4ee06e3 upstream. This commit fixes several miscellaneous documentation errors. Mostly, delete/update comments that are outdated or are leftovers from past code changes. Apart from that, remove double-spaces in several comments. Signed-off-by: Maíra Canal <[email protected]> Acked-by: Iago Toral Quiroga <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Commit dc4afc0de9654f88676d77094a38f9451d519011 upstream. CPU jobs, like Cache Clean jobs, execute synchronously once the DRM scheduler starts running them. Consequently, a global `v3d->cpu_job` variable is unnecessary, as everything is managed within the `v3d_cpu_job_run()` function. This commit removes the `v3d->cpu_job` pointer, as it is not needed. Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Jose Maria Casanova Crespo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
As on VC4, the OF property overrides the order implied by media bus format. Only 4 of the 6 possible orders are supported. New add-on hardware designs should not rely on this "legacy" feature. Signed-off-by: Nick Hollinghurst <[email protected]>
Link: raspberrypi#6623 Signed-off-by: Phil Elwell <[email protected]>
This patch adds the ina238 device tree parameters to the i2c-sensors overlay. The ina238 driver needs 2 configuration parameters, shut_resistor and ti,shunt-gain in addition to it's address, so they are added as well.
This patch adds the shtc3 device tree parameters to the i2c-sensors overlay. The shtc3 driver needs no other configuration parameters, as the i2c address is permanently baked in to the silicon.
Sourced from https://github.com/hailo-ai/hailort-drivers Signed-off-by: Naushir Patuck <[email protected]>
A few small improvements, with a view to making the updated overlays behave the same before and after the big conversion. Signed-off-by: Phil Elwell <[email protected]>
Create an i2c-buses.dtsi to hold all of the common I2C bus selection logic, and refactor existing overlays to use it. This patch should have no functional change overall except to increase the range of options for some overlays. There is a slightly ugly mechanism for overriding the default bus, where the mux nodes may or may not need to be enabled. Signed-off-by: Phil Elwell <[email protected]>
Remove rpi-5.15.y build status since it doesn't appear to be built anymore, and add rpi-6.12.y build status.
Add an ioctl type - SM_CONFIG_XFER32 - that takes uints for the buf_size and buf_count values. Signed-off-by: Phil Elwell <[email protected]>
Renesas UPD720201/-202 is a popular alternative to the VL805 USB3 phy used in many CM4 based products. Commit 25f51b7 ("xhci-pci: Make xhci-pci-renesas a proper modular driver") reworked the Renesas XHCI driver, resulting in CONFIG_USB_XHCI_PCI_RENESAS no longer being implicitly enabled. Explicitly add it to the defconfig to restore USB3 functionality. Signed-off-by: Nicolai Buchwitz <[email protected]>
If this is a DMA transfer, and if there is no simultaneous RX transfer, wait for the interface to go idle before reporting that TX is done. Link: https://forums.raspberrypi.com/viewtopic.php?t=383027 Signed-off-by: Phil Elwell <[email protected]>
If the RP1 firmware has reported an error then return that from the PIO probe function, otherwise defer the probing. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <[email protected]>
To avoid pointless retries, let the probe function succeed if the firmware interface is configured correctly but the firmware is incompatible. The value of the private drvdata field holds the outcome. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <[email protected]>
The of_xlate method saves the calculated event mask in the con_priv field. It also rejects subsequent attempt to use that channel because the mask is non-zero, which causes a repeated instantiation of a client driver to fail. The of_xlate method is not meant to be a point of resource acquisition. Leave the con_priv initialisation, but drop the test that it was previously zero. Signed-off-by: Phil Elwell <[email protected]>
With a future release of the firmware, it will be possible to use dts files with a top-level #size-cells of 2. This patch adds the remaining necessary changes to make that work, gated by the macro symbol FIRMWARE_UDPATED. Signed-off-by: Phil Elwell <[email protected]>
Resizing BARs can be blocked when a device in the bridge hierarchy
itself consumes resources from the resized range. This scenario is
common with Intel Arc DG2 GPUs where the following is a typical
topology:
+-[0000:5d]-+-00.0-[5e-61]----00.0-[5f-61]--+-01.0-[60]----00.0 Intel Corporation DG2 [Arc A380]
\-04.0-[61]----00.0 Intel Corporation DG2 Audio Controller
Here the system BIOS has provided a large 64bit, prefetchable window:
pci_bus 0000:5d: root bus resource [mem 0xb000000000-0xbfffffffff window]
But only a small portion is programmed into the root port aperture:
pci 0000:5d:00.0: bridge window [mem 0xbfe0000000-0xbff07fffff 64bit pref]
The upstream port then provides the following aperture:
pci 0000:5e:00.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]
With the missing range found to be consumed by the switch port itself:
pci 0000:5e:00.0: BAR 0 [mem 0xbff0000000-0xbff07fffff 64bit pref]
The downstream port above the GPU provides the same aperture as upstream:
pci 0000:5f:01.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]
Which is entirely consumed by the GPU:
pci 0000:60:00.0: BAR 2 [mem 0xbfe0000000-0xbfefffffff 64bit pref]
In summary, iomem reports the following:
b000000000-bfffffffff : PCI Bus 0000:5d
bfe0000000-bff07fffff : PCI Bus 0000:5e
bfe0000000-bfefffffff : PCI Bus 0000:5f
bfe0000000-bfefffffff : PCI Bus 0000:60
bfe0000000-bfefffffff : 0000:60:00.0
bff0000000-bff07fffff : 0000:5e:00.0
The GPU at 0000:60:00.0 supports a Resizable BAR:
Capabilities: [420 v1] Physical Resizable BAR
BAR 2: current size: 256MB, supported: 256MB 512MB 1GB 2GB 4GB 8GB
However when attempting a resize we get -ENOSPC:
pci 0000:60:00.0: BAR 2 [mem 0xbfe0000000-0xbfefffffff 64bit pref]: releasing
pcieport 0000:5f:01.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]: releasing
pcieport 0000:5e:00.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]: releasing
pcieport 0000:5e:00.0: bridge window [mem size 0x200000000 64bit pref]: can't assign; no space
pcieport 0000:5e:00.0: bridge window [mem size 0x200000000 64bit pref]: failed to assign
pcieport 0000:5f:01.0: bridge window [mem size 0x200000000 64bit pref]: can't assign; no space
pcieport 0000:5f:01.0: bridge window [mem size 0x200000000 64bit pref]: failed to assign
pci 0000:60:00.0: BAR 2 [mem size 0x200000000 64bit pref]: can't assign; no space
pci 0000:60:00.0: BAR 2 [mem size 0x200000000 64bit pref]: failed to assign
pcieport 0000:5d:00.0: PCI bridge to [bus 5e-61]
pcieport 0000:5d:00.0: bridge window [mem 0xb9000000-0xba0fffff]
pcieport 0000:5d:00.0: bridge window [mem 0xbfe0000000-0xbff07fffff 64bit pref]
pcieport 0000:5e:00.0: PCI bridge to [bus 5f-61]
pcieport 0000:5e:00.0: bridge window [mem 0xb9000000-0xba0fffff]
pcieport 0000:5e:00.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]
pcieport 0000:5f:01.0: PCI bridge to [bus 60]
pcieport 0000:5f:01.0: bridge window [mem 0xb9000000-0xb9ffffff]
pcieport 0000:5f:01.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]
pci 0000:60:00.0: BAR 2 [mem 0xbfe0000000-0xbfefffffff 64bit pref]: assigned
In this example we need to resize all the way up to the root port
aperture, but we refuse to change the root port aperture while resources
are allocated for the upstream port BAR.
The solution proposed here builds on the idea in commit 91fa127
("PCI: Expose PCIe Resizable BAR support via sysfs") where the BAR can
be resized while there is no driver attached. In this case, when there
is no driver bound to the upstream switch port we'll release resources
of the bridge which match the reallocation. Therefore we can achieve
the below successful resize operation by unbinding 0000:5e:00.0 from the
pcieport driver before invoking the resource2_resize interface on the
GPU at 0000:60:00.0.
pci 0000:60:00.0: BAR 2 [mem 0xbfe0000000-0xbfefffffff 64bit pref]: releasing
pcieport 0000:5f:01.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]: releasing
pci 0000:5e:00.0: bridge window [mem 0xbfe0000000-0xbfefffffff 64bit pref]: releasing
pci 0000:5e:00.0: BAR 0 [mem 0xbff0000000-0xbff07fffff 64bit pref]: releasing
pcieport 0000:5d:00.0: bridge window [mem 0xbfe0000000-0xbff07fffff 64bit pref]: releasing
pcieport 0000:5d:00.0: bridge window [mem 0xb000000000-0xb2ffffffff 64bit pref]: assigned
pci 0000:5e:00.0: bridge window [mem 0xb000000000-0xb1ffffffff 64bit pref]: assigned
pci 0000:5e:00.0: BAR 0 [mem 0xb200000000-0xb2007fffff 64bit pref]: assigned
pcieport 0000:5f:01.0: bridge window [mem 0xb000000000-0xb1ffffffff 64bit pref]: assigned
pci 0000:60:00.0: BAR 2 [mem 0xb000000000-0xb1ffffffff 64bit pref]: assigned
pci 0000:5e:00.0: PCI bridge to [bus 5f-61]
pci 0000:5e:00.0: bridge window [mem 0xb9000000-0xba0fffff]
pci 0000:5e:00.0: bridge window [mem 0xb000000000-0xb1ffffffff 64bit pref]
pcieport 0000:5d:00.0: PCI bridge to [bus 5e-61]
pcieport 0000:5d:00.0: bridge window [mem 0xb9000000-0xba0fffff]
pcieport 0000:5d:00.0: bridge window [mem 0xb000000000-0xb2ffffffff 64bit pref]
pci 0000:5e:00.0: PCI bridge to [bus 5f-61]
pci 0000:5e:00.0: bridge window [mem 0xb9000000-0xba0fffff]
pci 0000:5e:00.0: bridge window [mem 0xb000000000-0xb1ffffffff 64bit pref]
pcieport 0000:5f:01.0: PCI bridge to [bus 60]
pcieport 0000:5f:01.0: bridge window [mem 0xb9000000-0xb9ffffff]
pcieport 0000:5f:01.0: bridge window [mem 0xb000000000-0xb1ffffffff 64bit pref]
Link: https://patchwork.kernel.org/project/linux-pci/patch/[email protected]/
Signed-off-by: Alex Williamson <[email protected]>
Signed-off-by: Jonathan Bell <[email protected]>
P33M
force-pushed
the
bar_resize_bridge
branch
from
08662e5 to
26e9a9d
Compare
popcornmix
force-pushed
the
rpi-6.12.y
branch
from
1f19366 to
5ece90f
Compare
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.
From https://patchwork.kernel.org/project/linux-pci/patch/[email protected]/
Take the suggested patch which frees upstream bridge resources if a BAR is being resized.