[PATCH v5 2/5] firmware: exynos-acpm: add DVFS protocol
Tudor Ambarus
tudor.ambarus at linaro.org
Fri Sep 26 02:15:05 PDT 2025
Hi, André!
On 9/24/25 4:24 PM, André Draszik wrote:
>> + unsigned long (*get_rate)(const struct acpm_handle *handle,
>> + unsigned int acpm_chan_id,
>> + unsigned int clk_id, u32 dbg_val);
> Everything seems self-explanatory except this dbg_val. What are API users meant
> to put there? Maybe some kerneldoc could explain it?
I don't really know, there's no documentation. I can guess by reading the
downstream code.
Grepping the downstream sources reveals that this field has a value
other than zero just for the edgetpu driver.
Looking there I see:
#define TPU_DEBUG_REQ (1 << 31)
#define TPU_VDD_TPU_DEBUG (0 << 27)
#define TPU_VDD_TPU_M_DEBUG (1 << 27)
#define TPU_VDD_INT_M_DEBUG (2 << 27)
#define TPU_CLK_CORE_DEBUG (3 << 27)
#define TPU_CLK_CTL_DEBUG (4 << 27)
#define TPU_CLK_AXI_DEBUG (5 << 27)
#define TPU_CLK_APB_DEBUG (6 << 27)
#define TPU_CLK_UART_DEBUG (7 << 27)
#define TPU_CORE_PWR_DEBUG (8 << 27)
#define TPU_DEBUG_VALUE_MASK ((1 << 27) - 1)
And then I see methods like:
static int edgetpu_ctl_rate_get(void *data, u64 *val)
{
*val = exynos_acpm_get_rate(TPU_ACPM_DOMAIN,
TPU_DEBUG_REQ | TPU_CLK_CTL_DEBUG);
return 0;
}
or:
static int edgetpu_vdd_tpu_m_get(void *data, u64 *val)
{
*val = exynos_acpm_get_rate(TPU_ACPM_DOMAIN,
TPU_DEBUG_REQ | TPU_VDD_TPU_M_DEBUG);
return 0;
}
These methods are used only to be exposed for debugfs.
So it seems it's used to __get__ clock rates or voltages, and that the dbg_val
acts as a debug command that also specifies a secondary ID, TPU_ACPM_DOMAIN
being the first.
I find this a little ambiguous, so I refrained myself from adding a description.
Since I can't tell what it is, and whether TPU is really the only user or not,
I propose drop the argument or not describe it, as I already did. What's your
preference?
Thanks!
ta
More information about the linux-arm-kernel
mailing list