This is the replacement for the RFC sent on 2026-10-22, which Taniya Das
correctly rejected: the MDSS block resets do not belong to the clock driver,
and resetting the whole block from dispcc probe would also take the PLLs down.
The problem the RFC tried to solve is real. On a board that enters Linux
with the display block already running, the kernel later sees command DMA
timeouts on the first DPMS enable and the panel never comes up; resetting the
MDSS blocks before touching them fixes it, and it has to happen before the
first commit, not in the middle of one.
This version therefore leaves the clock driver completely alone and moves
the resets to the display side, where they already live:
1/3 describes three block resets on the MDSS node instead of one. minItems
is 1, so every existing device tree that describes only the core reset
keeps validating; the example in the SM8750 binding now shows all three.
2/3 makes msm_mdss_reset() drive the whole array described in DT instead of
the first reset only. Platforms with a single reset behave exactly as
before, which is why this is not gated on any board compatible.
3/3 describes the three resets on the SM8750 MDSS node.
The reset is still held for 20 ms, the value upstream uses today, and the
PLLs are untouched by it, so no flicker from reconfiguring them.
Scope and status, stated plainly: this was built with W=1 and the binding was
validated with dt-doc-validate, dt-validate (both with three resets and with
one, to prove the old shapes still pass) and dt-check-style. It has *not*
yet been run on hardware, and the ordering is the one point where I would
value review most: in the arm that was measured as good, the reset happened
before the dispcc PLLs were programmed, whereas here it happens after, because
mdss consumes dispcc clocks and must probe later. I could not find a way to
get the display side to probe earlier without reintroducing the clock-driver
problem, and resetting only the block resets (not the PLLs themselves) is the
part that I believe makes the later point harmless. If you think that is not
sound, say so and I will drop it rather than argue.
Only SM8750 is changed here; sc7180/sc7280/sc8280xp/sm6350/sm8150 also have an
RSCC reset described in their dtsi, and sm8650 has the same three, but whether
they want the same treatment is for their maintainers to decide.
Qianhui Xu (3):
dt-bindings: display: msm: mdss-common: describe additional block
resets
drm/msm/mdss: reset all block resets described in DT
arm64: dts: qcom: sm8750: describe all MDSS block resets
.../bindings/display/msm/mdss-common.yaml | 5 ++++-
.../bindings/display/msm/qcom,sm8750-mdss.yaml | 4 +++-
arch/arm64/boot/dts/qcom/sm8750.dtsi | 4 +++-
drivers/gpu/drm/msm/msm_mdss.c | 15 ++++++++++++---
4 files changed, 22 insertions(+), 6 deletions(-)
--
2.53.0
