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/tiny: panel-ssd16xx: Add power management support Date: Tue, 05 May 2026 10:10:10 +1000 Message-ID: In-Reply-To: <20260430183311.2978142-5-devarsht@ti.com> References: <20260430183311.2978142-1-devarsht@ti.com> <20260430183311.2978142-5-devarsht@ti.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review The PM implementation is generally well-thought-out for e-paper's bistable nature. Some issues: **`ssd16xx_remove()` ordering:** ```c + pm_runtime_dont_use_autosuspend(&spi->dev); + pm_runtime_disable(&spi->dev); drm_dev_unplug(&panel->drm); drm_atomic_helper_shutdown(&panel->drm); ``` PM is disabled before DRM shutdown. If `drm_atomic_helper_shutdown()` triggers `crtc_atomic_disable` which does `pm_runtime_resume_and_get()`, it will fail because PM is already disabled. The shutdown should happen first, then PM teardown. **Double PM get/put in commit path:** `crtc_atomic_enable` does `pm_runtime_resume_and_get()`/`pm_runtime_put_autosuspend()`, and `plane_atomic_update` also does its own pair. Since `drm_atomic_helper_commit_tail_rpm` is used, the RPM framework handles the overall commit lifecycle. Having nested get/put pairs is correct from a refcount perspective but adds unnecessary wake-up latency if the autosuspend fires between enable and update (extremely unlikely with 35s timeout, but architecturally fragile). **System suspend when already RPM-suspended:** ```c + if (pm_runtime_status_suspended(dev)) { + ... + ssd16xx_hw_reset(panel); + ssd16xx_send_cmd(panel, SSD16XX_CMD_DEEP_SLEEP_MODE, &err); + ssd16xx_send_data(panel, panel->controller_cfg->deep_sleep_mode_level2, &err); + panel->pm_force_suspended = false; + return err; + } ``` This does a hardware reset followed immediately by a deep sleep command. There's no software reset or wait-for-busy between the HWRESET and sending the deep sleep command. Per SSD1683 datasheet, after HWRESET a busy period occurs -- the code should call `ssd16xx_wait_for_panel()` before sending commands. --- --- Generated by Claude Code Patch Reviewer