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
