From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: "André Draszik" <andre.draszik@linaro.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Peter Griffin" <peter.griffin@linaro.org>,
"Michael Turquette" <mturquette@baylibre.com>,
"Stephen Boyd" <sboyd@kernel.org>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Alim Akhtar" <alim.akhtar@samsung.com>,
"Sylwester Nawrocki" <s.nawrocki@samsung.com>,
"Chanwoo Choi" <cw00.choi@samsung.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org, willmcvicker@google.com,
kernel-team@android.com
Subject: Re: [PATCH v5 2/5] firmware: exynos-acpm: add DVFS protocol
Date: Fri, 26 Sep 2025 10:15:05 +0100 [thread overview]
Message-ID: <586c85d8-7638-4e52-8f96-1aa4640afe64@linaro.org> (raw)
In-Reply-To: <03cbad1f4f311727b4dce9c969404e2bc138c556.camel@linaro.org>
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
next prev parent reply other threads:[~2025-09-26 9:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 15:10 [PATCH v5 0/5] exynos-acpm: add DVFS protocol and clock driver Tudor Ambarus
2025-09-24 15:11 ` [PATCH v5 1/5] dt-bindings: firmware: google,gs101-acpm-ipc: add ACPM clocks Tudor Ambarus
2025-09-24 15:11 ` [PATCH v5 2/5] firmware: exynos-acpm: add DVFS protocol Tudor Ambarus
2025-09-24 15:24 ` André Draszik
2025-09-26 9:15 ` Tudor Ambarus [this message]
2025-09-24 15:11 ` [PATCH v5 3/5] firmware: exynos-acpm: register ACPM clocks pdev Tudor Ambarus
2025-09-24 15:11 ` [PATCH v5 4/5] clk: samsung: add Exynos ACPM clock driver Tudor Ambarus
2025-09-24 16:00 ` André Draszik
2025-09-26 9:16 ` Tudor Ambarus
2025-09-24 15:11 ` [PATCH v5 5/5] arm64: defconfig: enable Exynos ACPM clocks Tudor Ambarus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=586c85d8-7638-4e52-8f96-1aa4640afe64@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel-team@android.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=peter.griffin@linaro.org \
--cc=robh@kernel.org \
--cc=s.nawrocki@samsung.com \
--cc=sboyd@kernel.org \
--cc=will@kernel.org \
--cc=willmcvicker@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox