[ladyada]

hiya pi-folks!
we have a cute DSI adapter that lets boards with 22-pin "DSI" connectors work with off-the-shelf 30-pin 2-lane DSI connectors such as the Huadi HD40007C30-V5 (480x480, ST7701) and HD395003C30-V2 (720x720, FL7707N).

They'll need these external panel modules to initialize! I've hand-tested both of these overlays/configs. This PR adds their initialization and timing data to the existing ST7701 and ST7703 drivers, plus separate Raspberry Pi 5 overlays for the Adafruit 30-pin DSI adapter.

Validation:

• Both panel modules build against 6.18.50+rpt-rpi-2712 with W=1 and no compiler warnings. The 480x480 module was rebuilt and tested after the clock-mode correction.
• Both updated overlays compile and merge with the Pi 5 tree in default, optional-GPIO, notouch, and DSI0 configurations. Standalone dtc emits unit_address_vs_reg warnings for the optional dormant fragments; all merges succeed and the GPIO properties appear only when requested.
• The overlay and clock-mode corrections pass checkpatch --strict with no errors or warnings. The other panel-driver diffs and binding schemas passed the earlier checks.
• Both panels display steady SMPTE color bars on CAM/DISP1 and CAM/DISP0; the Pi boot console was also visually verified on CAM/DISP1.
• Both panels boot with automatic Goodix binding on both ports. Native Linux input events confirm touch movement and release using APX803 reset and I2C polling, without extra reset or interrupt GPIO wires.

Written with assistance from GPT-6 Astra, reviewed and tested by human meat.

[pelwell]

That all looks unsurprisingly sensible, although I'm not a display expert. I'm not bothered about the checkpatch warnings about non-standard commit message tags, and unless you're planning on upstreaming this I also don't mind about the DT bindings being in with the driver, but I would like all the other Device Tree files (overlay, README, Makefile) to be in a separate patch because they all get squashed together with each new kernel version.

[6by9]

I also don't mind about the DT bindings being in with the driver,

Sorry, but I do, and I suspect it would make popcornmix's life more awkward on rebases. Where multiple drivers are squashed, things get lost if there are merge conflicts.
Each panel driver and each binding file change should be in a separate patch, and adding support for features (eg changing the delays on ST7703) should be a patch before adding the panel definition that uses it.
The actual changes all look reasonable.

It'd be nice if the driver and bindings changes were upstreamed. Adding additional models to existing drivers is generally fairly painless. I would recommend the use of b4 (https://b4.docs.kernel.org/en/latest/) to curate the patchset as it helps avoid the simple process errors. They are likely to object to the use of handle@users.noreply.github.com email addresses though.

I'm curious over the need to use MIPI_DSI_MODE_VIDEO_SYNC_PULSE instead of MIPI_DSI_MODE_VIDEO_BURST. Seeing as other panels with the same controller don't need it, that feels odd. The datasheet lists support for all 3 modes (sync pulse, sync events, and burst).
You say "Add Raspberry Pi 5 overlays" for the displays, and they do use the compatible = "brcm,bcm2712"; at the start. Do they really not work on earlier Pis? (I'm thinking Compute Modules as you've used the 22pin connector).
I can't recall if that compatible stops it loading on earlier boards, or whether overlay_map.dts needs to be modified.

And a general question on the hardware design. Has the Goodix IRQ line got a sensible pull up or down on it? The chip uses that to select between using I2C address 0x14 and 0x5d. We've seen issues too weak or absent a pull can result in a fast reset reading the last IRQ state rather than the desired address state.