mbox series

[v2,00/15] phy: qcom-qmp-pcie: add support for sc8280xp

Message ID 20221019113552.22353-1-johan+linaro@kernel.org
Headers show
Series phy: qcom-qmp-pcie: add support for sc8280xp | expand

Message

Johan Hovold Oct. 19, 2022, 11:35 a.m. UTC
This series adds support for the PCIe PHYs on SC8280XP including its
four-lane PHYs.

The first half of the series clean up the driver in preparation for
supporting SC8280XP and its new devicetree bindings that drops the
legacy child node and the (incomplete) description of register
subregions.

The other QMP bindings suffer from similar problems and follow-on series
will do corresponding changes to the UFS, USB and combo QMP bindings and
drivers.

Note that these patches depend on the linux-phy next branch of today and
the following two series:

 1. [PATCH v2 00/14] phy: qcom-qmp: further prep cleanups

    https://lore.kernel.org/lkml/20221012081241.18273-1-johan+linaro@kernel.org

 2. [PATCH 00/20] phy: qcom-qmp: further prep fixes and cleanups (set 3)

    https://lore.kernel.org/lkml/20221012084846.24003-1-johan+linaro@kernel.org

Johan


Changes in v2
 - rename current DT schema after first SoC added to the original
   bindings (IPQ8074) and add a reference to the new SC8280XP bindings
   instead of marking the current bindings as "legacy" (Krzysztof)

 - add "sc8280xp" infix to the new DT schema filename (Krzysztof)

 - tighten description of the 'qcom,4ln-config-sel' phandle array
   (Krzysztof)


Johan Hovold (15):
  phy: qcom-qmp-pcie: sort device-id table
  phy: qcom-qmp-pcie: move device-id table
  phy: qcom-qmp-pcie: merge driver data
  phy: qcom-qmp-pcie: clean up device-tree parsing
  phy: qcom-qmp-pcie: clean up probe initialisation
  phy: qcom-qmp-pcie: rename PHY ops structure
  phy: qcom-qmp-pcie: clean up PHY lane init
  phy: qcom-qmp-pcie: add register init helper
  dt-bindings: phy: qcom,qmp-pcie: rename current bindings
  dt-bindings: phy: qcom,qmp-pcie: add sc8280xp bindings
  phy: qcom-qmp-pcie: restructure PHY creation
  phy: qcom-qmp-pcie: fix initialisation reset
  phy: qcom-qmp-pcie: add support for pipediv2 clock
  phy: qcom-qmp-pcie: add support for sc8280xp
  phy: qcom-qmp-pcie: add support for sc8280xp 4-lane PHYs

 ...hy.yaml => qcom,ipq8074-qmp-pcie-phy.yaml} |   7 +-
 .../phy/qcom,sc8280xp-qmp-pcie-phy.yaml       | 165 ++++
 drivers/phy/qualcomm/Kconfig                  |   1 +
 drivers/phy/qualcomm/phy-qcom-qmp-pcie.c      | 853 ++++++++++++------
 .../phy/qualcomm/phy-qcom-qmp-pcs-pcie-v5.h   |   2 +
 5 files changed, 774 insertions(+), 254 deletions(-)
 rename Documentation/devicetree/bindings/phy/{qcom,qmp-pcie-phy.yaml => qcom,ipq8074-qmp-pcie-phy.yaml} (96%)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml

Comments

Johan Hovold Oct. 21, 2022, 9:11 a.m. UTC | #1
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