linux-kernel - RE: [PATCH v9 2/4] drm/msm/dp: Support only IRQ

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: <MW4PR02MB7186136C182E076A38270FFBE1FB9@MW4PR02MB7186.namprd02.prod.outlook.com>
Date:   Tue, 26 Apr 2022 03:45:49 +0000
From:   "Sankeerth Billakanti (QUIC)" <quic_sbillaka@...cinc.com>
To:     Stephen Boyd <swboyd@...omium.org>,
        "Sankeerth Billakanti (QUIC)" <quic_sbillaka@...cinc.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "freedreno@...ts.freedesktop.org" <freedreno@...ts.freedesktop.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:     "robdclark@...il.com" <robdclark@...il.com>,
        "seanpaul@...omium.org" <seanpaul@...omium.org>,
        quic_kalyant <quic_kalyant@...cinc.com>,
        "Abhinav Kumar (QUIC)" <quic_abhinavk@...cinc.com>,
        "dianders@...omium.org" <dianders@...omium.org>,
        "Kuogee Hsieh (QUIC)" <quic_khsieh@...cinc.com>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        "sean@...rly.run" <sean@...rly.run>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "daniel@...ll.ch" <daniel@...ll.ch>,
        "dmitry.baryshkov@...aro.org" <dmitry.baryshkov@...aro.org>,
        quic_vproddut <quic_vproddut@...cinc.com>,
        "Aravind Venkateswaran (QUIC)" <quic_aravindh@...cinc.com>,
        "steev@...i.org" <steev@...i.org>
Subject: RE: [PATCH v9 2/4] drm/msm/dp: Support only IRQ_HPD and REPLUG
 interrupts for eDP

Hi Stephen,

>> >>  int dp_catalog_ctrl_get_interrupt(struct dp_catalog *dp_catalog)
>> >> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
>> >> b/drivers/gpu/drm/msm/dp/dp_display.c
>> >> index 055681a..dea4de9 100644
>> >> --- a/drivers/gpu/drm/msm/dp/dp_display.c
>> >> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
>> >> @@ -1096,6 +1097,13 @@ static void dp_display_config_hpd(struct
>> >dp_display_private *dp)
>> >>         dp_display_host_init(dp);
>> >>         dp_catalog_ctrl_hpd_config(dp->catalog);
>> >>
>> >> +       /* Enable plug and unplug interrupts only for external DisplayPort */
>> >> +       if (!dp->dp_display.is_edp)
>> >> +               dp_catalog_hpd_config_intr(dp->catalog,
>> >> +                               DP_DP_HPD_PLUG_INT_MASK |
>> >> +                               DP_DP_HPD_UNPLUG_INT_MASK,
>> >> +                               true);
>> >> +
>> >
>> >It seems like only the plug and unplug is enabled for DP here. Is
>> >replug enabled for eDP when it shouldn't be?
>> >
>>
>> By default, all the interrupts are masked. This function is not
>> executed for eDP anymore because the host_init, phy_init and
>> enable_irq are all done from modeset_init for eDP with aux_bus. So,
>> none of the eDP hpd interrupts are enabled or unmasked before pre-
>enable.
>>
>> The replug interrupt is unmasked for DP and eDP from the
>> dp_hpd_plug_handle() and masked from dp_hpd_unplug_handle().
>
>Why is replug enabled for eDP?

As the eDP panel is assumed to be always connected, just enabling the IRQ_HPD is sufficient.

The REPLUG is enabled or unmasked along with IRQ_HPD in code.

I did not remove the REPLUG event support for eDP so that we have an option to see if the eDP panel
can undergo a short disconnect/connect cycle after pre-enable (while the panel power is enabled).

REPLUG can be generated for eDP if,
a) the panel power turns off and on OR 
b) the sink itself issues a fast disconnect-connect.

REPLUG event initiated by sink is rare and we observed it only during the DP compliance test.

Some more information on HPD events generated by the source:

Replug interrupt is something our controller HW supports and not part of the DP/eDP specification.

The programmed values for HPD on the HW controller indicates the following:

1. The HOTPLUG interrupt will be generated if the HPD line is continuously high for 100ms.
2. Similarly, UNPLUG interrupt will be generated when the HPD line transitions from high to low and remains low for 100ms.
3. IRQ_HPD will be generated when the HPD line transitions from high to low and remains low for less than 2ms.
4. REPLUG will be generated if the HPD line remains low for more than 2ms but less than 100ms.

According to the DP spec, replug event should be considered as a disconnect and then connect.

To answer your question, I did not remove REPLUG support for eDP because I felt it will not affect the eDP normal functioning in anyway.

Thank you,
Sankeerth