Add support for Pi 5 #5618
Add support for Pi 5 #5618
Conversation
|
@popcornmix We want to drop the top 3 patches marked DNI (Do Not Integrate) that mess with the workflow files. |
|
And the first PCIe reset revert can be replaced with upstream commit 8eb8c27. |
|
On the subject of workflow files, as long as we continue to guarantee that the only difference between bcm2712_defconfig and bcm2711_defconfig is the page size, we can omit a Pi 5-specific test build. |
It probably has some gain though in order to be able to use rpi-update to grab the appropriate build artifacts though (I'm hoping rpi-update looks at that bit of the extension too - I've not checked). |
This reverts commit c0ea202.
|
I've bumped |
|
|
|
Updated (@pelwell please check pcie-bcmstb.c - it is now not the same as initial PR). |
|
rpi-firmware will need the additional kernel2712.img built (and rpi-update will need checking that it copies it). But I think we'll need the additional build artifact - otherwise rpi-update will bump you from a 16K pagesize to a 4K pagesize. |
pcie-brcmstb.c now matches rpi-6.6.y in that respect. I'm happy this part needed changing to sit on top of that upstream change, but perhaps this is the wrong outcome. The question is whether PERST# also needs to be asserted on BCM2712 - the safe thing would be to add that case to the condition, since that matches the old behaviour, and then drop it if we decide it isn't necessary. I'll add a patch to that effect.
OK - I'll add the build type to the workflow. |
After discussion with Tim this is currently unnecessary because the bootloader does leave it reset, so I won't add such a patch at this time. |
So current PR is good (wrt pcie-bcmstb.c)? |
|
Yes, I think so. I've bumped the workflows. There is still some issue with one of the overlays that I'll look at next. |
|
@6by9 in vc4-kms-dsi-7inch-overlay.dts it references ts_i2c_frag, but no such label exists. I think the node you are aiming for is currently labelled frag13, but that doesn't fit with the nice user-friendly labels the rest of that file uses. However, changing edt-ft5406.dtsi could break edt-ft5406-overlay.dts Would you like me to: |
See commit d6e6b9a on the private branch. It just missed the cutoff yesterday, and looks like popcornmix hasn't included it in this PR or merged it into "dts: 2712: Update for device tree" |
|
DRM/KMS unit tests failing appears to be a build failure due to part of raspberrypi-gpiomem.c I'm not totally clear why it's even building gpiomem. KUnit Tests/VC4 are failing as the test vc4/tests/vc4_test_lbm_size.c needs updating for the lbm_size having moved. |
|
So, option d then. Cherry-picked. |
|
Upstream build fixup pushed. |
|
VC4 unit tests fixed with 6by9@950224c (I'm not sure I can do a push to popcornmix's branch. |
|
drivers/char/Kconfig has The old BCM2835_DEVGPIOMEM option for bcm2835-gpiomem was a module. |
|
Defaulting the gpiomem to a module makes sense - it's an anomaly that it isn't already. |
|
Commits 6by9@430bb5b and 6by9@bde073f sort the generic unit test CI failure. 430bb5b wants to go before "drivers: char: delete bcm2835-gpiomem", and bde073f fixes up "drivers: char: delete bcm2835-gpiomem". |
dtoverlays: Fix up edt5406 entries to match with vc4-kms-dsi-7inch vc4-kms-dsi-7inch expects the touch fragment to be named ts_i2c_frag, but edt5406 didn't do this. Fixes: 736d601 ("dts: 2712: Update for device tree") Signed-off-by: Dave Stevenson <[email protected]>
gpio-brcmstb: Report the correct bank width gpio: brcmstb: Use bank address as gpiochip label If the path to the device node is used as gpiochip label then gpio-brcmstb instances with multiple banks end up with duplicated names. Instead, use a combination of the driver name with the physical address of the bank, which is both unique and helpful for devmem debugging. Signed-off-by: Phil Elwell <[email protected]> gpio: mmio: Add DIRECT mode for shared access The generic MMIO GPIO library uses shadow registers for efficiency, but this breaks attempts by raspi-gpio to change other GPIOs in the same bank. Add a DIRECT mode that makes fewer assumptions about the existing register contents, but note that genuinely simultaneous accesses are likely to lose updates. Signed-off-by: Phil Elwell <[email protected]> gpio: brcmstb: Don't always clear interrupt mask If the GPIO controller is not being used as an interrupt source leave the interrupt mask register alone. On BCM2712 it might be used to generate interrupts to the VPU firmware, and on other devices it doesn't matter since no interrupts will be generated. Signed-off-by: Phil Elwell <[email protected]>
pinctrl: bcm2712: Reject invalid pulls Reject attempts to set pulls on aon-sgpios, and fix pull shift values. pinctrl: bcm2712: Add 7712 support, fix 2712 count Signed-off-by: Phil Elwell <[email protected]> pinctrl-bcm2712: add EMMC pins so pulls can be set These pins have pad controls but not mux controls. They look enough like GPIOs to squeeze in at the end of the list though. pinctrl: bcm2712: correct BCM2712C0 AON_GPIO pad pull control offset Signed-off-by: Jonathan Bell <[email protected]> pinctrl: bcm2712: on C0 the regular GPIO pad control register moves too Signed-off-by: Jonathan Bell <[email protected]> pinctrl: bcm2712: Implement (partially) pinconf_get Signed-off-by: Phil Elwell <[email protected]> pinctrl: bcm2712: Convert to generic pinconf Remove the legacy brcm,* pin configuration support and replace it with a proper generic pinconf interface, using named functions instead of alt function numbers. This is nicer for users, less error-prone, and immune to some of the C0->D0 changes. Signed-off-by: Phil Elwell <[email protected]> pinctrl: bcm2712: Remove vestigial pull parameter Now the legacy brcm, pinconf parameters are no longer supported, this custom pin config parameter is not needed. Signed-off-by: Phil Elwell <[email protected]> pinctrl: bcm2712: Guard against bad func numbers Signed-off-by: Phil Elwell <[email protected]> pinctrl: bcm2712: A better attempt at D0 support The BCM2712D0 sparse pinctrl maps play havoc with the old GPIO_REGS macro, so make the bit positions explicit. And delete the unwanted GPIO and pinmux declarations on D0. Note that a Pi 5 with D0 requires a separate DTS file with "bcm2712d0" compatible strings. Signed-off-by: Phil Elwell <[email protected]> pinctrl: bcm2712: Delete base register constants BCM2712D0 deletes many GPIOs and their associated mux and pad bits, so much so that the offsets to the start of the pad control registers changes. Remove the constant offsets from the *GPIO_REGS macros, compensating by adjusting the per-GPIO values. Signed-off-by: Phil Elwell <[email protected]>
The BCM2712 has an evolution of what used to be called TXP in the earlier SoCs, but is now called MOP. There's a few differences still, so we can add a new compatible to deal with them easily. Signed-off-by: Maxime Ripard <[email protected]>
The BCM2712 features a simpler TXP called MOPLET. Let's add support for it. Signed-off-by: Maxime Ripard <[email protected]>
Some code path in vc4 are conditional to a generation and cannot be executed on others. Let's put a WARN_ON if that ever happens. Signed-off-by: Maxime Ripard <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
The name collide with the Full KMS functions that are going to be made public. Signed-off-by: Maxime Ripard <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
On 2712, the firmware always runs these clock at a speed sufficient for dual 4kp60. The requests here prevent the gpu from going into its lowest voltage mode, so just skip the clock requests. With this applied the idle voltage on my pi 5 reduces from 0.7424V to 0.72V. Signed-off-by: Dom Cobley <[email protected]>
Avoid double buffering LBM allocations by making the allocation a single alloc per crtc at atomic_flush. Signed-off-by: Dave Stevenson <[email protected]>
vc4 has always fixed up the timing, so the values defined have never actually appeared on the wire. The display appears to want a slightly longer HFP, so extend the timings and recompute the clock to give the same frame rate. Signed-off-by: Dave Stevenson <[email protected]>
The 10.1" panel doesn't work with the timings defined. vc4 will always have been fixing up the timing due to the limited integer divider, so compute the fixed up mode and use it directly. Signed-off-by: Dave Stevenson <[email protected]>
The driver does not lock the imx477 mutex when calling imx477_set_framing_limits(), leading to: WARNING: CPU: 3 PID: 426 at drivers/media/v4l2-core/v4l2-ctrls-api.c:934 __v4l2_ctrl_modify_range+0x1a0/0x210 [ videodev] Fix this by taking the lock. Signed-off-by: Tomi Valkeinen <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
|
I believe I've squashed in commits that have been pushed/mentioned. Anything missing? |
|
Nope - that looks good to me if the checks are passing. |
:Release Notes: bcm2835-gpiomem was replaced by raspberrypi-gpiomem with support for Pi 5 :Detailed Notes: raspberrypi/linux#5618 raspberrypi/linux@36f254f raspberrypi/linux@27bda80 :Testing Performed: Only build tested. :QA Notes: Extra module installed into rpi image. :Issues Addressed: [WRR-2163] CCC: webos-rpi.inc: update gpiomem kernel module name Cherry-picked-from-commit: c617f94170d2cf9d3fd4bbbffc61188110c359dd Cherry-picked-from-branch:
Add support for Pi 5.
This supports the new hardware in BCM2712 and RP1.
There are two 64-bit defconfig options.
bcm2711_defconfig will support all 64-bit Pi devices and uses a pagesize of 4K
bcm2712_defconfig switches to a 64K pagesize, and only works on Pi 5.