Pocket screen off after idle and can't get on again?

stephano · April 1, 2026, 4:54am

I’ve been looking into a similar issue, though it only happens to me on warm reboots.

Intermittent Blank Screen on A311D

opened 04:59PM - 15 Mar 26 UTC

## Summary Booting the A311D SoM on the MNT Pocket Reform sometimes results in …a blank display after boot. The system itself is still functional in many of these cases: - SSH access works - the system appears fully booted - the display simply never becomes active Once the system reaches this blank-screen state, rebooting via SSH does not fix the issue. The screen usually recovers only after power cycling the system controller, either by: - using the keyboard controller power cycle, or - using the standby switch to cut power to the system controller. This suggests the issue may involve state or timing between the system controller firmware and the panel driver. ## Environments Observed The issue occurs on both: - the stock Debian system image - Arch Linux using mnt-build ## Debug Patch As of this commit: https://github.com/cetola/mnt-build/commit/4eee60a33efa4955c3bbb59287ea43f1056c5c24 I added a small patch to the panel driver to include additional debug output. The patch: - adds debug logging to the panel init path - replaces `gpiod_set_value()` with `gpiod_set_value_cansleep()` - adds a small delay (`msleep(120)`) inside `pocket_display_v2_init()` The patch does not fix the issue — it is purely for debugging. ## Observed Behavior Comparing Debian dmesg logs between a working boot and a blank screen boot, the panel driver logs appear almost identical, with the primary difference being timing offsets. The driver sequence itself is the same: ``` prepare fbcon takeover unprepare prepare again ``` However, the timing between events diverges between the good and bad boot. ## Timing Comparison A simple alignment of the two logs shows the following offsets. ### Initial Panel Bring-Up | Event | Working Boot | Blank Boot | Delta | |------|------|------|------| | first `prepare` | 5.451s | 5.703s | +252 ms | | `[display] init in prepare` | 5.452s | 5.703s | +251 ms | | `"not sending tables this time"` | 5.502s | 5.750s | +248 ms | | `[display v2] OK` | 5.607s | 5.850s | +243 ms | | fbcon takeover | 5.648s | 5.893s | +245 ms | | `fb0` registration | 5.810s | 6.024s | +214 ms | ### Second Prepare Cycle (Hotplug Path) | Event | Working Boot | Blank Boot | Delta | |------|------|------|------| | `unprepare` phase | 6.403s | 6.527s | +124 ms | | second `prepare` | 6.814s | 7.258s | +444 ms | | `[display] init in prepare` | 7.135s | 7.616s | +481 ms | | `"sent tables OK"` | 7.277s | 7.754s | +477 ms | | final `[display v2] OK` | 7.382s | 7.857s | +476 ms | ## Interpretation Observations from the logs: - The event order is identical between working and blank boots. - The timing difference is larger than simple jitter. - The difference grows during boot, from ~250 ms initially to ~480 ms later. This suggests the two boots are not simply shifted copies of one another, and that probe ordering / workqueue scheduling / DRM hotplug timing may diverge during boot. The offsets are large enough that panel initialization race conditions are plausible. ## GPIO Warning Removed by Debug Patch The debug patch also removes this warning from dmesg: ``` WARNING: CPU: 2 PID: 217 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x4c/0x80 ``` Backtrace: ``` pc : gpiod_set_value+0x4c/0x80 lr : jdi_panel_prepare+0xbc/0x178 ``` This appears to occur because the driver was using: ``` gpiod_set_value() ``` on a GPIO that may sleep. Replacing it with: ``` gpiod_set_value_cansleep() ``` removes the warning. This change is not believed to fix the display issue; it simply removes the GPIO API misuse warning. ## Attached Logs Working boot: ``` deb-dmesg-screen-working-v1.txt ``` Blank screen boot: ``` deb-dmesg-screen-blank-v1.txt ``` ## Hypothesis My current guess is that this is a timing/state issue between: - the system controller firmware - the panel driver - the DRM hotplug / prepare lifecycle Since the screen often recovers only after cutting power to the system controller, it seems possible that some panel state persists across reboots. ## Additional Debugging Next steps: - test additional delays in the panel driver - instrument DSI transactions - capture UART boot logs [deb-dmesg-screen-blank-v1.txt](https://github.com/user-attachments/files/26005995/deb-dmesg-screen-blank-v1.txt) [deb-dmesg-screen-working-v1.txt](https://github.com/user-attachments/files/26005996/deb-dmesg-screen-working-v1.txt)

I was able to make that warning go away by replacing gpiod_set_value() with gpiod_set_value_cansleep() in the panel driver. See the GPIO Warning Removed by Debug Patch section of that issue. The warning seems to have no effect on the panel behavior.