Claude review: drm/hibmc: Do not use cpp from struct drm_format_info

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

Patch Review

**Status: Good, one minor observation**

Two changes:

1. Replaces `width * cpp[0]` with `drm_format_info_min_pitch()`:
```c
reg = drm_format_info_min_pitch(fb->format, 0, fb->width);
```
This is the preferred API for computing line widths and handles multi-plane formats correctly.

2. Replaces the `cpp[0] * 8 / 16` formula with an explicit switch on the fourcc:
```c
switch (fb->format->format) {
case DRM_FORMAT_XRGB8888:
    reg |= HIBMC_FIELD(HIBMC_CRT_DISP_CTL_FORMAT, 2);
    break;
case DRM_FORMAT_RGB565:
    reg |= HIBMC_FIELD(HIBMC_CRT_DISP_CTL_FORMAT, 1);
    break;
}
```

The magic values 2 and 1 match the old formula's results (`4*8/16=2`, `2*8/16=1`) and are presumably the hardware register encoding. This is cleaner and eliminates the problematic dependency on cpp.

**Minor observation**: The switch has no `default` case. Since patch 2 restricts formats to only XRGB8888 and RGB565, an unhandled format reaching this point would be a framework bug. However, a `default: WARN_ONCE(...)` or `default: break;` could be added for defensive programming. Not blocking — the mask is cleared before the switch, so the worst case is the format field being left at 0, which may represent an undefined or 8bpp mode. Given that `atomic_check` validates the format list, this is fine in practice.

There's a minor inconsistency where `line_l = new_state->fb->pitches[0]` still uses `new_state->fb` instead of the newly-introduced `fb` local variable, but patch 4 cleans this up.

---
Generated by Claude Code Patch Reviewer