commit 687839a02f8da48ba2e3958ce943380500b752e4
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Mon Apr 27 15:36:05 2026 +0300
arm64: dts: rockchip: Drop unnecessary #{address,size}-cells from rk3588-jaguar
Remove the unnecessary #address-cells and #size-cells properties from
the usb_host0_xhci and usb_host1_xhci port nodes, as they each contain
a single endpoint child with no reg property.
This fixes the following dtc warnings:
rk3588-jaguar.dts: Warning (avoid_unnecessary_addr_size):
/usb@fc000000/port: unnecessary #address-cells/#size-cells [...]
/usb@fc400000/port: unnecessary #address-cells/#size-cells [...]
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 67694e3ec66469217ec83dda071b668a097d361b
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Apr 15 19:52:34 2026 +0300
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-roc-pc
The board exposes the GPIO4_B2 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
While at it, move hym8563 down to fix the ordering of &pinctrl entries.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit a1015bfd681e007412551986600934e5ea52a36f
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Sat Apr 11 00:37:23 2026 +0000
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-cm5-base
The board exposes the GPIO4_B5 pin to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
While at it, rename the hdmi_frl_pin pinmux to hdmi0_tx_on_h, in line
with the naming commonly used in RK3588s-bassed board schematics.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 42c3a1a24867ea69df6e8871c086c834cbb2a719
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Thu Apr 16 02:27:22 2026 +0300
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-khadas-edge2
The board exposes the GPIO4_B1 pin to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
While at it, remove the duplicated &hdmi0_sound node.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit e2b757bdbb6f25d4f93341cf25a10fd6c453620a
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Thu Apr 16 22:32:06 2026 +0300
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-gameforce-ace
The board exposes the GPIO4_B3 pin to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Additionally, drop the now unnecessary ddc-en-gpios property and the
associated pinctrl-* entries from hdmi0-con, and rename the hdmi0_en
pinmux to hdmi0_tx_on_h, in line with the naming commonly used in
RK3588s-based board schematics.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 2e082652075b1903d063a0e908aafd1f48c98ae4
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Sat Apr 11 01:06:42 2026 +0000
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s boards
The following RK3588s boards expose a GPIO pin to control the voltage
bias on the HDMI0 data lines:
- rk3588s-coolpi-4b
- rk3588s-indiedroid-nova
- rk3588s-nanopi-r6
- rk3588s-odroid-m2
- rk3588s-orangepi-5
- rk3588s-radxa-cm5-io
- rk3588s-rock-5a
- rk3588s-rock-5c
The pin must be asserted when operating in HDMI 2.1 FRL mode and
deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
While at it, also ensure that pinctrl-names is present and ordered
alphabetically within the hdmi nodes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 3596c939f343f62a70602dea5823c1a70b4cc422
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Apr 15 02:45:06 2026 +0300
arm64: dts: rockchip: Add frl-enable-gpios to rk3588 boards
The following RK3588 boards expose one or two GPIO pins to control the
voltage bias on the HDMI0 and/or HDMI1 data lines:
- rk3588-armsom-sige7
- rk3588-armsom-w3
- rk3588-coolpi-cm5-evb
- rk3588-coolpi-cm5-genbook
- rk3588-evb1-v10
- rk3588-evb2-v10
- rk3588-firefly-itx-3588j
- rk3588-friendlyelec-cm3588-nas
- rk3588-h96-max-v58
- rk3588-jaguar
- rk3588-mnt-reform2
- rk3588-nanopc-t6
- rk3588-orangepi-5-max
- rk3588-orangepi-5-plus
- rk3588-orangepi-5-ultra
- rk3588-roc-rt
- rk3588-rock-5-itx
- rk3588-rock-5b-5bp-5t
- rk3588-tiger
The pins must be asserted when operating in HDMI 2.1 FRL mode and
deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 and/or hdmi1 nodes to their dedicated GPIO pin(s) via
frl-enable-gpios to allow adjusting the bias when transitioning between
TMDS and FRL modes.
While at it, also ensure that pinctrl-names is present and ordered
alphabetically within the hdmi nodes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 1f24010f1b9d45ef64f942dc24047ddddf5dd46d
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Thu Apr 16 01:02:49 2026 +0300
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
The board exposes the GPIO4_C6 pin to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Additionally, drop the now unnecessary workaround of using vcc5v_hdmi_tx
as hdmi-pwr-supply solely to drive the GPIO into its default state.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 7678920ca04851bef07b2bfe353d802dfe3374ce
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Thu Apr 16 01:34:12 2026 +0300
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
The board exposes the GPIO4_C6 pin to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Additionally, remove the now unnecessary workaround of using
vcc_5v0_hdmi as hdmi-pwr-supply solely to drive the GPIO into its
default state.
Also rename the hdmi_con_en pinctrl to hdmi_tx_on_h to match the
schematic naming.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit c025b56f88f4ac1a2794259ea5736bf5e5029037
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Thu Apr 16 01:42:34 2026 +0300
arm64: dts: rockchip: Add frl-enable-gpios to rk3576 boards
The following RK3576 boards expose a GPIO pin to control the voltage
bias on the HDMI data lines:
- rk3576-100ask-dshanpi-a1
- rk3576-armsom-sige5
- rk3576-evb1-v10
- rk3576-evb2-v10
- rk3576-nanopi-m5
- rk3576-roc-pc
- rk3576-rock-4d
The pin must be asserted when operating in HDMI 2.1 FRL mode and
deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit eec696baa809b79b8948c3fb160c242c85a52c43
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Apr 7 00:33:45 2026 +0300
drm/rockchip: dw_hdmi_qp: Wire up TxFFE level adjustment
Provide the .set_ffe_level() PHY callback for the Rockchip platform glue
driver, enabling the bridge's FLT state machine to request FFE level
adjustments from the PHY during FRL link training.
The callback delegates to phy_configure() with the requested FFE level,
using a dedicated flag (set_ffe_level) to distinguish it from a regular
rate reconfiguration. A max_ffe_level field is added to the per-SoC
config table (defaulting to level 3 in auto mode) and propagated into
link_cfg at bind time, so the bridge knows the upper bound to advertise
to the sink.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit b125ceabadaf6d6e3b141987a83f00dd437de633
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Apr 7 00:31:24 2026 +0300
drm/rockchip: dw_hdmi_qp: Wire up FRL operating mode
Enable HDMI 2.1 FRL mode in the Rockchip platform glue driver for the
DesignWare HDMI QP controller:
- Switch PHY mode selection to use phy_set_mode_ext() with
PHY_HDMI_MODE_FRL or PHY_HDMI_MODE_TMDS depending on whether the
required data rate exceeds HDMI 2.0's TMDS ceiling or the sink's own
max TMDS clock
- Negotiate the FRL rate/lane count by capping the sink's advertised
capabilities against the hardware limits, and pass the result to the
PHY via phy_configure()
- Drive the frl_enable GPIO and set the HDMI 2.1 mode bit in the
relevant GRF SoC control registers to reflect the active link mode
- Implement .set_frl_rate() to allow the bridge's FLT state machine to
reconfigure the PHY to a lower FRL rate during training fallback
- Populate and validate the FRL rate/lane bounds in link_cfg at bind
time, with per-SoC overrides in the config table (RK3588 is capped at
10 Gbps/lane × 4 lanes due to a known flicker issue at higher rates)
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 31d01b7b958ddc703c8dd045ec7cdc2d2de45a82
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Apr 7 13:28:59 2026 +0300
drm/bridge: dw-hdmi-qp: Add TxFFE level control support
Extend the FRL link training state machine to handle sink-requested
Transmitter Feed-Forward Equalization (TxFFE) level increases.
During LTS3, a sink can signal that it needs a higher FFE level on the
transmitter to improve signal integrity at a given FRL rate, instead of
immediately requesting a rate downgrade. Handle this by incrementally
stepping up the FFE level (up to the hardware maximum) via a new
optional .set_ffe_level() PHY callback.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 9c797e9ff5b4bc41b2a87aba58a14684fdfa5297
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Apr 7 00:39:51 2026 +0300
drm/bridge: dw-hdmi-qp: Add HDMI 2.1 FRL support
Enable the DesignWare HDMI QP bridge to operate in HDMI 2.1 Fixed Rate
Link (FRL) mode, in addition to the existing TMDS mode:
- Expand dw_hdmi_qp_link_cfg to carry FRL rate/lane configuration
(current, max, and min), allowing the PHY layer to communicate FRL
operating parameters to the bridge
- Implement the full FRL Link Training (FLT) state machine as a kernel
work item, driving the SCDC-based handshake with the sink across all
training states
- Add an optional .set_frl_rate() PHY callback so the bridge can instruct
the PHY to switch to a lower FRL rate during training fallback
- Implement the .hdmi_frl_rate_valid() bridge callback so the DRM
framework can correctly filter modes based on the hardware's FRL
bandwidth capabilities
Co-developed-by: Algea Cao <algea.cao@rock-chips.com>
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 5f3eea374dbd3813561f6c45c92bfe92654d81af
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Mar 17 22:42:11 2026 +0200
drm/bridge: dw-hdmi-qp: Replace sentinel entries with ARRAY_SIZE() iteration
The two static lookup tables for audio TMDS N and CTS values use
all-zero sentinel entries as end-of-table markers, required to terminate
the iteration loops.
This is a rather fragile pattern, hence switch to ARRAY_SIZE()-bounded
for loops and remove the now redundant 'End of table' comments along with
the related rows.
No functional change intended.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 081277b56513693b32cd496135f60bfd59e448d7
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Feb 4 01:11:56 2026 +0200
drm/bridge: dw-hdmi-qp: Log resolution and refresh rate in atomic_enable()
The debug entry in the HDMI branch of dw_hdmi_qp_bridge_atomic_enable()
previously printed the literal string 'HDMI' as the mode field, giving
no information about the actual display timing being configured.
Extend it to include the active resolution and refresh rate by
retrieving the CRTC mode from the incoming atomic state:
dw_hdmi_qp_bridge_atomic_enable mode=1920x1080@50Hz fmt=RGB rate=185625000 bpc=10
This makes the log line self-contained and directly useful when
debugging mode-setting issues, format negotiation, or TMDS rate
mismatches without having to cross-reference a separate mode dump.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit f6a2ad99bc9a250226953e1ecc64d92f8363c72a
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Mar 31 17:52:43 2026 +0300
drm/rockchip: dw_hdmi_qp: Consolidate link config into dedicated struct
Abstract link configuration state into a dedicated dw_hdmi_qp_link_cfg
struct by moving tmds_char_rate out of the main driver data struct into
link_cfg, while also storing the configured PHY bit depth there.
Eventually expose it to the bridge layer via a new .get_link_cfg() PHY
operation.
This refactoring is needed to give the bridge core a clean, extensible
interface to query the active link parameters, a prerequisite for adding
HDMI 2.1 FRL fields (rate, lane count, etc.) to the same structure
without further scattering state across the driver.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 2c785516c9de2a8298eb4580ed2329e6181c014a
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Apr 8 00:23:35 2026 +0300
drm/rockchip: vop2: Scale ACLK rate up for RK3588 FRL display modes
At the default 500 MHz clock rate, the VOP2 AXI bus on RK3588 cannot
sustain the memory bandwidth required by high-resolution FRL modes (e.g.
4K@120Hz), leading to rendering artifacts and POST_BUF_EMPTY interrupt
errors.
Increase the ACLK_VOP rate from 500 MHz to 750 MHz when any video port
enters HDMI 2.1 FRL mode, and restore it to 500 MHz when the last FRL
video port is disabled.
In order for the FRL link state to be propagated from the HDMI encoder
into rockchip_crtc_state, introduce a new frl_enabled flag, and use a
reference counter (frl_vp_count) in struct vop2 to track how many video
ports are driving FRL outputs, so the rate boost is applied for the
first FRL VP and removed only after the last one goes idle.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit ea1617760336b11ae88a671c22e279abe248dbcd
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Mar 25 01:27:05 2026 +0200
drm/display: bridge-connector: Wire up rate validation for HDMI 2.1 bridges
The bridge connector infrastructure acts as a generic glue layer between
drm_bridge implementations and the DRM connector framework, delegating
TMDS character rate validation to the underlying bridge via
.hdmi_tmds_char_rate_valid(). FRL-capable bridges need the same
treatment for the new .frl_rate_valid() connector hook introduced to
support HDMI 2.1 mode validation.
Add the corresponding .hdmi_frl_rate_valid() hook to struct
drm_bridge_funcs, documented as optional and gated on
DRM_BRIDGE_OP_HDMI, to be consistent with all other HDMI bridge
callbacks.
Provide drm_bridge_connector_frl_rate_valid(), which implements the
.frl_rate_valid() callback in drm_connector_hdmi_funcs by forwarding the
call to the HDMI bridge .hdmi_frl_rate_valid() hook.
The delegation follows the same pattern as the TMDS equivalent, with one
exception: if the bridge does not implement the callback, reject the FRL
modes rather than silently permitting them. Unlike the TMDS path, FRL
support must be explicit.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 50fa13c85933e6407d576e094b674a63a3ca6b11
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Mar 25 01:34:26 2026 +0200
drm/display: hdmi: Provide hook for HDMI 2.1 FRL mode validation
HDMI 2.1 sinks that support Fixed Rate Link (FRL) can accept pixel
clocks that exceed their maximum TMDS character rate. The existing
hdmi_clock_valid() helper unconditionally rejects any mode whose clock
surpasses max_tmds_clock, making it impossible to validate modes that
would be transported over FRL.
Add the .frl_rate_valid() hook to struct drm_connector_hdmi_funcs,
mirroring the existing .tmds_char_rate_valid() pattern. The callback
receives both the required data rate and the sink's maximum link rate
(both in bps) and returns a drm_mode_status value. Implementing the hook
is mandatory for drivers that wish to expose FRL-capable modes.
Extend hdmi_clock_valid() to fall through to an FRL validation path when
the TMDS clock limit is exceeded:
1. Verify the sink advertises FRL capability via max_frl_rate_per_lane
and max_lanes fields parsed from the HF-VSDB in the sink EDID.
2. Require the driver to implement the new .frl_rate_valid() callback;
otherwise reject the mode, since FRL link management is
driver-specific.
3. Compute the required FRL bandwidth using 16b/18b encoding and compare
it against the sink's maximum FRL link capacity. Reject the mode if
the required bandwidth exceeds what the sink can handle.
4. Delegate the final validation to the driver's .frl_rate_valid()
callback, which can apply hardware-specific constraints on the
achievable FRL lane/rate configuration.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit c2a4b73cf437263e742a2b8d6982af9a5b770074
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Sat Mar 28 22:08:28 2026 +0200
drm/display: scdc-helper: Add FRL link training control functions
Provide a few SCDC-side primitives to support implementing the Fixed
Rate Link (FRL) link training handshake as mandated by the HDMI 2.1
specification:
- drm_scdc_set_frl(): configures the FRL rate and FFE (Feed-Forward
Equalization) level on the sink via the SCDC CONFIG_1 register, so the
source can negotiate and apply a specific FRL operating point during
link training
- drm_scdc_calc_lower_frl(): computes the next-lower FRL bandwidth
configuration given a current one, to support implementing the FRL
link training fallback mechanism, where the source must step down to a
lower rate when the sink signals training failure
- drm_scdc_get_frl_ltp_request(): reads the Link Training Pattern (LTP)
requests from the sink for all four FRL lanes via SCDC STATUS_FLAGS
registers, to determine what pattern each lane expects during FRL link
training so the source can respond appropriately
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 9ee034a4bcadf92fb9abe31c77a0d1f9a177cd26
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Thu Mar 12 17:55:32 2026 +0200
drm/display: scdc: Add HDMI 2.1 FRL register definitions
HDMI 2.1 introduced Fixed Rate Link (FRL) as a new physical layer
transport to replace TMDS for high-bandwidth modes requiring more than
~18 Gbps. Establishing a FRL link requires a training procedure known
as Fixed Rate Link Training (FLT), which is coordinated between source
and sink via the Status and Control Data Channel (SCDC).
Add the register definitions and bit-field macros needed to implement
this link training handshake.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit cf2907d40729ca74027385040452233455fca6c0
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Thu Mar 12 18:16:54 2026 +0200
drm/display: scdc: Convert bit-field macros to use BIT()
Make the code more robust and improve readability by replacing all
open-coded bit-shift expressions with the BIT() macro.
While at it, realign macro definitions so that the values line up
consistently across the file.
Moreover, SCDC_TMDS_BIT_CLOCK_RATIO_BY_10 is defined as (0 << 1), hence
indicating a cleared bit. Since BIT() cannot meaningfully represent
this, and the symbol has no users in the kernel tree, remove it.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit d0b2de25658a46b7c28ad785211ff9ee9a14bdc5
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Mon Apr 20 22:42:12 2026 +0300
drm/rockchip: dw_hdmi_qp: Restrict HPD event to the affected connector
Switch from drm_helper_hpd_irq_event(), which polls all connectors, to
drm_connector_helper_hpd_irq_event(), which runs the detect cycle only
on the affected connector.
This avoids unnecessary work and redundant detect calls on unrelated
connectors.
Tested-by: Diederik de Haas <diederik@cknow-tech.com>
Tested-by: Maud Spierings <maud_spierings@hotmail.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 48cab51fc0abcde49fb5ac9a88057df20a94708e
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Mon Apr 20 23:55:39 2026 +0300
drm/rockchip: dw_hdmi_qp: Register HPD IRQ after connector setup
Move devm_request_threaded_irq() to the end of bind(), after
drm_bridge_connector_init() and drm_connector_attach_encoder(), to
ensure all DRM resources are ready before HPD interrupts can fire.
While at it, add error handling for drm_connector_attach_encoder().
Tested-by: Diederik de Haas <diederik@cknow-tech.com>
Tested-by: Maud Spierings <maud_spierings@hotmail.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit b95d3af68eb68e7efa3ac6b6d52b6c44b81a94dc
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Apr 21 14:38:26 2026 +0300
drm/rockchip: dw_hdmi_qp: Use local dev variable consistently in bind()
Replace indirect struct device accesses via hdmi->dev and pdev->dev with
the local dev parameter already available in dw_hdmi_qp_rockchip_bind(),
for consistency and readability.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 77a1c827cf172c6e87c23c26efc11dea224f88db
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Apr 21 14:21:36 2026 +0300
drm/rockchip: dw_hdmi_qp: Add missing newlines in dev_err_probe() messages
Add the missing trailing newlines to a couple of dev_err_probe() calls
in dw_hdmi_qp_rockchip_bind().
Fixes: b6736a4ea3 ("drm/rockchip: dw_hdmi_qp: Improve error handling with dev_err_probe()")
Fixes: e1f7b7cbd74c ("drm/rockchip: dw_hdmi_qp: Switch to drmm_encoder_init()")
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit bcdaec3624719fad8a5459bf9065b06f5f5a9519
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Apr 21 14:08:12 2026 +0300
drm/bridge: dw-hdmi-qp: Rate limit i2c read error messages
During EDID reads, repeated i2c errors can flood the kernel log:
[ 25.361716] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 25.363376] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
...
[ 25.368671] dwhdmiqp-rockchip fde80000.hdmi: i2c read error
[ 25.369440] dwhdmiqp-rockchip fde80000.hdmi: failed to get edid
Switch to dev_err_ratelimited() in dw_hdmi_qp_i2c_read() to reduce log
spam while still reporting the condition.
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit a92b6c01414ab8486f0686dc634eaf2570fb61bf
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Sep 13 17:30:35 2024 +0300
drm/bridge: dw-hdmi-qp: Add HDMI 2.0 SCDC scrambling and high TMDS clock ratio support
Enable HDMI 2.0 display modes (e.g. 4K@60Hz) by adding SCDC management
for the high TMDS clock ratio and scrambling, required when the TMDS
character rate exceeds the 340 MHz HDMI 1.4b limit.
A periodic work item monitors the sink's scrambling status to recover
from sink-side resets. On hotplug detect, if SCDC scrambling state is
out of sync with the driver, trigger a CRTC reset to re-establish the
link.
Reject modes requiring TMDS rates above 600 MHz, as those fall in the
HDMI 2.1 FRL domain which is not supported. In no_hpd configurations,
further restrict to 340 MHz since SCDC requires a connected sink.
Tested-by: Diederik de Haas <diederik@cknow-tech.com>
Tested-by: Maud Spierings <maud_spierings@hotmail.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 85943850fdfa7b6675489247530be27fff57ef29
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Jan 10 23:04:23 2025 +0200
drm/bridge-connector: Switch to .detect_ctx() for connector detection
Use the atomic .detect_ctx() connector helper hook and invoke
drm_bridge_detect_ctx() to propagate the modeset acquire context to
bridge drivers.
This enables bridge drivers to perform modeset operations during
detection, which is needed for managing SCDC state lost on sink
disconnects in HDMI 2.0 scenarios.
Tested-by: Diederik de Haas <diederik@cknow-tech.com>
Tested-by: Maud Spierings <maud_spierings@hotmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 6bbde3ee02a64296c7f429bba41e3fc2314578a6
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Apr 22 01:26:32 2026 +0300
drm/bridge-connector: Use cached connector status in .get_modes()
Replace the active drm_bridge_connector_detect() call in get_modes()
with a read of the already-cached connector->status.
The .get_modes() callback is only invoked from
drm_helper_probe_single_connector_modes(), which has already retrieved
the connector status. Calling detect again is redundant and triggers a
duplicate hotplug event. This is also a prerequisite for switching to
the .detect_ctx() hook, which requires a drm_modeset_acquire_ctx not
available in the .get_modes() path.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit b7ac78f72638ffb883cbd3a526d906d79c478ef8
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Jan 10 22:48:01 2025 +0200
drm/bridge: Add detect_ctx hook and drm_bridge_detect_ctx() helper
Add an atomic-aware .detect_ctx() callback to drm_bridge_funcs and a
drm_bridge_detect_ctx() helper that accepts an optional
drm_modeset_acquire_ctx.
This enables bridge drivers to perform operations requiring modeset
locking during connector detection, such as SCDC management for HDMI
2.0. When both ->detect_ctx and ->detect are defined, the former takes
precedence. When ctx is NULL, locking is managed internally with EDEADLK
retry.
Tested-by: Diederik de Haas <diederik@cknow-tech.com>
Tested-by: Maud Spierings <maud_spierings@hotmail.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 33e319315257d17da6d920c1d494ede750255bd7
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Apr 21 23:51:17 2026 +0300
drm/bridge: Remove redundant error check in drm_bridge_helper_reset_crtc()
Remove the no-op error check after drm_atomic_helper_reset_crtc() since
the goto target is the immediately following label and the return value
is already propagated correctly without it.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 63cb438023cae2552e1aacb122e3a245f7404333
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Sun Mar 2 19:47:18 2025 +0200
[DEBUG] drm/rockchip: vop2: Log DCLK setup
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 8b45b802b49e1970466e5b9900688b41dd6c6e70
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Apr 10 04:19:28 2026 +0300
[WIP-update-fixes] phy: rockchip: samsung-hdptx: Handle PHY config after module reload
The pll_config_dirty mechanism introduced in commit e63ea089a8ab ("phy:
rockchip: samsung-hdptx: Handle uncommitted PHY config changes")
invalidates the clock rate in determine_rate() by resetting req->rate to
zero, ensuring CCF will invoke set_rate() to program pending PLL
configuration changes into hardware.
However, after a module reload cycle the PHY PLL clock gets
re-registered with CCF, which causes the framework's cached rate to also
be zero. Setting req->rate to zero then has no effect, since CCF sees
no difference between the requested and current rates and skips calling
set_rate(), leaving the PLL unconfigured.
Address this by first computing the actual target rate from the HDMI
link configuration, and only then invalidating it when it matches the
CCF cached rate.
Fixes: e63ea089a8ab ("phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 7138172130d3d4a484d3309ad618c6be21e7bcb3
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Mar 18 01:43:24 2026 +0200
phy: rockchip: samsung-hdptx: Add support for FRL TxFFE level control
During HDMI 2.1 FRL link training, the source may need to incrementally
raise the TxFFE level in response to persistent link failures reported
by the sink during LTS3. The phy_configure_opts_hdmi struct now carries
ffe_level and set_ffe_level fields to convey such an update
independently of a full rate reconfiguration.
Wire up the optional TxFFE control in the Samsung HDPTX PHY driver.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit d9c0693060fa199b71824091e9417041bed96daa
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Mar 18 01:17:57 2026 +0200
phy: hdmi: Add optional FRL TxFFE config options
During HDMI 2.1 FRL link training, the source and sink can negotiate a
Transmitter Feed-Forward Equalization (TxFFE) level to improve the
signal quality. Starting from zero, the source may increment the TxFFE
level up to a maximum agreed during the LTS3 stage if the sink keeps
reporting FLT failures. TxFFE adjustment is optional and only attempted
when both the source and the connected sink support it.
Since the existing HDMI PHY configuration API covers the FRL rate/lane
selection only, provide the following fields to the frl sub-struct of
phy_configure_opts_hdmi:
* ffe_level: the TxFFE level to apply, only meaningful when
set_ffe_level is set.
* set_ffe_level: a 1-bit flag that changes the semantics of the
phy_configure() call, i.e. when set, the PHY driver must apply the new
ffe_level and ignore the other frl related fields.
The flag-based approach reflects an important invariant in the link
training process: whenever the FRL rate or lane count changes, the TxFFE
level must be reset to zero. A separate phy_configure() call with
set_ffe_level can only follow after the rate has been established,
making the two operations deliberately distinct.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit bf11dd359fff547c240e17ec9b24cfdb982f5645
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Apr 21 18:17:02 2026 +0200
usb: typec: fusb302: drop custom gpio interrupt logic
When the driver was upstreamed it contained the logic to fetch a
"fcs,int_n" GPIO from device-tree, convert it into an interrupt
and use it. This was never part of the binding and there was only
a single upstream user, which got converted to follow the proper
bindings in 2020. Drop the custom logic and only allow the properly
documented ABI.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 2fe69bbda3ab4e1752e4fe1e485459abb8d82a31
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Apr 21 18:10:26 2026 +0200
usb: typec: fusb302: rework gpio_int_n_irq handling
Improve the code readability, so that one does not need to jump
into fusb302_init_irq() to understand that chip->gpio_int_n_irq
is guranteed to be initialized.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 1ffe0d80fbdda54d4d67d2746ad50e6f7085f595
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Apr 21 18:03:15 2026 +0200
usb: typec: fusb302: move gpio_int_n into function local scope
The driver only cares about the interrupt and the GPIO itself is
device managed, so drop the reference from the device structure
and only keep it in the function scope. While at it cleanup the
error handling by using dev_err_probe.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 73d657349390e4026d659ced4df702277db0f862
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Apr 21 18:01:37 2026 +0200
usb: typec: fusb302: rename init_gpio into fusb302_init_irq
Add the fusb302_ prefix to init_gpio, since it is used by all
the other functions and allows easy figuring out that it is a
local function.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 66ef691ee9fd5c23dcc0d3ed326fdd0a7aee6968
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Apr 21 17:41:17 2026 +0200
usb: typec: fusb302: Fix resource handling
The driver's probe routine is currently mixing registration calls for
device managed resources with unmananged ones. This results in issues
such as resource leaks or use-after-free. Fix this up by fully
converting the driver to device managed resources.
Resource acquisition has been reordered a bit, so that the work is
initialized after the TCPM port is registered as the work uses the
TCPM devices.
Fixes: 5d79c52540 ("usb: typec: fusb302: add DRM DP HPD bridge support")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit fd7d481a4853661e1c92297b727eb2a822c96260
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Apr 21 16:23:15 2026 +0200
usb: typec: tcpm: add device managed port registration
A few drivers would benefit from having device managed TCPM
port registration, so that their probe routine does not mix
device managed and non-device managed calls.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 0319d0e37428043426aad58b8843c59fe88c7aee
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Feb 12 22:22:54 2026 +0100
arm64: dts: rockchip: Fix DP sound-dai-cells on RK3588
The DP controller has a I2S and SPDIF interface and thus needs
one cell to specify the interface being used.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 51150c5680d678d03c321b25b3afbfa88986c573
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Wed Jan 21 06:02:48 2026 +0100
arm64: dts: rockchip: Add DP audio for ArmSom Sige5
Add audio support to the USB-C DisplayPort Alternate Mode.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 6783750613ba8718c5b34ae0fcedd2619ae96c97
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Wed Jan 21 06:01:21 2026 +0100
arm64: dts: rockchip: Add DP sound support to RK3576 device tree
Add support for enabling sound for the DisplayPort to the RK3576 DT.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit b49165722d67db5eb13a9999df8078e27155323f
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Wed Jan 21 05:22:05 2026 +0100
drm/bridge: synopsys: dw-dp: Add audio support
Implement audio support for the Synopsys DesignWare DisplayPort
controller.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 0cd7d8a7ba86f16e554f4f291cde5620fbd57ec3
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Jan 23 23:10:22 2026 +0100
[RFC] dt-bindings: display: rockchip: dw-dp: fix sound DAI cells
The RK3588 and RK3576 DesignWare DisplayPort controllers both have two
possible DAI interfaces: I2S and S/PDIF. Thus it is needed to have an
argument to select the right interface.
In case of RK3576 this is not enough though. The RK3576 has the same IP
as RK3588, but configured with Multi Stream Transport (MST) enabled for
up to 3 displays and thus has a total of 6 DAI interfaces (I2S and
S/PDIF for each possible stream. Meanwhile the RK3588 does not support
MST and thus has only 2 DAI interfaces.
The binding update right now only supports the simple single stream
transport (SST) setup. To avoid further DT ABI breakage (or complicated
bindings supporting different number of arguments), it's probably a good
idea to take MST into account now even though the upstream Linux driver
does not yet support it.
I see two options:
1. Adding yet another cell, so that we have the following:
<&dp_ctrl [display_stream] [i2s_or_spdif]>; potentially append
extra input ports for MST video data to existing ports node
(e.g. port@2). I would only handle the sound DAI part in my
patch and basically use '0' for the display stream and just
leave the option of using '1' or '2' once MST support is added.
2. The vendor kernel creates a sub-node for each supported display
stream and puts the ports mapping as well as the DAI reference
into that. This bundles all information for one display stream
together, which creates a clean look but the subnode does not
really describe any real thing in the hardware.
As upstream MST support seems to be quite limited, I wish for some
feedback about the preferred way to handle this.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 514da9fd7eda39333ed53b1512cea388d56a5160
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Mar 19 16:44:22 2026 +0100
drm/rockchip: dw_dp: Add runtime PM support
Add support for runtime PM to the Rockchip RK3576/3588 Synopsys
DesignWare DisplayPort driver.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit b1457c68a783dac5a1c4fafd42a22fe0cb07fa0c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Mar 19 16:40:50 2026 +0100
drm/bridge: synopsys: dw-dp: Add Runtime PM support
Add runtime PM stubs to the Synopsys DesignWare DisplayPort bridge
driver. Support is not enabled automatically and must be hooked up
in the vendor specific glue code.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit a8b3a672899acaea0d5c83c8e07be906e1f537fe
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Wed Mar 4 15:34:43 2026 +0100
drm/rockchip: dw_dp: Implement out-of-band HPD handling
Implement out-of-band hotplug handling, which will be used to receive
external hotplug information from the USB-C state machine. This is
currently handled by the USBDP PHY, which brings quite some trouble
as the register being accessed requires the power-domain from the DP
controller and also requires custom TypeC HPD info parsing in the
USBDP PHY driver.
In contrast to the USBDP PHY this does not just enable the hotplug
signal when a DP AltMode capable adapter is plugged in, but instead
properly detects if a cable is plugged in for things like USB-C to
HDMI adapters.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit f9cee5ac3ad1619d10486c9ab5f1725f87a1ed0f
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Wed Mar 4 15:29:45 2026 +0100
drm/bridge: synopsys: dw-dp: Support software triggered OOB HPD
Add support for USB-C DP AltMode out-of-band hotplug handling. The
handling itself is implemented in the platform specific driver as the
registers to force HPD state are not part of the Designware DisplayPort
IP itself. Instead the platform integration might provide the necessary
functionality to mux the HPD signal.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 4b34cab63be4b619c867b0f5c7aa690a6b4769dd
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Feb 26 16:42:44 2026 +0100
drm/bridge: Add out-of-band HPD notify handler
For DP bridges, that can be used for DP AltMode, it might be necessary
to enforce HPD status. There is an existing ->oob_hotplug_event() on
the DRM connector, but it currently just calls into hpd_notify().
As DP bridge drivers usually also implement .detect and that also
generates calls into hpd_notify, this is a bad place to force the
HPD status as the follow-up detect call might force it off again
resulting in all follow-up calls to the detection routine also
failing.
Avoid this by having a dedicated function for OOB events.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit d2cc8b5da90d0dbcbcf030d4feb9b9e1914bd134
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Mar 5 18:12:53 2026 +0100
drm/bridge: synopsys: dw-dp: Add follow-up bridge support
Add support to use USB-C connectors with the DP altmode helper code on
devicetree based platforms. To get this working there must be a DRM
bridge chain from the DisplayPort controller to the USB-C connector.
E.g. on Rockchip RK3576:
root@rk3576 # cat /sys/kernel/debug/dri/0/encoder-0/bridges
bridge[0]: dw_dp_bridge_funcs
refcount: 7
type: [10] DP
OF: /soc/dp@27e40000:rockchip,rk3576-dp
ops: [0x47] detect edid hpd
bridge[1]: drm_aux_bridge_funcs
refcount: 4
type: [0] Unknown
OF: /soc/phy@2b010000:rockchip,rk3576-usbdp-phy
ops: [0x0]
bridge[2]: drm_aux_hpd_bridge_funcs
refcount: 5
type: [10] DP
OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
ops: [0x4] hpd
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 02565d8be3a104e28c6153f75a199ff2199a62d8
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Mar 6 14:26:19 2026 +0100
drm/bridge: synopsys: dw-dp: Support MEDIA_BUS_FMT_FIXED
Add support for MEDIA_BUS_FMT_FIXED, which is e.g. requested for USB-C
DP chains as the last bridge in the chain (aux-hpd-bridge) does not
implement atomic_get_output_bus_fmts(), which results in the generic
drm_atomic_bridge_chain_select_bus_fmts() code using MEDIA_BUS_FMT_FIXED
instead.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 67d5933cb64f72665d47c5c88ba2f765210c3116
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Feb 19 15:55:04 2026 +0100
drm/bridge: synopsys: dw-dp: Simplify driver data setting
There is no need to get the platform device just for setting up
the driver data. Simplify the logic.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 914d5ba8990c0791af2dd9a7a61b571592666e43
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Mar 17 15:43:25 2026 +0100
[DEBUG] usb: typec: altmode/displayport: print message on probe error
Print an error message when the DisplayPort AltMode driver probe failed
due to incorrect pin assignment or wrong data-role to ease debugging
issues.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit c98a62f345a0fde6ca5ac242c31ce99ed4561a86
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Mon Mar 9 21:12:33 2026 +0200
drm/bridge: synopsys: dw-dp: Drop useless memory allocation
The bridge gets allocated and initialized implicitly via the
devm_drm_bridge_alloc() helper in dw_dp_bind(). However, this is
preceded by an explicit allocation for the same dw_dp struct, which is
never used anywhere as the return from devm_kzalloc() gets immediately
overwritten by the aforementioned helper.
Get rid of the unnecessary and confusing memory allocation.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 4b6e4d4fd05908dde94d24487d8952f8769a2d46
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Mar 27 02:55:08 2026 +0200
drm/rockchip: dw_dp: Release core resources
Core resources such as the DisplayPort AUX channel get initialized and
registered during dw_dp_bind(), but are never unregistered, which may
lead to memory leaks and/or use-after-free:
[ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0
[ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658
[ 224.662612]
[ 224.662752] CPU: 7 UID: 0 PID: 658 Comm: modprobe Not tainted 7.0.0-rc2-next-20260305 #14 PREEMPT
[ 224.662759] Hardware name: Radxa ROCK 5B (DT)
[ 224.662762] Call trace:
[ 224.662764] show_stack+0x20/0x38 (C)
[ 224.662772] dump_stack_lvl+0x6c/0x98
[ 224.662777] print_report+0x160/0x4b8
[ 224.662783] kasan_report+0xb4/0xe0
[ 224.662790] __asan_report_load8_noabort+0x20/0x30
[ 224.662796] device_is_dependent+0xe0/0x2b0
[ 224.662802] device_is_dependent+0x108/0x2b0
[ 224.662808] device_link_add+0x1f8/0x10b0
[ 224.662813] devm_of_phy_get_by_index+0x120/0x200
[ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp]
[ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm]
[ 224.662864] component_bind_all+0x3a8/0x720
[ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm]
[ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838
[ 224.662904] component_master_add_with_match+0x1f4/0x230
[ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm]
[ 224.662939] platform_probe+0xe8/0x168
[ 224.662945] really_probe+0x340/0x828
[ 224.662950] __driver_probe_device+0x2e0/0x350
[ 224.662954] driver_probe_device+0x80/0x140
[ 224.662959] __driver_attach+0x398/0x460
[ 224.662964] bus_for_each_dev+0xe0/0x198
[ 224.662968] driver_attach+0x50/0x68
[ 224.662972] bus_add_driver+0x2a0/0x4c0
[ 224.662977] driver_register+0x294/0x360
[ 224.662982] __platform_driver_register+0x7c/0x98
[ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm]
Since a previous commit exported dw_dp_unbind() function in DW DP core
library to take care of the necessary cleanup, use this in the
component's unbind() callback, as well as in its bind() error path.
Fixes: d68ba7bac9 ("drm/rockchip: Add RK3588 DPTX output support")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20260327-drm-rk-fixes-v3-2-fd2e6900c08c@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 916d18d1902aecc762438272d4bbbe03a27f1d8f
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Mar 27 02:55:07 2026 +0200
drm/bridge: synopsys: dw-dp: Support unregistering the AUX channel
The DisplayPort AUX channel gets initialized and registered during
dw_dp_bind(), but it is never unregistered, which may lead to resource
leaks and/or use-after-free.
Add the missing dw_dp_unbind() function to allow the users of the
library to handle the required cleanup, i.e. unregister the AUX adapter.
Fixes: 86eecc3a9c ("drm/bridge: synopsys: Add DW DPTX Controller support library")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20260327-drm-rk-fixes-v3-1-fd2e6900c08c@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 4dde4275afa46ffc57706b644b5e422f1b548709
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Jan 21 13:50:42 2026 +0200
drm/rockchip: dw_dp: Simplify error handling
Make the code a bit more compact by getting rid of the superfluous
assignments around PTR_ERR().
While at it, also drop dev assignment in dw_dp_probe().
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 81dc76cef334ea4ce0928c423e4a79469d45cd37
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Feb 17 20:36:26 2026 +0200
[DEBUG] phy: rockchip: samsung-hdptx: Add verbose logging
commit d7d2032ac340eb5d161cb396e5b4be3f718bda6e
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Feb 27 22:48:50 2026 +0200
phy: rockchip: samsung-hdptx: Consistently use bitfield macros
Make the code more robust and improve readability by using the available
bitfield macros (e.g. FIELD_PREP, FIELD_GET) whenever possible, instead
of open coding the related bit operations.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-6-f998f2762d0f@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 9aca848e4e43ac84c58d342eeb52cc80847ec9ba
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Feb 27 22:48:49 2026 +0200
phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16()
The 16 most significant bits of the general-purpose register (GRF) are
used as a write-enable mask for the remaining 16 bits.
Make use of the recently introduced FIELD_PREP_WM16() macro to avoid
open-coding the bit shift operations and improve code readability.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-5-f998f2762d0f@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit af6ca85fb74c6ab18a0794f410289ef242bec43a
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Feb 27 22:48:48 2026 +0200
phy: rockchip: samsung-hdptx: Drop restrict_rate_change handling
Since commit 6efbd0f46d ("phy: rockchip: samsung-hdptx: Restrict
altering TMDS char rate via CCF"), adjusting the rate via the Common
Clock Framework API has been disallowed.
To avoid breaking existing users until switching to the PHY config API,
it introduced a temporary exception to the rule, controlled via the
'restrict_rate_change' flag.
As the API transition completed, remove the now deprecated exception
logic.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-4-f998f2762d0f@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 722db0df9311ff60e7046f6d173cc5f27643fb9b
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Feb 27 22:48:47 2026 +0200
phy: rockchip: samsung-hdptx: Drop TMDS rate setup workaround
Since commit ba9c2fe18c ("drm/rockchip: dw_hdmi_qp: Switch to
phy_configure()") the TMDS rate setup doesn't rely anymore on the
unconventional usage of the bus width, instead it is managed exclusively
through the HDMI PHY configuration API.
Drop the now obsolete workaround to retrieve the TMDS character rate via
phy_get_bus_width() during power_on().
While at it, get rid of the extra call to rk_hdptx_phy_consumer_put() by
moving the statement at the end of the function.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-3-f998f2762d0f@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 191c95d66c82adc071bbbe93d6436626ef838356
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Feb 27 22:48:46 2026 +0200
phy: rockchip: samsung-hdptx: Handle uncommitted PHY config changes
Any changes to the PHY link rate and/or color depth done via the HDMI
PHY configuration API are not immediately programmed into the hardware,
but are delayed until the PHY usage count gets incremented from 0 to 1,
that is when it is powered on or when the PLL clock exposed through
the CCF API is prepared, whichever comes first.
Since the clock might remain in prepared state after subsequent PHY
config changes, the programming can also be triggered via
clk_ops.set_rate(). However, from the clock consumer perspective (i.e.
VOP2 display controller), the (pixel) clock rate doesn't vary with bpc,
as that is handled internally by the PHY and reflected in the TDMS
character rate only.
As a consequence, changing the bpc while preserving the modeline may
lead to out-of-sync issues between CCF and HDMI PHY config state,
because the .set_rate() callback is not invoked when clock rate remains
constant. This may also happen when the PHY PLL has been pre-programmed
by an external entity, e.g. the bootloader, which is actually a
regression introduced by the recent FRL patches.
Introduce a pll_config_dirty flag to keep track of uncommitted PHY
config changes and use it in clk_ops.determine_rate() to invalidate the
current clock rate (as known by CCF) and, consequently, ensure those
changes are programmed into hardware via clk_ops.set_rate().
Moreover, proceed with a similar fix in phy_ops.power_on() callback, to
handle the scenario where the CCF API is not used due to operating in
FRL mode, while the clock is still in a prepared state and thus
preventing rk_hdptx_phy_consumer_get() to apply the updated PHY
configuration.
Fixes: de5dba8331 ("phy: rockchip: samsung-hdptx: Add HDMI 2.1 FRL support")
Fixes: 9d0ec51d7c ("phy: rockchip: samsung-hdptx: Add high color depth management")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-2-f998f2762d0f@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit f611da21d7a2732e1039c6a0f20389e6384478bb
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Fri Feb 27 22:48:45 2026 +0200
phy: rockchip: samsung-hdptx: Fix rate recalculation for high bpc
The PHY PLL can been programmed by an external component, e.g. the
bootloader, just before the recalc_rate() callback is invoked during
devm_clk_hw_register() in the probe path.
Therefore rk_hdptx_phy_clk_recalc_rate() finds the PLL enabled and
attempts to compute the clock rate, while making use of the bpc value
from the HDMI PHY configuration, which always defaults to 8 because
phy_configure() was not run at that point. As a consequence, the
(re)calculated rate is incorrect when the actual bpc was higher than 8.
Do not rely on any of the hdmi_cfg members when computing the clock rate
and, instead, read the required input data (i.e. bpc), directly from the
hardware registers.
Fixes: 3481fc04d9 ("phy: rockchip: samsung-hdptx: Compute clk rate from PLL config")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20260227-hdptx-clk-fixes-v1-1-f998f2762d0f@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit ec413ff687f5987f17cafd74f04a501f85ba8c31
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Mar 24 18:16:31 2026 +0100
usb: typec: tcpm: log when VDM AMS state machine is cancelled
Since commit 0bc3ee9288 ("usb: typec: tcpm: Properly interrupt VDM
AMS") the VDM AMS state machine is cancelled when a non-VDM message
arrives. Apparently Dell U2725QE displays potentially interrupt the
discover identity AMS to try a power role swap:
[ 4.341899] AMS POWER_NEGOTIATION finished
[ 4.341906] cc:=4
[ 4.353165] AMS DISCOVER_IDENTITY start
[ 4.353187] PD TX, header: 0x176f
[ 4.365820] PD TX complete, status: 0
[ 4.365885] PD RX, header: 0x24a [1]
[ 4.365899] AMS DISCOVER_IDENTITY finished
[ 4.365903] cc:=4
[ 4.376612] PD TX, header: 0x964
[ 4.481320] PD RX, header: 0x444f [1]
[ 4.481353] PD RX, header: 0x64a [1]
[ 4.481374] PD TX, header: 0x964
[ 4.492423] PD TX complete, status: 0
At this point the log stops without the discover identity being
completed successfully.
Apparently what happens is:
1. TCPM negotiated power as PD source
2. TCPM continues with identity discovery
3. Display asks for a power swap
4. TCPM stops state machine for identity discovery
5. TCPM rejects the power swap
6. Display sends identity discovery response
7. Display sends the power swap request once more
Note, that this does not always happen. There is a race condition and
sometimes the power swap request arrives before TCPM switches into the
DISCOVER_IDENTITY phase, which avoids the AMS interruption and then
things work as expected.
I tried adding logic to restart the discover identity state machine in
this case, which should be fine according to the specification as far
as I can tell. Unfortunately it does not help with the Dell U2725QE:
Once it runs into the above issue, the display seems to have messed up
its internal message buffer resulting in the display sending answers to
the previous message instead of the current one. Obviously no sensible
PD communication is sensible at this point.
Improve the situation a bit by at least giving a decent log entry.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 1c1260d067df5985713dd01db0c5b831563ad42d
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Mar 2 22:37:40 2026 +0100
usb: typec: tcpm: Also use SNK_WAIT_CAPABILITIES_TIMEOUT for vbus_never_low
Most USB-C ports on Linux devices are self-powered (i.e. because the
device offering a port has a battery or is powered from Mains using
a dedicated power-supply). If a port instead is the only power source
for a device things become fragile. SNK_WAIT_CAPABILITIES_TIMEOUT
has been introduced to better handle these devices as it tries to
avoid sending a hard reset. This further improves things by also
trying to avoid the soft reset as that is simply escalated into a
hard reset with some USB PD sources.
This (hopefully, testing is still ongoing) fixes the following issue,
which sometimes happens with the ROCK 5B from the Collabora LAVA
lab (used for the KernelCI project):
[ 16.330582] typec_fusb302 4-0022: pending state change SNK_WAIT_CAPABILITIES -> SNK_SOFT_RESET @ 310 ms [rev2 NONE_AMS]
[ 16.641651] typec_fusb302 4-0022: state change SNK_WAIT_CAPABILITIES -> SNK_SOFT_RESET [delayed 310 ms]
[ 16.642488] typec_fusb302 4-0022: AMS SOFT_RESET_AMS start
[ 16.642968] typec_fusb302 4-0022: state change SNK_SOFT_RESET -> AMS_START [rev2 SOFT_RESET_AMS]
[ 16.643741] typec_fusb302 4-0022: state change AMS_START -> SOFT_RESET_SEND [rev2 SOFT_RESET_AMS]
[ 16.644525] typec_fusb302 4-0022: PD TX, header: 0x4d
[ 16.647659] typec_fusb302 4-0022: sending PD message header: 4d
[ 16.648190] typec_fusb302 4-0022: sending PD message len: 0
[ 16.650521] typec_fusb302 4-0022: IRQ: 0x41, a: 0x00, b: 0x00, status0: 0x83
[ 16.651154] typec_fusb302 4-0022: IRQ: BC_LVL, handler pending
[ 16.653494] typec_fusb302 4-0022: IRQ: 0x41, a: 0x00, b: 0x00, status0: 0x83
[ 16.654120] typec_fusb302 4-0022: IRQ: BC_LVL, handler pending
[ 16.656454] typec_fusb302 4-0022: IRQ: 0x41, a: 0x10, b: 0x00, status0: 0x83
[ 16.657078] typec_fusb302 4-0022: IRQ: BC_LVL, handler pending
[ 16.657612] typec_fusb302 4-0022: IRQ: PD retry failed
[ 16.658073] typec_fusb302 4-0022: PD TX complete, status: 2
[ 16.658583] typec_fusb302 4-0022: state change SOFT_RESET_SEND -> HARD_RESET_SEND [rev2 SOFT_RESET_AMS]
[ 16.659411] typec_fusb302 4-0022: AMS SOFT_RESET_AMS finished
[ 16.659920] typec_fusb302 4-0022: Initiating hard-reset, which might result in machine power-loss.
[ 16.660705] typec_fusb302 4-0022: AMS HARD_RESET start
[ 16.661162] typec_fusb302 4-0022: PD TX, type: 0x5
[ 16.664334] typec_fusb302 4-0022: IRQ: 0x41, a: 0x08, b: 0x00, status0: 0x83
[ 16.664965] typec_fusb302 4-0022: IRQ: BC_LVL, handler pending
[ 16.665514] typec_fusb302 4-0022: IRQ: PD hardreset sent
[ 16.666783] typec_fusb302 4-0022: PD TX complete, status: 0
[ 16.667305] typec_fusb302 4-0022: state change HARD_RESET_SEND -> HARD_RESET_START [rev2 HARD_RESET]
[ 16.672730] typec_fusb302 4-0022: pd := off
[ 16.673103] typec_fusb302 4-0022: state change HARD_RESET_START -> SNK_HARD_RESET_SINK_OFF [rev2 HARD_RESET]
[ 16.673972] typec_fusb302 4-0022: vconn:=0
[ 16.674331] typec_fusb302 4-0022: vconn is already off
[ 16.674787] typec_fusb302 4-0022: Requesting mux state 1, usb-role 2, orientation 1
--- board reset ---
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit b1689d02129a5d50982855b964e3ff4c32eb55a5
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Feb 12 03:52:38 2026 +0100
usb: typec: tcpm: improve handling of DISCOVER_MODES failures
UGREEN USB-C Multifunction Adapter Model CM512 (AKA "Revodok 107")
exposes two SVIDs: 0xff01 (DP Alt Mode) and 0x1d5c. The DISCOVER_MODES
step succeeds for 0xff01 and gets a NAK for 0x1d5c. Currently this
results in DP Alt Mode not being registered either, since the modes
are only registered once all of them have been discovered. The NAK
results in the processing being stopped and thus no Alt modes being
registered.
Improve the situation by handling the NAK gracefully and continue
processing the other modes.
Before this change, the TCPM log ends like this:
(more log entries before this)
[ 5.028287] AMS DISCOVER_SVIDS finished
[ 5.028291] cc:=4
[ 5.040040] SVID 1: 0xff01
[ 5.040054] SVID 2: 0x1d5c
[ 5.040082] AMS DISCOVER_MODES start
[ 5.040096] PD TX, header: 0x1b6f
[ 5.050946] PD TX complete, status: 0
[ 5.059609] PD RX, header: 0x264f [1]
[ 5.059626] Rx VDM cmd 0xff018043 type 1 cmd 3 len 2
[ 5.059640] AMS DISCOVER_MODES finished
[ 5.059644] cc:=4
[ 5.069994] Alternate mode 0: SVID 0xff01, VDO 1: 0x000c0045
[ 5.070029] AMS DISCOVER_MODES start
[ 5.070043] PD TX, header: 0x1d6f
[ 5.081139] PD TX complete, status: 0
[ 5.087498] PD RX, header: 0x184f [1]
[ 5.087515] Rx VDM cmd 0x1d5c8083 type 2 cmd 3 len 1
[ 5.087529] AMS DISCOVER_MODES finished
[ 5.087534] cc:=4
(no further log entries after this point)
After this patch the TCPM log looks exactly the same, but then
continues like this:
[ 5.100222] Skip SVID 0x1d5c (failed to discover mode)
[ 5.101699] AMS DFP_TO_UFP_ENTER_MODE start
(log goes on as the system initializes DP AltMode)
Cc: stable@vger.kernel.org
Fixes: 41d9d75344 ("usb: typec: tcpm: add discover svids and discover modes support for sop'")
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit a8e3b58d851aef0b93d6a69186bb687b105381ef
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Mar 17 15:44:57 2026 +0100
[WIP] arm64: dts: rockchip: disable command queue engine for Sige5
The Sige5 board often runs into CQE errors, which make the boot
unreliable; disable support for it to get consistent results
until somebody found time to analyze the root cause.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 898a11b78ca8c19c70a2d8d4c9f4118f24ad2946
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Jan 29 23:57:28 2026 +0100
[RFC] drm/rockchip: vop2: Add clock rate mode check
The display might offer modes, which exceed the maximum clock rate of a
video output. This usually happens for displays that offer refresh rates
above 60 Hz. This results in no picture (or a broken one) being displayed
without manual intervention. Fix this by teaching the driver about the
maximum achievable clock rates for each video port.
The information about the maximum clock rates for each video channel and
the tip about multiple pixels being processed per clock were provided by
Andy Yan and roughly checked against the information available in the
datasheet (which specifies limits like "2560x1600@60Hz with 10-bit"
instead of a specific pixel rate).
For the video ports supporting a 600 MHz input clock, there is some
logic to handle up to 4 pixels in parallel when needed resulting in
the extra multiplier.
Suggested-by: Andy Yan <andy.yan@rock-chips.com>
Link: https://lore.kernel.org/linux-rockchip/1528d788.186b.19d08ed974c.Coremail.andyshrk@163.com/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 10dd8d955e043adc63ae4f6510e585589212b542
Author: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Date: Wed Mar 18 22:26:19 2026 +0300
media: synopsys: hdmirx: Fix HPD hold time
Increase time of holding HPD pin low by 50ms. This fixes EDID change not
detected by sink/display side.
Fixes: 7b59b132ad ("media: platform: synopsys: Add support for HDMI input driver")
Reported-by: Ross Cawston <ross@r-sc.ca>
Closes: https://lore.kernel.org/linux-rockchip/20260209061654.54757-1-ross@r-sc.ca/
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/r/20260318192619.3910060-1-dmitry.osipenko@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 4204337dbcced365e339cfea63256d79e82afa39
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Jan 22 14:57:54 2026 +0100
thermal/drivers/rockchip: Shut up eFuse prober defer warning
Shut up the following message printed at error level on ArmSom Sige5:
rockchip-thermal 2ae70000.tsadc: failed reading trim of sensor 0: -EPROBE_DEFER
Fixes: ae332ec000 ("thermal/drivers/rockchip: Support reading trim values from OTP")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 6979f84ff727e7954f279913dc8060585c79822e
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Tue Jan 20 21:44:26 2026 +0200
drm/rockchip: dw_hdmi_qp: Switch to drmm_encoder_init()
Simplify encoder initialization and cleanup by making use of
drmm_encoder_init(), which takes care of registering
drm_encoder_cleanup() with drmm_add_action().
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 5bbf288f2e4672d20e99977cf7f0ac5a31f537bc
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Jan 21 14:02:15 2026 +0200
drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()
Attempting to access driver data in the platform driver ->remove()
callback may lead to a null pointer dereference since there is no
guaranty that the component ->bind() callback invoking
platform_set_drvdata() was executed.
A common scenario is when Rockchip DRM driver didn't manage to run
component_bind_all() because of an (unrelated) error causing early
return from rockchip_drm_bind().
Drop the unnecessary call to platform_get_drvdata() and, instead,
reference the target device structure via platform_device.
Fixes: d68ba7bac9 ("drm/rockchip: Add RK3588 DPTX output support")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit b9c34c176363349c88a128d2446575962fea486e
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed Jan 21 12:29:32 2026 +0200
drm/rockchip: dw_dp: Switch to drmm_kzalloc()
Driver makes use of drmm_encoder_init() to initialize the encoder and
automatically handle the cleanup by registering drm_encoder_cleanup()
with drmm_add_action().
However, the internal structure containing the encoder part gets
allocated with devm_kzalloc(), which happens while component_bind_all()
is being called from Rockchip DRM driver. The component framework
further ensures it is deallocated as part of releasing all the resources
claimed during bind, which is triggered from component_unbind_all().
When the reference to the DRM device gets eventually dropped via
drm_dev_put() in rockchip_drm_unbind(), drmm_encoder_alloc_release()
attempts to access the now released encoder structure, leading to
use-after-free.
Ensure driver's internal structure is still reachable on encoder cleanup
by switching from a device-managed allocation to a drm-managed one.
Fixes: d68ba7bac9 ("drm/rockchip: Add RK3588 DPTX output support")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 24692ea723108be97c91f3e5ed5635e67262a917
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Jan 19 13:11:40 2026 +0100
mmc: sdhci-of-dwcmshc: Reduce clock reduction print level
The system gracefully handles not being able to reduce the clock
frequencies, so there is nothing to be fixed. Reduce the error
print to debug level to keep the error log nice and short with
important messages.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 38bfca3d1f17299dde3233b67b3c9f96b77e3a8f
Author: Shawn Lin <shawn.lin@rock-chips.com>
Date: Wed Dec 24 15:10:10 2025 +0800
phy: rockchip-snps-pcie3: Only check PHY1 status when using it
RK3588_LANE_AGGREGATION and RK3588_BIFURCATION_LANE_2_3 should be
used to check if it need to check PHY1 status. Because in other
cases, only PHY0 could show locked status.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/1766560210-100883-6-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 041db3eb5011ee398667cff1aa53b91a0be800ef
Author: Shawn Lin <shawn.lin@rock-chips.com>
Date: Wed Dec 24 15:10:09 2025 +0800
phy: rockchip-snps-pcie3: Check more sram init status for RK3588
All the lower 4 bits should be checked which shows the mpllx_state.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/1766560210-100883-5-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 4f9002ae4e1c3ddcbb2597d715890c2bf89e38be
Author: Shawn Lin <shawn.lin@rock-chips.com>
Date: Wed Dec 24 15:10:08 2025 +0800
phy: rockchip-snps-pcie3: Increase sram init timeout
Per massive test, 500us is not enough for all chips, increase it
to 20000us for worse case recommended.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/1766560210-100883-4-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 2bb63a9006e6c7897db18f13ace23ee9c1ae877a
Author: Shawn Lin <shawn.lin@rock-chips.com>
Date: Wed Dec 24 15:10:07 2025 +0800
phy: rockchip-snps-pcie3: Add phy_calibrate() support
Move calibration from phy_init() to phy_calibrate().
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/1766560210-100883-3-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit c91b5347993ee6a4cf840c556f5aecb5b9768e4e
Author: Shawn Lin <shawn.lin@rock-chips.com>
Date: Wed Dec 24 15:10:06 2025 +0800
PCI: dw-rockchip: Add phy_calibrate() to check PHY lock status
Current we keep controller in reset state when initializing PHY which
is the right thing to do. But this case, the PHY is also reset because
it refers to a signal from controller. Now we check PHY lock status
inside .phy_init() callback which may be bogus for certain type of PHY,
because of the fact above. Add phy_calibrate() to better check PHY lock
status if provided.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://patch.msgid.link/1766560210-100883-2-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 4a1e425dfe2f443204d5e4c1c5041359fb4d558b
Author: Andy Yan <andy.yan@rock-chips.com>
Date: Fri Jan 9 18:01:19 2026 +0800
[WIP] arm64: dts: rockchip: add USB-C DP AltMode for ArmSom Sige5
Enable USB-C DP AltMode for the ArmSom Sige5.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
This has two issues:
1. The USB-C hotplug detection does not yet work properly. I.e. even
after plugging in a device with DP AltMode, /sys/class/drm/card0-DP-1
stays at 'disconnected'. This is a problem I've already seen on the
Rock 5B, which needs further investigation.
2. The DT binding does not yet look good for upstream.
On the plus side there are no regressions and this results in probing
the DP driver, which means it is already good for regression testing.
Thus I am already adding this to our development branch.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 0f0cad601b7c744f9edb4fdaac7e23c74444208f
Author: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Date: Wed Apr 15 09:23:41 2026 +0200
arm64: defconfig: enable Verisilicon IOMMU for Rockchip RK3588
Enable Verisilicon IOMMU used by Rockchip RK3588 AV1 hardware codec.
This hardware block could be found in Radxa ROCK 5B board.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260415072349.44237-6-benjamin.gaignard@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit de254603a1d214c5c1468b345b93d57a2de0257f
Author: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Date: Wed Apr 15 09:23:40 2026 +0200
arm64: dts: rockchip: Add verisilicon IOMMU node on RK3588
Add the device tree node for the Verisilicon IOMMU present
in the RK3588 SoC.
This IOMMU handles address translation for the VPU hardware blocks.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Link: https://lore.kernel.org/r/20260415072349.44237-5-benjamin.gaignard@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 4092d8b05af0b0e1d2f56ca6b0d0d5b9b047c4f9
Author: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Date: Wed Apr 15 09:23:39 2026 +0200
iommu: Add verisilicon IOMMU driver
The Verisilicon IOMMU hardware block can be found in combination
with Verisilicon hardware video codecs (encoders or decoders) on
different SoCs.
Enable it will allow us to use non contiguous memory allocators
for Verisilicon video codecs.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Link: https://lore.kernel.org/r/20260415072349.44237-4-benjamin.gaignard@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit ca8da68b44dd83d17ddcf01400906eac46e6d1f4
Author: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Date: Wed Apr 15 09:23:38 2026 +0200
dt-bindings: iommu: verisilicon: Add binding for VSI IOMMU
Add a device tree binding for the Verisilicon (VSI) IOMMU.
This IOMMU sits in front of hardware encoder and decoder
blocks on SoCs using Verisilicon IP, such as the Rockchip RK3588.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20260415072349.44237-3-benjamin.gaignard@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 79a49b19d045eac9e6ef783d054504dc05dbc518
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Sat Jan 10 04:29:23 2026 +0100
arm64: defconfig: enable Rockchip VDEC
Enable the VDPU381/VDPU383 video decoder driver used for H.264 and H.265
decoding on Rockchip RK3588 and RK3576.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit bd24abee10c55c72ee3462747382c48bdd13eb0c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Wed Nov 5 18:44:09 2025 +0100
arm64: dts: rockchip: Enable ALDPS on both network interfaces of RK3576 EVB1
ALDPS reduces the power consumption while the network interfaces
are enabled, but no cable is plugged in. The datasheet specifies:
> Whole system power consumption in ALDPS low power mode (with PLL
> turned off) is 10.3mW for the RTL8211F(I), and 23.1 mW for the
> RTL8211FD(I).
For the 3.3V line supplying the network PHYs I see the following
power numbers:
* both interfaces down: 239mW
* both interface up, 1 cable plugged: 1005mW
* both interfaces up, 1 cable plugged after this series: 995mW
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 5073bfa555ee00ca61c46cec3471a2e099ef43a9
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Nov 6 16:21:05 2025 +0100
net: phy: realtek: re-init after reset
The reset in the resume function results in the custom configuration
being lost, which effectively renders the 'realtek,aldps-enable'
functionality useless. Fix this up by doing a re-init as necessary.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 0c35849bd66c15ad114ec6fa116cb5a1aea6f8b3
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Wed Oct 8 18:15:24 2025 +0200
arm64: dts: rockchip: add missing UFS regulators to ROCK 4D
Add missing regulator information for the ROCK 4D UFS interface.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit e13f052f7179a006a82a659c99c66f6e60f661a6
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Tue Sep 2 01:24:33 2025 +0200
[HACK] disable mipi hosts that are attached to csi dcphy
While the DSI part of the MIPI Combo DCPHYs is supported, the CSI
side should probably not be used right now.
TODO: figure out the best approach to deal with this situation.
commit 713cd9c0c22bd6dc5ae39e2b7bad0be8bf05c807
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Thu Sep 4 00:49:22 2025 +0200
[NOUPSTREAM] .gitlab-ci: enable innosilicon csi dphy driver
commit 3339b7879fb0a407cb7f28fb8f9b03c2a2f74dc2
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Feb 16 18:46:19 2026 +0100
[NOUPSTREAM] .gitlab-ci: enable imx415 image sensor driver
commit 9de0d5c7fa6432006320bf3a0ec0abb816a07590
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Feb 16 18:58:43 2026 +0100
[NOUPSTREAM] media: synopsys: csi2: enable interrupts and error reporting
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
commit 090a9fe4b497675aba69274fe5f08cb37fbf0027
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Sep 1 23:40:16 2025 +0200
arm64: dts: rockchip: add radxa camera 4k on rock 5b+ cam1
Add device tree overlay for the Radxa Camera 4K (featuring the
Sony IMX415 image sensor) to applied on the Radxa ROCK 5B+
CAM1 port.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
commit 278f1adf4928e23688575a3a51cfffc555869600
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Sep 1 23:40:15 2025 +0200
arm64: dts: rockchip: add radxa camera 4k on rock 5b+ cam0
Add device tree overlay for the Radxa Camera 4K (featuring the
Sony IMX415 image sensor) to applied on the Radxa ROCK 5B+
CAM0 port.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
commit e5f19a1e57c0293062e57cddf807da707ce2a3f8
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Sep 1 23:40:15 2025 +0200
arm64: dts: rockchip: use correct pinctrl for i2c3 on rock 5b family
Use the correct pinctrl for the I2C4 bus on both the Radxa ROCK 5B
family in their shared base dtsi.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
commit c1bae1c146d629505c2c1720fd9d07eb0de8a1ce
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Sep 1 23:40:15 2025 +0200
arm64: dts: rockchip: add vicap node to rk3588
Add the device tree node for the RK3588 Video Capture (VICAP) unit.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
commit 316848b4c8142c9b0ef72600ec0790eb527ede29
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Sep 1 23:40:15 2025 +0200
arm64: dts: rockchip: add mipi csi-2 receiver nodes to rk3588
Add the device tree nodes for the six MIPI CSI-2 Receiver units
of the RK3588.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
commit bb239c3c2e334ba71efa3538fce04e2aafc587c3
Author: Michael Riesch <michael.riesch@wolfvision.net>
Date: Mon Sep 1 23:40:15 2025 +0200
arm64: dts: rockchip: add mipi csi-2 receiver node to rk356x
Add the device tree node for the RK356x MIPI CSI-2 Receiver.
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
commit 18c7956ef71228adee9516725b753c7ecf01ae1c
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Feb 16 20:16:09 2026 +0100
media: dt-bindings: rockchip csi-2: Add RK3588 support
Add compatible for the RK3588 CSI-2 receiver, which is compatible
with the one used by RK3568.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
[Ported over from Michael's previous patch, rebased]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit be09614056dedea38f679ea91ebad90288e0020d
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Sep 1 23:40:14 2025 +0200
media: rockchip: rkcif: add support for rk3588 vicap
The RK3588 Video Capture (VICAP) unit features a Digital Video
Port (DVP) and six MIPI CSI-2 capture interfaces. Add initial
support for this variant to the rkcif driver and enable the
MIPI CSI-2 capture interfaces.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
commit 15b080c0735893d94cffb75a9d5af58b5cb19643
Author: Michael Riesch <michael.riesch@collabora.com>
Date: Mon Sep 1 23:40:13 2025 +0200
media: dt-bindings: add rockchip rk3588 vicap
Add documentation for the Rockchip RK3588 Video Capture (VICAP) unit.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
commit 94c3d717f2fc880f0a03a49fe050ca1dab29cc70
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Jul 28 16:58:21 2025 +0200
arm64: dts: rockchip: add USB-C DP AltMode for ROCK 5B family
Enable support for USB-C DP AltMode to the ROCK 5B/5B+/5T.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 3c4143eb002d7aca797341f985401c4530cc73c8
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Apr 24 13:43:09 2026 +0200
phy: rockchip: usbdp: Use guard functions for mutex
Convert the driver to use guard functions for mutex handling as
a small cleanup. There is a small functional change in the DP PHY
power up function, which no longer sleeps if the internal powerup
code returns an error. This is not a problem as the sleep is only
relevant for successful power-up.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 186aa4343a2d6ea1f713f038a08ab3f2e0501342
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Apr 24 12:45:50 2026 +0200
phy: rockchip: usbdp: Factor out lane_mux_sel setup
Avoid describing the USB+DP lane_mux_sel logic twice by introducing
a helper function to reduce code duplication.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 5f4d40a0434a13d62517f7b8368cc7f3bef4e020
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Apr 24 12:25:32 2026 +0200
phy: rockchip: usbdp: Re-init the PHY on orientation change
Changing the cable orientation reconfigures the lane muxing, which
requires re-initializing the PHY. Without this DP functionality
breaks, if the cable is re-plugged with swapped orientation.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 01a1a5020aa00455f7793bce41188cc1a091c537
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Apr 24 11:25:21 2026 +0200
phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit
Right now the mode_change property is set whenever the mode changes
between USB-only, DP-only and USB-DP. It is needed, because on any
mode change the PHY needs to be re-initialized. Apparently at least
DP also requires a re-init when the cable orientation is changed,
which is currently not being done (except when the orientation switch
also involves a mode change). Prepare for this by renaming mode_change
to phy_needs_reinit.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 42474d505cde68cd177fd6584b041a4f8d40115b
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Wed Mar 4 15:53:21 2026 +0100
phy: rockchip: usbdp: Drop DP HPD handling
Drop the HPD handling logic from the USBDP PHY. The registers involved
require the display controller power domain being enabled and thus the
HPD signal should be handled by the displayport controller itself.
Apart from that the HPD handling as it is done here is incorrect and
misses hotplug events happening after the USB-C connector (e.g. when
a USB-C to HDMI adapter is involved and the HDMI cable is replugged).
Proper USB-C DP HPD support requires some restructuring of the DP
controller driver, which will happen independent of this patch. The
mainline kernel does not yet support USB-C DP AltMode on RK3588 and
RK3576, so it is fine to drop this code without adding the counterpart
in the DRM in an atomic change.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit ed675fb530b07aaef8f5bff4242f5cb6d8feca6c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Mar 5 18:06:48 2026 +0100
phy: rockchip: usbdp: Register DP aux bridge
Add support to use USB-C connectors with the DP altmode helper code on
devicetree based platforms. To get this working there must be a DRM
bridge chain from the DisplayPort controller to the USB-C connector.
E.g. on Rockchip RK3576:
root@rk3576 # cat /sys/kernel/debug/dri/0/encoder-0/bridges
bridge[0]: dw_dp_bridge_funcs
refcount: 7
type: [10] DP
OF: /soc/dp@27e40000:rockchip,rk3576-dp
ops: [0x47] detect edid hpd
bridge[1]: drm_aux_bridge_funcs
refcount: 4
type: [0] Unknown
OF: /soc/phy@2b010000:rockchip,rk3576-usbdp-phy
ops: [0x0]
bridge[2]: drm_aux_hpd_bridge_funcs
refcount: 5
type: [10] DP
OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
ops: [0x4] hpd
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 9334d88f4ecd2995804ce65fccc570d54ec9a5aa
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Jan 29 15:24:20 2026 +0100
phy: rockchip: usbdp: Cleanup DP lane selection function
Use FIELD_PREP_WM16() helpers to simplify the DP lane selection
logic.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 96ea82154d8f04acec2700bc23d697de9e1db9c8
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Jan 29 15:15:23 2026 +0100
phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST
Cleanup code by replacing open-coded version of FIELD_PREP_WM16_CONST
with the existing helper macro.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 191524e960b707f39cc4a85aa7d0de3e9c4de5a5
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Jan 29 22:45:18 2026 +0100
phy: rockchip: usbdp: Rename DP lane functions
The common prefix for DisplayPort related functions is rk_udphy_dp_
(with a final _), so update the two DP lane functions to follow that
scheme.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit b8af8887b53f84f93365d97b4c40b68d4a7748ef
Author: Zhang Yubing <yubing.zhang@rock-chips.com>
Date: Thu Jan 29 13:04:47 2026 +0100
phy: rockchip: usbdp: Support single-lane DP
Implement support for using just a single DisplayPort line.
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 3cdee9fc930467a966a516d70ab4b65420a93634
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Jan 29 21:32:59 2026 +0100
phy: rockchip: usbdp: Add missing mode_change update
rk_udphy_set_typec_default_mapping() updates the available modes,
but does not set the mode_change as required. This results in
missing re-initialization and thus non-working DisplayPort.
Fix this issue by introducing a new helper to update the available
modes.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 04182a111b25ac2c1b15fecd7c6be954d1ae12ec
Author: William Wu <william.wu@rock-chips.com>
Date: Fri Jan 16 20:31:20 2026 +0100
phy: rockchip: usbdp: Fix LFPS detect threshold control
According to the LFPS Tx Low Power/LFPS Rx Detect Threshold [1],
the device under test(DUT) must not respond if LFPS below the
minimum LFPS Rx Detect Threshold 100mV. Test fail on Rockchip
platforms, because the default LFPS detect threshold is set to
65mV.
The USBDP PHY LFPS detect threshold voltage could be set to
30mV ~ 140mV, and since there could be 10-20% PVT variation,
we set LFPS detect threshold voltage to 110mV.
[1] https://compliance.usb.org/resources/LFPS_Rx_Tx_Low_Power_Compliance_Update_Rev5.pdf
Signed-off-by: William Wu <william.wu@rock-chips.com>
[Taken over from rockchip's kernel tree; the registers are not described
in the TRM]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 9f2191dcda36c7f3382ee7ac2c72ad0310c18446
Author: Frank Wang <frank.wang@rock-chips.com>
Date: Fri Jan 16 20:28:08 2026 +0100
phy: rockchip: usbdp: Amend SSC modulation deviation
Move SSC modulation deviation into private config of clock
- 24M: 0x00d4[5:0] = 0x30
- 26M: 0x00d4[5:0] = 0x33
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
[Taken over from rockchip's kernel tree; register 0x00d4 is not
described in the TRM]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit e0ac81b3f7b1f842b3aced86c0a6f73ac8288a8c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Feb 5 19:26:12 2026 +0100
phy: rockchip: usbdp: Keep clocks running on PHY re-init
When a mode change is required rk_udphy_power_on() disables
the clocks and then calls rk_udphy_setup(), which then enables
all the clocks again before continuing with rk_udphy_init().
Considering that rk_udphy_init() does assert the reset lines,
re-enabling the clocks is just delaying things. Avoid it by
directly calling rk_udphy_init().
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 263f8dbbddb62d8371bb73e2df10e69e0d556c6c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Feb 12 01:22:02 2026 +0100
phy: rockchip: usbdp: Do not loose USB3 PHY status
By default (i.e. without manually enabling runtime PM) DWC3 requests the
USB3 PHY once and keeps it enabled all the time. When DisplayPort is
being requested later on, a mode change is needed. This re-initializes
the PHY. During re-initialization the status variable has incorrectly
been cleared, which means the tracking information for USB3 ist lost.
This is not an immediate problem, since the DP side keeps the PHY
enabled. But once DP is toggled off, the whole PHY will be disabled.
This is a problem, because the USB side still needs it powered.
Fix things by not clearing the status flags.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 04c88cb5eecc9866e993abeb48e3009e042cd164
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Aug 22 18:49:35 2025 +0200
dt-bindings: phy: rockchip-usbdp: add improved ports scheme
Currently the Rockchip USBDP PHY is missing a documented port scheme.
Meanwhile upstream RK3588 DTS files are a bit messy and use different
port schemes. The upstream USBDP PHY Linux kernel driver does not yet
parse the ports at all and thus does not create any implicit ABI either.
But with the current mess it is not possible to properly support USB-C
DP AltMode. Thus this introduces a proper port scheme following roughly
the ports design of the Qualcomm QMP USB4-USB3-DP PHY controller binding
with a slight difference that there is an additional port for the
USB-C SBU port as the Rockchip USB-DP PHY also contains the SBU mux.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 98aa520fd663daa64c77c22e9c269f8bb102a152
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Nov 24 20:06:39 2025 +0100
[RFC] PCI: dw-rockchip: port some suspend code from vendor kernel
Rockchip's vendor kernel does these calls before starting the actual
process of going into L2 state. I'm not sure about the rationale,
hopefully Shawn can help out with that.
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 36afcd721a1b191ed8a2d259ec92ade054bcebf9
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Oct 20 20:49:34 2025 +0200
PCI: dw-rockchip: Add system PM support
Add system PM support for Rockchip PCIe Designware Controllers.
I've tested this on the Rockchip RK3576 EVB1, the Radxa ROCK 4D
and the ArmSom Sige5 boards.
While I haven't experienced any issues, most of my tests have been done
without any devices attached (i.e. default board without any extras), so
there _might_ still be some problems. As system suspend does not work at
all right now, I think it makes sense to get at least the basic
configurations working as soon as possible as it will allow us to catch
regressions by enabling system suspend in CI systems like KernelCI.
Co-developed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit d38728deb253e3a0aca62001a76dd773d2da9b33
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Oct 20 20:38:54 2025 +0200
PCI: dw-rockchip: Add pme_turn_off support
Prepare Rockchip PCIe controller for system suspend support by
adding the PME turn off operation.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 3993daab6c289aa20ed64fa9d7cb9e9a435da275
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Oct 20 20:30:11 2025 +0200
PCI: dw-rockchip: Add helper function for DDL indicator
Remove code duplication and improve readability by introducing a new
function to setup the DLL indicator.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 08ff4e25b00f0883736359217d46bd76f0c4e74a
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Oct 20 20:27:04 2025 +0200
PCI: dw-rockchip: Add helper function for controller mode
Remove code duplication and improve readability by introducing a new
function to setup the controller mode.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit e66eac33a631236dab81a613e9577d1e0a486b04
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Oct 20 20:21:02 2025 +0200
PCI: dw-rockchip: Add helper function for enhanced LTSSM control mode
Remove code duplication and improve readability by introducing a new
function to setup the enhanced LTSSM mode.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit f70c223c7fd37272d5fa9badcce49ad98186f7ea
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Oct 20 20:06:36 2025 +0200
PCI: dw-rockchip: Move devm_phy_get out of phy_init
By moving devm_phy_get() to the probe routine, rockchip_pcie_phy_init()
can be used to re-initialize the PCIe PHY, which is for example needed
after a system suspend/resume cycle.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 38a56c2e095adde3150aaeb1efff07287a7bffbe
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Mon Dec 22 20:25:56 2025 +0100
PCI: dw-rockchip: Restore vpcie3v3 regulator handle
This reverts c930b10f17 ("PCI: dw-rockchip: Simplify regulator setup with
devm_regulator_get_enable_optional()"), which nicely cleaned up the code.
The vpcie3v3 regulator handle is needed to disable the regulator during
system suspend (to be added in its own patch).
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 7ab21f73b129fe6564773698dac68475b6cd907a
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Nov 21 19:27:00 2025 +0100
PCI: dw-rockchip: Fix LTSSM set functions
Before the Rockchip PCIe driver has been switched over to the
FIELD_PREP_WM16 macro, PCIE_CLIENT_ENABLE_LTSSM and PCIE_CLIENT_DISABLE_LTSSM
were setting bits with a mask of 0xc = 0b1100, which means BIT 2 and BIT 3.
After the conversion it only sets bit 2, with bit 3 being handled by a
separate define named PCIE_CLIENT_LD_RQ_RST_GRT. Apparently the
conversion missed to make use of this new macros resulting in the third
bit not being set.
Fixes: 30e9195705 ("PCI: dw-rockchip: Switch to FIELD_PREP_WM16 macro")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 0dd81ef295b8e58679a8379dd801e714d4318b1f
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Jul 8 19:36:31 2025 +0200
arm64: dts: rockchip: use MAC TX delay for ROCK 4D
According to the Ethernet controller device tree binding "rgmii-id"
means, that the PCB does not have extra long lines to add the required
delays. This is indeed the case for the ROCK 4D.
The problem is, that the Rockchip MAC Linux driver interprets the
interface type differently and abuses the information to configure
RX and TX delays in the MAC using (vendor) properties 'rx_delay' and
'tx_delay'.
When Detlev Casanova upstreamed the ROCK 4D device tree, he used the
correct description for the board ("rgmii-id"). This results in no delays
being configured in the MAC. At the same time the PHY will provide
some delays.
This works to some degree, but is not a stable configuration. All five
ROCK 4D production boards, which have recently been added to the Collabora
LAVA lab for CI purposes have trouble with data not getting through
after a connection has been established.
Using the same delay setup as the vendor device tree fixes the
functionality (at the cost of not properly following the DT binding).
As we cannot fix the driver behavior for RK3576 (some other boards
already depend on this), let's update the ROCK 4D DT instead.
Cc: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit a623fe19b523bbbaebf4506649884c38ae56e6d1
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Jul 3 01:21:14 2025 +0200
net: phy: realtek: Reset after clock enable
On Radxa ROCK 4D boards we are seeing some issues with PHY detection and
stability (e.g. link loss or not capable of transceiving packages) after
new board revisions switched from a dedicated crystal to providing the
25 MHz PHY input clock from the SoC instead.
This board is using a RTL8211F PHY, which is connected to an always-on
regulator. Unfortunately the datasheet does not explicitly mention the
power-up sequence regarding the clock, but it seems to assume that the
clock is always-on (i.e. dedicated crystal).
By doing an explicit reset after enabling the clock, the issue on the
boards could no longer be observed.
Note, that the RK3576 SoC used by the ROCK 4D board does not yet
support system level PM, so the resume path has not been tested.
Cc: stable@vger.kernel.org
Fixes: 7300c9b574 ("net: phy: realtek: Add optional external PHY clock")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit ec25fb89245a7f1391040feb9aef3918356f3df5
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Date: Mon Jun 30 12:19:26 2025 +0200
arm64: dts: rockchip: add analog audio to ROCK 4D
The RADXA ROCK 4D, like many other Rockchip-based boards, uses an ES8388
analog audio codec. On the production version of the board, the codec's
LOUT1 and ROUT1 pins are tied to the headphone jack, whereas pins LOUT2
and ROUT2 lead to a non-populated speaker amplifier that itself leads to
a non-populated speaker jack. The schematic is still haunted by the
ghosts of those symbols, but it clearly marks them as "NC".
The 3.5mm TRRS jack has its microphone ring (and ground ring) wired to
the codec's LINPUT1 and RINPUT1 pins for differential signalling.
Furthermore, it uses the SoCs ADC to detect whether the inserted cable
is of headphones (i.e., no microphone), or a headset (i.e., with
microphone). The way this is done is that the ADC input taps the output
of a 100K/100K resistor divider that divides the microphone ring pin
that's pulled up to 3.3V.
There is no ADC level difference between a completely empty jack and one
with a set of headphones (i.e., ones that don't have a microphone)
connected. Consequently headphone insertion detection isn't something
that can be done.
Add the necessary codec and audio card nodes. The non-populated parts,
i.e. LOUT2 and ROUT2, are not modeled at all, as they are not present on
the hardware.
Also, add an adc-keys node for the headset detection, which uses an
input type of EV_SW with the SW_MICROPHONE_INSERT keycode. Below the
220mV pressed voltage level of our SW_MICROPHONE_INSERT switch, we also
define a button that emits a KEY_RESERVED code, which is there to model
this part of the voltage range as not just being extra legroom for the
button above it, but actually a state that is encountered in the real
world, and should be recognised as a valid state for the ADC range to be
in so that no "closer" ADC button is chosen.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250630-rock4d-audio-v1-3-0b3c8e8fda9c@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 4e20c247655d199720f078867a9ead45a6d575d0
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Date: Mon Jun 30 12:19:25 2025 +0200
Input: adc-keys - support types that aren't just keyboard keys
Instead of doing something like what gpio-keys is doing, adc-keys
hardcodes that all keycodes must be of type EV_KEY.
This limits the usefulness of adc-keys, and overcomplicates the code
with manual bit-setting logic.
Instead, refactor the code to read the linux,input-type fwnode property,
and get rid of the custom bit setting logic, replacing it with
input_set_capability instead. input_report_key is replaced with
input_event, which allows us to explicitly pass the type.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250630-rock4d-audio-v1-2-0b3c8e8fda9c@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit b8100ee0ac2e02f437fa5de79e190d77c4c84903
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Date: Mon Jun 30 12:19:24 2025 +0200
dt-bindings: input: adc-keys: allow linux,input-type property
adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid
property. This makes it impossible to model devices that have ADC inputs
that should generate switch events.
Add the property to the binding with the same default as gpio-keys.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250630-rock4d-audio-v1-1-0b3c8e8fda9c@collabora.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 743af0c14072ef8480aedbda981c0bc6411c05c8
Author: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Date: Tue Jun 10 16:07:09 2025 +0200
phy: rockchip: inno-usb2: add soft vbusvalid control
With USB type C connectors, the vbus detect pin of the OTG controller
attached to it is pulled high by a USB Type C controller chip such as
the fusb302. This means USB enumeration on Type-C ports never works, as
the vbus is always seen as high.
Rockchip added some GRF register flags to deal with this situation. The
RK3576 TRM calls these "soft_vbusvalid_bvalid" (con0 bit index 15) and
"soft_vbusvalid_bvalid_sel" (con0 bit index 14).
Downstream introduces a new vendor property which tells the USB 2 PHY
that it's connected to a type C port, but we can do better. Since in
such an arrangement, we'll have an OF graph connection from the USB
controller to the USB connector anyway, we can walk said OF graph and
check the connector's compatible to determine this without adding any
further vendor properties.
Do keep in mind that the usbdp PHY driver seemingly fiddles with these
register fields as well, but what it does doesn't appear to be enough
for us to get working USB enumeration, presumably because the whole
vbus_attach logic needs to be adjusted as well either way.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250610-rk3576-sige5-usb-v4-1-7e7f779619c1@collabora.com
Signed-off-by: Sebastian Reichel <sre@kernel.org>
commit d88c451faed6c30b1f0052f4595607a195b68b47
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Sat Mar 15 09:34:02 2025 +0100
arm64: dts: rockchip: enable camera I2C interfaces for ROCK 5B family
Any camera related IP of the RK3588 is not yet supported and the cameras
must be handled via overlays anyways, but it is sensible to expose the
related I2C interfaces by default. This allows using i2cdetect to
investigate anything connected to the CSI connectors right now. Since
the Rockchip I2C driver implements proper power management there are no
disadvantages, if nothing is connected to the port.
Note, that the second CSI port's I2C in the Rock 5B+ and Rock 5T reuse
I2C4, which is already used by fusb302 and thus already enabled.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 4fd30c13ea70f1551dbc3ed6c7afd0971a60dd4b
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Jul 29 18:21:03 2025 +0200
arm64: dts: rockchip: Fix USB-C description for RK3588 EVB1
Fix the USB-C connector description, so that it follows the binding:
port@0 is the high-speed lanes
port@1 is the super-speed lanes
port@2 is the SBU lanes
Right now the high-speed and super-speed links are swapped and
for the high-speed lanes the link points to the controller instead
of the PHY. I'm still investigating if this should be changed.
This also updates the port naming, so that it describes the hardware
instead of how the drivers are using the information. These are
effectively the same, but the DT should describe hardware and not
software.
Fixes: b37146b5a5 ("arm64: dts: rockchip: add USB3 to rk3588-evb1")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit c40e4ef22e39691fe9093fba44ba7c1860160843
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Nov 14 17:36:18 2024 +0100
drm/rockchip: vop2: Add core reset support
A previous from Detlev Casanova adds reset handling for the
video ports. This also resets the AHB and AXI interface when
the system binds the VOP2 controller.
This fixes issues when the bootloader (or a previously running
kernel when using kexec) left the VOP2 initialized to some degree.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit aef22911b6f8ebaca0bb9b4f8600571833b03ab5
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Nov 8 17:35:44 2024 +0100
arm64: dts: rockchip: rk3588-evb1: add DSI panel
The RK3588 EVB1 comes with a W552793DBA-V10 Touchscreen/Display
combination. It contains a Wanchanglong W552793BAA panel and a
Goodix GT1158 touchscreen. This adds the DT description of it.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit b5eb65d8425fe7061ef52bc9e1183472404648a9
Author: Detlev Casanova <detlev.casanova@collabora.com>
Date: Fri Nov 15 11:20:42 2024 -0500
arm64: dts: rockchip: Add VOP clock resets for rk3588s
This adds the needed clock resets for all rk3588(s) based SOCs.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
commit 77699dd4ddcfae718c01ac5d68f4635319588036
Author: Detlev Casanova <detlev.casanova@collabora.com>
Date: Fri Nov 15 11:20:41 2024 -0500
drm/rockchip: vop2: Add clock resets support
At the end of initialization, each VP clock needs to be reset before
they can be used.
Failing to do so can put the VOP in an undefined state where the
generated HDMI signal is either lost or not matching the selected mode.
This issue can be reproduced by switching modes multiple times.
Depending on the setup, after about 10 mode switches, the signal will be
lost and the value in register 0x890 (VSYNCWIDTH + VFRONT) will take the value
`0x0000018c`.
That makes VSYNCWIDTH=0, which is wrong.
Adding the clock resets after the VOP configuration fixes the issue.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
commit 120a2f380d859e26eff88143db712764ccc0b5fd
Author: Detlev Casanova <detlev.casanova@collabora.com>
Date: Fri Nov 15 11:20:40 2024 -0500
dt-bindings: display: vop2: Add VP clock resets
Add the documentation for VOP2 video ports reset clocks.
One reset can be set per video port.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
commit 77f3334e52ddac21d328255d56603c29f3ef53dc
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Thu Jul 25 18:12:24 2024 +0200
mfd: rk8xx: Fix shutdown handler
When I converted rk808 to device managed resources I converted the rk808
specific pm_power_off handler to devm_register_sys_off_handler() using
SYS_OFF_MODE_POWER_OFF_PREPARE, which is allowed to sleep. I did this
because the driver's poweroff function makes use of regmap and the backend
of that might sleep.
But the PMIC poweroff function will kill off the board power and the
kernel does some extra steps after the prepare handler. Thus the prepare
handler should not be used for the PMIC's poweroff routine. Instead the
normal SYS_OFF_MODE_POWER_OFF phase should be used. The old pm_power_off
method is also being called from there, so this would have been a
cleaner conversion anyways.
But it still makes sense to investigate the sleep handling and check
if there are any issues. Apparently the Rockchip and Meson I2C drivers
(the only platforms using the PMICs handled by this driver) both have
support for atomic transfers and thus may be called from the atomic
poweroff context.
Things are different on the SPI side. That is so far only used by rk806
and that one is only used by Rockchip RK3588. Unfortunately the Rockchip
SPI driver does not support atomic transfers. That means this change will
introduce an error splash directly before doing the final power off on all
upstream supported RK3588 boards:
[ 13.761353] ------------[ cut here ]------------
[ 13.761764] Voluntary context switch within RCU read-side critical section!
[ 13.761776] WARNING: CPU: 0 PID: 1 at kernel/rcu/tree_plugin.h:330 rcu_note_context_switch+0x3ac/0x404
[ 13.763219] Modules linked in:
[ 13.763498] CPU: 0 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.10.0-12284-g2818a9a19514 #1499
[ 13.764297] Hardware name: Rockchip RK3588 EVB1 V10 Board (DT)
[ 13.764812] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 13.765427] pc : rcu_note_context_switch+0x3ac/0x404
[ 13.765871] lr : rcu_note_context_switch+0x3ac/0x404
[ 13.766314] sp : ffff800084f4b5b0
[ 13.766609] x29: ffff800084f4b5b0 x28: ffff00040139b800 x27: 00007dfb4439ae80
[ 13.767245] x26: ffff00040139bc80 x25: 0000000000000000 x24: ffff800082118470
[ 13.767880] x23: 0000000000000000 x22: ffff000400300000 x21: ffff000400300000
[ 13.768515] x20: ffff800083a9d600 x19: ffff0004fee48600 x18: fffffffffffed448
[ 13.769151] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000048
[ 13.769787] x14: fffffffffffed490 x13: ffff80008473b3c0 x12: 0000000000000900
[ 13.770421] x11: 0000000000000300 x10: ffff800084797bc0 x9 : ffff80008473b3c0
[ 13.771057] x8 : 00000000ffffefff x7 : ffff8000847933c0 x6 : 0000000000000300
[ 13.771692] x5 : 0000000000000301 x4 : 40000000fffff300 x3 : 0000000000000000
[ 13.772328] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000400300000
[ 13.772964] Call trace:
[ 13.773184] rcu_note_context_switch+0x3ac/0x404
[ 13.773598] __schedule+0x94/0xb0c
[ 13.773907] schedule+0x34/0x104
[ 13.774198] schedule_timeout+0x84/0xfc
[ 13.774544] wait_for_completion_timeout+0x78/0x14c
[ 13.774980] spi_transfer_one_message+0x588/0x690
[ 13.775403] __spi_pump_transfer_message+0x19c/0x4ec
[ 13.775846] __spi_sync+0x2a8/0x3c4
[ 13.776161] spi_write_then_read+0x120/0x208
[ 13.776543] rk806_spi_bus_read+0x54/0x88
[ 13.776905] _regmap_raw_read+0xec/0x16c
[ 13.777257] _regmap_bus_read+0x44/0x7c
[ 13.777601] _regmap_read+0x60/0xd8
[ 13.777915] _regmap_update_bits+0xf4/0x13c
[ 13.778289] regmap_update_bits_base+0x64/0x98
[ 13.778686] rk808_power_off+0x70/0xfc
[ 13.779024] sys_off_notify+0x40/0x6c
[ 13.779356] atomic_notifier_call_chain+0x60/0x90
[ 13.779776] do_kernel_power_off+0x54/0x6c
[ 13.780146] machine_power_off+0x18/0x24
[ 13.780499] kernel_power_off+0x70/0x7c
[ 13.780845] __do_sys_reboot+0x210/0x270
[ 13.781198] __arm64_sys_reboot+0x24/0x30
[ 13.781558] invoke_syscall+0x48/0x10c
[ 13.781897] el0_svc_common+0x3c/0xe8
[ 13.782228] do_el0_svc+0x20/0x2c
[ 13.782528] el0_svc+0x34/0xd8
[ 13.782806] el0t_64_sync_handler+0x120/0x12c
[ 13.783197] el0t_64_sync+0x190/0x194
[ 13.783527] ---[ end trace 0000000000000000 ]---
The board will shutdown nevertheless, since this also re-enables
interrupts. A proper fix for this requires changes to the core SPI
subsystem and will be done as a follow-up series.
Note, that this patch also fixes a problem for the Asus C201. Without
the function being registered as a proper shutdown handler the syscall
for poweroff exits early and does not even call the shutdown prepare
handler. This in turn means the system can no longer poweroff properly
since my original change.
Fixes: 4fec8a5a85 ("mfd: rk808: Convert to device managed resources")
Cc: stable@vger.kernel.org
Reported-by: Urja <urja@urja.dev>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit bc811d3dd074d4d9da611e219be4f4925c427e25
Author: Carsten Haitzler (Rasterman) <raster@rasterman.com>
Date: Tue Feb 6 10:12:54 2024 +0000
arm64: dts: rockchip: Slow down EMMC a bit to keep IO stable
This drops to hs200 mode and 150Mhz as this is actually stable across
eMMC modules. There exist some that are incompatible at higher rates
with the rk3588 and to avoid your filesystem corrupting due to IO
errors, be more conservative and reduce the max. speed.
Signed-off-by: Carsten Haitzler <raster@rasterman.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit e5b7ef9cd29f261d4ee6cb629f2ec0562ef222b7
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Jan 2 09:39:11 2024 +0100
arm64: dts: rockchip: rk3588-evb1: improve PCIe ethernet pin muxing
Also describe wake signal PCIe pinmux for the onboard LAN card.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 10ab07cc795e206ffe7eeddb0fb4520a9f5348cf
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Jan 2 09:35:43 2024 +0100
arm64: dts: rockchip: rk3588-evb1: add bluetooth rfkill
Add rfkill support for bluetooth. Bluetooth support itself is still
missing, but this ensures bluetooth can be powered off properly.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 338d48263a0b3ccfb28aacbd48ad01af51adcf45
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Oct 24 18:09:57 2023 +0200
clk: composite: replace open-coded abs_diff()
Replace the open coded abs_diff() with the existing helper function.
Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 57b769f2f14ee28e98df3a2cb9e2070417b9f937
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Oct 24 16:13:50 2023 +0200
clk: divider: Fix divisor masking on 64 bit platforms
The clock framework handles clock rates as "unsigned long", so u32 on
32-bit architectures and u64 on 64-bit architectures.
The current code casts the dividend to u64 on 32-bit to avoid a
potential overflow. For example DIV_ROUND_UP(3000000000, 1500000000)
= (3.0G + 1.5G - 1) / 1.5G = = OVERFLOW / 1.5G, which has been
introduced in commit 9556f9dad8 ("clk: divider: handle integer overflow
when dividing large clock rates").
On 64 bit platforms this masks the divisor, so that only the lower
32 bit are used. Thus requesting a frequency >= 4.3GHz results
in incorrect values. For example requesting 4300000000 (4.3 GHz) will
effectively request ca. 5 MHz. Requesting clk_round_rate(clk, ULONG_MAX)
is a bit of a special case, since that still returns correct values as
long as the parent clock is below 8.5 GHz.
Fix this by switching to DIV_ROUND_UP_NO_OVERFLOW, which cannot
overflow. This avoids any requirements on the arguments (except
that divisor should not be 0 obviously).
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit f2368880e49cc610a605df05f6d7d8a8acd73f8b
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Oct 24 16:09:35 2023 +0200
math.h: add DIV_ROUND_UP_NO_OVERFLOW
Add a new DIV_ROUND_UP helper, which cannot overflow when
big numbers are being used.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 14650d48053d6190faa0d7071edb144c7aa109a2
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Jul 1 22:58:37 2025 +0200
[DEBUG] usb: typec: fusb302: also log to dmesg
Also log to normal dmesg to assist debugging hard reset issues.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 98677c6ca842c4e6377ac36791f5c20154580bf3
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Apr 4 20:04:49 2025 +0200
[DEBUG] usb: typec: tcpm: also log to dmesg
Also log to normal dmesg to assist debugging hard reset issues.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit d78f38c48e571ab4de355a168ea7c2f04c89494d
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Fri Apr 17 23:05:36 2026 +0200
[CI] explicitly catch USB-C hard-reset errors
The hub providing power to the ROCK 5Bs is tends to hang, so that it no
longer responds to PD messages. At some point the TCPM requests a hard
reset, which results in a board reset due to power-loss. This in turn
results in a failed test. Add explicit error detection for this to
simplify root cause analysis of failed tests.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit 73643a830841fdec0b2d421c1e68cb8be032bfef
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Date: Tue Aug 5 16:39:38 2025 +0200
[CI] skip flakey H264 tests
Do not run flakey H.264 tests for now to have stable CI results until
the root cause has been identified and fixed.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
commit a2e36d1d7817913f38bc8df7b9c7f4086f69767b
Author: Christopher Obbard <chris.obbard@collabora.com>
Date: Mon Feb 20 16:59:04 2023 +0000
[NOUPSTREAM] Add GitLab CI support
Add CI support. This will do the following:
1. Run dt_binding_check to make sure no major flaws were introduced in
the DT bindings
2. Run dtbs_check, for Rock 5A, Rock 5B and EVB1. If warnings are
generated the CI will report that as warning
3. Build a Kernel .deb package
4. Generate a test job for LAVA and run it
Co-developed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Co-developed-by: Sjoerd Simons <sjoerd@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>
Linux kernel
============
The Linux kernel is the core of any Linux operating system. It manages hardware,
system resources, and provides the fundamental services for all other software.
Quick Start
-----------
* Report a bug: See Documentation/admin-guide/reporting-issues.rst
* Get the latest kernel: https://kernel.org
* Build the kernel: See Documentation/admin-guide/quickly-build-trimmed-linux.rst
* Join the community: https://lore.kernel.org/
Essential Documentation
-----------------------
All users should be familiar with:
* Building requirements: Documentation/process/changes.rst
* Code of Conduct: Documentation/process/code-of-conduct.rst
* License: See COPYING
Documentation can be built with make htmldocs or viewed online at:
https://www.kernel.org/doc/html/latest/
Who Are You?
============
Find your role below:
* New Kernel Developer - Getting started with kernel development
* Academic Researcher - Studying kernel internals and architecture
* Security Expert - Hardening and vulnerability analysis
* Backport/Maintenance Engineer - Maintaining stable kernels
* System Administrator - Configuring and troubleshooting
* Maintainer - Leading subsystems and reviewing patches
* Hardware Vendor - Writing drivers for new hardware
* Distribution Maintainer - Packaging kernels for distros
* AI Coding Assistant - LLMs and AI-powered development tools
For Specific Users
==================
New Kernel Developer
--------------------
Welcome! Start your kernel development journey here:
* Getting Started: Documentation/process/development-process.rst
* Your First Patch: Documentation/process/submitting-patches.rst
* Coding Style: Documentation/process/coding-style.rst
* Build System: Documentation/kbuild/index.rst
* Development Tools: Documentation/dev-tools/index.rst
* Kernel Hacking Guide: Documentation/kernel-hacking/hacking.rst
* Core APIs: Documentation/core-api/index.rst
Academic Researcher
-------------------
Explore the kernel's architecture and internals:
* Researcher Guidelines: Documentation/process/researcher-guidelines.rst
* Memory Management: Documentation/mm/index.rst
* Scheduler: Documentation/scheduler/index.rst
* Networking Stack: Documentation/networking/index.rst
* Filesystems: Documentation/filesystems/index.rst
* RCU (Read-Copy Update): Documentation/RCU/index.rst
* Locking Primitives: Documentation/locking/index.rst
* Power Management: Documentation/power/index.rst
Security Expert
---------------
Security documentation and hardening guides:
* Security Documentation: Documentation/security/index.rst
* LSM Development: Documentation/security/lsm-development.rst
* Self Protection: Documentation/security/self-protection.rst
* Reporting Vulnerabilities: Documentation/process/security-bugs.rst
* CVE Procedures: Documentation/process/cve.rst
* Embargoed Hardware Issues: Documentation/process/embargoed-hardware-issues.rst
* Security Features: Documentation/userspace-api/seccomp_filter.rst
Backport/Maintenance Engineer
-----------------------------
Maintain and stabilize kernel versions:
* Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst
* Backporting Guide: Documentation/process/backporting.rst
* Applying Patches: Documentation/process/applying-patches.rst
* Subsystem Profile: Documentation/maintainer/maintainer-entry-profile.rst
* Git for Maintainers: Documentation/maintainer/configure-git.rst
System Administrator
--------------------
Configure, tune, and troubleshoot Linux systems:
* Admin Guide: Documentation/admin-guide/index.rst
* Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst
* Sysctl Tuning: Documentation/admin-guide/sysctl/index.rst
* Tracing/Debugging: Documentation/trace/index.rst
* Performance Security: Documentation/admin-guide/perf-security.rst
* Hardware Monitoring: Documentation/hwmon/index.rst
Maintainer
----------
Lead kernel subsystems and manage contributions:
* Maintainer Handbook: Documentation/maintainer/index.rst
* Pull Requests: Documentation/maintainer/pull-requests.rst
* Managing Patches: Documentation/maintainer/modifying-patches.rst
* Rebasing and Merging: Documentation/maintainer/rebasing-and-merging.rst
* Development Process: Documentation/process/maintainer-handbooks.rst
* Maintainer Entry Profile: Documentation/maintainer/maintainer-entry-profile.rst
* Git Configuration: Documentation/maintainer/configure-git.rst
Hardware Vendor
---------------
Write drivers and support new hardware:
* Driver API Guide: Documentation/driver-api/index.rst
* Driver Model: Documentation/driver-api/driver-model/driver.rst
* Device Drivers: Documentation/driver-api/infrastructure.rst
* Bus Types: Documentation/driver-api/driver-model/bus.rst
* Device Tree Bindings: Documentation/devicetree/bindings/
* Power Management: Documentation/driver-api/pm/index.rst
* DMA API: Documentation/core-api/dma-api.rst
Distribution Maintainer
-----------------------
Package and distribute the kernel:
* Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst
* ABI Documentation: Documentation/ABI/README
* Kernel Configuration: Documentation/kbuild/kconfig.rst
* Module Signing: Documentation/admin-guide/module-signing.rst
* Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst
* Tainted Kernels: Documentation/admin-guide/tainted-kernels.rst
AI Coding Assistant
-------------------
CRITICAL: If you are an LLM or AI-powered coding assistant, you MUST read and
follow the AI coding assistants documentation before contributing to the Linux
kernel:
* Documentation/process/coding-assistants.rst
This documentation contains essential requirements about licensing, attribution,
and the Developer Certificate of Origin that all AI tools must comply with.
Communication and Support
=========================
* Mailing Lists: https://lore.kernel.org/
* IRC: #kernelnewbies on irc.oftc.net
* Bugzilla: https://bugzilla.kernel.org/
* MAINTAINERS file: Lists subsystem maintainers and mailing lists
* Email Clients: Documentation/process/email-clients.rst
Bill Sideris
efc27e06d5