TMDX654IDKEVM: AM65x

Dhruva,

I may need some help from others on the team, but I'd like to get things started.  From a hardware perspective, please refer to Section 6.5.3 PRU_ICSSG Integration in the AM65xx Technical Reference Manual.  Here's an excerpt:

The PRU cores supports three clock speeds — 200 MHz, 225 MHz (default), and 250 MHz. Below are the
basic register configurations required for enabling each clock speed:
• 200 MHz
– CTRLMMR_ICSSGn_CLKSEL[0] CORE_CLKSEL = 1 (CPSWHSDIV_CLKOUT2 is source clock)
– ICSSG_CORE_SYNC_REG[0] CORE_VBUSP_SYNC_EN = 0 (Async Mode, default)
• 225 MHz
– CTRLMMR_ICSSGn_CLKSEL[0] CORE_CLKSEL = 0 (PER1HSDIV_CLKOUT1, default)
– ICSSG_CORE_SYNC_REG[0] CORE_VBUSP_SYNC_EN = 0 (Async Mode, default)
• 250 MHz
– CTRLMMR_ICSSGn_CLKSEL[0] CORE_CLKSEL = don’t care
– ICSSG_CORE_SYNC_REG[0] CORE_VBUSP_SYNC_EN = 1 (Sync-to-VCLK Mode)

Which ICSSG are you using?  ICSSG0?  For starters, please check the corresponding register values:

• CTRLMMR_ICSSG0_CLKSEL, address 0010 8040h
• ICSSG_CORE_SYNC_REG, address 0B02 603Ch

Given the info in the TRM, I expect to see that ICSSG_CORE_SYNC_REG = 1 and that's why you see a 4ns clock.  That bit however cannot simply be cleared in software.  The ICSSG must be reset in order to clear that bit.  We will need to understand where/why that bit is being set so that we can adjust the software accordingly.  Please confirm the bit is set before we launch into that investigation.

Best regards,
Brad

Hi Brad,

Thanks for the response. We have confirmed that ICSSG_CORE_SYNC_REG is set to 1. 

Regards,

Dhruva Krishnadas

Dhruva,

Thanks for the confirmation.  I'm still working to resolve this issue.  I have a partial solution for you.  In your dts file, add the following:

&icssg0_coreclk_mux {

               assigned-clock-parents = <&k3_clks 62 19>;

};

Let me explain it a bit more...  It's meant to modify this entry from k3-am65-main.dtsi:

icssg0_coreclk_mux: coreclk_mux {
#clock-cells = <0>;
clocks = <&k3_clks 62 19>, /* icssg0_core_clk */
<&k3_clks 62 3>; /* icssg0_iclk */
assigned-clocks = <&icssg0_coreclk_mux>;
assigned-clock-parents = <&k3_clks 62 3>;
};

The first two lines I highlighted define the inputs to the mux.  I'm specifically referring to the mux controlled by ICSSG_CORE_SYNC_REG.  The code as it is originally written is selecting icssg0_iclk which is the 250 MHz clock.  The update is to choose the other clock (icssg0_core_clk). 

With that change to the dts file, you should observe that ICSSG_CORE_SYNC_REG now has a value of 0 instead of 1.  Please confirm.

The icssg0_core_clk actually comes from yet another mux.  That particular mux relates to the other register I mentioned, CTRLMMR_ICSSG0_CLKSEL.  By default that register defaults to a value of 0 which will result in a 225 MHz PRU clock.  As a temporary workaround you should be able to force the mux to the desired value by doing something like executing:

devmem2 0x00108040 w 1

I'm looking into a more appropriate solution still.  Perhaps you have some ideas?  Feel free to share any thoughts.

Best regards,
Brad

Dhruva,

I just did some testing on my board so I could do some sanity checking of the registers.  Here's the patch that I made:

diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index 93d7243f83..b8f06694b6 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -546,3 +546,8 @@
>;
};
};
+
+&icssg0_coreclk_mux {
+ assigned-clocks = <&k3_clks 62 19>, <&icssg0_coreclk_mux>;
+ assigned-clock-parents = <&k3_clks 62 21>, <&k3_clks 62 19>;
+};

With this patch to my dtb, I was able to confirm that both registers were configured as expected:

root@am65xx-evm:~# devmem2 0x0b02603c
/dev/mem opened.
Memory mapped at address 0xffffa4e80000.
Read at address 0x0B02603C (0xffffa4e8603c): 0x00000000

root@am65xx-evm:~# devmem2 0x00108040
/dev/mem opened.
Memory mapped at address 0xffff8eff0000.
Read at address 0x00108040 (0xffff8eff8040): 0x00000001

Please apply this patch, verify that the registers are reading the expected values as I have shown, and then re-run your test to confirm that ICSSG is running at 200 MHz (5 ns period).

Best regards,
Brad

I forgot to mention something that will help make some sense of the patch.  The "magic numbers" in the patch for the k3_clks come from this documentation:

http://downloads.ti.com/tisci/esd/latest/5_soc_doc/am6x/clocks.html#clocks-for-pru-icssg0-device

The first argument 62 is the identifier for ICSSG0.  The second argument relates to the Clock ID shown in the documentation.  The clock configuration is performed by the DMSC, which is why we are leveraging these identifiers, i.e. the underlying software is communicating via TI-SCI with the DMSC to request this clock configuration.