[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1309c23-530b-c698-b7ba-4f1a5226fe8c@quicinc.com>
Date: Mon, 24 Jan 2022 20:41:26 +0530
From: Kathiravan Thirumoorthy <quic_kathirav@...cinc.com>
To: Baruch Siach <baruch@...s.co.il>,
Kathiravan T <kathirav@...eaurora.org>
CC: Sean Anderson <sean.anderson@...o.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
<linux-usb@...r.kernel.org>, Felipe Balbi <balbi@...nel.org>,
Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
"Balaji Prakash J" <bjagadee@...eaurora.org>,
<linux-kernel@...r.kernel.org>,
Robert Hancock <robert.hancock@...ian.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Michal Simek <michal.simek@...inx.com>,
"Rob Herring" <robh+dt@...nel.org>, <devicetree@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v2 0/7] usb: dwc3: Calculate REFCLKPER et. al. from
reference clock
Hi Baruch,
On 1/20/2022 3:59 PM, Baruch Siach wrote:
> Hi Kathiravan,
>
> On Thu, Jan 20 2022, Kathiravan T wrote:
>> On 2022-01-19 23:44, Baruch Siach wrote:
>>> Hi Sean,
>>> On Tue, Jan 18 2022, Sean Anderson wrote:
>>>> This is a rework of patches 3-5 of [1]. It attempts to correctly program
>>>> REFCLKPER and REFCLK_FLADJ based on the reference clock frequency. Since
>>>> we no longer need a special property duplicating this configuration,
>>>> snps,ref-clock-period-ns is deprecated.
>>>> Please test this! Patches 3/4 in this series have the effect of
>>>> programming REFCLKPER and REFCLK_FLADJ on boards which already configure
>>>> the "ref" clock. I have build tested, but not much else.
>>> Tested here on IPQ6010 based system. USB still works. But the with
>>> "ref"
>>> clock at 24MHz, period is calculated as 0x29. Previous
>>> snps,ref-clock-period-ns value used to be 0x32.
>>> Is that expected?
>> Yes, it is 0x29 for IPQ60xx based SoCs. In downstream it was wrongly mentioned
>> as 0x32, which was corrected recently.
> Thanks for the update. This needs fixing in upstream kernel. I'll send a
> patch.
>
> For some reason USB appears to work here with both values. Is it because
> I only use USB2 signals? If this is the case them I can not actually
> test this series on my system.
I could recollect we did see some issue on USB2.0 port as well, but it
wasn't fatal one. Anyways it is better to test it.
Thanks,
Kathiravan T.
>
> Thanks,
> baruch
>
>>>> [1]
>>>> https://lore.kernel.org/linux-usb/20220114044230.2677283-1-robert.hancock@calian.com/
>>>> Changes in v2:
>>>> - Document clock members
>>>> - Also program GFLADJ.240MHZDECR
>>>> - Don't program GFLADJ if the version is < 2.50a
>>>> - Add snps,ref-clock-frequency-hz property for ACPI
>>>> Sean Anderson (7):
>>>> dt-bindings: usb: dwc3: Deprecate snps,ref-clock-period-ns
>>>> usb: dwc3: Get clocks individually
>>>> usb: dwc3: Calculate REFCLKPER based on reference clock
>>>> usb: dwc3: Program GFLADJ
>>>> usb: dwc3: Add snps,ref-clock-frequency-hz property for ACPI
>>>> arm64: dts: zynqmp: Move USB clocks to dwc3 node
>>>> arm64: dts: ipq6018: Use reference clock to set dwc3 period
>>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 7 +-
>>>> arch/arm64/boot/dts/qcom/ipq6018.dtsi | 3 +-
>>>> .../arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 4 +-
>>>> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 4 +-
>>>> drivers/usb/dwc3/core.c | 112 +++++++++++++++---
>>>> drivers/usb/dwc3/core.h | 17 ++-
>>>> 6 files changed, 120 insertions(+), 27 deletions(-)
>
Powered by blists - more mailing lists