Repository navigation
Conversation
nbuchwitz
force-pushed
the
devel/pcie-mip1-bump
branch
from
October 31, 2026 21:28
55e66be to
b789b8b
Compare
nbuchwitz
force-pushed
the
devel/pcie-mip1-bump
branch
from
November 2, 2026 15:34
b789b8b to
ba5b936
Compare
Contributor
|
From the incomplete Broadcom documentation that I have, the MIP to SPI mappings look correct. There was a register bit on 2712C1 that the firmware always sets to enable this (expanded but discontiguous) mapping, I believe it's hardcoded to a 1 in 2712D0. |
Contributor
Author
|
Thanks! Has the firmware always set that bit on C1, or is there a minimum version? |
Contributor
|
All rpi-eeprom releases supporting Pi 5 set this bit on C1. |
The documentation says that the TPZ filter can not upscale, and requesting a scaling factor > 1:1 will output the original image in the top left, and repeat the right/bottom most pixels thereafter. That fits perfectly with upscaling a 1x1 image which is done a fair amount by some compositors to give solid colour, and it saves a large amount of LBM (TPZ is based on src size, whilst PPF is based on dest size). Select TPZ filter for images with source rectangle <=1. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The register to enable/disable background fill was being set from atomic flush, however that will be applied immediately and can be a while before the vblank. If it was required for the current frame but not for the next one, that can result in corruption for part of the current frame. Store the state in vc4_hvs, and update it on vblank. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The HVS can accept an arbitrary number of planes, provided that the overall pixel read load is within limits, and the display list can fit into the dlist memory. Now that DRM will support 64 planes per device, increase the number of overlay planes from 16 to 48 so that the dlist complexity can be increased (eg 4x4 video wall on each of 3 displays). Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Instead of having 48 generic overlay planes, assign 32 to the writeback connector so that there is no ambiguity in wlroots when trying to find a plane for composition using the writeback connector vs display. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The transposer/writeback connector should be running with a lower priority, so shouldn't be factored into the load calculations. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
As the writeback connector doesn't have the same realtime constraints of a live display, drop the panic priority for it. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The txp block can implement transpose as it writes out the image data, so expose that through the new connector rotation property. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm: vc4: txp: Do not allow 24bpp formats when transposing The hardware doesn't support transposing to 24bpp (RGB888/BGR888) formats. There's no way to advertise this through DRM, so block it from atomic_check instead. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: txp: fix incorrect width and height check logic in vc4_txp_atomic_check Since incorrect conditional operator was used in vc4_txp_atomic_check(), the check may be bypassed if only one of the width or height does not match. To prevent this, the conditional operator must be corrected. Signed-off-by: Jeongjun Park <aha310510@gmail.com>
Currently, booting with no hdmi connected has: pi@pi4:~ $ vcgencmd measure_clock hdmi pixel frequency(9)=120010256 frequency(29)=74988280 After connecting hdmi we get: pi@pi4:~ $ vcgencmd measure_clock hdmi pixel frequency(9)=300005856 frequency(29)=149989744 and that persists after disconnecting hdmi I can measure this on a power supply as 10mA@5.2V (52mW). We should always remove clk_set_min_rate requests when we no longer need them. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Whilst BCM2712 does fix using odd horizontal timings, it doesn't work with interlaced modes. Drop the workaround for interlaced modes and revert to the same behaviour as BCM2711. raspberrypi#6281 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
This is a squash of all firmware-kms related patches from previous branches, up to and including "drm/vc4: Set the possible crtcs mask correctly for planes with FKMS" plus a couple of minor fixups for the 5.9 branch. Please refer to earlier branches for full history. This patch includes work by Eric Anholt, James Hughes, Phil Elwell, Dave Stevenson, Dom Cobley, and Jonathon Bell. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Fixup firmware-kms after "drm/atomic: Pass the full state to CRTC atomic enable/disable" Prototype for those calls changed, so amend fkms (which isn't upstream) to match. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Fixup fkms for API change Atomic flush and check changed API, so fix up the downstream-only FKMS driver. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Make normalize_zpos conditional on using fkms Eric's view was that there was no point in having zpos support on vc4 as all the planes had the same functionality. Can be later squashed into (and fixes): drm/vc4: Add firmware-kms mode Signed-off-by: Dom Cobley <popcornmix@gmail.com> drm/vc4: FKMS: Change of Broadcast RGB mode needs a mode change The Broadcast RGB (aka HDMI limited/full range) property is only notified to the firmware on mode change, so this needs to be signalled when set. raspberrypi/firmware#1580 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> vc4/drv: Only notify firmware of display done with kms fkms driver still wants firmware display to be active Signed-off-by: Dom Cobley <popcornmix@gmail.com> ydrm/vc4: fkms: Fix margin calculations for the right/bottom edges The calculations clipped the right/bottom edge of the clipped range based on the left/top margins. raspberrypi#4447 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: fkms: Use new devm_rpi_firmware_get api drm/kms: Add allow_fb_modifiers Signed-off-by: Dom Cobley <popcornmix@gmail.com> drm/vc4: Add async update support for cursor planes Now that cursors are implemented as regular planes, all cursor movements result in atomic updates. As the firmware-kms driver doesn't support asynchronous updates, these are synchronous, which limits the update rate to the screen refresh rate. Xorg seems unaware of this (or at least of the effect of this), because if the mouse is configured with a higher update rate than the screen then continuous mouse movement results in an increasing backlog of mouse events - cue extreme lag. Add minimal support for asynchronous updates - limited to cursor planes - to eliminate the lag. See: raspberrypi#4971 raspberrypi#4988 Signed-off-by: Phil Elwell <phil@raspberrypi.com> drivers/gpu/drm/vc4: Add missing 32-bit RGB formats The missing 32-bit per pixel ABGR and various "RGB with an X value" formats are added. Change sent by Dave Stevenson. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> drm: vc4: Fixup duplicated macro definition in vc4_firmware_kms Both vc4_drv.h and vc4_firmware_kms.c had definitions for to_vc4_crtc. Rename the fkms one to make it unique, and drop the magic define vc4_crtc vc4_kms_crtc define to_vc4_crtc to_vc4_kms_crtc that renamed half the variable and function names in a slightly unexpected way. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: Fix FKMS for when the YUV chroma planes are different buffers The code was assuming that it was a single buffer with offsets, when kmstest uses separate buffers and 0 offsets for each plane. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: fkms: Rename plane related functions The name collide with the Full KMS functions that are going to be made public. Signed-off-by: Maxime Ripard <maxime@cerno.tech> drm/vc4_fkms: Fix up interrupt handler for both 2835/2711 and 2712 2712 has switched from using the SMI peripheral to another interrupt source for the vsync interrupt, so handle both sources cleanly. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> drm/vc4: fkms: No SMI abuse needed on BCM2712 Since we don't use the (absent) SMI block to create interrupts on BCM2712, there's no need to map any registers. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Testing whether the VideoCore generation we want to mock is vc5 or vc4 worked so far, but will be difficult to extend to support BCM2712 (VC6). Convert to a switch. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The DRM device pointer and the DRM encoder pointer are redundant, since the latter is attached to the former and we can just follow the drm_encoder->dev pointer. Let's remove the drm_device pointer argument. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Some tests will need to retrieve the output that was just allocated by vc4_mock_atomic_add_output(). Instead of making them look them up in the DRM device, we can simply make vc4_mock_atomic_add_output() return an error pointer that holds the allocated output instead of the error code. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The BCM2712 has a simpler pipeline that can only output to a writeback connector and two HDMI controllers. Let's allow our kunit tests to create a mock of that pipeline. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The BCM2712 has a simpler pipeline than the BCM2711, and thus the muxing requirements are different. Create some tests to make sure we get proper muxing decisions. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The current mock planes were just using the regular drm_plane_state, while the driver expect struct vc4_plane_state that subclasses drm_plane_state. Hook the proper implementations of reset, duplicate_state, destroy and atomic_check to create vc4_plane_state. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Some tests will need to find a plane to run a test on for a given CRTC. Let's create a small helper to do that. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
We'll start to add some tests for the plane state logic, so let's create a helper to add a plane to an existing atomic state. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
We'll start testing our planes code in situations where we will use more than XRGB8888, so let's add a few common pixel formats. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The BCM2712 comes with a different LBM size computation than the previous generations, so let's add the few examples provided as kunit tests to make sure we always satisfy those requirements. Signed-off-by: Maxime Ripard <maxime@cerno.tech> drm/vc4: tests: Fix up vc4_test_lbm_size Following the example of [1], move the state allocation out of the init function to make it thread safe. [1] commit 7e0351a ("drm/vc4: tests: Stop allocating the state in test init") Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The tests on vc4 (BCM2835-7) were checking for DSI1 muxing being to restricted channel 2, and therefore muxing with TXP was impossible. As we no longer have that restriction, update the capabilities defined for DSI1, move the tests that used to be impossible to the valid list, and extend for additional combinations that are now possible. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Get the KUnit tests passing. Signed-off-by: Maíra Canal <mcanal@igalia.com>
Bring the upstream driver up to par with the downstream rtc-rpi driver it replaces: - sysfs attributes charging_voltage, charging_voltage_min, charging_voltage_max and battery_voltage (in microvolts), as before. - Accept "trickle-charge-microvolt" on the firmware node when "trickle-voltage-millivolt" is absent, so the existing rtc_bbat_vchg dtparam (in microvolts) keeps working. - Skip registering the RTC device when the firmware node has "raspberrypi,disable-rtc", so dtparam=rtc=off still works. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Add the features of the downstream bcm2712-iommu driver that the upstream one lacks: - "aperture-base": put the translated window at a 4GB-aligned address and pass through all addresses below it, so blocks that share an IOMMU with IOMMU-aware ones keep working with physical addresses. - "aperture-size": limit the translated window (256MB..4GB). - "dma-iova-offset": an offset added to all DMA addresses, restoring the "dma-ranges" offset lost for masters behind a PCIe RC (RP1 on iommu5). The generic page table still covers VAs from 0, so map/unmap/iova_to_phys are rebased onto it, and TLB maintenance converts back to IOMMU input addresses. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The properties of /aliases are paths to other nodes, but an alias may legitimately be called "gpio" (or "foo-gpios"), in which case it is parsed as a phandle list and logs, e.g.: OF: /aliases: could not find phandle 796094307 (0x2f736f63 being "/soc"). Skip /aliases as is done for __symbols__. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Since commit 860e748 ("drm: ensure blend mode supported if pixel format with alpha exposed") DRM warns for every plane that offers formats with alpha but has no "pixel blend mode" property. The firmware chooses the blend mode for fkms planes and the mailbox interface has no way to change it. Reading back the HVS display lists the firmware generates for an ARGB8888 plane shows per-pixel alpha with premultiplied alpha on BCM2835-7 and BCM2711, and per-pixel alpha without premultiplication (coverage) on BCM2712. Expose that single mode, so userspace knows how its alpha will be used and the warning goes away. Set vc4->fkms before the planes are created so the revision can be read there. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
This is used in some HAT designs.
This is used in some HAT designs.
MIP1, the MSI controller behind pcie1 on BCM2712, only describes 8
outputs. I measured the wiring on a CM5 and found 20, routed to GIC
SPIs that are not contiguous.
Patch 1 documents multiple msi-ranges entries. Patch 2 fixes multi-MSI
blocks for non-power-of-two counts and is meant for stable. Patch 3
lets the driver take several ranges. Patch 4 adds the outputs and
depends on patch 3.
Tested on rpi-7.3.y on a Revolution Pi Connect 5 (CM5) with three
LAN7430 NICs behind a PCIe switch, 6 MSI-X vectors each. DPC on the
switch ports uses another 6 outputs. Vectors per NIC:
8 outputs 20 outputs
--------------------------------------------
without DPC 6, 2, INTx 6, 6, 6
with DPC 2, INTx, INTx 6, 6, 2
Industrial Ethernet setups often pin each NIC's interrupts to its own
CPU. That only works on MIP1. The RC MSI target keeps everything on
CPU0. Two NVMe drives behind a switch or an FPGA design [1] hit the
same limit.
A test module requesting 3 MSI vectors per NIC gets aligned blocks with
the series. Without patch 2 the block is misaligned, its last vector
lands outside the described outputs and the device's own MSI never
arrives. The old single-range node still works.
[1] https://forums.raspberrypi.com/viewtopic.php?t=398134
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
--- b4-submit-tracking ---
# This section is used internally by b4 prep for tracking purposes.
{
"series": {
"revision": 1,
"change-id": "20261030-investigate-bcm2712-mip1-v2-4ff97c32b04a",
"prefixes": [],
"presubject": ""
}
}
…msi-ranges The MIP outputs are not wired to one contiguous block of GIC SPIs, so a single msi-ranges entry cannot describe all of them. Define how several entries map to the outputs, and limit the legacy brcm,msi-offset to a single entry, the only case the driver has ever handled. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
…unts Multi-message MSI needs a naturally aligned block of message data, but ilog2() rounds the request size down. A request for three vectors reserves two slots and maps the third onto the next slot, which may already belong to another device. Reserve exactly the requested number of slots at a start aligned to the next power of two. Fixes: 32c6c05 ("irqchip: Add Broadcom BCM2712 MSI-X interrupt controller") Cc: stable@vger.kernel.org Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
The MIP outputs are not wired to one contiguous block of GIC SPIs, so a single msi-ranges entry can only describe part of a MIP. Accept one entry per contiguous run, in output order, and look up the SPI for each message. brcm,msi-offset keeps its meaning for the existing single range and is rejected when more than one range is given. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
MIP1 serves pcie1, the external PCIe x1 port on Pi 5 and CM5, but only 8 of its outputs are described. A single multi-queue device can use most of them, and further devices get fewer vectors or none. The remaining wiring was measured on a CM5 by raising each MIP output and checking which SPI became pending. 20 outputs are wired, the others showed no route. The wiring is assumed to be the same on all BCM2712 steppings but has only been verified on CM5. MIP output GIC SPI 0..1 196..197 2..3 200..201 4..5 206..207 6 240 7 246 8..15 255..262 16 275 17 282 18 263 19 283 Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
nbuchwitz
force-pushed
the
devel/pcie-mip1-bump
branch
from
November 7, 2026 10:41
ba5b936 to
9c77be0
Compare
This file contains hidden or 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
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.
I've been experimenting with more MSI vectors on MIP1, as our RevPi Connect 5 has 3x LAN7430s on pcie1. They don't fit into the 8 MIP1 outputs (each tries to claim 6 outputs), so our DT uses the rc MSI controller instead. Unfortunately it can't pin IRQs, which is not great in most industrial fieldbus setups.
The patches seem to work for my limited PCIe knowledge, but I'd really value @P33M's (and others) feedback on it. If this can work, I'd try to upstream the patches as usual.