From 4dd8014a4e695fc166008d1541e9288521800fc1 Mon Sep 17 00:00:00 2001
From: Brad Barnett <127794626+bdbarnett@users.noreply.github.com>
Date: Fri, 25 Sep 2026 02:10:15 -0500
Subject: [PATCH 1/2] LCD-7: 10-row RGB bounce buffers, leaving internal DMA
 RAM for Wi-Fi and USB

At displayif's default 20 rows the panel takes 64 KB of internal DMA RAM. On
this board with Wi-Fi, TLS and a USB audio host up (spotapi's remote and an
earful speaker playing into a P4 sound card), the DMA-capable region sat at
24 bytes free; esp-aes then failed to allocate and Wi-Fi dropped. 10 rows
(32 KB) keeps ~65 KB free under the same load. Needs displayif's bounce_rows
(PyDevices/displayif, branch dcfb-bounce-rows); older builds ignore it via
the TypeError fallback.
---
 .../fbdisplay/esp32-s3-touch-lcd-7/board_config.py     | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/board_configs/fbdisplay/esp32-s3-touch-lcd-7/board_config.py b/board_configs/fbdisplay/esp32-s3-touch-lcd-7/board_config.py
index b57e2ee4..4bdc063e 100644
--- a/board_configs/fbdisplay/esp32-s3-touch-lcd-7/board_config.py
+++ b/board_configs/fbdisplay/esp32-s3-touch-lcd-7/board_config.py
@@ -64,7 +64,15 @@
     "pclk_idle_high": False,
 }
 
-fb = dotclockframebuffer.DotClockFramebuffer(**tft_pins, **tft_timings)
+# 10-row bounce buffers: 32 KB of internal DMA RAM instead of 64 KB. This
+# board often runs Wi-Fi, TLS and a USB host beside the panel, and all of
+# them need that RAM; with 20-row buffers a Spotify remote plus a USB audio
+# host left the DMA-capable region at 24 bytes and Wi-Fi fell over
+# (2026-09-25). displayif builds without bounce_rows keep their default.
+try:
+    fb = dotclockframebuffer.DotClockFramebuffer(**tft_pins, **tft_timings, bounce_rows=10)
+except TypeError:
+    fb = dotclockframebuffer.DotClockFramebuffer(**tft_pins, **tft_timings)
 display_drv = FBDisplay(fb)
 
 # GT911: RST on CH422G EXIO1, INT=GPIO4 (address-select during reset → 0x5D)

From 4aff3b688eabd0db03a709fda5fd33383905cdc5 Mon Sep 17 00:00:00 2001
From: Brad Barnett <127794626+bdbarnett@users.noreply.github.com>
Date: Fri, 25 Sep 2026 02:58:58 -0500
Subject: [PATCH 2/2] LCD-7: 14 MHz pixel clock, so the board's Wi-Fi survives
 the panel

At 16 MHz the RGB scanout's PSRAM traffic (or its emissions; the effect is
the same) wrecked the board's own Wi-Fi: 10-33 % ping loss with the panel
running and 0 % with it stopped, at the same -77 dBm, and TLS downloads that
stalled until the server reset the connection. At 14 MHz: 1.7 % loss and
five of five 500 KB downloads at 176-237 KB/s (12 MHz: 250-306 KB/s, 29 Hz).
14 MHz keeps the refresh at ~34 Hz.
---
 .../fbdisplay/esp32-s3-touch-lcd-7/board_config.py         | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/board_configs/fbdisplay/esp32-s3-touch-lcd-7/board_config.py b/board_configs/fbdisplay/esp32-s3-touch-lcd-7/board_config.py
index 4bdc063e..51f15d0f 100644
--- a/board_configs/fbdisplay/esp32-s3-touch-lcd-7/board_config.py
+++ b/board_configs/fbdisplay/esp32-s3-touch-lcd-7/board_config.py
@@ -47,8 +47,13 @@
     "red": (1, 2, 42, 41, 40),
 }
 
+# 14 MHz pixel clock (~34 Hz refresh), not 16: at 16 MHz the panel's scanout
+# took ~32 MB/s of PSRAM bandwidth, and the board's own Wi-Fi fell apart
+# under it -- 10-33 % ping loss with the panel on, 0 % with it stopped, and
+# TLS downloads that stalled until the server reset them. At 14 MHz: 1.7 %
+# loss and 176-237 KB/s downloads (12 MHz was similar). 2026-09-25.
 tft_timings = {
-    "frequency": 16_000_000,
+    "frequency": 14_000_000,
     "width": 800,
     "height": 480,
     "hsync_pulse_width": 4,