Product studyGraphLab Boot / Pro

Low-power display operation

A heterogeneous system may not need the application cores awake for every visible state. This study explores keeping a controlled display active from the real-time core while the A-cores enter a supported low-power state and are woken only for agreed events.

Battery-powered greenhouse controller with its main display asleep and a smaller essential status screen still active.

Intended outcome

Separate a lightweight visible state from the full Linux workload

The real-time side would maintain a deliberately limited screen while Linux is suspended. Local inputs, timers, or system events could update that screen within the capabilities of the real-time firmware.

When an event needs Linux, the real-time side would request a wake-up and retain the controlled display until the Linux application publishes a complete, approved frame.

Proposed behavior

A project-defined operating sequence

Prepare for sleep
Linux and the real-time firmware agree on display state, shared-memory ownership, pending work, and permitted wake sources.
Suspend application cores
The A-cores enter a platform-supported low-power state while required real-time and display resources remain available.
Maintain the display
The real-time firmware presents the approved low-power view and handles only the agreed local events.
Wake and restore
A qualified event requests an A-core wake-up, then normal Linux rendering becomes visible after the readiness contract is satisfied.

Architecture

Responsibilities stay explicit

Power authority

The platform power controller and BSP define which processor, memory, clocks, and peripherals can remain active in each sleep state.

Real-time experience

GraphLab Core owns a small, deterministic set of visible states and input reactions that do not depend on Linux.

Wake contract

Wake sources, acknowledgement, timeout, shared-memory restoration, and Linux readiness are explicit and testable.

Project inputs

Integration points to define and validate

Supported SoC sleep states and auxiliary-core behavior.
Display controller, panel, bridge, clock, regulator, and backlight retention.
Shared-memory lifetime, cache state, and framebuffer validity across suspend.
Wake sources, interrupt routing, power-controller permissions, and timeout policy.
Linux suspend and resume ordering in the selected BSP.
Power measurements and repeated suspend-resume regression testing on target hardware.

Assess the concept