[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d1cd6d30-2142-765b-c201-4d6662576665@linaro.org>
Date: Thu, 29 Dec 2022 19:48:46 +0000
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Stephan Gerhold <stephan@...hold.net>
Cc: agross@...nel.org, andersson@...nel.org, vkoul@...nel.org,
kishon@...nel.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, konrad.dybcio@...aro.org,
linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: phy: Add qcom,dp-manual-pullup
description
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
Powered by blists - more mailing lists