Messages in this thread | | | Date | Thu, 29 Dec 2022 19:48:46 +0000 | Subject | Re: [PATCH v2 1/2] dt-bindings: phy: Add qcom,dp-manual-pullup description | From | Bryan O'Donoghue <> |
| |
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
| |