Hello everyone,
I'm trying to gain a deeper understanding of the power management architecture in the Raspberry Pi 5, specifically regarding the BCM2712 SoC. My core question is whether the BCM2712 implements true, dynamic domain-level power gating in the way it's understood in advanced SoC design (i.e., completely shutting off power to individual functional blocks to eliminate leakage current).
I've done a fair bit of digging through device trees, kernel patches, and community discussions, and while there's strong evidence of a sophisticated power management system, there's no public documentation that confirms the full extent of this capability.
Here is a summary of what I've found so far:
1. Power domains in device tree
In the Pi 5’s device tree for the BCM2712 (the main SoC), there are “power” nodes and power-domain references for various subsystems. For example:
* In the file bcm2712-rpi-5-b.dts, patches have been made to add “firmware clocks and power nodes” and to define power-domain cells.
* Also, in a “gpiomem” / “aon-pinctrl” node, there are “power-domains = <...>” properties.
These show that the design supports, at least, distinct power domains from a device tree / OS perspective for some blocks of the hardware.
2. RP1 southbridge chip
The Pi 5 introduces a new in-house I/O controller (RP1), offloading many slower/low-speed peripherals from the main SoC. It handles e.g. USB, Ethernet, CSI/DSI, GPIO etc. This separation suggests better modularity in managing power (since RP1 handles a lot of I/O independently).
3. Sleep / shutdown behavior
* The Pi 5 still consumes some power even after shutdown (by default) because certain rails are still powered.
* There is a config option POWER_OFF_ON_HALT=1 that causes it to shut off more power domains/rails when “halted”, reducing standby power dramatically. This suggests that there are power gating / power rail control mechanisms in the hardware or power management controller that can disable parts of the system when halted.
What isn’t known / what is unclear
* There’s no public info that shows detailed power gating control of every logical domain (e.g. CPU cluster, GPU, VideoCore blocks, memory controller, etc.), in the sense of being able to turn off power to unused blocks dynamically (while the rest of the chip continues to work).
* No datasheet (especially for the main BCM2712) has been published that details fine-grained power gating or state retention circuits for all domains. The RP1 datasheet is “draft” and doesn’t seem to reveal everything.
* It’s not clear whether “power-domains” in the device tree correspond to true shut-off (i.e. removal of power) or just clock or gating or voltage scaling or putting blocks into low power mode. Sometimes “power domain” means “able to shut off or reduce power usage significantly” but not necessarily full domain power gating with zero leakage.
There are exposed power-domains on the Pi 5 (BCM2712 / RP1 device tree + RP1 docs + kernel patches), and the Linux generic power-domain (genpd) infrastructure can be used to control/describe them — but there is no public Broadcom datasheet or technical reference that documents full, fine-grained, dynamic domain-level power-gating (with per-domain rail removal and state-retention details) for every internal block of the BCM2712.
I found, why the evidence points to partial (firmware/DT + some rails) control rather than a fully open fine-grained power-gating facility.
What I found (evidence & meaning)
1. Device tree / kernel patches add power nodes for BCM2712 — Raspberry Pi kernel device-tree patches add power nodes and #power-domain-cells for BCM2712; that means the SoC exposes (or the firmware advertises) PM domains to Linux so drivers can bind to power domains via the genpd framework. This is a strong sign the platform supports multiple power domains at least at the device-tree/firmware level.
2. RP1 documentation and RP1 peripherals PDF exist — RP1 is a new Raspberry-Pi-designed I/O controller on the Pi 5 and has a published peripherals PDF; RP1 splits many I/O functions off the main SoC, which makes independent power control of I/O blocks more feasible and likely. The RP1 documentation is useful for how I/O and some rails are managed.
3. Practical shutdown behavior shows rail control is present — Users and testers (Jeff Geerling and forum threads) show that changing POWER_OFF_ON_HALT=1 changes how much power the Pi consumes at shutdown — i.e. some rails/domains are turned off when halted. That demonstrates some hardware/firmware power gating of rails is implemented.
4. No public full BCM2712 TRM/datasheet with per-domain gating details — The community repeatedly asks for a full BCM2712 datasheet/TRM that would list per-domain power-gating capabilities, but Raspberry Pi/Broadcom haven’t made such a document public. Without that, we can’t confirm every internal domain (CPU clusters, GPU subblocks, memory controller SRAM retention, etc.) supports independent, fully documented power gating.
5. Linux power-domain framework exists and is the exact mechanism used — The kernel’s generic power-domain (genpd) and the device-tree power-domains binding are intended for exactly this: grouping devices into PM domains which can be power-gated. The presence of DT power nodes and the kernel patches tying BCM2712 to the firmware power driver mean the kernel is prepared to manage PM domains if the firmware/hardware supports the required operations. That still doesn’t prove every SoC internal block can be dynamically power-removed — only that the mechanism exists.
Practical interpretation
* The Pi 5 platform does have power domains and firmware/kernel support to control them (so some domains can be switched off or put into low-power states).
* However, there is no public, detailed Broadcom BCM2712 datasheet documenting full domain-level power-gating for every internal block. The result: we can conclude partial/OS/firmware managed domain gating exists, but we cannot publicly verify the presence of full fine-grained hardware power-gating primitives (with retention/state details) for every internal domain.
I realize that full silicon documentation often can't be made public, but any clarification on the capability of the hardware would be immensely helpful for understanding the Pi 5's power efficiency potential.
I'm trying to gain a deeper understanding of the power management architecture in the Raspberry Pi 5, specifically regarding the BCM2712 SoC. My core question is whether the BCM2712 implements true, dynamic domain-level power gating in the way it's understood in advanced SoC design (i.e., completely shutting off power to individual functional blocks to eliminate leakage current).
I've done a fair bit of digging through device trees, kernel patches, and community discussions, and while there's strong evidence of a sophisticated power management system, there's no public documentation that confirms the full extent of this capability.
Here is a summary of what I've found so far:
1. Power domains in device tree
In the Pi 5’s device tree for the BCM2712 (the main SoC), there are “power” nodes and power-domain references for various subsystems. For example:
* In the file bcm2712-rpi-5-b.dts, patches have been made to add “firmware clocks and power nodes” and to define power-domain cells.
* Also, in a “gpiomem” / “aon-pinctrl” node, there are “power-domains = <...>” properties.
These show that the design supports, at least, distinct power domains from a device tree / OS perspective for some blocks of the hardware.
2. RP1 southbridge chip
The Pi 5 introduces a new in-house I/O controller (RP1), offloading many slower/low-speed peripherals from the main SoC. It handles e.g. USB, Ethernet, CSI/DSI, GPIO etc. This separation suggests better modularity in managing power (since RP1 handles a lot of I/O independently).
3. Sleep / shutdown behavior
* The Pi 5 still consumes some power even after shutdown (by default) because certain rails are still powered.
* There is a config option POWER_OFF_ON_HALT=1 that causes it to shut off more power domains/rails when “halted”, reducing standby power dramatically. This suggests that there are power gating / power rail control mechanisms in the hardware or power management controller that can disable parts of the system when halted.
What isn’t known / what is unclear
* There’s no public info that shows detailed power gating control of every logical domain (e.g. CPU cluster, GPU, VideoCore blocks, memory controller, etc.), in the sense of being able to turn off power to unused blocks dynamically (while the rest of the chip continues to work).
* No datasheet (especially for the main BCM2712) has been published that details fine-grained power gating or state retention circuits for all domains. The RP1 datasheet is “draft” and doesn’t seem to reveal everything.
* It’s not clear whether “power-domains” in the device tree correspond to true shut-off (i.e. removal of power) or just clock or gating or voltage scaling or putting blocks into low power mode. Sometimes “power domain” means “able to shut off or reduce power usage significantly” but not necessarily full domain power gating with zero leakage.
There are exposed power-domains on the Pi 5 (BCM2712 / RP1 device tree + RP1 docs + kernel patches), and the Linux generic power-domain (genpd) infrastructure can be used to control/describe them — but there is no public Broadcom datasheet or technical reference that documents full, fine-grained, dynamic domain-level power-gating (with per-domain rail removal and state-retention details) for every internal block of the BCM2712.
I found, why the evidence points to partial (firmware/DT + some rails) control rather than a fully open fine-grained power-gating facility.
What I found (evidence & meaning)
1. Device tree / kernel patches add power nodes for BCM2712 — Raspberry Pi kernel device-tree patches add power nodes and #power-domain-cells for BCM2712; that means the SoC exposes (or the firmware advertises) PM domains to Linux so drivers can bind to power domains via the genpd framework. This is a strong sign the platform supports multiple power domains at least at the device-tree/firmware level.
2. RP1 documentation and RP1 peripherals PDF exist — RP1 is a new Raspberry-Pi-designed I/O controller on the Pi 5 and has a published peripherals PDF; RP1 splits many I/O functions off the main SoC, which makes independent power control of I/O blocks more feasible and likely. The RP1 documentation is useful for how I/O and some rails are managed.
3. Practical shutdown behavior shows rail control is present — Users and testers (Jeff Geerling and forum threads) show that changing POWER_OFF_ON_HALT=1 changes how much power the Pi consumes at shutdown — i.e. some rails/domains are turned off when halted. That demonstrates some hardware/firmware power gating of rails is implemented.
4. No public full BCM2712 TRM/datasheet with per-domain gating details — The community repeatedly asks for a full BCM2712 datasheet/TRM that would list per-domain power-gating capabilities, but Raspberry Pi/Broadcom haven’t made such a document public. Without that, we can’t confirm every internal domain (CPU clusters, GPU subblocks, memory controller SRAM retention, etc.) supports independent, fully documented power gating.
5. Linux power-domain framework exists and is the exact mechanism used — The kernel’s generic power-domain (genpd) and the device-tree power-domains binding are intended for exactly this: grouping devices into PM domains which can be power-gated. The presence of DT power nodes and the kernel patches tying BCM2712 to the firmware power driver mean the kernel is prepared to manage PM domains if the firmware/hardware supports the required operations. That still doesn’t prove every SoC internal block can be dynamically power-removed — only that the mechanism exists.
Practical interpretation
* The Pi 5 platform does have power domains and firmware/kernel support to control them (so some domains can be switched off or put into low-power states).
* However, there is no public, detailed Broadcom BCM2712 datasheet documenting full domain-level power-gating for every internal block. The result: we can conclude partial/OS/firmware managed domain gating exists, but we cannot publicly verify the presence of full fine-grained hardware power-gating primitives (with retention/state details) for every internal domain.
I realize that full silicon documentation often can't be made public, but any clarification on the capability of the hardware would be immensely helpful for understanding the Pi 5's power efficiency potential.
Statistics: Posted by Fuzzy Logic — Sun Sep 14, 2025 11:23 pm