linux-kernel - Re: [PATCH v3 2/9] drm/mediatek: dp: Move AUX and panel poweron/off sequence to function

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <17342952-ce6b-a473-4bf0-f96a49d13632@collabora.com>
Date:   Thu, 6 Apr 2023 10:26:38 +0200
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Chen-Yu Tsai <wenst@...omium.org>
Cc:     chunkuang.hu@...nel.org, p.zabel@...gutronix.de, airlied@...il.com,
        daniel@...ll.ch, matthias.bgg@...il.com,
        dri-devel@...ts.freedesktop.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, kernel@...labora.com
Subject: Re: [PATCH v3 2/9] drm/mediatek: dp: Move AUX and panel poweron/off
 sequence to function

Il 06/04/23 10:20, Chen-Yu Tsai ha scritto:
> On Tue, Apr 4, 2023 at 6:48 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@...labora.com> wrote:
>>
>> Everytime we run bridge detection and/or EDID read we run a poweron
>> and poweroff sequence for both the AUX and the panel; moreover, this
>> is also done when enabling the bridge in the .atomic_enable() callback.
>>
>> Move this power on/off sequence to a new mtk_dp_aux_panel_poweron()
>> function as to commonize it.
>> Note that, before this commit, in mtk_dp_bridge_atomic_enable() only
>> the AUX was getting powered on but the panel was left powered off if
>> the DP cable wasn't plugged in while now we unconditionally send a D0
>> request and this is done for two reasons:
>>   - First, whether this request fails or not, it takes the same time
>>     and anyway the DP hardware won't produce any error (or, if it
>>     does, it's ignorable because it won't block further commands)
>>   - Second, training the link between a sleeping/standby/unpowered
>>     display makes little sense.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>> ---
>>   drivers/gpu/drm/mediatek/mtk_dp.c | 76 ++++++++++++-------------------
>>   1 file changed, 30 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
>> index 84f82cc68672..76ea94167531 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
>> @@ -1253,6 +1253,29 @@ static void mtk_dp_audio_mute(struct mtk_dp *mtk_dp, bool mute)
>>                             val[2], AU_TS_CFG_DP_ENC0_P0_MASK);
>>   }
>>
>> +static void mtk_dp_aux_panel_poweron(struct mtk_dp *mtk_dp, bool pwron)
>> +{
>> +       if (pwron) {
>> +               /* power on aux */
>> +               mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
>> +                                  DP_PWR_STATE_BANDGAP_TPLL_LANE,
>> +                                  DP_PWR_STATE_MASK);
>> +
>> +               /* power on panel */
>> +               drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
>> +               usleep_range(2000, 5000);
>> +       } else {
>> +               /* power off panel */
>> +               drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3);
>> +               usleep_range(2000, 3000);
>> +
>> +               /* power off aux */
>> +               mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
>> +                                  DP_PWR_STATE_BANDGAP_TPLL,
>> +                                  DP_PWR_STATE_MASK);
>> +       }
>> +}
>> +
>>   static void mtk_dp_power_enable(struct mtk_dp *mtk_dp)
>>   {
>>          mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_RESET_AND_PROBE,
>> @@ -1937,16 +1960,9 @@ static enum drm_connector_status mtk_dp_bdg_detect(struct drm_bridge *bridge)
>>          if (!mtk_dp->train_info.cable_plugged_in)
>>                  return ret;
>>
>> -       if (!enabled) {
>> -               /* power on aux */
>> -               mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
>> -                                  DP_PWR_STATE_BANDGAP_TPLL_LANE,
>> -                                  DP_PWR_STATE_MASK);
>> +       if (!enabled)
>> +               mtk_dp_aux_panel_poweron(mtk_dp, true);
>>
>> -               /* power on panel */
>> -               drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
> 
> I suspect the original code was somewhat wrong already? We shouldn't need
> to pull the panel out of standby just for HPD or reading EDID.
> 
> This driver probably needs a lot more cleanup. :/
> 

I believe the same... but I wanted to play safe, as I don't know if there's any
panel in particular that requires such quirk...

Angelo