From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Matthias Brugger <matthias.bgg@gmail.com>, chunkuang.hu@kernel.org
Cc: p.zabel@pengutronix.de, airlied@gmail.com, daniel@ffwll.ch,
dri-devel@lists.freedesktop.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kernel@collabora.com,
wenst@chromium.org
Subject: Re: [PATCH v3 1/9] drm/mediatek: dp: Cache EDID for eDP panel
Date: Wed, 12 Apr 2023 10:06:25 +0200 [thread overview]
Message-ID: <783c03af-fc88-96c8-c6fc-6f02051dc6b1@collabora.com> (raw)
In-Reply-To: <09c61b94-1ed1-eb72-9682-1f1f203f6f63@gmail.com>
Il 12/04/23 09:08, Matthias Brugger ha scritto:
>
>
> On 04/04/2023 12:47, AngeloGioacchino Del Regno wrote:
>> Since eDP panels are not removable it is safe to cache the EDID:
>> this will avoid a relatively long read transaction at every PM
>> resume that is unnecessary only in the "special" case of eDP,
>> hence speeding it up a little, as from now on, as resume operation,
>> we will perform only link training.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> ---
>> drivers/gpu/drm/mediatek/mtk_dp.c | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
>> index 1f94fcc144d3..84f82cc68672 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dp.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
>> @@ -118,6 +118,7 @@ struct mtk_dp {
>> const struct mtk_dp_data *data;
>> struct mtk_dp_info info;
>> struct mtk_dp_train_info train_info;
>> + struct edid *edid;
>> struct platform_device *phy_dev;
>> struct phy *phy;
>> @@ -1993,7 +1994,11 @@ static struct edid *mtk_dp_get_edid(struct drm_bridge
>> *bridge,
>> usleep_range(2000, 5000);
>> }
>> - new_edid = drm_get_edid(connector, &mtk_dp->aux.ddc);
>> + /* eDP panels aren't removable, so we can return a cached EDID. */
>> + if (mtk_dp->edid && mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP)
>> + new_edid = drm_edid_duplicate(mtk_dp->edid);
>> + else
>> + new_edid = drm_get_edid(connector, &mtk_dp->aux.ddc);
>
> Maybe it would make sense to add a macro for the check of mtk_dp->bridge.type ==
> DRM_MODE_CONNECTOR_eDP
> it would make the code more readable.
>
I had the same idea... but then avoided that because in most (if not all?) of the
DRM drivers (at least, the one I've read) this check is always open coded, so I
wrote it like that for consistency and nothing else.
I have no strong opinions on that though!
>> /*
>> * Parse capability here to let atomic_get_input_bus_fmts and
>> @@ -2022,6 +2027,10 @@ static struct edid *mtk_dp_get_edid(struct drm_bridge
>> *bridge,
>> drm_atomic_bridge_chain_post_disable(bridge, connector->state->state);
>> }
>> + /* If this is an eDP panel and the read EDID is good, cache it for later */
>> + if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP && !mtk_dp->edid && new_edid)
>> + mtk_dp->edid = drm_edid_duplicate(new_edid);
>> +
>
> How about putting this in an else if branch of mtk_dp_parse_capabilities. At least
> we could get rid of the check regarding if new_edid != NULL.
>
> I was thinking on how to put both if statements in one block, but I think the
> problem is, that we would leak memory if the capability parsing failes due to the
> call to drm_edid_duplicate(). Correct?
>
Correct. The only other "good" place would be in the `if (new_edid)` conditional,
but that wouldn't be as readable as it is right now...
Cheers,
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-12 8:07 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 [this message]
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
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=783c03af-fc88-96c8-c6fc-6f02051dc6b1@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