linux-kernel - Re: [PATCH] drm/msm/dp: no dp_hpd_unplug

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]

Date:   Fri, 24 Jun 2022 08:00:51 -0700
From:   Kuogee Hsieh <quic_khsieh@...cinc.com>
To:     Stephen Boyd <swboyd@...omium.org>, <agross@...nel.org>,
        <airlied@...ux.ie>, <bjorn.andersson@...aro.org>,
        <daniel@...ll.ch>, <dianders@...omium.org>,
        <dmitry.baryshkov@...aro.org>, <robdclark@...il.com>,
        <sean@...rly.run>, <vkoul@...nel.org>
CC:     <quic_abhinavk@...cinc.com>, <quic_aravindh@...cinc.com>,
        <quic_sbillaka@...cinc.com>, <freedreno@...ts.freedesktop.org>,
        <dri-devel@...ts.freedesktop.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/msm/dp: no dp_hpd_unplug_handle() required for eDP


On 6/23/2022 5:09 PM, Stephen Boyd wrote:
> Quoting Kuogee Hsieh (2022-06-23 16:34:16)
>> eDP implementation does not reuried to support hpd signal. Therefore
> s/reuried/require/
>
>> it only has either ST_DISPLAY_OFF or ST_CONNECTED state during normal
>> operation. This patch remove unnecessary dp_hpd_unplug_handle() for
>> eDP but still keep dp_hpd_plug_handle() to support eDP to either
>> booting up or resume from ST_DISCONNECTED state.
> I take it that making this change also fixes a glitch seen on the eDP
> panel when a second modeset happens? Can you add that detail to the
> commit text? The way it reads makes it sound like this is purely a
> cleanup patch, but then there's a Fixes tag so it must be a bug fix or
> worthy optimization, neither of which is described.

no, this patch will not fix edp (primary display) corruption issue.

This patch is pure clean up edp.

I will submit fixes edp corruption issue at other patch.

>> Fixes: 391c96ff0555 ("drm/msm/dp: Support only IRQ_HPD and REPLUG interrupts for eDP")
>> Signed-off-by: Kuogee Hsieh <quic_khsieh@...cinc.com>
>> ---
>>   drivers/gpu/drm/msm/dp/dp_display.c | 5 +----
>>   1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
>> index da5c03a..ef9794e 100644
>> --- a/drivers/gpu/drm/msm/dp/dp_display.c
>> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
>> @@ -1666,7 +1666,7 @@ void dp_bridge_enable(struct drm_bridge *drm_bridge)
>>                  return;
>>          }
>>
>> -       if (dp->is_edp)
>> +       if (dp->is_edp && dp_display->hpd_state == ST_DISCONNECTED)
>>                  dp_hpd_plug_handle(dp_display, 0);
>>
>>          mutex_lock(&dp_display->event_mutex);
>> @@ -1737,9 +1737,6 @@ void dp_bridge_post_disable(struct drm_bridge *drm_bridge)
>>
>>          dp_display = container_of(dp, struct dp_display_private, dp_display);
>>
>> -       if (dp->is_edp)
>> -               dp_hpd_unplug_handle(dp_display, 0);
> dp_hpd_unplug_handle() has a !edp check, and from what I can tell after
> this patch that condition will always trigger? But then I wonder why we
> aren't masking the irqs for hpd when the eDP display is disabled.
> Shouldn't we at least be doing that so that we don't get spurious hpd
> irqs when the eDP display is off or on the path to suspend where I
> suspect the power may be removed from the panel?