Re: [PATCH 1/9] dt-bindings: usb: qcom,snps-dwc3: Add ability to select UTMI as reference clock

[George Moussalem]

On 8/30/26 13:41, Krzysztof Kozlowski wrote:
> On Tue, Aug 25, 2026 at 02:42:26PM +0400, George Moussalem wrote:
>> Add ability to select the UTMI clock as reference clock which is passed
>> by the glue layer to the DWC3 core to calculate the reference clock
>> period and frame length adjustment based on its clock rate.
>>
>> In the flattened snsp-dwc3 model, it is currently not possible to pass a
>> reference clock that differs from the default since:
>> commit 613a2e655d4d ("usb: dwc3: core: Expose core driver as library")
>>
>> This prevents moving chipsets such as IPQ5018, IPQ6018, IPQ5332, IPQ5424
>> and IPQ9574 with a reference clock rate different from 19.2 MHz from
>> moving to the flattened model.
>>
>> The Qualcomm takes care of clock and resets management itself and sets
>> the ignore_clocks_and_resets flag in dwc3_probe_data to true, so the
>> core doesn't acquire the reference clock from the devicetree.
>>
>> The existing DT property 'snps,quirk-ref-clk-period-ns' has been
>> deprecated.
> 
> There is no such property.
> 
> 
>>
>> So, add a property to select the UTMI clock used by many (if not all)
>> Qualcomm USB controllers as the reference clock.
>>
>> Signed-off-by: George Moussalem <george.moussalem@xxxxxxxxxxx>
>> ---
>>  Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
>> index ea60f7220afe..aa263dfd42a1 100644
>> --- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
>> +++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
>> @@ -155,6 +155,15 @@ properties:
>>        HS/FS/LS modes are supported.
>>      type: boolean
>>  
>> +  qcom,select-utmi-as-ref-clk:
>> +    description:
>> +      If present, pass the UTMI clock as the reference clock to the DWC3 core to
>> +      use its clock rate to calculate the reference clock period and frame
>> +      length adjustment in GUCTL and GFLADJ registers. This is needed when these
>> +      values based on the standard clock rate deviate from the hardware default
>> +      values. If not set, the hardware default values are used.
> 
> Sashiko comment seems valid. You describe Linux behavior. In your commit
> msg you mention that clock cannot be passed since commit 613a2e655d4d,
> which is a driver commit. So trivial answer would be: if issue was
> caused by driver commit, then fix is within driver, not bindings.

The issue stems from collapsing the snps and dwc nodes into one: the
same clock was passed as "mock_utmi" in snps and as "ref" in the dwc
child node. In the flattened model, this causes two issues:
1. the core driver gets the ref clock by name ("ref") but you would
break the binding by changing the clock name from mock_utmi to ref and
perhaps causes backwards compatibility issues.
2. Even if you change the clock name, the new qcom glue layer sets
ignore_clocks_and_resets to true in the probe_data struct which means
the core driver doesn't acquire and manage the clocks/resets.

> 
> Maybe there is different issue which is not purely-driver specific, but
> I did not get that from description.
> 
> For example, if given SoC has different rates, then the SoC-specific DWC
> compatible defines which clock to use and you do not need such property.

That was possible in the 'old' way because it was allowed to pass the
same clock as both the mock_utmi and ref clock, albeit in different
nodes targeting snps and dwc respectively.

To solve it in the driver itself means we'd need to create compatible
specific match data structs which currently aren't in the driver and all
SoCs that require it (at least the ones in this series) wouldn't be able
to just use qcom,snps-dwc as the fallback. This would increase
complexity of the driver (which now is nice and simple) and would
require a change to the bindings too.
In addition, for some SoCs such as IPQ6018, we'd need two compatibles
because it has two USB controllers and only one of them requires setting
the ref clock.

Kindly advise so I can adjust v-next of the series accordingly.

> 
> Best regards,
> Krzysztof
> 
> 

Thanks,
George