u-boot/drivers/remoteproc/ti_k3_arm64_rproc.c

247 lines
5.8 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0+
/*
* Texas Instruments' K3 ARM64 Remoteproc driver
*
* Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
* Lokesh Vutla <lokeshvutla@ti.com>
*
*/
#include <common.h>
#include <dm.h>
#include <remoteproc.h>
#include <errno.h>
#include <clk.h>
#include <reset.h>
#include <asm/io.h>
#include <power-domain.h>
#include <dm/device_compat.h>
#include <linux/err.h>
#include <linux/soc/ti/ti_sci_protocol.h>
#include "ti_sci_proc.h"
#define INVALID_ID 0xffff
#define GTC_CNTCR_REG 0x0
remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC 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>
2021-01-06 19:20:32 +00:00
#define GTC_CNTFID0_REG 0x20
#define GTC_CNTR_EN 0x3
/**
* struct k3_arm64_privdata - Structure representing Remote processor data.
* @rproc_pwrdmn: rproc power domain data
* @rproc_rst: rproc reset control data
* @sci: Pointer to TISCI handle
* @tsp: TISCI processor control helper structure
remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC 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>
2021-01-06 19:20:32 +00:00
* @gtc_clk: GTC clock description
* @gtc_base: Timer base address.
*/
struct k3_arm64_privdata {
struct power_domain rproc_pwrdmn;
struct power_domain gtc_pwrdmn;
struct reset_ctl rproc_rst;
struct ti_sci_proc tsp;
remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC 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>
2021-01-06 19:20:32 +00:00
struct clk gtc_clk;
void *gtc_base;
};
/**
* k3_arm64_load() - Load up the Remote processor image
* @dev: rproc device pointer
* @addr: Address at which image is available
* @size: size of the image
*
* Return: 0 if all goes good, else appropriate error message.
*/
static int k3_arm64_load(struct udevice *dev, ulong addr, ulong size)
{
struct k3_arm64_privdata *rproc = dev_get_priv(dev);
int ret;
dev_dbg(dev, "%s addr = 0x%lx, size = 0x%lx\n", __func__, addr, size);
/* request for the processor */
ret = ti_sci_proc_request(&rproc->tsp);
if (ret)
return ret;
return ti_sci_proc_set_config(&rproc->tsp, addr, 0, 0);
}
/**
* k3_arm64_start() - Start the remote processor
* @dev: rproc device pointer
*
* Return: 0 if all went ok, else return appropriate error
*/
static int k3_arm64_start(struct udevice *dev)
{
struct k3_arm64_privdata *rproc = dev_get_priv(dev);
remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC 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>
2021-01-06 19:20:32 +00:00
ulong gtc_rate;
int ret;
dev_dbg(dev, "%s\n", __func__);
ret = power_domain_on(&rproc->gtc_pwrdmn);
if (ret) {
dev_err(dev, "power_domain_on() failed: %d\n", ret);
return ret;
}
remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC 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>
2021-01-06 19:20:32 +00:00
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);
/*
* Setting the right clock frequency would have taken care by
* assigned-clock-rates during the device probe. So no need to
* set the frequency again here.
*/
ret = power_domain_on(&rproc->rproc_pwrdmn);
if (ret) {
dev_err(dev, "power_domain_on() failed: %d\n", ret);
return ret;
}
return ti_sci_proc_release(&rproc->tsp);
}
/**
* k3_arm64_init() - Initialize the remote processor
* @dev: rproc device pointer
*
* Return: 0 if all went ok, else return appropriate error
*/
static int k3_arm64_init(struct udevice *dev)
{
dev_dbg(dev, "%s\n", __func__);
/* Enable the module */
dev_dbg(dev, "%s: rproc successfully initialized\n", __func__);
return 0;
}
static const struct dm_rproc_ops k3_arm64_ops = {
.init = k3_arm64_init,
.load = k3_arm64_load,
.start = k3_arm64_start,
};
static int ti_sci_proc_of_to_priv(struct udevice *dev, struct ti_sci_proc *tsp)
{
dev_dbg(dev, "%s\n", __func__);
tsp->sci = ti_sci_get_by_phandle(dev, "ti,sci");
if (IS_ERR(tsp->sci)) {
dev_err(dev, "ti_sci get failed: %ld\n", PTR_ERR(tsp->sci));
return PTR_ERR(tsp->sci);
}
tsp->proc_id = dev_read_u32_default(dev, "ti,sci-proc-id", INVALID_ID);
if (tsp->proc_id == INVALID_ID) {
dev_err(dev, "proc id not populated\n");
return -ENOENT;
}
tsp->host_id = dev_read_u32_default(dev, "ti,sci-host-id", INVALID_ID);
tsp->ops = &tsp->sci->ops.proc_ops;
return 0;
}
/**
* k3_of_to_priv() - generate private data from device tree
* @dev: corresponding k3 remote processor device
* @priv: pointer to driver specific private data
*
* Return: 0 if all goes good, else appropriate error message.
*/
static int k3_arm64_of_to_priv(struct udevice *dev,
struct k3_arm64_privdata *rproc)
{
int ret;
dev_dbg(dev, "%s\n", __func__);
ret = power_domain_get_by_index(dev, &rproc->rproc_pwrdmn, 1);
if (ret) {
dev_err(dev, "power_domain_get() failed: %d\n", ret);
return ret;
}
ret = power_domain_get_by_index(dev, &rproc->gtc_pwrdmn, 0);
if (ret) {
dev_err(dev, "power_domain_get() failed: %d\n", ret);
return ret;
}
remoteproc: ti_k3_arm64: Program CNTFID0 register in GTC 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>
2021-01-06 19:20:32 +00:00
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);
return ret;
}
ret = ti_sci_proc_of_to_priv(dev, &rproc->tsp);
if (ret)
return ret;
rproc->gtc_base = dev_read_addr_ptr(dev);
if (!rproc->gtc_base) {
dev_err(dev, "Get address failed\n");
return -ENODEV;
}
return 0;
}
/**
* k3_arm64_probe() - Basic probe
* @dev: corresponding k3 remote processor device
*
* Return: 0 if all goes good, else appropriate error message.
*/
static int k3_arm64_probe(struct udevice *dev)
{
struct k3_arm64_privdata *priv;
int ret;
dev_dbg(dev, "%s\n", __func__);
priv = dev_get_priv(dev);
ret = k3_arm64_of_to_priv(dev, priv);
if (ret) {
dev_dbg(dev, "%s: Probe failed with error %d\n", __func__, ret);
return ret;
}
dev_dbg(dev, "Remoteproc successfully probed\n");
return 0;
}
static const struct udevice_id k3_arm64_ids[] = {
{ .compatible = "ti,am654-arm64"},
{ .compatible = "ti,am654-rproc"},
{}
};
U_BOOT_DRIVER(k3_arm64) = {
.name = "k3_arm64",
.of_match = k3_arm64_ids,
.id = UCLASS_REMOTEPROC,
.ops = &k3_arm64_ops,
.probe = k3_arm64_probe,
.priv_auto = sizeof(struct k3_arm64_privdata),
.flags = DM_FLAG_DEFAULT_PD_CTRL_OFF,
};