lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dc656c7a-eab4-f547-ca52-51f7510c2858@linaro.org>
Date:   Wed, 16 Nov 2022 17:55:27 +0200
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Kalyan Thota <quic_kalyant@...cinc.com>,
        dri-devel@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
        freedreno@...ts.freedesktop.org, devicetree@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, robdclark@...omium.org,
        dianders@...omium.org, swboyd@...omium.org,
        quic_vpolimer@...cinc.com
Subject: Re: [PATCH v2 2/3] drm/msm/disp/dpu1: add helper to know if display
 is pluggable

On 16/11/2022 18:35, Abhinav Kumar wrote:
> 
> 
> On 11/16/2022 7:18 AM, Dmitry Baryshkov wrote:
>> 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@...cinc.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.
>>
> 
> We have had many products where we used HDMI as the primary display 
> where the HPD line was disconnected in the design, so now if we 
> generalize all HDMI connectors to be pluggable we can never enable color 
> management on those even though DSI is not even used in that product.

Did they use HDMI connector internally? Or was it just a panel wired 
somehow to the HDMI pins?

If the former is true, then they still are pluggable. Even if you don't 
have a way to detect that via the HPD pin.

If the later is the case, then it shouldn't be DRM_MODE_CONNECTOR_HDMI.
Well, even if this is an internal HDMI, I'd still use some other 
connector (e.g. DRM_MODE_CONNECTOR_Unknown) just to point out that this 
is not an externally visible HDMI connector one assumes to be able to 
find on the body of the device.

Last, but not least, how would you remove DRM_BRIDGE_OPS_HPD from the 
corresponding bridge driver?


> Thats why I felt we should rely on the HPD_OPS as that way we know that 
> it will be set only if HPD will be used.
> 
> Wouldnt it be just better to also check polling displays to complete 
> this check? Is there a way to do it?


Yes, check DRM_BRIDGE_OP_DETECT. But as I noted, there is a list of 
connectors that will not ever have HPD or polling, but still always are 
external. Well, even for VGA there is no good way to detect whether it 
is plugged in or not (see the comment in display-connector.c).



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ