Claude review: drm/panel: simple: Add timings for Raspberry Pi 7" panel

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

Patch Review

The commit message is excellent — it documents the strict back-porch requirements, the connector type rationale, and the hardware topology clearly.

**Timing analysis:**

The timing definition looks correct for an 800x480 panel. The typical pixel clock of 30MHz gives approximately 60fps:
- htotal = 800 + 72 + 32 + 46 = 950
- vtotal = 480 + 21 + 2 + 23 = 526
- 30MHz / (950 * 526) = ~60.0 Hz

The fixed back-porch values (hbp=46, vbp=23 with min=typ=max) match the commit message's claim that these must be exact. The wide pixel clock range (10–50MHz) allows flexible refresh rate selection, which is reasonable for a panel behind a DSI-to-DPI bridge where the host controller determines the actual rate.

**Observation — similarity to rocktech_rk070er9427:**

The existing `rocktech_rk070er9427` panel at line 4274 shares strikingly similar parameters: same resolution (800x480), same physical size (154x86mm), identical fixed back-porches (hbp=46, vbp=23), and overlapping front-porch/pixel-clock ranges. The main differences are bpc (6 vs 8), bus_format (RGB666_1X18 vs RGB888_1X24), and the new panel's bus_flags/sync flags. This might suggest Rocktech is one of the undisclosed panel vendors — not a problem for the patch, but an interesting data point.

**bus_flags usage:**

The patch uses `DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE` and `DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE` in the `panel_desc.bus_flags`. These are from the transmitter's perspective (DRIVE), not the receiver/panel perspective (SAMPLE). Since `DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE` == `DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE` (both BIT(2)), and similarly for sync, these will pass the DPI validation checks at line 664 without warnings.

This is consistent with how several other panels in the file define their bus_flags (e.g., lines 1644, 1851, 2123-2124), so this is fine. However, given the comment in the timing struct:

```c
	/* Note: the rest of the flags are defined below in bus_flags */
```

It's worth noting that `DISPLAY_FLAGS_VSYNC_HIGH | DISPLAY_FLAGS_HSYNC_HIGH` in the timing struct defines sync polarity (which sync level is active), while `DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE` in bus_flags defines the clock edge on which sync is driven — these are orthogonal, so no conflict. The comment might mislead a reader into thinking the bus_flags are an alternative location for the *same* kind of flags, when they're actually complementary. This is a very minor nit.

**of_device_id table:**

The entry is correctly placed in alphabetical order between `qishenglong,gopher2b-lcd` and `raystar,rff500f-awh-dnn` at the updated line 5519.

**No blocking issues.**

---
Generated by Claude Code Patch Reviewer