accel/amdxdna: add query DPM level and DPM frequency table support by donwalkarsoham · Pull Request #1465 · amd/xdna-driver

donwalkarsoham · 2026-06-30T18:00:06Z

No description provided.

Copilot

Pull request overview

This PR improves clock/TOPS reporting for the amdxdna AIE4/NPU3 path by adding firmware queries for the current DPM level and the firmware-programmed (per-silicon) DPM frequency tables, then using those to report live domain frequencies.

Changes:

Add new AIE4 management message opcodes and ABI structs for querying DPM frequency tables and current DPM levels.
Cache firmware-authoritative DPM frequency tables at probe and use them (plus a live DPM level query) to resolve current AIE/NPU-H frequencies.
Update clock metadata reporting to rely on refreshed live clock values from aie_update_counters().

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
drivers/accel/amdxdna/npu3_regs.c	Update counters to prefer sensor telemetry when available, otherwise query FW DPM level and map to frequency (FW table preferred, static table fallback).
drivers/accel/amdxdna/aie4_pci.h	Extend device handle with cached FW DPM tables and add prototypes for new DPM query/init helpers.
drivers/accel/amdxdna/aie4_pci.c	Initialize DPM frequency table cache during AIE4 device query and clarify clock metadata reporting.
drivers/accel/amdxdna/aie4_msg_priv.h	Define new AIE4 message opcodes and request/response structs for DPM table/level queries.
drivers/accel/amdxdna/aie4_message.c	Implement querying/caching of FW DPM frequency tables and querying current FW DPM levels.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

xdavidz · 2026-07-01T18:36:40Z


-	aie->npuclk_freq = npu_metrics.mpnpuclk_freq;
-	aie->hclk_freq = npu_metrics.npuclk_freq;
+	if (ndev->dpm_aie_levels && ndev->dpm_npuh_levels) {


@donwalkarsoham this code... generated by AI?

Hi @xdavidz,
As discussed, this is an initial copy for giving an idea of the changes and this needs further review, changes and testing. As suggested, using some AI tools for workflow.

xdavidz · 2026-07-06T18:27:08Z

 	u32				total_col;
 	u32				max_dpm_level;

+	/* FW-provided DPM frequency tables (MHz); *_levels == 0 if unavailable */


There is a dpm_clk_tbl in amdxdna_dev_priv, but you add another in the amdxdna_dev_hdl.

I understand this is a cache of current dpm level, thus the other one in the priv is obsolated?

I think the logic is not.

We do have 2 dpm_clk_freq arrrays, one is hardcoded, one is dynamically quired from the fw. if dynamic query failed, then use the hardcode one.

you might consider adding it to the amdxdna_dev_priv for dpm_clk_tbl, and only update it when query is successful. So the logic is a little different than windows driver.

We always query from the dpm_clk_tbl, but we do update the dpm_clk_tbl once by querying the fw when aie4_pci init.

Do this make better sense?

ok got it, makes sense. So, we query the FW table at aie4_pci initialization and update the dpm_clk_tbl. After this, we only query the dpm_clk_tbl during run time.

ok got it, makes sense. So, we query the FW table at aie4_pci initialization and update the dpm_clk_tbl. After this, we only query the dpm_clk_tbl during run time.

We query dpm freq from FW during initializaioon and update the dpm_clk_tbl, if query is failed, use the default freq.

We query the dpm_clk_tbl freq during run time.
2.1) During the run time query, we also call update_dpm from pmf, if pmf is not ready, we skip updating the final freq.

In this way, we have good dpm_clk_tbl and also accurate freq when pmf is working. I think current code structure support this flow.

Thanks, that flow makes sense.
One implementation detail: Since priv->dpm_clk_tbl is const and shared across devices, we can't update it in place. We can leave it as the read-only default template and add a small writable array in the per-device amdxdna_dev_hdl. At init, we can copy the defaults into that per-device array, then overwrite it with the FW values if the query succeeds (if it fails, it just keeps the defaults). At runtime we will read frequencies from this per-device table if PMF is not available. That way priv stays immutable, each device has its own correct table, and there's a single table to index.

Added the changes.

Added the changes.

I will review this today.

Copilot

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

+	n = min_t(u32, resp.aieclk_table.num_levels, resp.npuhclk_table.num_levels);
+	n = min_t(u32, n, AIE4_MAX_DPM_LEVEL_COUNT);
+	for (i = 0; i < n; i++) {
+		ndev->dpm_clk_tbl[i].npuclk = resp.aieclk_table.values[i];
+		ndev->dpm_clk_tbl[i].hclk = resp.npuhclk_table.values[i];
+	}
+
+	return 0;


xdavidz · 2026-07-08T18:57:37Z

+	if (!ret) {
+		aie->npuclk_freq = npu_metrics.mpnpuclk_freq;
+		aie->hclk_freq = npu_metrics.npuclk_freq;
+	} else if (!aie4_query_dpm_level(ndev, &aieclk_level, &npuhclk_level)) {


I do not think this logic is right, let's sync up offline.

the logic here is:

during fw boot (load fw), query dpm level and dpm freq

each time query will call_get_sensors to get most accurate data
2.0) if query success, use the pmf sensor data
2.1) if the query failed, maybe not support this etc, use the dpm level data. Given the dpm level data is either hardcoded or set correctly by No.1 step, we don't need to redo the query, just get what ever date from the dpm level.

Thus, I think you don't have to use windows driver's example (if 0 then not query).

I think you should:

still use the priv->dpm_level to update the dpm_table

if dpm_query failed, warn but skip updating the dpm_table

That's it.

Signed-off-by: Soham Donwalkar <Soham.Donwalkar@amd.com>

donwalkarsoham requested review from houlz0507, maxzhen and xdavidz as code owners June 30, 2026 18:00

xdavidz added the do-not-review label Jun 30, 2026

xdavidz requested a review from Copilot June 30, 2026 18:19

Copilot started reviewing on behalf of xdavidz June 30, 2026 18:20 View session

Copilot AI reviewed Jun 30, 2026

View reviewed changes

Comment thread drivers/accel/amdxdna/aie4_message.c

Comment thread drivers/accel/amdxdna/npu3_regs.c Outdated

xdavidz reviewed Jul 1, 2026

View reviewed changes

donwalkarsoham force-pushed the xrt-smi-validate-dpm branch 2 times, most recently from c38174c to 78678a8 Compare July 1, 2026 23:30

donwalkarsoham requested a review from xdavidz July 1, 2026 23:49

donwalkarsoham removed the do-not-review label Jul 1, 2026

xdavidz requested changes Jul 6, 2026

View reviewed changes

donwalkarsoham force-pushed the xrt-smi-validate-dpm branch from 78678a8 to 01f6dc8 Compare July 6, 2026 22:56

donwalkarsoham requested a review from xdavidz July 6, 2026 23:21

donwalkarsoham force-pushed the xrt-smi-validate-dpm branch from 01f6dc8 to 98cd198 Compare July 7, 2026 16:30

xdavidz requested a review from Copilot July 8, 2026 16:51

Copilot started reviewing on behalf of xdavidz July 8, 2026 16:52 View session

Copilot AI reviewed Jul 8, 2026

View reviewed changes

donwalkarsoham force-pushed the xrt-smi-validate-dpm branch from 98cd198 to 0504cfc Compare July 8, 2026 18:49

xdavidz requested changes Jul 8, 2026

View reviewed changes

donwalkarsoham force-pushed the xrt-smi-validate-dpm branch 3 times, most recently from 0ba087e to 42c0e80 Compare July 15, 2026 19:45

donwalkarsoham force-pushed the xrt-smi-validate-dpm branch from 42c0e80 to 7410b30 Compare July 15, 2026 23:21

donwalkarsoham requested a review from xdavidz July 15, 2026 23:45

xdavidz approved these changes Jul 16, 2026

View reviewed changes

donwalkarsoham requested a review from NishadSaraf July 16, 2026 23:12

accel/amdxdna: add query DPM level and DPM frequency table support

02675ed

Signed-off-by: Soham Donwalkar <Soham.Donwalkar@amd.com>

donwalkarsoham force-pushed the xrt-smi-validate-dpm branch from 7410b30 to 02675ed Compare July 16, 2026 23:12

Uh oh!

Conversation

donwalkarsoham commented Jun 30, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants