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

Message-ID: <a78d5ddf-38d8-4b54-a9b3-7a8745d3b537@ti.com>
Date: Mon, 10 Jun 2024 18:02:41 +0530
From: Aradhya Bhatia <a-bhatia1@...com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
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

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! =)

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;
>> +}
>> +
>