Repository navigation
T8140: run the ISP as macOS does around a sleep (SLP_DDR wake stall) - #1377
Closed
DjDeveloperr wants to merge 5 commits into
Closed
DjDeveloperr wants to merge 5 commits into
DjDeveloperr wants to merge 5 commits into
Conversation
After the camera ran, a sleep that kept DRAM up (SLP_DDR) never came back: the SoC reset 5 s after the alarm, inside the sleep engine's own wake. The first such sleep of every boot did the same, because the driver booted the firmware at probe for the sensor detection. That wake runs a program of its own for the ISP: it powers its CPU domains up, has it run, waits for it and powers it down again. macOS traced under aura leaves the ISP for it in one state: off with no client, its firmware stopped from WFI with the CPU's run bit still set, and started only when a client opens the camera. Linux kept the firmware running between streams, booted it at probe, and cleared the run bit before the power-down. With the run bit cleared the wake stalled even with everything else as macOS has it (1 of 1); with it set, 9 of 9 SLP_DDR sleeps returned, the first of a boot and those after a camera start included. So, on T8140: start the firmware at the first open, halt it at the end of each stream, and leave the run bit set when its domains go off. The camera still doesn't start after any SLP_DDR wake, with or without camera use before it, until a deep sleep: the firmware boots but its first command times out. A failed start of firmware that starts again no longer marks it unusable until the next boot, so the camera comes back after the next deep sleep. Signed-off-by: Diljit Singh <hey@djdev.me>
macOS traced under aura (stop mode, a Photo Booth capture, then a sleep) powers the camera sensor domains ISPSENS0 and ISPSENS1 with the camera, after ISP_FE and before the rest of the pipeline, and lowers them at the close. It writes the ISP-local domains exactly 0xf, never with automatic power management, which Linux turned on for the two CPU cores. List the sensor domains in the ISP's power-domains in that order, and keep automatic power management off for the ISP-local domains. Signed-off-by: Diljit Singh <hey@djdev.me>
On T8140 both ISP CPU core domains reach off with BUSY (bit 11) latched, every time Linux powers them down: 0x0f000b00. macOS's trace has them off with it clear, 0x0f000300, through to the sleep commit. Only a PS reset clears it; the power-on path already pulses one for a latch it finds. Do the same when a domain goes down: if it reads off with BUSY still set, pulse its PS reset while it is off. Not during a system sleep transition, as on the power-on path. Signed-off-by: Diljit Singh <hey@djdev.me>
The rule that sends the next sleep deep after an ISP start came from the SLP_DDR wake stall after camera use, which the ISP driver now avoids. It still matters for the camera: on T8140 the ISP firmware doesn't start after any SLP_DDR wake until a deep sleep, whether the camera ran before it or not. Say so; the behaviour is unchanged. Signed-off-by: Diljit Singh <hey@djdev.me>
The first SLP_DDR sleep of a boot stalled in the sleep engine, 13 of 13, so every boot's first sleep went deep. The stall came from the ISP firmware booted at probe for the camera detection, which the ISP driver no longer does on T8140, and from the way it was stopped; forced SLP_DDR first sleeps returned after the change. Let the host's vote apply from the first sleep. Signed-off-by: Diljit Singh <hey@djdev.me>
This was referenced Nov 9, 2026
Closed
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The DRAM-kept (SLP_DDR) wake stalled after any camera use, and on the first sleep of every boot. Both came from how Linux ran the ISP.
macOS, traced under aura (Photo Booth capture, then a sleep, stopped at the commit), leaves the ISP for the sleep engine with its firmware stopped from WFI and the CPU run bit still set. Its sensor domains are powered with the camera, its local domains have no automatic power management, and the cores are off with no BUSY latched. The engine's own wake runs the ISP and depends on that state. Linux booted the firmware at probe, kept it running between streams, cleared the run bit before the power-down, and left both cores' power words latched busy.
Tested on the Neo: 9 of 9 forced SLP_DDR sleeps returned, including the first of a boot and sleeps after camera starts. Before, 6 of 6 after the camera and 13 of 13 first sleeps stalled.
Still open: on T8140 the camera doesn't start after any SLP_DDR wake until a deep sleep, whether or not the camera ran before it. The firmware boots, but its first command times out. The deep-after-ISP-start rule keeps a camera used before a sleep working after it.
🤖 Generated with Claude Code