Hi Piotr,
On Thu, 25 Jul 2024 at 20:06, Piotr Zalewski <pZ010001011111@xxxxxxxxx> wrote:
> I based my patch on how gamma LUT is handled in VOP. There, in atomic
> enable, gamma LUT write takes places at the end too, after the mutex was
> already first-time unlocked. I understand the concept of DRM atomic state
> updates and what you wrote makes sense.
Yeah, no problem - the old VOP1 code is clearly incorrect here. I'm
glad you can improve VOP2. :)
> static void vop2_dither_setup(struct drm_crtc *crtc, u32 *dsp_ctrl)
> @@ -2152,6 +2127,9 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
>
> vop2_post_config(crtc);
>
> + if (crtc->state->gamma_lut)
> + vop2_crtc_gamma_set(vop2, crtc, old_state, &dsp_ctrl);
I think this call should be unconditional, so that we correctly
program LUT_DIS if there is no LUT set up during enable.
> @@ -2599,8 +2575,17 @@ static void vop2_crtc_atomic_begin(struct drm_crtc *crtc,
> vop2_setup_alpha(vp);
> vop2_setup_dly_for_windows(vop2);
>
> - if (crtc_state->color_mgmt_changed && !crtc_state->active_changed)
> - vop2_crtc_gamma_set(vop2, crtc, old_crtc_state);
> + if (crtc_state->color_mgmt_changed && !crtc_state->active_changed) {
> + u32 dsp_ctrl = vop2_vp_read(vp, RK3568_VP_DSP_CTRL);;
> +
> + vop2_lock(vop2);
> +
> + vop2_crtc_gamma_set(vop2, crtc, old_crtc_state, &dsp_ctrl);
> +
> + vop2_vp_write(vp, RK3568_VP_DSP_CTRL, dsp_ctrl);
> + vop2_cfg_done(vp);
> + vop2_unlock(vop2);
> + }
Calling lock/set/write/done/unlock here seems like an anti-pattern;
the cfg_done is already written in atomic_flush, so at least that part
is not necessary.
On platforms like RK3588, it looks like the new LUT can just be
written directly from atomic_begin without needing to program
DSP_CTRL, take locks, or synchronise against anything, so that should
be an easy straight-line path.
On platforms like RK3568, it would probably be better to set
mode_changed when the colour management configuration changes. That
will give you a good point to synchronise the cross-VOP dependencies
(i.e. claim or release the shared LUT when it is being
enabled/disabled), and also a hint to userspace that it is not going
to be a seamless transition as the LUT is disabled, programmed, then
re-enabled.
I think this would end up in a net reduction of LoC as well as a net
reduction of code weirdness.
Cheers,
Daniel
