public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/msm/dpu: fix mismatch between power and frequency
Date: Tue, 10 Mar 2026 12:42:47 +1000	[thread overview]
Message-ID: <review-patch1-20260309063720.13572-1-yuanjie.yang@oss.qualcomm.com> (raw)
In-Reply-To: <20260309063720.13572-1-yuanjie.yang@oss.qualcomm.com>

Patch Review

**Commit message:** The commit message is well-written with a clear explanation of the race condition between `rpmhpd_sync_state` and `dpu_kms_hw_init`, and the resulting voltage/clock mismatch. The ASCII timeline diagram is a nice touch for illustrating the concurrency issue.

**Code change:**

```c
-	/* Drop the performance state vote */
-	dev_pm_opp_set_rate(dev, 0);
 	clk_bulk_disable_unprepare(dpu_kms->num_clocks, dpu_kms->clocks);
```

The removal is clean and correct. Two observations:

1. **Asymmetry concern is addressed:** The resume path at `dpu_kms.c:1485` only calls `clk_bulk_prepare_enable()` and never restores the OPP rate, so removing the drop in suspend eliminates the unpaired voltage reduction.

2. **Potential concern — performance state leak during suspend:** By not calling `dev_pm_opp_set_rate(dev, 0)`, the performance state vote from the last `dev_pm_opp_set_rate(&kms->pdev->dev, clk_rate)` call in `dpu_core_perf.c:398` remains active even during suspend. However, since the clocks are being disabled and the ICC bandwidth is zeroed (`icc_set_bw(dpu_kms->path[i], 0, 0)` at line 1469), runtime PM should still allow the power domain to scale down appropriately once the device is fully suspended. The OPP framework will reconcile when genpd aggregates votes. This should be fine in practice, but **the maintainers should confirm** that not explicitly dropping the OPP vote doesn't prevent the power domain from reaching a low-power state during suspend on all affected platforms.

3. **Fixes tag is correct:** The referenced commit `b0530eb11913` is the one that introduced the OPP API usage in this driver.

**Verdict:** The patch looks correct and addresses a real bug. The fix is minimal and appropriate. The only question worth raising with the maintainers is whether the stale OPP vote could prevent optimal power savings during runtime suspend, but given that genpd aggregation handles this when the device is fully powered off, this should be fine.

---
Generated by Claude Code Patch Reviewer

      parent reply	other threads:[~2026-03-10  2:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09  6:37 [PATCH v2] drm/msm/dpu: fix mismatch between power and frequency yuanjie yang
2026-03-10  2:42 ` Claude review: " Claude Code Review Bot
2026-03-10  2:42 ` Claude Code Review Bot [this message]

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=review-patch1-20260309063720.13572-1-yuanjie.yang@oss.qualcomm.com \
    --to=claude-review@example.com \
    --cc=dri-devel-reviews@example.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