From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Neil Armstrong <neil.armstrong@linaro.org>,
Rob Clark <robin.clark@oss.qualcomm.com>,
Dmitry Baryshkov <lumag@kernel.org>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Jessica Zhang <jessica.zhang@oss.qualcomm.com>,
Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7] drm/msm/dsi/phy: Fix reading zero as PLL rates when unprepared
Date: Fri, 24 Oct 2025 16:34:34 +0200 [thread overview]
Message-ID: <05d6ea2a-c1ae-422d-b178-5d2a306f3669@linaro.org> (raw)
In-Reply-To: <50a49d72-2b1e-471d-b0c4-d5a0b38b2a21@linaro.org>
On 24/10/2025 14:43, Neil Armstrong wrote:
> Hi,
>
> On 9/8/25 11:49, Krzysztof Kozlowski wrote:
>> Hardware Programming Guide for DSI PHY says that PLL_SHUTDOWNB and
>> DIGTOP_PWRDN_B have to be asserted for any PLL register access.
>> Whenever dsi_pll_7nm_vco_recalc_rate() or dsi_pll_7nm_vco_set_rate()
>> were called on unprepared PLL, driver read values of zero leading to all
>> sort of further troubles, like failing to set pixel and byte clock
>> rates.
>>
>> Asserting the PLL shutdown bit is done by dsi_pll_enable_pll_bias() (and
>> corresponding dsi_pll_disable_pll_bias()) which are called through the
>> code, including from PLL .prepare() and .unprepare() callbacks.
>>
>> The .set_rate() and .recalc_rate() can be called almost anytime from
>> external users including times when PLL is or is not prepared, thus
>> driver should not interfere with the prepare status.
>>
>> Implement simple reference counting for the PLL bias, so
>> set_rate/recalc_rate will not change the status of prepared PLL.
>>
>> Issue of reading 0 in .recalc_rate() did not show up on existing
>> devices, but only after re-ordering the code for SM8750.
>
> It happens this breaks the bonded DSI use-case, mainly because both PHYs
> uses the same PLL, and trying to enable the DSI0 PHY PLL from the DSI1
> PHY fails because the DSI0 PHY enable_count == 0.
If it is ==0, the check you removed would not be hit and enable would
work. I don't quite get the analysis.
>
> Reverting part the the patch makes the bonded work again:
> ===================><===============================
> diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
> index 32f06edd21a9..24811c52d34c 100644
> --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
> +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c
> @@ -426,11 +426,8 @@ static void dsi_pll_enable_pll_bias(struct dsi_pll_7nm *pll)
> u32 data;
>
> spin_lock_irqsave(&pll->pll_enable_lock, flags);
> - if (pll->pll_enable_cnt++) {
> - spin_unlock_irqrestore(&pll->pll_enable_lock, flags);
> - WARN_ON(pll->pll_enable_cnt == INT_MAX);
> - return;
> - }
> + pll->pll_enable_cnt++;
> + WARN_ON(pll->pll_enable_cnt == INT_MAX);
>
> data = readl(pll->phy->base + REG_DSI_7nm_PHY_CMN_CTRL_0);
> data |= DSI_7nm_PHY_CMN_CTRL_0_PLL_SHUTDOWNB;
> @@ -965,10 +962,8 @@ static int dsi_7nm_phy_enable(struct msm_dsi_phy *phy,
> u32 const delay_us = 5;
> u32 const timeout_us = 1000;
> struct msm_dsi_dphy_timing *timing = &phy->timing;
> - struct dsi_pll_7nm *pll = phy->pll_data;
> void __iomem *base = phy->base;
> bool less_than_1500_mhz;
> - unsigned long flags;
> u32 vreg_ctrl_0, vreg_ctrl_1, lane_ctrl0;
> u32 glbl_pemph_ctrl_0;
> u32 glbl_str_swi_cal_sel_ctrl, glbl_hstx_str_ctrl_0;
> @@ -1090,13 +1085,10 @@ static int dsi_7nm_phy_enable(struct msm_dsi_phy *phy,
> glbl_rescode_bot_ctrl = 0x3c;
> }
>
> - spin_lock_irqsave(&pll->pll_enable_lock, flags);
This should not be removed.
> - pll->pll_enable_cnt = 1;
So you basically remoevd pll_enable_cnt everywhere and reverted entirely
my commit. How is this patch different than revert?
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-10-24 14:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-08 9:49 Krzysztof Kozlowski
2025-09-09 14:23 ` Dmitry Baryshkov
2025-10-24 12:43 ` Neil Armstrong
2025-10-24 14:34 ` Krzysztof Kozlowski [this message]
2025-10-24 14:48 ` Neil Armstrong
2025-10-27 10:35 ` Krzysztof Kozlowski
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=05d6ea2a-c1ae-422d-b178-5d2a306f3669@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jessica.zhang@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=neil.armstrong@linaro.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
/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
all inboxes | Powered by JetHome®