mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Kalyan Thota <quic_kalyant@quicinc.com>,
	dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org, devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, robdclark@chromium.org,
	dianders@chromium.org, swboyd@chromium.org,
	quic_vpolimer@quicinc.com
Subject: Re: [PATCH v2 2/3] drm/msm/disp/dpu1: add helper to know if display is pluggable
Date: Wed, 16 Nov 2022 18:18:37 +0300	[thread overview]
Message-ID: <bf14540a-745c-c378-520a-f8edfd3e3adf@linaro.org> (raw)
In-Reply-To: <6b1907db-3fdb-8fe0-e5e3-21ea17021925@quicinc.com>

On 16/11/2022 18:11, Abhinav Kumar wrote:
> 
> 
> On 11/16/2022 7:08 AM, Dmitry Baryshkov wrote:
>> On 16/11/2022 17:30, Kalyan Thota wrote:
>>> Since DRM encoder type for few encoders can be similar
>>> (like eDP and DP) find out if the interface supports HPD
>>> from encoder bridge to differentiate between builtin
>>> and pluggable displays.
>>>
>>> Changes in v1:
>>> - add connector type in the disp_info (Dmitry)
>>> - add helper functions to know encoder type
>>> - update commit text reflecting the change
>>>
>>> Changes in v2:
>>> - avoid hardcode of connector type for DSI as it may not be true 
>>> (Dmitry)
>>> - get the HPD information from encoder bridge
>>>
>>> Signed-off-by: Kalyan Thota <quic_kalyant@quicinc.com>
>>> ---
>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 16 ++++++++++++++++
>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  6 ++++++
>>>   2 files changed, 22 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> index 9c6817b..be93269 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>>> @@ -15,6 +15,7 @@
>>>   #include <drm/drm_crtc.h>
>>>   #include <drm/drm_file.h>
>>>   #include <drm/drm_probe_helper.h>
>>> +#include <drm/drm_bridge.h>
>>>   #include "msm_drv.h"
>>>   #include "dpu_kms.h"
>>> @@ -217,6 +218,21 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
>>>       15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
>>>   };
>>> +bool dpu_encoder_is_pluggable(struct drm_encoder *encoder)
>>> +{
>>> +    struct drm_bridge *bridge;
>>> +    int ops = 0;
>>> +
>>> +    if (!encoder)
>>> +        return false;
>>> +
>>> +    /* Get last bridge in the chain to determine pluggable state */
>>> +    drm_for_each_bridge_in_chain(encoder, bridge)
>>> +        if (!drm_bridge_get_next_bridge(bridge))
>>> +            ops = bridge->ops;
>>> +
>>> +    return ops & DRM_BRIDGE_OP_HPD;
>>
>> No. This is not what you should be checking (hint: polled connectors 
>> also can be pluggable).
>>
>> Please check the type of the actual connector connected to this encoder.
>>
> 
> Even if we check the connector type as DSI or eDP that does not 
> necessarily mean its built-in.
> 
> We can even use DSI or eDP as a pluggable display.

Well, I don't think so. eDP and DSI connectors are not pluggable per 
design. One can use them so, but they are not thought to be used this 
way. Unlike e.g. HDMI, DP, VGA, etc.

I would say LVDS, eDP, DSI, DPI and SPI can be assumed to be constantly 
plugged.

Compare this with Composite, SVIDEO, 9PinDIN, TV. They can be assumed to 
be external even if they do not have the HPD (or even polling). And 
these connectors usually don't have it.

> 
> Thats why we thought of this check.
> 
-- 
With best wishes
Dmitry


  reply	other threads:[~2022-11-16 15:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-16 14:30 [PATCH v2 0/3] add color management support for the crtc Kalyan Thota
2022-11-16 14:30 ` [PATCH v2 1/3] drm/msm/disp/dpu1: pin 1 crtc to 1 encoder Kalyan Thota
2022-11-16 14:30 ` [PATCH v2 2/3] drm/msm/disp/dpu1: add helper to know if display is pluggable Kalyan Thota
2022-11-16 15:08   ` Dmitry Baryshkov
2022-11-16 15:11     ` Abhinav Kumar
2022-11-16 15:18       ` Dmitry Baryshkov [this message]
2022-11-16 15:35         ` Abhinav Kumar
2022-11-16 15:55           ` Dmitry Baryshkov
2022-11-16 14:30 ` [PATCH v2 3/3] drm/msm/disp/dpu1: add color management support for the crtc Kalyan Thota

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=bf14540a-745c-c378-520a-f8edfd3e3adf@linaro.org \
    --to=dmitry.baryshkov@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_kalyant@quicinc.com \
    --cc=quic_vpolimer@quicinc.com \
    --cc=robdclark@chromium.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®