On Fri, Oct 23, 2026 at 08:39:28AM +0200, Tomeu Vizoso wrote:

A firmware may drive the core's timers, which need their power domains held; the remoteproc driver does not hold them, so let the DSP node reference them for a driver that attaches to the running core to hold.

Assisted-by: LLM Signed-off-by: Tomeu Vizoso tomeu@tomeuvizoso.net

---

v3:

• Initial version

---

.../devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml index d6319c8e96f8..80eaef0a19b8 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml @@ -76,6 +76,23 @@ properties: # Optional properties: # --------------------

• power-domains:
• description: |

•  Power domains of the SoC timers the running firmware ticks on and
  

•  times its work out with. The firmware programs these timers itself
  

•  and makes no power request for them, and the timers' own nodes are
  

•  reserved for it, so nothing else requests their power; a client
  

•  driver of the firmware holds them on while it drives the processor.
  

•  The processor's own power is managed through ti,sci-dev-id, not here.
  

• items:

•  - description: power domain of the first timer
  

first timer

•  - description: power domain of the second timer
  

second timer

No need to say that power domain is a power domain.

Reviewed-by: Krzysztof Kozlowski krzysztof.kozlowski@oss.qualcomm.com

Best regards, Krzysztof