All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abhinav Kumar <quic_abhinavk@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: <freedreno@lists.freedesktop.org>,
	David Airlie <airlied@linux.ie>, <linux-arm-msm@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>,
	"Kuogee Hsieh" <quic_khsieh@quicinc.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Stephen Boyd <swboyd@chromium.org>, Sean Paul <sean@poorly.run>
Subject: Re: [RFC PATCH v2 3/5] drm/msm/dp: support finding next bridge even for DP interfaces
Date: Thu, 24 Feb 2022 13:09:34 -0800	[thread overview]
Message-ID: <06f7d17b-3614-d3bb-87db-611e6a4c4ba5@quicinc.com> (raw)
In-Reply-To: <CAA8EJpo0C1vtiZAeBDU0G0rg5CEHwc5fmdkeKRiEyOvfPxNm-Q@mail.gmail.com>



On 2/24/2022 12:49 PM, Dmitry Baryshkov wrote:
> On Thu, 24 Feb 2022 at 23:13, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote:
>>
>>
>>
>> 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?
> 
> It will succeed as dp_parser_parse() will not return -ENODEV if the
> connector is not eDP.
> To rephrase the comment:
> For the dp_parser_find_next_bridge() result:
> - for eDP the driver passes all errors to the calling function.
> - for DP the driver ignores -ENODEV (no external bridge is supplied),
> but passes all other errors (which can mean e.g. that the bridge is
> not properly declared or that it did hasn't been probed yet).
> 

Ah okay, I just noticed that dp_parser_parse() returns 0 by default and 
not rc.

So in this case it will still return 0.

Hence this change LGTM,

Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>

WARNING: multiple messages have this Message-ID (diff)
From: Abhinav Kumar <quic_abhinavk@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
	linux-arm-msm@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
	dri-devel@lists.freedesktop.org,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Kuogee Hsieh <quic_khsieh@quicinc.com>,
	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 13:09:34 -0800	[thread overview]
Message-ID: <06f7d17b-3614-d3bb-87db-611e6a4c4ba5@quicinc.com> (raw)
In-Reply-To: <CAA8EJpo0C1vtiZAeBDU0G0rg5CEHwc5fmdkeKRiEyOvfPxNm-Q@mail.gmail.com>



On 2/24/2022 12:49 PM, Dmitry Baryshkov wrote:
> On Thu, 24 Feb 2022 at 23:13, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote:
>>
>>
>>
>> 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?
> 
> It will succeed as dp_parser_parse() will not return -ENODEV if the
> connector is not eDP.
> To rephrase the comment:
> For the dp_parser_find_next_bridge() result:
> - for eDP the driver passes all errors to the calling function.
> - for DP the driver ignores -ENODEV (no external bridge is supplied),
> but passes all other errors (which can mean e.g. that the bridge is
> not properly declared or that it did hasn't been probed yet).
> 

Ah okay, I just noticed that dp_parser_parse() returns 0 by default and 
not rc.

So in this case it will still return 0.

Hence this change LGTM,

Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>

  reply	other threads:[~2022-02-24 21:09 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
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 [this message]
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=06f7d17b-3614-d3bb-87db-611e6a4c4ba5@quicinc.com \
    --to=quic_abhinavk@quicinc.com \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --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=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: link
Be 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.