linux-kernel - Re: [PATCH 1/7] drm/tidss: Add CRTC mode

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: <20240521-lean-dragon-of-perfection-043fad@houat>
Date: Tue, 21 May 2024 15:18:36 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Aradhya Bhatia <a-bhatia1@...com>
Cc: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, 
	Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Robert Foss <rfoss@...nel.org>, Laurent Pinchart <Laurent.pinchart@...asonboard.com>, 
	Jonas Karlman <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Jyri Sarha <jyri.sarha@....fi>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, 
	Daniel Vetter <daniel@...ll.ch>, DRI Development List <dri-devel@...ts.freedesktop.org>, 
	Linux Kernel List <linux-kernel@...r.kernel.org>, Sam Ravnborg <sam@...nborg.org>, 
	Thierry Reding <treding@...dia.com>, Kieran Bingham <kieran.bingham+renesas@...asonboard.com>, 
	Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>, 
	Praneeth Bajjuri <praneeth@...com>, Udit Kumar <u-kumar1@...com>, Devarsh Thakkar <devarsht@...com>, 
	Jayesh Choudhary <j-choudhary@...com>, Jai Luthra <j-luthra@...com>
Subject: Re: [PATCH 1/7] drm/tidss: Add CRTC mode_fixup

On Thu, May 16, 2024 at 04:33:40PM GMT, Aradhya Bhatia wrote:
> Hi Maxime,
> 
> Thank you for reviewing the patches.
> 
> On 16/05/24 13:40, Maxime Ripard wrote:
> > Hi,
> > 
> > On Sat, May 11, 2024 at 09:00:45PM +0530, Aradhya Bhatia wrote:
> >> Add support for mode_fixup for the tidss CRTC.
> >>
> >> Some bridges like the cdns-dsi consume the crtc_* timing parameters for
> >> programming the blanking values. Allow for the normal timing parameters
> >> to get copied to crtc_* timing params.
> >>
> >> Signed-off-by: Aradhya Bhatia <a-bhatia1@...com>
> >> ---
> >>  drivers/gpu/drm/tidss/tidss_crtc.c | 11 +++++++++++
> >>  1 file changed, 11 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c
> >> index 94f8e3178df5..797ef53d9ad2 100644
> >> --- a/drivers/gpu/drm/tidss/tidss_crtc.c
> >> +++ b/drivers/gpu/drm/tidss/tidss_crtc.c
> >> @@ -309,12 +309,23 @@ enum drm_mode_status tidss_crtc_mode_valid(struct drm_crtc *crtc,
> >>  	return dispc_vp_mode_valid(tidss->dispc, tcrtc->hw_videoport, mode);
> >>  }
> >>  
> >> +static
> >> +bool tidss_crtc_mode_fixup(struct drm_crtc *crtc,
> >> +			   const struct drm_display_mode *mode,
> >> +			   struct drm_display_mode *adjusted_mode)
> >> +{
> >> +	drm_mode_set_crtcinfo(adjusted_mode, 0);
> >> +
> >> +	return true;
> >> +}
> >> +
> >>  static const struct drm_crtc_helper_funcs tidss_crtc_helper_funcs = {
> >>  	.atomic_check = tidss_crtc_atomic_check,
> >>  	.atomic_flush = tidss_crtc_atomic_flush,
> >>  	.atomic_enable = tidss_crtc_atomic_enable,
> >>  	.atomic_disable = tidss_crtc_atomic_disable,
> >>  
> >> +	.mode_fixup = tidss_crtc_mode_fixup,
> >>  	.mode_valid = tidss_crtc_mode_valid,
> >>  };
> > 
> > mode_fixup is deprecated for atomic drivers, so the solution must be
> > different there.
> > 
> > It's also not clear to me how it could change anything there:
> > drm_mode_set_crtcinfo with no flags will make crtc_* field exactly
> > identical to their !crtc counterparts.
> >
> 
> I checked the flag options. There isn't any flag required. The only
> reason to add this call is because cdns-dsi strictly requires the crtc_*
> fields to be populated during the bridge enable.
> 
> Secondly, if mode_fixup is deprecated, I think the crtc_atomic_check
> would be the next best place to add this call.

That would be better, yes, but we shouldn't even have to do that in the
first place. AFAIK all the path that create a drm_display_mode will call
drm_mode_set_crtcinfo on it to fill those fields. So if they are missing
somewhere, that's what the actual bug is, not something we should work
around of at the driver level.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)