Re: [PATCH] Revert "phy: qualcomm: usb28nm: Add MDM9607 init sequence"

[Stephan Gerhold <stephan@gerhold.net>]

On Wed, Dec 14, 2022 at 11:37:32PM +0100, Marijn Suijten wrote:
> This reverts commit 557a28811c7e0286d3816842032db5eb7bb5f156.
> 
> This commit introduced an init sequence from downstream DT [1] in the
> driver.  As mentioned by the comment above the HSPHY_INIT_CFG macro for
> this sequence:
> 
>     /*
>      * The macro is used to define an initialization sequence.  Each tuple
>      * is meant to program 'value' into phy register at 'offset' with 'delay'
>      * in us followed.
>      */
> 
> Instead of corresponding to offsets into the phy register, the sequence
> read by the downstream driver [2] is passed into ulpi_write [3] which
> crafts the address-value pair into a new value and writes it into the
> same register at USB_ULPI_VIEWPORT [4].  In other words, this init
> sequence is programmed into the hardware in a totally different way than
> downstream and is unlikely to achieve the desired result, if the hsphy
> is working at all.
> 

Thanks for sending this, I've also been meaning to do this for quite
some time :)

Reviewed-by: Stephan Gerhold <stephan@gerhold.net>

> An alternative method needs to be found to write these init values at
> the desired location.  Fortunately mdm9607 did not land upstream yet [5]
> and should have its compatible revised to use the generic one, instead
> of a compatible that writes wrong data to the wrong registers.
> 

There is a simple solution to write the init values correctly: You can
just use the ULPI PHY driver for MSM8916 (phy-qcom-usb-hs.c), which
writes those init values correctly.

If you look closely at downstream you can see that all targets with the
"SNPS Femto PHY" (at least MSM8909, MDM9607, MSM8976) actually use a
mixture of the code currently implemented in the mainline ULPI PHY
driver (phy-qcom-usb-hs.c) and the actual Femto PHY driver
(phy-qcom-usb-hs-28nm.c):

 - The device trees contains "qcom,dp-manual-pullup", which enables the
   ULPI_MISC_A_VBUSVLDEXT magic that is currently implemented partly in
   phy-qcom-usb-hs.c and partly in ci_hdrc_msm.c: 
     - Downstream: https://git.codelinaro.org/clo/la/kernel/msm-4.9/-/blob/29f81c613f4c853f4125ef189ede1f6d610653c0/drivers/usb/gadget/ci13xxx_msm.c#L113
     - Mainline: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/qualcomm/phy-qcom-usb-hs.c?h=v6.1#n92
       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/chipidea/ci_hdrc_msm.c?h=v6.1#n117

  - The ULPI init sequence is also implemented by phy-qcom-usb-hs.c in
    mainline: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/qualcomm/phy-qcom-usb-hs.c?h=v6.1#n144

  - The PHY CSR registers implemented by phy-qcom-usb-hs-28nm.c are only
    used to enter retention mode downstream (I guess some low-power mode
    where an USB device/host could still wake up the other host/device).

We don't have support for proper support for retention on mainline
(phy-qcom-usb-hs-28nm.c never enables the retention mode without
 fully powering off the PHY immediately after using the regulators).

So I suggest that we simply use the ULPI PHY driver for MSM8916 at least
for MSM8909 and MDM9607 (haven't checked MSM8976 in detail). I have
tried it and it works without any problems on both MSM8909 and MDM9607.
No driver changes needed!

Thanks,
Stephan