Pocket DS lower panel: replace our downstream driver with the mainline ST7703

[loki666]

Upstream: ROCKNIX/distribution#3051

Replaces a 341-line out-of-tree panel driver with a 164-line addition to the in-tree ST7703
driver, plus a DTS compatible switch.

What we carry today

• kernel/patches/0054-gpu-panel-add-Pocket-DS-lower-panel-driver.patch (DRM_PANEL_AR11_5INCH)
• kernel/dts/qcom/qcs8550-ayaneo-pocketds.dts:236 → compatible = "ayaneo,pocket-ds-secondary-panel"

Why bother

No behaviour change is expected — this is purely 177 fewer lines of downstream driver to re-roll
across every kernel bump. That is also the argument for not doing it on its own: the payoff is
maintenance, so it should ride along with the next kernel bump rather than spend a separate HW cycle.

hw-gate: needs a Pocket DS to confirm the lower panel still lights. Worth pairing with #37 (the
SY7758 backlight has no enable-gpios), since that is the same board and the same "does the second
display come up" question — a single Pocket DS session could settle both.

Verified against main @ a53ba1b, 2026-08-29.

[loki666]

Checked against #37 — these are adjacent but not duplicates, and neither one's fix does the other's work.

• Pocket DS: SY7758 backlight has no enable-gpios → panel will defer (no display) #37 is backlight: backlight@2e (kernel/dts/qcom/qcs8550-ayaneo-pocketds.dts:145, compatible = "silergy,sy7758") — a four-line node missing the enable-gpios the driver needs to bind. Consequence: deferred probe, no display. A defect.
• This issue is panel@0 (:235, compatible = "ayaneo,pocket-ds-secondary-panel") — swapping our downstream DRM_PANEL_AR11_5INCH (patch 0054) for the mainline ST7703. Consequence: none expected. Maintenance.

Giving the backlight an enable GPIO does not retire patch 0054; switching to ST7703 does not supply a missing enable GPIO.

They are also blocked on different things, which is the practical reason to keep them apart: #37 is blocked on information (which tca6408 pin — see the lead I just added there), while this is blocked only on a confirmation run. The code change here can be written against any kernel bump with no hardware at all; only the verification needs a board.

What they do share is the board and the HW session, so they should be scheduled together — one Pocket DS power-on settles both.

One migration detail found while comparing: :243 uses enable-gpio singular, a downstream-only binding name. That is exactly the kind of thing the mainline driver will not accept, so budget for it here.