[PATCH 0/2] remoteproc: ti_k3_arm64: Program GTC FID0 register

[PATCH 0/2] remoteproc: ti_k3_arm64: Program GTC FID0 register

[Nishanth Menon]

Hi,

ARMv8's generic timer[1] picks up it's graycode from GTC. However,
the frequency of the GTC is supposed to be programmed in CNTFID0[2]
register prior to enabling the GTC in CNTCR[3] register. U-boot for K3
is currently missing that programming sequence. This series introduces
the clock nodes necessary for the lookup and writes the frequency to the
corresponding register for TF-A to pick up [4].

Based on: 62b07b5173e3 (tag: v2021.01-rc5, upstream/master) Prepare
v2021.01-rc5

J721e: https://pastebin.ubuntu.com/p/Wcxfd3BNSv/
J7200: https://pastebin.ubuntu.com/p/VsVqn7y8pv/
I dont have an AM654-evm handy at the moment, but the programming
sequences are similar in nature.

[1]
https://developer.arm.com/documentation/100095/0002/generic-timer/generic-timer-register-summary/aarch64-generic-timer-register-summary
[2]
https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntfid0
[3]
https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntcr
[4]
https://github.com/ARM-software/arm-trusted-firmware/commit/6a22d9ea3c7fa28d053d3ba264b49b7396a86f9e


Nishanth Menon (2):
  arm: dts: k3-*-r5-*-board: Add GTC clock
  remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC

 arch/arm/dts/k3-am654-r5-base-board.dts        |  1 +
 arch/arm/dts/k3-j7200-r5-common-proc-board.dts |  1 +
 arch/arm/dts/k3-j721e-r5-common-proc-board.dts |  1 +
 drivers/remoteproc/ti_k3_arm64_rproc.c         | 15 +++++++++++++++
 4 files changed, 18 insertions(+)

-- 
2.29.2

[PATCH 1/2] arm: dts: k3-*-r5-*-board: Add GTC clock

[Nishanth Menon]

Add GTC Clock definition as index 0 clock so that we can use the clock
node in the driver later on.

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 arch/arm/dts/k3-am654-r5-base-board.dts        | 1 +
 arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 1 +
 arch/arm/dts/k3-j721e-r5-common-proc-board.dts | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts b/arch/arm/dts/k3-am654-r5-base-board.dts
index d43a4edc7189..f12510259da4 100644
--- a/arch/arm/dts/k3-am654-r5-base-board.dts
+++ b/arch/arm/dts/k3-am654-r5-base-board.dts
@@ -36,6 +36,7 @@
 		power-domains = <&k3_pds 61 TI_SCI_PD_EXCLUSIVE>,
 				<&k3_pds 202 TI_SCI_PD_EXCLUSIVE>;
 		resets = <&k3_reset 202 0>;
+		clocks = <&k3_clks 61 0>;
 		assigned-clocks = <&k3_clks 202 0>;
 		assigned-clock-rates = <800000000>;
 		ti,sci = <&dmsc>;
diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
index db63d93777e0..2ac887b180c9 100644
--- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
@@ -32,6 +32,7 @@
 		power-domains = <&k3_pds 61 TI_SCI_PD_EXCLUSIVE>,
 				<&k3_pds 202 TI_SCI_PD_EXCLUSIVE>;
 		resets = <&k3_reset 202 0>;
+		clocks = <&k3_clks 61 1>;
 		assigned-clocks = <&k3_clks 202 2>, <&k3_clks 61 1>;
 		assigned-clock-rates = <2000000000>, <200000000>;
 		ti,sci = <&dmsc>;
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
index 2dde65d9681d..1f621676785e 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
@@ -28,6 +28,7 @@
 		power-domains = <&k3_pds 61 TI_SCI_PD_EXCLUSIVE>,
 				<&k3_pds 202 TI_SCI_PD_EXCLUSIVE>;
 		resets = <&k3_reset 202 0>;
+		clocks = <&k3_clks 61 1>;
 		assigned-clocks = <&k3_clks 202 2>, <&k3_clks 61 1>;
 		assigned-clock-rates = <2000000000>, <200000000>;
 		ti,sci = <&dmsc>;
-- 
2.29.2

[PATCH 2/2] remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC

[Nishanth Menon]

ARMv8's generic timer[1] picks up it's graycode from GTC. However,
the frequency of the GTC is supposed to be programmed in CNTFID0[2]
register prior to enabling the GTC in CNTCR[3] register.

In K3 architecture, GTC provides a central time to many parts of the
SoC including graycode to the generic timer in the ARMv8 subsystem.
However, due to the central nature and the need to enable the counter
early in the boot process, the R5 based u-boot enables GTC and
programs it's frequency based on central needs of the system. This
may not be a constant 200MHz based on the system. The bootloader is
supposed to program the FID0 register with the correct frequency it
has sourced for GTC from the central system controller OR from PLLs
as appropriate, and TF-A is supposed[4] to use that as the frequency for
it's local timer.

Currently we are programming just the CNTCR[3] register to enable the
GTC, however we dont let TF-A know the frequency that GTC is actually
running at. A mismatch in programmed frequency and what we program for
generic timer will, as we can imagine, all kind of weird mayhem.

So, program the CNTFID0 register with the clock frequency. Note:
assigned-clock-rates should have set the clock frequency, so the only
operation we need to explicitly do is to retrieve the frequency and
program it in FID0 register.

Since the valid in K3 for GTC clock frequencies are < U32_MAX, we can
just cast the ulong and continue.

[1] https://developer.arm.com/documentation/100095/0002/generic-timer/generic-timer-register-summary/aarch64-generic-timer-register-summary
[2] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntfid0
[3] https://developer.arm.com/docs/ddi0595/h/external-system-registers/cntcr
[4] https://github.com/ARM-software/arm-trusted-firmware/commit/6a22d9ea3c7fa28d053d3ba264b49b7396a86f9e

Signed-off-by: Nishanth Menon <nm@ti.com>
---
 drivers/remoteproc/ti_k3_arm64_rproc.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/remoteproc/ti_k3_arm64_rproc.c b/drivers/remoteproc/ti_k3_arm64_rproc.c
index 28c6ddb69191..395b74192b06 100644
--- a/drivers/remoteproc/ti_k3_arm64_rproc.c
+++ b/drivers/remoteproc/ti_k3_arm64_rproc.c
@@ -23,6 +23,7 @@
 #define INVALID_ID	0xffff
 
 #define GTC_CNTCR_REG	0x0
+#define GTC_CNTFID0_REG	0x20
 #define GTC_CNTR_EN	0x3
 
 /**
@@ -31,6 +32,7 @@
  * @rproc_rst:		rproc reset control data
  * @sci:		Pointer to TISCI handle
  * @tsp:		TISCI processor control helper structure
+ * @gtc_clk:		GTC clock description
  * @gtc_base:		Timer base address.
  */
 struct k3_arm64_privdata {
@@ -38,6 +40,7 @@ struct k3_arm64_privdata {
 	struct power_domain gtc_pwrdmn;
 	struct reset_ctl rproc_rst;
 	struct ti_sci_proc tsp;
+	struct clk gtc_clk;
 	void *gtc_base;
 };
 
@@ -73,6 +76,7 @@ static int k3_arm64_load(struct udevice *dev, ulong addr, ulong size)
 static int k3_arm64_start(struct udevice *dev)
 {
 	struct k3_arm64_privdata *rproc = dev_get_priv(dev);
+	ulong gtc_rate;
 	int ret;
 
 	dev_dbg(dev, "%s\n", __func__);
@@ -83,6 +87,11 @@ static int k3_arm64_start(struct udevice *dev)
 		return ret;
 	}
 
+	gtc_rate = clk_get_rate(&rproc->gtc_clk);
+	dev_dbg(dev, "GTC RATE= %d\n", (u32) gtc_rate);
+	/* Store the clock frequency down for GTC users to pick  up */
+	writel((u32)gtc_rate, rproc->gtc_base + GTC_CNTFID0_REG);
+
 	/* Enable the timer before starting remote core */
 	writel(GTC_CNTR_EN, rproc->gtc_base + GTC_CNTCR_REG);
 
@@ -169,6 +178,12 @@ static int k3_arm64_of_to_priv(struct udevice *dev,
 		return ret;
 	}
 
+	ret = clk_get_by_index(dev, 0, &rproc->gtc_clk);
+	if (ret) {
+		dev_err(dev, "clk_get failed: %d\n", ret);
+		return ret;
+	}
+
 	ret = reset_get_by_index(dev, 0, &rproc->rproc_rst);
 	if (ret) {
 		dev_err(dev, "reset_get() failed: %d\n", ret);
-- 
2.29.2

[PATCH 0/2] remoteproc: ti_k3_arm64: Program GTC FID0 register

[Lokesh Vutla]

On 07/01/21 12:50 am, Nishanth Menon wrote:
> Hi,
> 
> ARMv8's generic timer[1] picks up it's graycode from GTC. However,
> the frequency of the GTC is supposed to be programmed in CNTFID0[2]
> register prior to enabling the GTC in CNTCR[3] register. U-boot for K3
> is currently missing that programming sequence. This series introduces
> the clock nodes necessary for the lookup and writes the frequency to the
> corresponding register for TF-A to pick up [4].
> 
> Based on: 62b07b5173e3 (tag: v2021.01-rc5, upstream/master) Prepare
> v2021.01-rc5
> 
> J721e: https://pastebin.ubuntu.com/p/Wcxfd3BNSv/
> J7200: https://pastebin.ubuntu.com/p/VsVqn7y8pv/
> I dont have an AM654-evm handy at the moment, but the programming
> sequences are similar in nature.

Applied to u-boot-ti/for-next branch.

Thanks and regards,
Lokesh