[<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