From: Abhinav Kumar <quic_abhinavk@quicinc.com> To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>, Kuogee Hsieh <quic_khsieh@quicinc.com> Cc: Stephen Boyd <swboyd@chromium.org>, David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>, <linux-arm-msm@vger.kernel.org>, <dri-devel@lists.freedesktop.org>, <freedreno@lists.freedesktop.org> Subject: Re: [RFC PATCH v2 3/5] drm/msm/dp: support finding next bridge even for DP interfaces Date: Thu, 24 Feb 2022 12:13:50 -0800 [thread overview] Message-ID: <9348028b-a898-428e-a855-9df18e577328@quicinc.com> (raw) In-Reply-To: <20220211224006.1797846-4-dmitry.baryshkov@linaro.org> On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote: > It is possible to supply display-connector (bridge) to the DP interface, > add support for parsing it too. > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > drivers/gpu/drm/msm/dp/dp_parser.c | 19 ++++++++++++------- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c > index 901d7967370f..1056b8d5755b 100644 > --- a/drivers/gpu/drm/msm/dp/dp_parser.c > +++ b/drivers/gpu/drm/msm/dp/dp_parser.c > @@ -301,17 +301,22 @@ static int dp_parser_parse(struct dp_parser *parser, int connector_type) > return rc; > > /* > - * Currently we support external bridges only for eDP connectors. > + * External bridges are mandatory for eDP interfaces: one has to > + * provide at least an eDP panel (which gets wrapped into panel-bridge). > * > - * No external bridges are expected for the DisplayPort connector, > - * it is physically present in a form of a DP or USB-C connector. > + * For DisplayPort interfaces external bridges are optional, so > + * silently ignore an error if one is not present (-ENODEV). > */ > - if (connector_type == DRM_MODE_CONNECTOR_eDP) { > - rc = dp_parser_find_next_bridge(parser); > - if (rc) { > - DRM_ERROR("DP: failed to find next bridge\n"); > + rc = dp_parser_find_next_bridge(parser); > + if (rc == -ENODEV) { > + if (connector_type == DRM_MODE_CONNECTOR_eDP) { > + DRM_ERROR("eDP: next bridge is not present\n"); > return rc; > } > + } else if (rc) { > + if (rc != -EPROBE_DEFER) > + DRM_ERROR("DP: error parsing next bridge: %d\n", rc); > + return rc; > } How is this silently ignoring? static int dp_display_bind(struct device *dev, struct device *master, void *data) { int rc = 0; struct dp_display_private *dp = dev_get_dp_display_private(dev); struct msm_drm_private *priv = dev_get_drvdata(master); struct drm_device *drm = priv->dev; dp->dp_display.drm_dev = drm; priv->dp[dp->id] = &dp->dp_display; rc = dp->parser->parse(dp->parser, dp->dp_display.connector_type); if (rc) { DRM_ERROR("device tree parsing failed\n"); goto end; } dp_display_bind will still fail if a bridge is not found. If supplying a bridge is optional even this should succeed right? > > /* Map the corresponding regulator information according to
WARNING: multiple messages have this Message-ID (diff)
From: Abhinav Kumar <quic_abhinavk@quicinc.com> To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>, Kuogee Hsieh <quic_khsieh@quicinc.com> Cc: David Airlie <airlied@linux.ie>, linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, Stephen Boyd <swboyd@chromium.org>, freedreno@lists.freedesktop.org Subject: Re: [RFC PATCH v2 3/5] drm/msm/dp: support finding next bridge even for DP interfaces Date: Thu, 24 Feb 2022 12:13:50 -0800 [thread overview] Message-ID: <9348028b-a898-428e-a855-9df18e577328@quicinc.com> (raw) In-Reply-To: <20220211224006.1797846-4-dmitry.baryshkov@linaro.org> On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote: > It is possible to supply display-connector (bridge) to the DP interface, > add support for parsing it too. > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > drivers/gpu/drm/msm/dp/dp_parser.c | 19 ++++++++++++------- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c > index 901d7967370f..1056b8d5755b 100644 > --- a/drivers/gpu/drm/msm/dp/dp_parser.c > +++ b/drivers/gpu/drm/msm/dp/dp_parser.c > @@ -301,17 +301,22 @@ static int dp_parser_parse(struct dp_parser *parser, int connector_type) > return rc; > > /* > - * Currently we support external bridges only for eDP connectors. > + * External bridges are mandatory for eDP interfaces: one has to > + * provide at least an eDP panel (which gets wrapped into panel-bridge). > * > - * No external bridges are expected for the DisplayPort connector, > - * it is physically present in a form of a DP or USB-C connector. > + * For DisplayPort interfaces external bridges are optional, so > + * silently ignore an error if one is not present (-ENODEV). > */ > - if (connector_type == DRM_MODE_CONNECTOR_eDP) { > - rc = dp_parser_find_next_bridge(parser); > - if (rc) { > - DRM_ERROR("DP: failed to find next bridge\n"); > + rc = dp_parser_find_next_bridge(parser); > + if (rc == -ENODEV) { > + if (connector_type == DRM_MODE_CONNECTOR_eDP) { > + DRM_ERROR("eDP: next bridge is not present\n"); > return rc; > } > + } else if (rc) { > + if (rc != -EPROBE_DEFER) > + DRM_ERROR("DP: error parsing next bridge: %d\n", rc); > + return rc; > } How is this silently ignoring? static int dp_display_bind(struct device *dev, struct device *master, void *data) { int rc = 0; struct dp_display_private *dp = dev_get_dp_display_private(dev); struct msm_drm_private *priv = dev_get_drvdata(master); struct drm_device *drm = priv->dev; dp->dp_display.drm_dev = drm; priv->dp[dp->id] = &dp->dp_display; rc = dp->parser->parse(dp->parser, dp->dp_display.connector_type); if (rc) { DRM_ERROR("device tree parsing failed\n"); goto end; } dp_display_bind will still fail if a bridge is not found. If supplying a bridge is optional even this should succeed right? > > /* Map the corresponding regulator information according to
next prev parent reply other threads:[~2022-02-24 20:13 UTC|newest] Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-11 22:40 [RFC PATCH v2 0/5] Simplify and correct msm/dp bridge implementation Dmitry Baryshkov 2022-02-11 22:40 ` Dmitry Baryshkov 2022-02-11 22:40 ` [RFC PATCH v2 1/5] drm/msm/dp: fix panel bridge attachment Dmitry Baryshkov 2022-02-11 22:40 ` Dmitry Baryshkov 2022-02-18 21:14 ` Kuogee Hsieh 2022-02-18 21:14 ` Kuogee Hsieh 2022-02-18 23:56 ` Stephen Boyd 2022-02-18 23:56 ` Stephen Boyd 2022-02-19 2:26 ` Dmitry Baryshkov 2022-02-19 2:26 ` Dmitry Baryshkov 2022-02-24 18:25 ` [Freedreno] " Abhinav Kumar 2022-02-24 18:25 ` Abhinav Kumar 2022-02-24 20:41 ` Dmitry Baryshkov 2022-02-24 20:41 ` Dmitry Baryshkov 2022-02-25 2:01 ` Abhinav Kumar 2022-02-25 2:01 ` Abhinav Kumar 2022-02-25 4:22 ` Dmitry Baryshkov 2022-02-25 4:22 ` Dmitry Baryshkov 2022-02-25 4:45 ` Abhinav Kumar 2022-02-25 4:45 ` Abhinav Kumar 2022-02-25 9:04 ` Dmitry Baryshkov 2022-02-25 9:04 ` Dmitry Baryshkov 2022-02-25 17:11 ` Abhinav Kumar 2022-02-25 17:11 ` Abhinav Kumar 2022-02-25 17:25 ` Dmitry Baryshkov 2022-02-25 17:25 ` Dmitry Baryshkov 2022-02-11 22:40 ` [RFC PATCH v2 2/5] drm/msm/dp: support attaching bridges to the DP encoder Dmitry Baryshkov 2022-02-11 22:40 ` Dmitry Baryshkov 2022-02-18 21:28 ` Kuogee Hsieh 2022-02-18 21:28 ` Kuogee Hsieh 2022-02-18 21:31 ` Dmitry Baryshkov 2022-02-18 21:31 ` Dmitry Baryshkov 2022-02-18 23:38 ` Stephen Boyd 2022-02-18 23:38 ` Stephen Boyd 2022-02-23 17:47 ` Kuogee Hsieh 2022-02-23 17:47 ` Kuogee Hsieh 2022-02-24 19:56 ` Abhinav Kumar 2022-02-24 19:56 ` Abhinav Kumar 2022-02-11 22:40 ` [RFC PATCH v2 3/5] drm/msm/dp: support finding next bridge even for DP interfaces Dmitry Baryshkov 2022-02-11 22:40 ` Dmitry Baryshkov 2022-02-18 21:29 ` Kuogee Hsieh 2022-02-18 21:29 ` Kuogee Hsieh 2022-02-19 0:34 ` Stephen Boyd 2022-02-19 0:34 ` Stephen Boyd 2022-02-24 20:13 ` Abhinav Kumar [this message] 2022-02-24 20:13 ` Abhinav Kumar 2022-02-24 20:49 ` Dmitry Baryshkov 2022-02-24 20:49 ` Dmitry Baryshkov 2022-02-24 21:09 ` Abhinav Kumar 2022-02-24 21:09 ` Abhinav Kumar 2022-02-11 22:40 ` [RFC PATCH v2 4/5] drm/msm/dp: replace dp_connector with drm_bridge_connector Dmitry Baryshkov 2022-02-11 22:40 ` Dmitry Baryshkov 2022-02-18 21:31 ` Kuogee Hsieh 2022-02-18 21:31 ` Kuogee Hsieh 2022-02-18 21:52 ` Dmitry Baryshkov 2022-02-18 21:52 ` Dmitry Baryshkov 2022-02-18 22:32 ` Dmitry Baryshkov 2022-02-18 22:32 ` Dmitry Baryshkov 2022-02-19 0:55 ` Stephen Boyd 2022-02-19 0:55 ` Stephen Boyd 2022-02-19 2:22 ` Dmitry Baryshkov 2022-02-19 2:22 ` Dmitry Baryshkov 2022-02-23 17:21 ` Kuogee Hsieh 2022-02-23 17:21 ` Kuogee Hsieh 2022-02-23 18:22 ` Dmitry Baryshkov 2022-02-23 18:22 ` Dmitry Baryshkov 2022-02-23 18:27 ` Kuogee Hsieh 2022-02-23 18:27 ` Kuogee Hsieh 2022-02-23 18:45 ` Dmitry Baryshkov 2022-02-23 18:45 ` Dmitry Baryshkov 2022-02-23 21:33 ` Stephen Boyd 2022-02-23 21:33 ` Stephen Boyd 2022-02-24 0:40 ` Kuogee Hsieh 2022-02-24 0:40 ` Kuogee Hsieh [not found] ` <64a5ae1a-df65-b0a5-5d0d-cfb1d4da3bf7@quicinc.com> 2022-03-16 16:45 ` Sankeerth Billakanti (QUIC) 2022-03-16 16:45 ` Sankeerth Billakanti (QUIC) 2022-04-14 20:17 ` Abhinav Kumar 2022-04-14 20:17 ` Abhinav Kumar 2022-02-11 22:40 ` [RFC PATCH v2 5/5] drm/msm/dp: remove extra wrappers and public functions Dmitry Baryshkov 2022-02-11 22:40 ` Dmitry Baryshkov [not found] ` <26549f55-6195-a7ec-5896-de5f986ad716@quicinc.com> 2022-03-16 16:31 ` Sankeerth Billakanti (QUIC) 2022-03-16 16:31 ` Sankeerth Billakanti (QUIC) 2022-04-14 20:17 ` Abhinav Kumar 2022-04-14 20:17 ` Abhinav Kumar
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=9348028b-a898-428e-a855-9df18e577328@quicinc.com \ --to=quic_abhinavk@quicinc.com \ --cc=airlied@linux.ie \ --cc=bjorn.andersson@linaro.org \ --cc=daniel@ffwll.ch \ --cc=dmitry.baryshkov@linaro.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=quic_khsieh@quicinc.com \ --cc=robdclark@gmail.com \ --cc=sean@poorly.run \ --cc=swboyd@chromium.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.