Claude review: drm/tiny: panel-ssd16xx: Add power management support

[Claude Code Review Bot <claude-review@example.com>]

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