Re: [PATCH v5 09/10] drm/msm/dpu: only reassign resources when the encoder is reprogrammed

From: Konrad Dybcio

Date: Mon Oct 26 2026 - 05:20:21 EST


On 10/24/26 1:25 AM, Dmitry Baryshkov wrote:
> Running kms_plane@pixel-format-source-clamping causes SMMU faults
> (fsr=0x402, iova=0x0001fb00): it sets a CTM, after which the display stops
> updating, so the test times out waiting for a CRC and the pipe is still
> fetching the framebuffers released when the runner kills it.
>
> dpu_crtc_atomic_check() reassigns resources whenever color_mgmt_changed is
> set, but crtc_set_mode() only calls ->atomic_mode_set() for mode_changed or
> connectors_changed. A colour management update therefore re-reserves and
> can get a different CTL: cstate->mixers[].lm_ctl points at the new one
> while phys->hw_ctl still points at the old, so the flush mask is
> accumulated on one and triggered on the other. CTL_FLUSH is written with
> zero, so the pipe is not reprogrammed again until the next modeset.
>
> Reassign only when the encoder is reprogrammed too. Enabling colour
> management still needs a modeset, as that is when DSPPs join the topology,
> so ask for one in dpu_crtc_check_mode_changed() and only there. Drop the
> msm_atomic_check() hack, which forced a modeset both ways, ignored
> GAMMA_LUT and overrode allow_modeset behind userspace's back.
>
> Fixes: 39a750ff5fc9 ("drm/msm/dpu: Add DSPP GC driver to provide GAMMA_LUT DRM property")
> Assisted-by: LLM
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx>
> ---

LLM is curious whether turning off CTM/GAMMA should trigger a modeset too.
My hunch is "yes"

Konrad