From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: benl@squareup.com, robdclark@gmail.com, sean@poorly.run
Cc: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
AngeloGioacchino Del Regno <kholk11@gmail.com>,
Harigovindan P <harigovi@codeaurora.org>,
Konrad Dybcio <konradybcio@gmail.com>,
zhengbin <zhengbin13@huawei.com>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/msm/dsi: save PLL registers across first PHY reset
Date: Sat, 15 May 2021 03:33:58 +0300 [thread overview]
Message-ID: <c425c92d-3149-592b-f72e-009c972b9b21@linaro.org> (raw)
In-Reply-To: <010101750064e17e-3db0087e-fc37-494d-aac9-2c2b9b0a7c5b-000000@us-west-2.amazonses.com>
Rob,
On 07/10/2020 03:10, benl-kernelpatches@squareup.com wrote:
> From: Benjamin Li <benl@squareup.com>
>
> Take advantage of previously-added support for persisting PLL
> registers across DSI PHY disable/enable cycles (see 328e1a6
> 'drm/msm/dsi: Save/Restore PLL status across PHY reset') to
> support persisting across the very first DSI PHY enable at
> boot.
>
> The bootloader may have left the PLL registers in a non-default
> state. For example, for dsi_pll_28nm.c on 8x16/8x39, the byte
> clock mux's power-on reset configuration is to bypass DIV1, but
> depending on bandwidth requirements[1] the bootloader may have
> set the DIV1 path.
>
> When the byte clock mux is registered with the generic clock
> framework at probe time, the framework reads & caches the value
> of the mux bit field (the initial clock parent). After PHY enable,
> when clk_set_rate is called on the byte clock, the framework
> assumes there is no need to reparent, and doesn't re-write the
> mux bit field. But PHY enable resets PLL registers, so the mux
> bit field actually silently reverted to the DIV1 bypass path.
> This causes the byte clock to be off by a factor of e.g. 2 for
> our tested WXGA panel.
>
> The above issue manifests as the display not working and a
> constant stream of FIFO/LP0 contention errors.
>
> [1] The specific requirement for triggering the DIV1 path (and
> thus this issue) on 28nm is a panel with pixel clock <116.7MHz
> (one-third the minimum VCO setting). FHD/1080p (~145MHz) is fine,
> WXGA/1280x800 (~75MHz) is not.
This patch seems to be still relevant. Applying it would allow us to
drop respective save_state calls from 10nm and 7nm drivers.
I'd suggest applying it.
>
> Signed-off-by: Benjamin Li <benl@squareup.com>
> ---
> drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> index 009f5b843dd1..139b4a5aaf86 100644
> --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> @@ -621,6 +621,22 @@ static int dsi_phy_driver_probe(struct platform_device *pdev)
> phy->pll = NULL;
> }
>
> + /*
> + * As explained in msm_dsi_phy_enable, resetting the DSI PHY (as done
> + * in dsi_mgr_phy_enable) silently changes its PLL registers to power-on
> + * defaults, but the generic clock framework manages and caches several
> + * of the PLL registers. It initializes these caches at registration
> + * time via register read.
> + *
> + * As a result, we need to save DSI PLL registers once at probe in order
> + * for the first call to msm_dsi_phy_enable to successfully bring PLL
> + * registers back in line with what the generic clock framework expects.
> + *
> + * Subsequent PLL restores during msm_dsi_phy_enable will always be
> + * paired with PLL saves in msm_dsi_phy_disable.
> + */
> + msm_dsi_pll_save_state(phy->pll);
> +
> dsi_phy_disable_resource(phy);
>
> platform_set_drvdata(pdev, phy);
>
--
With best wishes
Dmitry
prev parent reply other threads:[~2021-05-15 0:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-07 0:10 [PATCH] drm/msm/dsi: save PLL registers across first PHY reset benl-kernelpatches
2020-10-30 13:55 ` Dmitry Baryshkov
2021-01-30 2:00 ` Benjamin Li
2021-01-30 16:16 ` Dmitry Baryshkov
2020-10-30 15:12 ` [PATCH] drm/msm/dsi: do not try reading 28nm vco rate if it's not enabled Dmitry Baryshkov
2020-12-29 20:15 ` patchwork-bot+linux-arm-msm
2021-05-15 0:33 ` Dmitry Baryshkov [this message]
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=c425c92d-3149-592b-f72e-009c972b9b21@linaro.org \
--to=dmitry.baryshkov@linaro.org \
--cc=airlied@linux.ie \
--cc=benl@squareup.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=harigovi@codeaurora.org \
--cc=kholk11@gmail.com \
--cc=konradybcio@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=zhengbin13@huawei.com \
/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;
as well as URLs for NNTP newsgroup(s).