linux-kernel - Re: [PATCH v3] rockchip/drm: vop2: add support for gamma LUT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPj87rOM=j0zmuWL9frGKV1xzPbJrk=Q9ip7F_HAPYnbCqPouw@mail.gmail.com>
Date: Fri, 26 Jul 2024 12:31:34 +0100
From: Daniel Stone <daniel@...ishbar.org>
To: Piotr Zalewski <pZ010001011111@...ton.me>
Cc: "airlied@...il.com" <airlied@...il.com>, "andy.yan@...k-chips.com" <andy.yan@...k-chips.com>, 
	"daniel@...ll.ch" <daniel@...ll.ch>, 
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, "heiko@...ech.de" <heiko@...ech.de>, 
	"hjc@...k-chips.com" <hjc@...k-chips.com>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-rockchip@...ts.infradead.org" <linux-rockchip@...ts.infradead.org>, 
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>, 
	"mripard@...nel.org" <mripard@...nel.org>, "tzimmermann@...e.de" <tzimmermann@...e.de>
Subject: Re: [PATCH v3] rockchip/drm: vop2: add support for gamma LUT

Hi Piotr,

On Thu, 25 Jul 2024 at 20:06, Piotr Zalewski <pZ010001011111@...ton.me> 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