drm/mipi-dbi: display a cropped region of an oversized framebuffer

[HorseyofCoursey]

Currently a drm/tiny MIPI-DBI panel can only scan out a framebuffer that
is exactly panel-sized, always from the origin. This series lets a client
allocate a larger framebuffer and choose the displayed region via the
plane source rectangle — a crop / pan with no scaling.

1. drm/mipi-dbi: honor the plane source offset when flushing
   Pass the integer plane src origin into mipi_dbi_fb_dirty() and
   subtract it in mipi_dbi_set_window_address(). The buffer copy still
   uses framebuffer coordinates so it reads the right pixels from an
   oversized source. src=(0,0) behaviour is unchanged.

2/3. drm/tiny/{ili9341,hx8357d}: raise mode_config.max_width/height,
which were pinned to the panel size and rejected any non-panel-sized
framebuffer. Fixed mode / minimums / connector unchanged; the plane
check forbids scaling and repositioning and tx_buf is mode-sized, so
the flushed rectangle stays bounded by the panel.

Change 1 is in the shared core; changes 2/3 are the per-driver limit
bump (the max_* values moved into the tiny drivers in 7.2). Entirely
within the DBI path — no shared shadow-plane / damage-helper changes.

Tested (Pi Zero 2 W, generic 2.4" 240x320 ILI9341, landscape):

• 480x640 framebuffer into 320x240: accepted (was "bad framebuffer
  width"), displayed from origin.
• Offsets on both axes via kmstest -f 480x640-RG16 -v <x>,<y>-320x240:
  the displayed region tracks the source rectangle.
• Native panel-sized framebuffer: no visual change.
• Sustained 30fps full-frame video through the flush path: no
  performance regression.
  hx8357d: compile-tested only.

Follow-up, not in this series: mipi_dbi_fb_dirty() can skip the tx_buf
repack when the framebuffer stride matches the panel width (rows are
contiguous). Independent of this feature; will send separately.

Thanks to @6by9 for the guidance throughout! (:

[6by9]

Tested on my hx8357 (PiTFT 3.5" resistive) and works as expected.

Altering to kmstest -v -p 0,0-320x420 480x640-RG16 -v <x>,<y>-320x480 is still rejected as that would be scaling the plane rather than cropping, so that's all good.

For me with this display (and quite probably your ili9341) it always goes through the copy path as swap_bytes is set, needing to swap the two bytes in RGB565.
That's a limitation of the SPI controller in Pi0-4. It looks like Pi5 should support 16 bit transfers (and possibly 32bit) and hence not need the swap flag.

Once we have this series tidied up, we can look at sending it upstream.

[HorseyofCoursey]

@6by9 Thanks for testing on the hx8357d. Good point on swap bytesm, makes sense the zero-copy path never fires on Pi 0–4, so the stride-match optimization would only ever help Pi 5.

[6by9]

Ideally all the tiny drm drivers that use mipi-dbi-spi would benefit from the increase in max_width/max_height, but no rush. That can be done when sending upstream.

[HorseyofCoursey]

Makes sense, and upstream it collapses to a single change in drm_mipi_dbi.c since mainline still has the limits in the core, so all the mipi-dbi drivers get it for free there. Only 7.2.y needs the per-driver version. Happy to do the full 7.2.y sweep separately if you want it before the upstream submission, otherwise I'll fold it into that. Once this lands in 7.2.y, do you want to send it to dri-devel yourself, or would you rather I do it with you CC'd? Happy either way; if I send it I'll rebase onto drm-misc-next and collapse 2/3 into the single core change first.