Re: [PATCH v2 12/15] phy: qcom-qmp-pcie: fix initialisation reset

[Johan Hovold <johan@kernel.org>]

On Wed, Oct 19, 2022 at 04:52:29PM +0300, Dmitry Baryshkov wrote:
> On 19/10/2022 14:35, Johan Hovold wrote:
> > Add the missing delay after asserting reset. This is specifically needed
> > for the reset to have any effect on SC8280XP.
> > 
> > The vendor driver uses a 1 ms delay, but that seems a bit excessive.
> > Instead use a 200 us delay which appears to be more than enough and also
> > matches the UFS reset delay added by commit 870b1279c7a0 ("scsi:
> > ufs-qcom: Add reset control support for host controller").
> > 
> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
> > ---
> >   drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > index 2f4bdef73395..9c8e009033f1 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > @@ -1866,6 +1866,8 @@ static int qmp_pcie_init(struct phy *phy)
> >   		goto err_disable_regulators;
> >   	}
> >   
> > +	usleep_range(200, 300);
> > +
> 
> If there is a v3, I'd kindly ask to add a comment about vendor using 1ms 
> here.

No, I'm going to leave this is as is. The vendor driver is just a
reference implementation with a wide range of differences which there's
little point in documenting in mainline.

This information will continue to be available in the git logs if anyone
wonders were these numbers came from.

If it turns out that some other platform needs a longer delay, we can
consider increasing the delay unconditionally after verifying
experimentally.

And anyone with access to actual documentation is of course free to
suggest a different delay from the start.

> >   	ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets);
> >   	if (ret) {
> >   		dev_err(qmp->dev, "reset deassert failed\n");

Johan