On Thu, Dec 29, 2022 at 07:48:46PM +0000, Bryan O'Donoghue wrote: > 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. > Correct. If I'm reading the DB410c schematic correctly the USB_HS_ID on DB410c is actually derived from VBUS on the micro USB port (and not the ID pin of the port as one would normally expect). > But not ULPI_MISC_A_VBUSVLDEXTSEL this is the additional register that > downstream updates when "VBUS is not routed to the controller" AFAICT ULPI_MISC_A_VBUSVLDEXTSEL is set in qcom_usb_hs_phy_set_mode() if the USB controller enables device mode? (And disabled again in host mode.) > > 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. > The bit-level description of this register in the public APQ8016E TRM [1] is not very useful (page 1957): VBUSVLDEXTSEL = "External VBUS valid select" VBUSVLDEXT = "External VBUS valid indicator" But I think VBUSVLDEXTSEL basically means "Use external VBUS state from VBUSVLDEXT instead of internal detection". And VBUSVLDEXT then contains the actual VBUS state. The VBUS state is then probably used somewhere inside the USB controller or PHY to enable necessary USB protocol things such as enabling this "DP pull-up" (to be fair I have no idea how the USB protocol really works :)). [1]: https://developer.qualcomm.com/download/sd410/snapdragon-410e-technical-reference-manual.pdf > > 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.. > I don't feel qualified to comment on this. I'd just follow the suggestion from the docs here to make VBUSVLDEXT effectively represent the result of the external VBUS detection (see APQ8016E TRM [1] section 6.4.5.3.3 Software control for SESS_VALID, page 1927). DB410c and other devices with USB hub are obviously a bit special, but I think it works correctly for DB410c at the moment because its USB_HS_ID GPIO basically indicates the incoming VBUS on the micro USB port. There might be some funky design where it is completely impossible to detect the incoming VBUS. In that case we have no choice but to force the detected VBUS state on permanently. Thanks, Stephan [1]: https://developer.qualcomm.com/download/sd410/snapdragon-410e-technical-reference-manual.pdf
