lkml.org 
[lkml]   [2022]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Revert "phy: qualcomm: usb28nm: Add MDM9607 init sequence"
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

\
 
 \ /
  Last update: 2022-12-15 11:08    [W:0.091 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site