linux-kernel - Re: [PATCH v2 7/9] drm/bridge: cdns-dsi: Support atomic bridge APIs

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] [day] [month] [year] [list]

Message-ID: <hofs67cb2oylwdkuazdzukswbi5t7v7e6frhv52zaz4p2lgwro@vr3muasxj4mw>
Date: Mon, 10 Jun 2024 20:37:10 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.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>, Maxime Ripard <mripard@...nel.org>, 
	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 v2 7/9] drm/bridge: cdns-dsi: Support atomic bridge APIs

On Mon, Jun 10, 2024 at 06:02:41PM +0530, Aradhya Bhatia wrote:
> Hi Dmitry,
> 
> Thank you for reviewing the patches.
> 
> On 31/05/24 04:51, Dmitry Baryshkov wrote:
> > On Thu, May 30, 2024 at 03:06:19PM +0530, Aradhya Bhatia wrote:
> >> Change the existing (and deprecated) bridge hooks, to the bridge
> >> atomic APIs.
> >>
> >> Add drm helpers for duplicate_state, destroy_state, and bridge_reset
> >> bridge hooks.
> >>
> >> Further add support for the input format negotiation hook.
> >>
> >> Signed-off-by: Aradhya Bhatia <a-bhatia1@...com>
> >> ---
> >>  .../gpu/drm/bridge/cadence/cdns-dsi-core.c    | 70 ++++++++++++++++---
> >>  1 file changed, 62 insertions(+), 8 deletions(-)
> > 
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > 
> > Minor nit below.
> > 
> >>
> >> @@ -915,13 +920,62 @@ static void cdns_dsi_bridge_pre_enable(struct drm_bridge *bridge)
> >>  	cdns_dsi_hs_init(dsi);
> >>  }
> >>  
> >> +static u32 *cdns_dsi_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
> >> +					       struct drm_bridge_state *bridge_state,
> >> +					       struct drm_crtc_state *crtc_state,
> >> +					       struct drm_connector_state *conn_state,
> >> +					       u32 output_fmt,
> >> +					       unsigned int *num_input_fmts)
> >> +{
> > 
> > This code below looks pretty generic. Would be logical to extract it to
> > a helper and allow it to be used by other DSI host bridges?
> 
> I agree, it would indeed make sense.
> 
> I just tried to make a helper function that could directly be passed to
> the drm_bridge_funcs list - like we do with
> "drm_atomic_helper_bridge_propagate_bus_fmt". This would have been ideal
> in my opinion.
> 
> But, that doesn't seem possible today. The parameter "output_fmt"
> doesn't describe any of the DSI pixel formats from "enum
> mipi_dsi_pixel_format", which is what's required to ascertain the input
> bus format for dsi hosts. Neither do the drm_bridge{_state} help with
> that.
> 
> For now, I am thinking to just add a common function that accepts the
> dsi bus output format and returns the corresponding input bus format.
> With this, every dsi host will still need to implement their own
> get_input_fmt hook and call that function.
> 
> If you had something else in mind, do let me know! =)

No, the code that you have described looks pretty good. Please proceed
with the implementation!

> 
> Regards
> Aradhya
> 
> > 
> >> +	struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
> >> +	struct cdns_dsi *dsi = input_to_dsi(input);
> >> +	struct cdns_dsi_output *output = &dsi->output;
> >> +	u32 *input_fmts;
> >> +
> >> +	*num_input_fmts = 0;
> >> +
> >> +	input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
> >> +	if (!input_fmts)
> >> +		return NULL;
> >> +
> >> +	switch (output->dev->format) {
> >> +	case MIPI_DSI_FMT_RGB888:
> >> +		input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> >> +		break;
> >> +
> >> +	case MIPI_DSI_FMT_RGB666:
> >> +		input_fmts[0] = MEDIA_BUS_FMT_RGB666_1X24_CPADHI;
> >> +		break;
> >> +
> >> +	case MIPI_DSI_FMT_RGB666_PACKED:
> >> +		input_fmts[0] = MEDIA_BUS_FMT_RGB666_1X18;
> >> +		break;
> >> +
> >> +	case MIPI_DSI_FMT_RGB565:
> >> +		input_fmts[0] = MEDIA_BUS_FMT_RGB565_1X16;
> >> +		break;
> >> +
> >> +	default:
> >> +		/* Unsupported DSI Format */
> >> +		return NULL;
> >> +	}
> >> +
> >> +	*num_input_fmts = 1;
> >> +
> >> +	return input_fmts;
> >> +}
> >> +
> > 

-- 
With best wishes
Dmitry