Message-ID: <085dbb83-d805-45c7-962c-2cf40a93a31a@oss.qualcomm.com>
Date: Tue, 7 Oct 2025 12:31:48 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Val Packett <val@...kett.cool>, Vinod Koul <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Neil Armstrong <neil.armstrong@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] phy: qcom: qmp-combo: Move pipe_clk on/off to common

On 10/6/25 6:13 PM, Val Packett wrote:
> 
> On 10/6/25 11:44 AM, Konrad Dybcio wrote:
>> On 9/27/25 11:17 AM, Val Packett wrote:
>>> Keep the USB pipe clock working when the phy is in DP-only mode, because
>>> the dwc controller still needs it for USB 2.0 over the same Type-C port.
>>> [..]
>>>
>>> In [1] Konrad mentioned that "the hardware disagrees" with keeping the USB
>>> PLL always on. I'm not sure what exactly was meant by disagreement there,
>>> and I didn't find any specific code that touches that PLL in the driver,
>>> so I decided to just try it anyway.
>> So what I did was playing around with the RESET_OVRD settings, which
>> dictate what parts of the PHY (and their associated PLLs) are kept online..
>> but I totally forgot that there is a branch/gate clock in GCC that sits
>> inbetween!
>>
>>> [..]
>>> I'm sure it might not be that simple but from my limited and uninformed
>>> understanding without any internal knowledge, the "sneaky workaround"
>>> might actually be the intended way to do things?
>> Normally the clock which you're enabling is sourced from the QMPPHY.
>> The other option (bar some debug outputs) is for it to be driven by
>> the 19.2 MHz always-on crystal (instead of $lots_of_mhz from the PHY).
>>
>> For USB hosts without a USB3 phy connected to them, there's an option
>> to mux the controller's PIPE clock to be sourced from the UTMI clock
>> input. In those cases, the UTMI (and therefore PIPE) clock runs at..
>> well, 19.2 MHz!
>>
>> (you can actually do that on USB3-phy-connected hosts too, at the cost
>> of.. USB3, probably)
>>
>> So I'm not sure how much of that is well thought-out design and how
>> much is luck, but this ends up working for us anyway, with seemingly
>> no downsides.
>>
>> At least that's my understanding of the situation.
> 
> I wonder how Windows drivers handle this.
> 
> The ability to use the UTMI clock sounds more appropriate for when only a legacy USB2 device is plugged in and the entirety of QMPPHY is unnecessary and can be shut down to save power.

How would you hotplug a USB3 device then?

> BTW I'm still seeing USB2 functionality die if I boot with the monitor cable *already* plugged in, but that sounds like a very different issue (the host controller starting to touch the bus before the PIPE clock is up? something something probe order?)

Unclocked accesses would result in immediate restarts

We've had some coldplug woes in the past due to the ADSP Type-C handling..
does replugging (maybe more than once, maybe in a different orientation)
fix it for you?

>> The suspend logic is broken and unused anyway, but that's a nice catch,
>> the PIPE clock in question is even conveniently called "usb3_pipe" in DT
> 
> Hmm. Is it unused? Oh, you mean the pm_runtime_forbid(), right.
> 
> Do you have any pointers about what exactly is broken there? I've been poking at the runtime PM stuff too (https://gitlab.com/Linaro/arm64-laptops/linux/-/issues/14 for USB), the PHYs are the biggest missing piece there overall..

The PHYs likely sip power compared to other things.. (but of course fixing
this would be welcome as every drop counts)

I am not sure what needs fixing, but there exists a chance that because
of the relationship that we're talking about in this thread, the xhci
suspend could use some love first.. I think there was some work on that,
somewhere?

Konrad

Powered by blists - more mailing lists