Hi,
On Thu, Jun 13, 2019 at 8:28 AM Marc Gonzalez <marc.w.gonzalez@xxxxxxx> wrote:
>
> readl_poll_timeout() calls usleep_range() to sleep between reads.
> usleep_range() doesn't work efficiently for tiny values.
>
> Raise the polling delay in qcom_qmp_phy_enable() to bring it in line
> with the delay in qcom_qmp_phy_com_init().
>
> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@xxxxxxx>
> ---
> Vivek, do you remember why you didn't use the same delay value in
> qcom_qmp_phy_enable) and qcom_qmp_phy_com_init() ?
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index bb522b915fa9..34ff6434da8f 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -1548,7 +1548,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, 10,
> PHY_INIT_COMPLETE_TIMEOUT);
I would agree that the existing code is almost certainly wrong, since,
as you said, trying to sleep for 1 us is likely pointless. I quickly
coded up a test and ran it on sdm845-cheza. It looked like this:
--
ktime_t a, b, c;
a = ktime_get();
b = ktime_get();
usleep_range(1, 1);
c = ktime_get();
pr_info("DOUG: %d ns, %d ns\n", (int)ktime_to_ns(ktime_sub(b, a)),
(int)ktime_to_ns(ktime_sub(c, b)));
--
At bootup I got:
[ 4.121247] DOUG: 52 ns, 9479 ns
[ 4.144990] DOUG: 52 ns, 9636 ns
[ 4.328168] DOUG: 0 ns, 11667 ns
[ 4.332659] DOUG: 52 ns, 7136 ns
[ 4.358833] DOUG: 0 ns, 6666 ns
[ 4.362095] DOUG: 52 ns, 8229 ns
So basically the existing code is already waiting 5-10 us between
polls but it's spending all of that time context switching. Changing
the above to:
usleep_range(5, 10);
Give me instead:
[ 4.120781] DOUG: 52 ns, 16927 ns
[ 4.144626] DOUG: 53 ns, 17447 ns
[ 4.327932] DOUG: 52 ns, 11302 ns
[ 4.332501] DOUG: 0 ns, 7395 ns
[ 4.357912] DOUG: 0 ns, 6823 ns
[ 4.361175] DOUG: 52 ns, 9063 ns
...and that seems fine to me.
--
Thus:
Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
