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: <8ccdba247e1b3649af382b77039afa9d19bf81e2.camel@nxp.com>
Date:   Wed, 15 Feb 2023 16:40:48 +0800
From:   Liu Ying <victor.liu@....com>
To:     Alexander Stein <alexander.stein@...tq-group.com>,
        dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Cc:     marex@...x.de, stefan@...er.ch, airlied@...il.com, daniel@...ll.ch,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
        festevam@...il.com, linux-imx@....com,
        krzysztof.kozlowski@...aro.org, LW@...o-electronics.de
Subject: Re: [PATCH v3 4/6] drm: lcdif: Check consistent bus format and
 flags across first bridges

On Wed, 2023-02-15 at 08:55 +0100, Alexander Stein wrote:
> Hi Liu,

Hi Alexander,

> 
> thanks for the update.

Thanks for the review.

> 
> Am Montag, 13. Februar 2023, 09:56:10 CET schrieb Liu Ying:
> > The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> > simultaneously.  Check bus format and flags across first bridges in
> > ->atomic_check() to ensure they are consistent.  This is a
> > preparation
> > for adding i.MX93 LCDIF support.
> > 
> > Signed-off-by: Liu Ying <victor.liu@....com>
> > ---
> > v2->v3:
> > * No change.
> > 
> > v1->v2:
> > * Split from patch 2/2 in v1. (Marek, Alexander)
> > * Drop a comment about bridge input bus format from
> > lcdif_crtc_atomic_check().
> > 
> >  drivers/gpu/drm/mxsfb/lcdif_drv.c |  2 -
> >  drivers/gpu/drm/mxsfb/lcdif_drv.h |  1 -
> >  drivers/gpu/drm/mxsfb/lcdif_kms.c | 76 ++++++++++++++++++++++-----
> > ----
> >  3 files changed, 55 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> > b/drivers/gpu/drm/mxsfb/lcdif_drv.c index
> > cc2ceb301b96..b5b9a8e273c6 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> > @@ -52,8 +52,6 @@ static int lcdif_attach_bridge(struct
> > lcdif_drm_private
> > *lcdif) if (ret)
> >  		return dev_err_probe(drm->dev, ret, "Failed to attach 
> 
> bridge\n");
> > 
> > -	lcdif->bridge = bridge;
> > -
> >  	return 0;
> >  }
> > 
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.h
> > b/drivers/gpu/drm/mxsfb/lcdif_drv.h index
> > 6cdba6e20c02..aa6d099a1897 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_drv.h
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.h
> > @@ -31,7 +31,6 @@ struct lcdif_drm_private {
> >  	} planes;
> >  	struct drm_crtc			crtc;
> >  	struct drm_encoder		encoder;
> > -	struct drm_bridge		*bridge;
> >  };
> > 
> >  static inline struct lcdif_drm_private *
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > b/drivers/gpu/drm/mxsfb/lcdif_kms.c index
> > 294cecdf5439..4ea3d2b2cf61 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > @@ -17,6 +17,7 @@
> >  #include <drm/drm_atomic_helper.h>
> >  #include <drm/drm_bridge.h>
> >  #include <drm/drm_color_mgmt.h>
> > +#include <drm/drm_connector.h>
> >  #include <drm/drm_crtc.h>
> >  #include <drm/drm_encoder.h>
> >  #include <drm/drm_fb_dma_helper.h>
> > @@ -424,15 +425,19 @@ static int lcdif_crtc_atomic_check(struct
> > drm_crtc
> > *crtc, struct drm_atomic_state *state)
> >  {
> >  	struct drm_device *drm = crtc->dev;
> > -	struct lcdif_drm_private *lcdif = to_lcdif_drm_private(drm);
> >  	struct drm_crtc_state *crtc_state = 
> 
> drm_atomic_get_new_crtc_state(state,
> >  								
> 
> 	  crtc);
> >  	struct lcdif_crtc_state *lcdif_crtc_state =
> > to_lcdif_crtc_state(crtc_state); bool has_primary = crtc_state-
> > >plane_mask
> > &
> >  			   drm_plane_mask(crtc->primary);
> > +	struct drm_connector_state *connector_state;
> > +	struct drm_connector *connector;
> > +	struct drm_encoder *encoder;
> >  	struct drm_bridge_state *bridge_state;
> > -	struct drm_bridge *bridge = lcdif->bridge;
> > -	int ret;
> > +	struct drm_bridge *bridge;
> > +	u32 bus_format, bus_flags;
> > +	bool format_set = false, flags_set = false;
> > +	int ret, i;
> > 
> >  	/* The primary plane has to be enabled when the CRTC is active.
> > */
> >  	if (crtc_state->active && !has_primary)
> > @@ -442,26 +447,55 @@ static int lcdif_crtc_atomic_check(struct
> > drm_crtc
> > *crtc, if (ret)
> >  		return ret;
> > 
> > -	bridge_state = drm_atomic_get_new_bridge_state(state, bridge);
> > -	if (!bridge_state)
> > -		lcdif_crtc_state->bus_format = MEDIA_BUS_FMT_FIXED;
> > -	else
> > -		lcdif_crtc_state->bus_format = bridge_state-
> > input_bus_cfg.format;
> > -
> > -	if (lcdif_crtc_state->bus_format == MEDIA_BUS_FMT_FIXED) {
> > -		dev_warn_once(drm->dev,
> > -			      "Bridge does not provide bus format, 
> 
> assuming
> > MEDIA_BUS_FMT_RGB888_1X24.\n" -			      "Please
> > fix 
> 
> bridge driver by
> > handling atomic_get_input_bus_fmts.\n"); -		lcdif_crtc_stat
> > e-
> > bus_format =
> > MEDIA_BUS_FMT_RGB888_1X24;
> > +	/* Try to find consistent bus format and flags across first
> > bridges. 
> 
> */
> > +	for_each_new_connector_in_state(state, connector,
> > connector_state, 
> 
> i) {
> > +		if (!connector_state->crtc)
> > +			continue;
> > +
> > +		encoder = connector_state->best_encoder;
> > +
> > +		bridge = drm_bridge_chain_get_first_bridge(encoder);
> > +		if (!bridge)
> > +			continue;
> > +
> > +		bridge_state = drm_atomic_get_new_bridge_state(state, 
> 
> bridge);
> > +		if (!bridge_state)
> > +			bus_format = MEDIA_BUS_FMT_FIXED;
> > +		else
> > +			bus_format = bridge_state-
> > >input_bus_cfg.format;
> > +
> > +		if (bus_format == MEDIA_BUS_FMT_FIXED) {
> > +			dev_warn(drm->dev,
> > +				 "[ENCODER:%d:%s]'s bridge does not 
> 
> provide bus format, assuming
> > MEDIA_BUS_FMT_RGB888_1X24.\n" +				 
> 
> "Please fix bridge driver by handling
> > atomic_get_input_bus_fmts.\n", +				 
> 
> encoder->base.id, encoder->name);
> > +			bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> > +		}
> > +
> > +		if (!format_set) {
> > +			lcdif_crtc_state->bus_format = bus_format;
> > +			format_set = true;
> > +		} else if (lcdif_crtc_state->bus_format != bus_format)
> > {
> > +			DRM_DEV_DEBUG_DRIVER(drm->dev, "inconsistent
> > bus 
> 
> format\n");
> 
> Is there another way to know the actual reason the atomic_check
> fails? Maybe 
> this is worthy to be an error message instead.

No, I don't think there is any other way.  -EINVAL is what we can tell 
userspace about the reason why the atomic check fails, plus the debug
message if userspace wants to look at it.

Error message is not appropriate here.  Userspace supposes to try
another combination of output modes and hopes it passes atomic check.
We don't want to give too much error message to userspace.

Regards,
Liu Ying

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ