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 andtimes its work out with. The firmware programs these timers itselfand makes no power request for them, and the timers' own nodes arereserved for it, so nothing else requests their power; a clientdriver 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