From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/tidss: Remove extra pm_runtime_mark_last_busy Date: Thu, 23 Apr 2026 09:45:58 +1000 Message-ID: In-Reply-To: <20260420-beagley-ai-display-v1-6-f628543dfd14@ideasonboard.com> References: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com> <20260420-beagley-ai-display-v1-6-f628543dfd14@ideasonboard.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review Correct. `pm_runtime_put_autosuspend()` calls `pm_runtime_mark_last_busy()`= internally (via `__pm_runtime_idle()` -> `rpm_idle()` path... actually, ch= ecking the pm_runtime code, `pm_runtime_put_autosuspend` does NOT always ca= ll `pm_runtime_mark_last_busy` =E2=80=94 it calls `__pm_runtime_suspend` wh= ich schedules autosuspend using the *last recorded* busy time).=20 **Issue:** This removal may be incorrect. The `pm_runtime_mark_last_busy()`= + `pm_runtime_put_autosuspend()` pattern is the standard recommended usage= . `pm_runtime_put_autosuspend()` schedules a delayed suspend based on the *= existing* last busy timestamp. Without `pm_runtime_mark_last_busy()` before= hand, the autosuspend timeout is measured from whenever `mark_last_busy` wa= s *previously* called, which could be much earlier, causing the device to s= uspend almost immediately. The commit message's claim that `pm_runtime_put_= autosuspend() calls pm_runtime_mark_last_busy()` appears to be wrong. Pleas= e verify this against the current kernel PM runtime implementation. --- Generated by Claude Code Patch Reviewer