Re: [PATCH v2 1/2] dt-bindings: phy: Add qcom,dp-manual-pullup description

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 29/12/2022 18:57, Stephan Gerhold wrote:
> AFAIK it is not possible to route VBUS directly to the controller on
> these SoCs so this property would likely be added to the SoC dtsi
> (i.e. msm8916.dtsi and msm8939.dtsi) and used by all boards.

So db410c signals the SoC via GPIO 121 / USB_HS_ID

https://fccid.io/2AFQA-DB410C/Schematics/Schematics-2816094.pdf

Which causes ULPI_MISC_A_VBUSVLDEXT to be updated depending on the state 
VBUS.

But not ULPI_MISC_A_VBUSVLDEXTSEL this is the additional register that 
downstream updates when "VBUS is not routed to the controller"

I don't have a bit-level description of these registers at the moment 
so, I'm guessing that ULPI_MISC_A_VBUSVLDEXTSEL *is* being updated.

The reason for that is if I just set ULPI_MISC_A_VBUSVLDEXT then as a 
device a host never sees my SoC via the internal USB hub.

In other words, for me at any rate I need to see both

- ULPI_MISC_A_VBUSVLDEXT
- ULPI_MISC_A_VBUSVLDEXTSEL

to get the pullup to work and hence the Hub/Host to detect the 8939.

> This means we could just bind this behavior to the existing SoC-specific
> compatible (i.e. of_device_is_compatible(..., "qcom,usb-hs-phy-msm8916"))
> and avoid having an extra property.
> 
> Thoughts?

So. I'm OOO at the moment and didn't bring my db410c but TBH to me I 
don't see why we do this whole dance with the pullup on/off with VBUS.

The right thing to do is to run an experiment statically setting

- ULPI_MISC_A_VBUSVLDEXT
- ULPI_MISC_A_VBUSVLDEXTSEL

On/off at power on/off respectively on

- db410c
- My reference where I already know it works

I'm not really seeing the utility of - partially waggling one of two 
registers with VBUS.

Why not just push the pullup on with power-on and off with power-off..

Its worth an experiement if you have the time, if not I'll check it when 
I get back home.

---
bod