This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM69: PCIE REFCLK OUT and ACSPCIE mappings

Part Number: AM69

Tool/software:

Hello TI Experts,
We have custom hardware based on the AM69 SoC and intend to use the PCIE_SOC_REFCLK0_OUT, PCIE_SOC_REFCLK1_OUT, PCIE_SOC_REFCLK2_OUT, and PCIE_SOC_REFCLK3_OUT pins to provide reference clocks for PCIe devices.
Based on the AM69 TRM and patches from the J784S4 EVM board, I identified the need to enable the ACSPCIE0 and ACSPCIE1 modules in the device tree (patches below).

I have the following questions:

  1. For the pcie3_rc (pcie@2930000) node, the PCIe reference clock functions only when ti,syscon-acspcie-proxy-ctrl = <&acspcie0_proxy_ctrl 0x3>. Similarly, should the pcie2_rc (pcie@2920000) node have ti,syscon-acspcie-proxy-ctrl = <&acspcie1_proxy_ctrl 0x3>?  When bit-mask is 0x2 or 0x1 instead of 0x3 , PCIe ref clocks does not work.

    Is this configuration correct? Additionally, how is the ACSPCIE clock buffer mapped for each SERDES ?

  2. Although the PCIe reference clocks are running at 100MHz on the actual hardware, the k3conf dump clocks command shows all DEV_BOARD0_PCIE_REFCLK* values as 0. Could you clarify why this is happening ?

Logs: /cfs-file/__key/communityserver-discussions-components-files/791/Aquila_5F00_AM69_5F00_PCIe_5F00_Tests_5F00_with_5F00_Internal_5F00_PCIE_5F00_REFCLK_5F00_Console_5F00_Logs.txt

Patches:

From 889e4f447920cba44bc61a6fb4e9f3a4545bdc1d Mon Sep 17 00:00:00 2001
From: Parth Pancholi <parth.pancholi@toradex.com>
Date: Fri, 7 Mar 2025 11:02:20 +0100
Subject: [PATCH 1/2] arm64: dts: ti: k3-j784s4-main: Enable ACSPCIE0 output
 for PCIe3

The PCIe reference clock required by the PCIe Endpoints corresponding to the
PCIe3 instance could be driven by the ACSPCIE0 module. Add the device-tree
support for enabling the same.

TODO: bitmask 0x3 for '<&acspcie0_proxy_ctrl 0x3>' is not clear.

Upstream-Status: Pending
Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index ab4a8c4444bb..f7557d2341e6 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -1205,11 +1205,12 @@ pcie3_rc: pcie@2930000 {
 		interrupts = <GIC_SPI 354 IRQ_TYPE_EDGE_RISING>;
 		device_type = "pci";
 		ti,syscon-pcie-ctrl = <&pcie3_ctrl 0x0>;
+		ti,syscon-acspcie-proxy-ctrl = <&acspcie0_proxy_ctrl 0x3>;
 		max-link-speed = <3>;
 		num-lanes = <2>;
 		power-domains = <&k3_pds 335 TI_SCI_PD_EXCLUSIVE>;
-		clocks = <&k3_clks 335 0>;
-		clock-names = "fck";
+		clocks = <&k3_clks 335 0>, <&serdes0 CDNS_TORRENT_REFCLK_DRIVER>;
+		clock-names = "fck", "pcie_refclk";
 		#address-cells = <3>;
 		#size-cells = <2>;
 		bus-range = <0x0 0xff>;
-- 
2.34.1


From 30642b45b151a52c4ad08a73177db0ddd4962112 Mon Sep 17 00:00:00 2001
From: Parth Pancholi <parth.pancholi@toradex.com>
Date: Fri, 7 Mar 2025 11:14:34 +0100
Subject: [PATCH 2/2] arm64: dts: ti: k3-j784s4-main: Enable ACSPCIE1 output
 for PCIe0 and PCIe2

The PCIe reference clock required by the PCIe Endpoints corresponding to the
PCIe0 and PCIe2 instances could be driven by the ACSPCIE1 module. Add the
device-tree support for enabling the same.

TODO: bitmask 0x3 for '<&acspcie1_proxy_ctrl 0x3>' is not clear.

Upstream-Status: Pending
Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index f7557d2341e6..46ea13f049b7 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -147,6 +147,11 @@ acspcie0_proxy_ctrl: acspcie0-ctrl@1a090 {
 			reg = <0x1a090 0x4>;
 		};
 
+		acspcie1_proxy_ctrl: acspcie1-ctrl@1a094 {
+			compatible = "ti,j784s4-acspcie-proxy-ctrl", "syscon";
+			reg = <0x1a094 0x4>;
+		};
+
 		serdes_ln_ctrl: mux-controller@4080 {
 			compatible = "reg-mux";
 			reg = <0x00004080 0x30>;
@@ -1117,11 +1122,12 @@ pcie0_rc: pcie@2900000 {
 		interrupts = <GIC_SPI 318 IRQ_TYPE_EDGE_RISING>;
 		device_type = "pci";
 		ti,syscon-pcie-ctrl = <&pcie0_ctrl 0x0>;
+		ti,syscon-acspcie-proxy-ctrl = <&acspcie1_proxy_ctrl 0x1>;
 		max-link-speed = <3>;
 		num-lanes = <4>;
 		power-domains = <&k3_pds 332 TI_SCI_PD_EXCLUSIVE>;
-		clocks = <&k3_clks 332 0>;
-		clock-names = "fck";
+		clocks = <&k3_clks 332 0>, <&serdes1 CDNS_TORRENT_REFCLK_DRIVER>;
+		clock-names = "fck", "pcie_refclk";
 		#address-cells = <3>;
 		#size-cells = <2>;
 		bus-range = <0x0 0xff>;
@@ -1176,11 +1182,12 @@ pcie2_rc: pcie@2920000 {
 		interrupts = <GIC_SPI 342 IRQ_TYPE_EDGE_RISING>;
 		device_type = "pci";
 		ti,syscon-pcie-ctrl = <&pcie2_ctrl 0x0>;
+		ti,syscon-acspcie-proxy-ctrl = <&acspcie1_proxy_ctrl 0x3>;
 		max-link-speed = <3>;
 		num-lanes = <2>;
 		power-domains = <&k3_pds 334 TI_SCI_PD_EXCLUSIVE>;
-		clocks = <&k3_clks 334 0>;
-		clock-names = "fck";
+		clocks = <&k3_clks 334 0>, <&serdes1 CDNS_TORRENT_REFCLK_DRIVER>;
+		clock-names = "fck", "pcie_refclk";
 		#address-cells = <3>;
 		#size-cells = <2>;
 		bus-range = <0x0 0xff>;
-- 
2.34.1


Thank you.

Regards,

Parth P

  • Hi Parth,

    Great to see you again.

    The mapping for ACSPCIE to PCIe* should be:

    • PCIe0 -> ACSPCIE1 PAD0
    • PCIe1 -> ACSPCIE0 PAD0
    • PCIe2 -> ACSPCIE1 PAD1
    • PCIe3 -> ACSPCIE0 PAD1

    Value 0x2 should work as well for PAD1, but value of 0x3 should also be fine... if 0x2 is not working but 0x3 is working, then what I can imagine is happening is that the bits are being overwritten, since each ACSPCIe instance supports two interfaces.

    As for k3conf, it should be fine if the ACSPCIe clocks are getting set.

    Regards,

    Takuma

  • Hi ,

    It's great to hear back from you!

    Thanks for sharing the mapping information.

    Value 0x2 should work as well for PAD1, but value of 0x3 should also be fine... if 0x2 is not working but 0x3 is working, then what I can imagine is happening is that the bits are being overwritten, since each ACSPCIe instance supports two interfaces.

    Could you please clarify what you mean by "bits are overwritten"? Are you referring to PAD0 and PAD1 configurations being overwritten?
    If we need both PAD0 and PAD1 clocks enabled, should the last two bits of the ACSPCIE* CTRL_MMR registers be set to 11b (0x3)? Is that the correct understanding?

    As for k3conf, it should be fine if the ACSPCIe clocks are getting set.

    Also, is there any known limitation or issue causing dump clocks to not work correctly for  DEV_BOARD0_PCIE_REFCLK*?

    As we plan to use PCIe reference clocks from the AM69 SoC in our hardware, these details are crucial for us to fully understand.

    Thank you.

    Regards,

    Parth P

  • Hi Parth,

    Yes, last two bits for PAD0 and PAD1. Bit 0 controls PAD0 and bit 1 controls PAD1.

    k3conf reads all the clocks that are defined in TISCI API. I do not think we set DEV_BOARD0_PCIE_REFCLK* in devicetree, and this does not default to a value during TISCI initialization as well. Hence this is 0. 

    Is there an issue currently being faced with reference clock on the custom hardware, and is this the reason why the details are needed?

    Regards,

    Takuma

  • Hi ,

    Thank you for the clarification; that was helpful.

    At this point, I haven’t encountered any apparent issues in the initial tests I conducted using each of the PCIe reference clocks across different PCIe endpoint devices.

    My intent in exploring these topics from a software perspective was to validate the expected configurations and ensure that the clocks are being generated correctly as a result of proper configuration settings.

    Regards,

    Parth P

  • Hi Parth,

    Understood. I will mark this thread as resolved, but please feel free to re-open or start a new thread if an issue arise.

    Regards,

    Takuma