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/v3d: Reduce PM runtime autosuspend delay Date: Thu, 04 Jun 2026 15:23:15 +1000 Message-ID: In-Reply-To: <20260530-v3d-fix-rpi4-freezes-v1-4-c2c8307da6ce@igalia.com> References: <20260530-v3d-fix-rpi4-freezes-v1-0-c2c8307da6ce@igalia.com> <20260530-v3d-fix-rpi4-freezes-v1-4-c2c8307da6ce@igalia.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 **Purpose:** With the cache/MMU bugs fixed, the inflated 100ms autosuspend = delay is no longer needed. Reduce to 50ms. **Code change in `v3d_drv.c:423`:** ```c pm_runtime_set_autosuspend_delay(dev, 50); ``` **Analysis:** - The rationale is well explained in the commit message: 100ms was a workar= ound for the bugs fixed in patches 1-3. - This patch has no `Fixes:` tag, which is correct =E2=80=94 it's a tuning = change, not a bugfix. - No `Cc: stable@` either, which is correct =E2=80=94 this should not be ba= ckported independently of the series. **Question:** Is 50ms the right value? The commit message says "a more reas= onable value" but doesn't cite benchmarks or power measurements. For a desk= top/embedded system like RPi4, the difference between 50ms and 100ms is unl= ikely to matter for power savings but could theoretically increase suspend/= resume cycle frequency. This is a judgment call for the maintainers =E2=80= =94 the value seems reasonable, but some data or a reference to what other = GPU drivers use would strengthen the justification. Not a blocker. **Verdict: Fine as-is; the maintainers can adjust the value at merge time i= f they prefer a different number.** --- Generated by Claude Code Patch Reviewer