From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Chen-Yu Tsai <wenst@chromium.org>
Cc: chunkuang.hu@kernel.org, p.zabel@pengutronix.de,
airlied@gmail.com, daniel@ffwll.ch, matthias.bgg@gmail.com,
dri-devel@lists.freedesktop.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kernel@collabora.com
Subject: Re: [PATCH v3 2/9] drm/mediatek: dp: Move AUX and panel poweron/off sequence to function
Date: Thu, 6 Apr 2023 10:26:38 +0200 [thread overview]
Message-ID: <17342952-ce6b-a473-4bf0-f96a49d13632@collabora.com> (raw)
In-Reply-To: <CAGXv+5FrUPUg_SsRz6LrW_K_C7By2tSCQ9W_MNJr8XCOcn7gLA@mail.gmail.com>
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@collabora.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@collabora.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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-06 8:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-04 10:47 [PATCH v3 0/9] MediaTek DisplayPort: support eDP and aux-bus AngeloGioacchino Del Regno
2023-04-04 10:47 ` [PATCH v3 1/9] drm/mediatek: dp: Cache EDID for eDP panel AngeloGioacchino Del Regno
2023-04-12 7:08 ` Matthias Brugger
2023-04-12 8:06 ` AngeloGioacchino Del Regno
2023-04-12 10:39 ` Matthias Brugger
2023-04-04 10:47 ` [PATCH v3 2/9] drm/mediatek: dp: Move AUX and panel poweron/off sequence to function AngeloGioacchino Del Regno
2023-04-06 8:20 ` Chen-Yu Tsai
2023-04-06 8:26 ` AngeloGioacchino Del Regno [this message]
2023-04-04 10:47 ` [PATCH v3 3/9] drm/mediatek: dp: Always return connected status for eDP in .detect() AngeloGioacchino Del Regno
2023-04-04 10:47 ` [PATCH v3 4/9] drm/mediatek: dp: Always set cable_plugged_in at resume for eDP panel AngeloGioacchino Del Regno
2023-04-04 10:47 ` [PATCH v3 5/9] drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer() AngeloGioacchino Del Regno
2023-04-06 6:20 ` Chen-Yu Tsai
2023-04-04 10:47 ` [PATCH v3 6/9] drm/mediatek: dp: Enable event interrupt only when bridge attached AngeloGioacchino Del Regno
2023-04-04 10:47 ` [PATCH v3 7/9] drm/mediatek: dp: Use devm variant of drm_bridge_add() AngeloGioacchino Del Regno
2023-04-04 10:47 ` [PATCH v3 8/9] drm/mediatek: dp: Move AUX_P0 setting to mtk_dp_initialize_aux_settings() AngeloGioacchino Del Regno
2023-04-04 10:48 ` [PATCH v3 9/9] drm/mediatek: dp: Add support for embedded DisplayPort aux-bus AngeloGioacchino Del Regno
2023-06-23 13:29 ` Nícolas F. R. A. Prado
2023-06-23 16:22 ` Nícolas F. R. A. Prado
2023-04-06 7:20 ` [PATCH v3 0/9] MediaTek DisplayPort: support eDP and aux-bus Chen-Yu Tsai
2023-04-06 8:25 ` AngeloGioacchino Del Regno
2023-04-06 8:43 ` Chen-Yu Tsai
2023-05-30 6:52 ` AngeloGioacchino Del Regno
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=17342952-ce6b-a473-4bf0-f96a49d13632@collabora.com \
--to=angelogioacchino.delregno@collabora.com \
--cc=airlied@gmail.com \
--cc=chunkuang.hu@kernel.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=p.zabel@pengutronix.de \
--cc=wenst@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