Hello Sricharan,

On Wednesday, June 19, 2019 4:42:11 PM CEST Sricharan R wrote:

On 6/15/2019 2:11 AM, Christian Lamparter wrote:

quoted

On Wednesday, June 12, 2019 11:48:48 AM CEST Sricharan R wrote:

quoted

Hi Christian,

On 6/10/2019 5:45 PM, Christian Lamparter wrote:

quoted

On Monday, June 10, 2019 12:09:56 PM CEST Sricharan R wrote:

quoted

Hi Christian,

On 6/6/2019 2:11 AM, Christian Lamparter wrote:

quoted

On Wed, Jun 5, 2019 at 7:16 PM Sricharan R [off-list ref] wrote:

quoted

Add initial device tree support for the Qualcomm IPQ6018 SoC and
CP01 evaluation board.

Signed-off-by: Sricharan R <redacted>
Signed-off-by: Abhishek Sahu <redacted>

--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi

+       clocks {
+               sleep_clk: sleep_clk {
+                       compatible = "fixed-clock";
+                       clock-frequency = <32000>;
+                       #clock-cells = <0>;
+               };
+

Recently-ish, we ran into an issue with the clock-frequency of the sleep_clk
on older IPQ40XX (and IPQ806x) on the OpenWrt Github and ML.
From what I know, the external "32KHz" crystals have 32768 Hz, but the QSDK
declares them at 32000 Hz. Since you probably have access to the BOM and
datasheets. Can you please confirm what's the real clock frequency for
the IPQ6018.
(And maybe also for the sleep_clk of the IPQ4018 as well?).

What exactly is the issue that you faced ?
Looking in to the docs, it is <32000> only on ipq6018 and ipq40xx as well.

We need just a confirmation.

Then again, Currently the qcom-ipq4019.dtsi is using 32768 Hz.

|		sleep_clk: sleep_clk {
|			compatible = "fixed-clock";
|			clock-frequency = <32768>;
|			#clock-cells = <0>;
|		};

<https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom-ipq4019.dtsi#L144>

Which makes sense, because all previous Qualcomm Atheros MIPS and the
future IPQ8072 SoCs have been either using or deriving a 32768 Hz clock.

For example: The AR9344 derives the clock from the 25MHz/40MHz external
oscillator. This is explained in "8.16.9 Derived RTC Clock (DERIVED_RTC_CLK)".
Which mentions that the "32KHz" clock interval is 30.5 usec / 30.48 usec
depending whenever the external reference crystal has 40MHz or 25MHz.
(1/30.5usec = 32.7868852 kilohertz!). The QCA9558 datasheet says the same
in "10.19.11 Derived RTC Clock". 

For IPQ8072: I point to the post by Sven Eckelmann on the OpenWrt ML:
<http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017131.html>
"I was only able to verify for IPQ8072 that it had a 32.768 KHz
sleep clock." 

So this is pretty much "why there is an issue", it's confusing.
Is possible can you please look if there are (fixed) divisors values
listed in the documentation or the registers and bits that the values
are stored in? Because then we could just calculate it. 

Really sorry for the confusion. So looking little more, SLEEP_CLK is derived
from an external 38.4MHZ crystal, it is 32.768 KHZ.

That's really valuable information to have. Thank you!

quoted

Somehow the clk freq plan etc seems to mention them only as .032 MHZ and misses
out. That means i will correct the patch for 32768 and probably the
ipq8074.dtsi as well

Ok, there's one more issue that Paul found (at least with the IPQ4019),
https://patchwork.ozlabs.org/patch/1099482

it seems that the "sleep_clk" node in the qcom-ipq4019.dtsi is not used by
the gcc-ipq4019.c clk driver. this causes both wifi rtc_clks and the usb sleep
clks to dangle in the /sys/kernel/debug/clk/clk_summary (from a RT-AC58U)

   clock                         enable_cnt  prepare_cnt        rate   accuracy   phase
----------------------------------------------------------------------------------------
 xo                                       9            9    48000000          0 0
 [...]
 sleep_clk                                1            1       32768          0 0  
 gcc_wcss5g_rtc_clk                       1            1           0          0 0  
 gcc_wcss2g_rtc_clk                       1            1           0          0 0  
 gcc_usb3_sleep_clk                       1            1           0          0 0  
 gcc_usb2_sleep_clk                       1            1           0          0 0  

with his patch the /sys/kernel/debug/clk/clk_summary looks "better" 

(something like this:)

   clock                         enable_cnt  prepare_cnt        rate   accuracy   phase
----------------------------------------------------------------------------------------
 xo                                       9            9    48000000          0 0
 [...] 
 gcc_sleep_clk_src                        5            5       32000          0 0  
    gcc_wcss5g_rtc_clk                    1            1       32000          0 0  
    gcc_wcss2g_rtc_clk                    1            1       32000          0 0  
    gcc_usb3_sleep_clk                    1            1       32000          0 0  
    gcc_usb2_sleep_clk                    1            1       32000          0 0  

but judging from your comment "SLEEP_CLK is derived from an
external 38.4MHZ crystal" the gcc_sleep_clk_src / sleep_clk
should have xo as the parent. so the ideal output should be:

   clock                         enable_cnt  prepare_cnt        rate   accuracy   phase
----------------------------------------------------------------------------------------
 xo                                      10           10    48000000          0 0
 [...] 
    gcc_sleep_clk                         5            5       32768          0 0  
       gcc_wcss5g_rtc_clk                 1            1       32768          0 0  
       gcc_wcss2g_rtc_clk                 1            1       32768          0 0  
       gcc_usb3_sleep_clk                 1            1       32768          0 0  
       gcc_usb2_sleep_clk                 1            1       32768          0 0  

or am I missing/skipping over something important? 

Sorry for the delayed response. So what i said above (32768 clk) looks
like true only for ipq8074. For ipq4019, looks like 32000.

That means, there is still some thing unclear. I am checking for precise
information from HW team for ipq4019/8074/6018. Please hang on, will
update you asap.

Thank you for looking this up! I'll definitely stick around for the final
verdict.

Also, I think the "xo" clk of your IPQ6018 dts should get the
"always-on;" property (any maybe sleep_clk as well?).

Paul discovered that the QSDK had this extra commit
<https://lore.kernel.org/patchwork/patch/1089385/>
(Maybe the changeid can help you look it up internally)

For IPQ4019, this enables the high resolution with a 1ns resolution
instead of 10ms.

(echo q > /proc/sysrq-trigger can be used to check this just look for
the "resolution" value before and after.) 

Cheers,
Christian