Enanle PINCTRL_SINGLE for bcm2712_defconfig#7440
Draft
Cyanoxygen wants to merge 675 commits into
Draft
Conversation
The TC358762 bridge and panel decodes the mode differently on DSI0 to DSI1 for no obvious reason, and results in a shift off the screen. Whilst it would be possible to change the compatible used for the panel, that then messes up Pi5. As it appears to be restricted to vc4 DSI0, fix up the mode in vc4_dsi. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Some DSI peripheral drivers wish to send commands in the post_disable or panel unprepare callback. These are called after the DSI host's disable call, but before the host's post_disable if pre_enable_prev_first is set. Don't reset the block until post_disable to allow these commands to be sent. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The DSI block appears to be able to come up stuck in a condition where it leaves the lanes in HS mode or just jabbering. This stops LP transfers from completing as there is no LP time available. This is signalled via the LP1 contention error. Enabling video briefly clears that condition, so if we detect the error condition, enable video mode and then retry. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Similar to the ch7006 and nouveau drivers, introduce a "tv_mode" module parameter that allow setting the TV norm by specifying vc4.tv_norm= on the kernel command line. If that is not specified, try inferring one of the most popular norms (PAL or NTSC) from the video mode specified on the command line. On Raspberry Pis, this causes the most common cases of the sdtv_mode setting in config.txt to be respected. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> drm/vc4: Do not reset tv mode as this is already handled by framework In vc4_vec_connector_reset, the tv mode is already reset to the property default by drm_atomic_helper_connector_tv_reset, so there is no need for a local fixup to potentially some other default. Fixes: 96922af ("drm/vc4: Allow setting the TV norm via module parameter") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
With the command line parser now providing the information about the tv mode, use that as the preferred choice for initialising the default of the tv_mode property. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
See: https://forum.libreelec.tv/thread/24783-tv-avr-turns-back-on-right-after-turning-them-off While the kernel provides a :D flag for assuming device is connected, it doesn't stop this function from being called and generating a cec_phys_addr_invalidate message when hotplug is deasserted. That message provokes a flurry of CEC messages which for many users results in the TV switching back on again and it's very hard to get it to stay switched off. It seems to only occur with an AVR and TV connected but has been observed across a number of manufacturers. The issue started with raspberrypi#4371 and this provides an optional way of getting back the old behaviour Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The intention of the vc4.force_hotplug setting is to ignore hotplug completely. It can be used when a display toggles hotplug when switching AV inputs, going into standby or changing a KVM switch, and some side effect of that is unwanted. It turns out while vc4.force_hotplug currently makes hotplug always read as asserted, that isn't enough to stop drm doing lots of stuff, including re-reading the edid. An example of what drm does with a hotplug deasert/assert and vc4.force_hotplug=1 currently is: https://paste.debian.net/hidden/dc07434b/ That is unwanted. Lets ignore the hotplug interrupt completely so drm is blissfully unaware of the hotplug change. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
There appears to be a requirement for some devices (I'm testing with a 8K VRROOM 40Gbps HDMI switch) for a measable delay between removing the hdmi phy output from the old mode, to enabling the hdmi phy output for the new mode. Without the delay, a mode switch has a small change of getting a permanent 'no signal', which requires a subsequent mode switch or a unplug/replug to redetect. Switching between 4kp24/25/30 modes fails about 5% of time in my testing. Add a delay to make it impossible to switch faster than this. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The body of this function was missing so we don't reset the phy when disabling it. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
The current reset code doesn't actually stop the hdmi output. That makes it difficult for displays to handle a mode set. Powering down the PLL does actually remove the hdmi signal and makes mode sets more reliable Signed-off-by: Dom Cobley <popcornmix@gmail.com>
There are no MEDIA_BUS_FMT_* defines for GRB or BRG, and adding them is a pain. Add a DT override to allow setting the order. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Seeing as the HVS can be configured with regard the scaling filter, and DRM now supports selecting scaling filters at a per CRTC or per plane level, we can implement it. Default remains as the Mitchell/Netravali filter, but nearest neighbour is now also implemented. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
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>
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>
v3d_mmu_set_page_table() ends by calling v3d_mmu_flush_all() to flush the
MMU cache and clear the TLB after reprogramming V3D_MMU_PT_PA_BASE.
v3d_mmu_flush_all() is gated by pm_runtime_get_if_active(), which returns
0 unless runtime_status == RPM_ACTIVE.
v3d_mmu_set_page_table() is called from two paths that *know* V3D is
reachable, but where the runtime PM status might be wrong:
1. v3d_power_resume(): the runtime resume callback itself, where
runtime_status is RPM_RESUMING.
2. v3d_reset(): called from the DRM scheduler timeout handler with the
hung job's pm_runtime reference held, so RPM_ACTIVE, but here we
don't need to take an extra reference for the duration of the flush
either.
In the first case pm_runtime_get_if_active() returns 0, the flush is
silently skipped, and V3D resumes executing with whatever MMUC/TLB state
happened to survive the last reset. On BCM2711, this leaves stale
translations live across runtime PM cycles, manifesting as random GPU
hangs.
Split the actual flush sequence into a helper that does the writes
unconditionally, and have v3d_mmu_set_page_table() call it directly.
Fixes: 17af1d14deaf ("drm/v3d: Introduce Runtime Power Management")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
v3d_clean_caches() starts the cache-clean sequence by writing V3D_L2TCACTL_TMUWCF to V3D_CTL_L2TCACTL and then polling for that bit to clear. It does not, however, check for an L2T flush (L2TFLS) that may still be in flight from a previous operation. On pre-V3D 7.1 hardware, kicking off the TMU write-combiner flush while an L2T flush is still pending can clobber bits in L2TCACTL and cause cache inconsistencies. Poll for L2TFLS to clear before writing L2TCACTL on V3D < 7.1, ensuring any pending flush has completed before a new clean is issued. Cc: stable@vger.kernel.org Fixes: d223f98 ("drm/v3d: Add support for compute shader dispatch.") Signed-off-by: Maíra Canal <mcanal@igalia.com>
On runtime suspend, clean the V3D caches before suspending so all dirty lines are written back to memory before the power domain is shut down. Fixes several system hangs reported in [1][2][3]. Closes: raspberrypi#7381 [1] Closes: raspberrypi#7396 [2] Closes: raspberrypi#7397 [3] Fixes: 17af1d14deaf ("drm/v3d: Introduce Runtime Power Management") Signed-off-by: Maíra Canal <mcanal@igalia.com>
Align with the non-arm64 code, as it's technically possible to run the cpu in BE mode. Fixes: d30fd12 ("nvme-pci: manually allocate Host Memory Buffer segments on arm64") Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
In commit df289f8 ("pcie-brcmstb: move the unilateral disable of CLKREQ# before link-up") the clkreq_cntl ending up being initialised to zero instead of the read/reset value of the hardware register. Preserve non-clkreq related bits by restoring the read. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
With the jump to the 6.18 kernel we dropped a patch that had been overriding #size-cells in the upstream bcm2712 dts files. The result is cleaner, but only Pi 5 and CM5 EEPROMs since February 2025 are compatible with it. Apply a few hacks to the kernel's early DT parsing and to the 2712 dts so that the EEPROM is able to update the CMA section and the kernel is able to read the result, despite the fact that it is malformed. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Enable DSA support for Microchip KSZ switches with SPI interface. It is for example used in the CM4S based RevPi Flat S. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
The overlays had a cam0 override that changed the CSI2 and I2C interfaces, but it didn't create unique nodes for the clocks and mux nodes meaning that loading two instances simultaneously didn't work. Update them to create unique nodes, and add overrides to set the GPIOs controlling the muxes. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Some Waveshare DSI touch panels (e.g. the 8.8-DSI-TOUCH-A) need extra rails
on the on-board display MCU enabled before the panel itself starts
powering up, and require a longer settle time for those rails to come
up cleanly. The selection is made from device tree via the new
"pre-power-on" boolean property on the regulator's I2C node (asserted
by the matching overlay override).
When "pre-power-on" is present:
- OR BIT(4) | BIT(1) | BIT(0) into the initial poweron_state, so the
additional MCU rails are turned on together with VCC.
- Wait 200 ms after writing REG_TP / REG_LCD so the rails fully
stabilise before the panel/touch are accessed.
When the property is absent the driver behaves exactly as before:
poweron_state stays at BIT(9) | BIT(8) and the post-write delay
remains 20 ms.
Documented in the overlay README alongside the 8_8_inch_a parameter.
Signed-off-by: Waveshare_Team <support@waveshare.com>
The reset, iovcc and avdd GPIOs are requested with GPIOD_OUT_LOW today,
which forces every line low at probe time before the panel sequencing
code has a chance to drive them. On boards where the regulator MCU has
already brought these rails up (notably the 8.8-DSI-TOUCH-A using the new
"pre-power-on" path) this momentarily drops power/reset on a panel that
should already be live, producing visible flicker or a failed first
modeset.
Switch the three optional GPIO requests to GPIOD_ASIS so the kernel
inherits whatever state the bootloader / pre-power-on regulator left
behind. Subsequent gpiod_set_value() calls in prepare()/unprepare()
still drive the lines explicitly, so the runtime sequencing is
unchanged.
Tested on:
- 8.8" DSI touch (pre-power-on path): no flicker on boot, panel comes
up first try.
- 7.0" / 5.0" / 4.0"-c DSI touch (no pre-power-on): unchanged
behaviour, panels still initialise correctly across suspend/resume.
Signed-off-by: Waveshare_Team <support@waveshare.com>
The 8.8-DSI-TOUCH-A (8_8_inch_a) requires the on-board display MCU to enable additional power rails before the panel itself is brought up. Add the "pre-power-on" property to the display_mcu node via the 8_8_inch_a override so the regulator driver knows to assert the extra rails (and apply the longer settle delay) at probe time. Signed-off-by: Waveshare_Team <support@waveshare.com>
Add device tree binding documentation for Waveshare DSI touchscreen panels. This documents all supported compatible strings from 3.4" to 12.3" sizes. Signed-off-by: Waveshare_Team <support@waveshare.com>
Add support for two new Waveshare products: - 4-DSI-TOUCH-A (480x800, 2-lane) - 4.3-DSI-TOUCH-A (480x800, 2-lane) Signed-off-by: Waveshare_Team <support@waveshare.com>
…SI-TOUCH-A Add device tree overlay entries for the Waveshare 4-DSI-TOUCH-A and 4.3-DSI-TOUCH-A. Update the overlay README to document the new parameters. Signed-off-by: Waveshare_Team <support@waveshare.com>
Add support for two MediaTek WiFi PCIe/M.2 interfaces. See: raspberrypi#7415 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Add support for the edatec 101c (800x1280) DSI panel. This panel uses the ILI9881C driver IC and is compatible with the existing initialization sequence defined in the driver. Signed-off-by: FrankLeeEDA <Fli@edatec.cn>
This driver provides support for controlling the panel's power supply, including the necessary voltage and current regulation for proper backlight and LCD operation. Signed-off-by: FrankLeeEDA <Fli@edatec.cn>
Enable the Edatec panel regulator driver as a loadable module in the following default configurations: - bcm2711_defconfig - bcm2711_rt_defconfig - bcm2712_defconfig This allows the kernel to support edatec display panels that require specific power sequencing controlled by this regulator driver. Signed-off-by: FrankLeeEDA <Fli@edatec.cn>
Add overlays for edatec 10inch (101c) and 7inch (070c) DSI panels. Update Makefile to build these new overlays and README to document their usage. Signed-off-by: FrankLeeEDA <Fli@edatec.cn>
The TPZ filter wants ideally 3 lines of image to give good quality downscaling. More than that leads to excessive SDRAM bandwidth for no gain. If the downsample factor allows for it, reduce the programmed image height and increase the pitch to compensate. This currently does not handle T-format images where we need to configure it slightly differently. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Fixes the following v4l2-compliance failure: fail: v4l2-test-controls.cpp(871): subscribe event for control 'User Controls' failed test Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Add support for GPRS Tunneling Protocol tunnels. Signed-off-by: Manawyrm <git@tbspace.de>
Some of the Intel IWL WiFi drivers now also need IWLMLD specifying. See: raspberrypi#7422 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
pitch*height does not necessarily equate to buffer size if the buffer is non-linear, so the buffer validation is invalid. Disable it for non-linear buffers. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
[ Early port of patch sent to linux-arm-kernel, minus documentation ] A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org>
Raspberry Pi 5B will not boot from SD card without PINCTRL_SINGLE since Linux 7.0: [ 17.888687] platform 107d50c000.serial: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/bt_shutdown_pins [ 17.888693] platform pwr_button: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/pwr_button_pins [ 17.888697] platform 107d004000.spi: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/spi10_cs_gpio1 [ 17.888699] platform wl-on-reg: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/wl_on_pins [ 17.888701] platform 1000fff000.mmc: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d510700/emmc_aon_cd_pins [ 17.888704] platform 1001100000.mmc: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/sdio2_30_pins [ 30.688427] vcc-sd: disabling
Contributor
|
My Raspberry Pi 5 is booting happily from SD with top-of-tree rpi-7.0.y. I can't see any way in which the presence of the pinctrl-single (pcs) driver would make any difference - it's a platform driver, and the compatible string is not mentioned in the Pi 5 dts files. To be sure I'd not missed anything, I rebuilt with Please explain how you came to this diagnosis and remedy. |
Author
|
Hi,
I was wondering the same thing, but I at the time I couldn't find out why it happened.
I came to this conclusion by trial and error, and came to this conclusion after a few configuration changes. I cleaned up the boot partition, reapplied the device tree, overlay files and the kernel, after then it booted fine, so now I think it is a fluke 😂 . I will dig deeply tomorrow. Thanks! |
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
20 participants
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.
Raspberry Pi 5B will not boot from SD card without PINCTRL_SINGLE since Linux 7.0:
[ 17.888687] platform 107d50c000.serial: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/bt_shutdown_pins
[ 17.888693] platform pwr_button: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/pwr_button_pins
[ 17.888697] platform 107d004000.spi: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/spi10_cs_gpio1
[ 17.888699] platform wl-on-reg: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/wl_on_pins
[ 17.888701] platform 1000fff000.mmc: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d510700/emmc_aon_cd_pins
[ 17.888704] platform 1001100000.mmc: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/sdio2_30_pins
[ 30.688427] vcc-sd: disabling