From: Niklas Cassel <niklas.cassel@linaro.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Evan Green <evgreen@chromium.org>,
Marc Gonzalez <marc.w.gonzalez@free.fr>,
Vivek Gautam <vivek.gautam@codeaurora.org>
Subject: Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition
Date: Wed, 12 Jun 2019 15:08:58 +0200 [thread overview]
Message-ID: <20190612130858.GA11167@centauri> (raw)
In-Reply-To: <20190604232443.3417-1-bjorn.andersson@linaro.org>
On Tue, Jun 04, 2019 at 04:24:43PM -0700, Bjorn Andersson wrote:
> After issuing a PHY_START request to the QMP, the hardware documentation
> states that the software should wait for the PCS_READY_STATUS to become
> 1.
>
> With the introduction of c9b589791fc1 ("phy: qcom: Utilize UFS reset
> controller") an additional 1ms delay was introduced between the start
> request and the check of the status bit. This greatly increases the
> chances for the hardware to actually becoming ready before the status
> bit is read.
>
> The result can be seen in that UFS PHY enabling is now reported as a
> failure in 10% of the boots on SDM845, which is a clear regression from
> the previous rare/occasional failure.
>
> This patch fixes the "break condition" of the poll to check for the
> correct state of the status bit.
>
> Unfortunately PCIe on 8996 and 8998 does not specify the mask_pcs_ready
> register, which means that the code checks a bit that's always 0. So the
> patch also fixes these, in order to not regress these targets.
>
> Cc: stable@vger.kernel.org
> Cc: Evan Green <evgreen@chromium.org>
> Cc: Marc Gonzalez <marc.w.gonzalez@free.fr>
> Cc: Vivek Gautam <vivek.gautam@codeaurora.org>
> Fixes: 73d7ec899bd8 ("phy: qcom-qmp: Add msm8998 PCIe QMP PHY support")
> Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> @Kishon, this is a regression spotted in v5.2-rc1, so please consider applying
> this towards v5.2.
>
> drivers/phy/qualcomm/phy-qcom-qmp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index cd91b4179b10..43abdfd0deed 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -1074,6 +1074,7 @@ static const struct qmp_phy_cfg msm8996_pciephy_cfg = {
>
> .start_ctrl = PCS_START | PLL_READY_GATE_EN,
> .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
> + .mask_pcs_ready = PHYSTATUS,
> .mask_com_pcs_ready = PCS_READY,
>
> .has_phy_com_ctrl = true,
> @@ -1253,6 +1254,7 @@ static const struct qmp_phy_cfg msm8998_pciephy_cfg = {
>
> .start_ctrl = SERDES_START | PCS_START,
> .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
> + .mask_pcs_ready = PHYSTATUS,
> .mask_com_pcs_ready = PCS_READY,
> };
>
> @@ -1547,7 +1549,7 @@ static int qcom_qmp_phy_enable(struct phy *phy)
> status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
> mask = cfg->mask_pcs_ready;
>
> - ret = readl_poll_timeout(status, val, !(val & mask), 1,
> + ret = readl_poll_timeout(status, val, val & mask, 1,
> PHY_INIT_COMPLETE_TIMEOUT);
> if (ret) {
> dev_err(qmp->dev, "phy initialization timed-out\n");
> --
> 2.18.0
>
msm8996_pciephy_cfg and msm8998_pciephy_cfg not having a bit mask defined
for PCS ready is really a separate bug, so personally I would have created
two patches, one that adds the missing masks, and one patch that fixes the
broken break condition.
Either way:
Reviewed-by: Niklas Cassel <niklas.cassel@linaro.org>
next prev parent reply other threads:[~2019-06-12 13:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-04 23:24 [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition Bjorn Andersson
2019-06-04 23:35 ` Evan Green
2019-06-12 13:08 ` Niklas Cassel [this message]
2019-06-12 17:34 ` Bjorn Andersson
2019-06-12 16:24 ` Marc Gonzalez
2019-06-12 17:25 ` Bjorn Andersson
2019-06-13 9:10 ` Marc Gonzalez
2019-06-19 12:43 ` Marc Gonzalez
2019-07-19 15:50 ` Marc Gonzalez
2019-07-23 10:31 ` Marc Gonzalez
2019-08-02 19:54 ` Marc Gonzalez
2019-08-06 0:43 ` Bjorn Andersson
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=20190612130858.GA11167@centauri \
--to=niklas.cassel@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=evgreen@chromium.org \
--cc=kishon@ti.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.w.gonzalez@free.fr \
--cc=stable@vger.kernel.org \
--cc=vivek.gautam@codeaurora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.