From: Liu Ying <victor.liu@nxp.com>
To: Alexander Stein <alexander.stein@ew.tq-group.com>,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: marex@denx.de, stefan@agner.ch, airlied@gmail.com,
daniel@ffwll.ch, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, linux-imx@nxp.com,
krzysztof.kozlowski@linaro.org, LW@karo-electronics.de
Subject: Re: [PATCH v3 4/6] drm: lcdif: Check consistent bus format and flags across first bridges
Date: Wed, 15 Feb 2023 16:40:48 +0800 [thread overview]
Message-ID: <8ccdba247e1b3649af382b77039afa9d19bf81e2.camel@nxp.com> (raw)
In-Reply-To: <2148647.Icojqenx9y@steina-w>
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@nxp.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
next prev parent reply other threads:[~2023-02-15 8:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-13 8:56 [PATCH v3 0/6] drm: lcdif: Add i.MX93 LCDIF support Liu Ying
2023-02-13 8:56 ` [PATCH v3 1/6] dt-bindings: " Liu Ying
2023-02-15 7:26 ` Alexander Stein
2023-02-15 7:49 ` Liu Ying
2023-02-15 8:44 ` Alexander Stein
2023-02-13 8:56 ` [PATCH v3 2/6] drm: lcdif: Drop unnecessary NULL pointer check on lcdif->bridge Liu Ying
2023-02-14 13:42 ` Alexander Stein
2023-02-13 8:56 ` [PATCH v3 3/6] drm: lcdif: Determine bus format and flags in ->atomic_check() Liu Ying
2023-02-14 14:12 ` Alexander Stein
2023-02-14 14:16 ` Ville Syrjälä
2023-02-15 3:44 ` Liu Ying
2023-02-15 8:27 ` Alexander Stein
2023-02-13 8:56 ` [PATCH v3 4/6] drm: lcdif: Check consistent bus format and flags across first bridges Liu Ying
2023-02-15 7:55 ` Alexander Stein
2023-02-15 8:40 ` Liu Ying [this message]
2023-02-13 8:56 ` [PATCH v3 5/6] drm: lcdif: Add multiple encoders and first bridges support Liu Ying
2023-02-15 7:54 ` Alexander Stein
2023-02-15 8:52 ` Liu Ying
2023-02-13 8:56 ` [PATCH v3 6/6] drm: lcdif: Add i.MX93 LCDIF compatible string Liu Ying
2023-02-15 7:55 ` Alexander Stein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ccdba247e1b3649af382b77039afa9d19bf81e2.camel@nxp.com \
--to=victor.liu@nxp.com \
--cc=LW@karo-electronics.de \
--cc=airlied@gmail.com \
--cc=alexander.stein@ew.tq-group.com \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marex@denx.de \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=stefan@agner.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).