Skip to content

QCLINUX: arm64: dts: qcom: lemans and monaco: Rework RTSS Mailbox DT to use syscon and staging overlays #1768

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sargarram7 wants to merge 7 commits into
base: tech/overlay/dt
Choose a base branch
from
Open

QCLINUX: arm64: dts: qcom: lemans and monaco: Rework RTSS Mailbox DT to use syscon and staging overlays #1768

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
96bae66
Revert "QCLINUX: arm64: dts: qcom: lemans: Add RTSS Mailbox device tr…
sargarram7 Sep 5, 2026
280fb67
Revert "QCLINUX: arm64: dts: qcom: Monaco: Add RTSS Mailbox device tr…
sargarram7 Sep 5, 2026
acaad01
QCLINUX: dt-bindings: mailbox: Add qcom,rtss-mailbox schema
sargarram7 Sep 9, 2026
1cc19d2
QCLINUX: arm64: dts: qcom: lemans: Add IPCC and syscon nodes for RTSS…
sargarram7 Sep 9, 2026
09e0ccc
QCLINUX: arm64: dts: qcom: lemans-staging: Add rtss-mailbox node
sargarram7 Sep 9, 2026
7547cfe
QCLINUX: arm64: dts: qcom: monaco: Add IPCC, syscon, and memory nodes…
sargarram7 Sep 9, 2026
215e02f
QCLINUX: arm64: dts: qcom: monaco-staging: Add rtss-mailbox node
sargarram7 Sep 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
99 changes: 99 additions & 0 deletions Documentation/devicetree/bindings/mailbox/qcom,rtss-mailbox.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause

@ricardosalveti Ricardo Salveti (ricardosalveti) Sep 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Binding should should come before it is used by another patch.

@sargarram7 sargarram7 Sep 15, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

expecting separate PR ?

@ricardosalveti Ricardo Salveti (ricardosalveti) Sep 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change the order of the commits.

@sargarram7 sargarram7 Sep 15, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

%YAML 1.2
---
$id: http://devicetree.org/schemas/mailbox/qcom,rtss-mailbox.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Qualcomm Technologies, Inc. RTSS Mailbox

maintainers:
- Ram Sargar <rsargar@qti.qualcomm.com>

description:
The RTSS mailbox exposes a shared-memory and IPCC doorbell channel between
the application processor and the RTSS subsystem, and manages handshake
with the RTSS subsystem to handle different milestones in mission mode.

properties:
compatible:
items:
- enum:
- qcom,sa8775p-rtss-mailbox
- qcom,qcs8300-rtss-mailbox
- const: qcom,rtss-mailbox

qcom,syscon-tcsr-req:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the TCSR syscon node
- description: offset of the RTSS request register from the syscon base
description:
Reference to the TCSR syscon node and register offset used to write
the boot/suspend handshake magic that RTSS reads.

qcom,syscon-tcsr-resp:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the TCSR syscon node
- description: offset of the RTSS response register from the syscon base
description:
Reference to the TCSR syscon node and register offset used to read
back the handshake magic RTSS acknowledges with.

qcom,syscon-ipc:
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
- items:
- description: phandle to the APSS shared IPC syscon node
- description: offset of the IPC trigger register from the syscon base
description:
Reference to the syscon node and register offset used to trigger the
IPC interrupt that notifies RTSS a TCSR handshake register was updated.

mboxes:
description:
IPCC mailbox channels used to send interrupts to the RTSS-facing IPCC
client/signal pairs.

interrupts-extended:
description:
IPCC channels used to receive interrupts from the RTSS-facing IPCC
client/signal pairs.

memory-region:
items:
- description: reserved-memory carveout for the RTSS mailbox descriptor region
- description: reserved-memory carveout for the OTA region
description:
Reference to the reserved-memory regions used for the mailbox
descriptor and for OTA.

required:
- compatible
- qcom,syscon-tcsr-req
- qcom,syscon-tcsr-resp
- qcom,syscon-ipc
- mboxes
- interrupts-extended
- memory-region

additionalProperties: false

examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/mailbox/qcom-ipcc.h>

rtss-ipcc-mailbox {
compatible = "qcom,sa8775p-rtss-mailbox", "qcom,rtss-mailbox";
qcom,syscon-tcsr-req = <&tcsr 0x3e02c>;
qcom,syscon-tcsr-resp = <&tcsr 0x3d018>;
qcom,syscon-ipc = <&apss_shared_ipc 0x0>;
mboxes = <&ipcc1 IPCC_CLIENT_RTSS0 0x2>,
<&ipcc1 IPCC_CLIENT_RTSS1 0x3>;
interrupts-extended = <&ipcc1 IPCC_CLIENT_RTSS0 0x2 IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS1 0x3 IRQ_TYPE_EDGE_RISING>;
memory-region = <&sail_mailbox_mem>, <&sail_ota_mem>;
};
2 changes: 0 additions & 2 deletions arch/arm64/boot/dts/qcom/Makefile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -542,7 +542,6 @@ dtb-$(CONFIG_ARCH_QCOM) += lemans-camx-el2.dtbo

dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-staging.dtbo

dtb-$(CONFIG_ARCH_QCOM) += lemans-rtss-mb.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-staging.dtbo

monaco-evk-camx-dtbs := monaco-evk.dtb monaco-evk-camx.dtbo
Expand All @@ -556,7 +555,6 @@ dtb-$(CONFIG_ARCH_QCOM) += monaco-camx-el2.dtb
dtb-$(CONFIG_ARCH_QCOM) += monaco-camx-el2.dtbo

dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-staging.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-rtss-mb.dtbo

dtb-$(CONFIG_ARCH_QCOM) += monaco-staging.dtbo

Expand Down
65 changes: 0 additions & 65 deletions arch/arm64/boot/dts/qcom/lemans-rtss-mb.dtso
View file
Open in desktop

This file was deleted.

43 changes: 43 additions & 0 deletions arch/arm64/boot/dts/qcom/lemans-staging.dtso
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,8 +7,51 @@

/dts-v1/;
/plugin/;
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/qcom,sa8775p-gcc.h>
#include <dt-bindings/mailbox/qcom-ipcc.h>

&soc {
rtss_mailbox: rtss-ipcc-mailbox {
compatible = "qcom,sa8775p-rtss-mailbox", "qcom,rtss-mailbox";
qcom,syscon-tcsr-req = <&tcsr 0x3e02c>;
qcom,syscon-tcsr-resp = <&tcsr 0x3d018>;
qcom,syscon-ipc = <&apss_shared_ipc 0x0>;
mboxes = <&ipcc1 IPCC_CLIENT_RTSS0 0x2>,
<&ipcc1 IPCC_CLIENT_RTSS1 0x3>,
<&ipcc1 IPCC_CLIENT_RTSS0 0x4>,
<&ipcc1 IPCC_CLIENT_RTSS0 0x5>,
<&ipcc1 IPCC_CLIENT_RTSS0 0x6>,
<&ipcc1 IPCC_CLIENT_RTSS0 0x7>,
<&ipcc1 IPCC_CLIENT_RTSS2 0x8>,
<&ipcc1 IPCC_CLIENT_RTSS1 0x9>,
<&ipcc1 IPCC_CLIENT_RTSS2 0xa>,
<&ipcc1 IPCC_CLIENT_RTSS1 0xb>,
<&ipcc1 IPCC_CLIENT_RTSS0 0xc>,
<&ipcc1 IPCC_CLIENT_RTSS0 0xd>,
<&ipcc1 IPCC_CLIENT_RTSS1 0xe>,
<&ipcc1 IPCC_CLIENT_RTSS2 0xf>,
<&ipcc1 IPCC_CLIENT_RTSS3 0x10>;
interrupts-extended = <&ipcc1 IPCC_CLIENT_RTSS0 0x2 IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS1 0x3 IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS0 0x4 IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS0 0x5 IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS0 0x6 IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS0 0x7 IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS2 0x8 IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS1 0x9 IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS2 0xa IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS1 0xb IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS0 0xc IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS0 0xd IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS1 0xe IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS2 0xf IRQ_TYPE_EDGE_RISING>,
<&ipcc1 IPCC_CLIENT_RTSS3 0x10 IRQ_TYPE_EDGE_RISING>;
memory-region = <&sail_mailbox_mem>,
<&sail_ota_mem>;
};

tgu@4b0e000 {
compatible = "qcom,tgu", "arm,primecell";
reg = <0x0 0x4b0e000 0x0 0x1000>;
Expand Down
43 changes: 42 additions & 1 deletion arch/arm64/boot/dts/qcom/lemans.dtsi
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1018,6 +1018,42 @@
#mbox-cells = <2>;
};

ipcc1: mailbox@488000 {
compatible = "qcom,sa8775p-ipcc", "qcom,ipcc";
reg = <0x0 0x00488000 0x0 0x1000>;
interrupts = <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <3>;
#mbox-cells = <2>;
};

ipcc2: mailbox@4a1000 {
compatible = "qcom,sa8775p-ipcc", "qcom,ipcc";
reg = <0x0 0x004a1000 0x0 0x1000>;
interrupts = <GIC_SPI 553 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <3>;
#mbox-cells = <2>;
};

ipcc3: mailbox@4a2000 {
compatible = "qcom,sa8775p-ipcc", "qcom,ipcc";
reg = <0x0 0x004a2000 0x0 0x1000>;
interrupts = <GIC_SPI 554 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <3>;
#mbox-cells = <2>;
};

ipcc4: mailbox@4a3000 {
compatible = "qcom,sa8775p-ipcc", "qcom,ipcc";
reg = <0x0 0x004a3000 0x0 0x1000>;
interrupts = <GIC_SPI 555 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;
#interrupt-cells = <3>;
#mbox-cells = <2>;
};

@ricardosalveti Ricardo Salveti (ricardosalveti) Sep 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have consumers for ipcc2-4 at this point?

@sargarram7 sargarram7 Sep 15, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, these channels are required for RTSS communication. While the current consumer is qcom-ipcc, the actual end user is rtss-mailbox.

This change addresses the existing RTSS channel limitation. The newly added channels have already been allocated from ipcc1 by Qualcomm and are intended to support:

  • New RTSS clients for customer-specific use cases.
  • Future Qualcomm internal use cases.
  • Specialized robotics workloads that require additional RTSS communication paths from end user side

Without reserving these channels, RTSS scalability is constrained and future clients cannot be integrated without further IPCC channel rework. This update is intended to close that gap and provide sufficient channel capacity for upcoming RTSS consumers.


qfprom: efuse@784000 {
compatible = "qcom,sa8775p-qfprom", "qcom,qfprom";
reg = <0x0 0x00784000 0x0 0x3000>;
Expand Down Expand Up @@ -4635,7 +4671,7 @@

tcsr: syscon@1fc0000 {
compatible = "qcom,sa8775p-tcsr", "syscon";
reg = <0x0 0x1fc0000 0x0 0x30000>;
reg = <0x0 0x1fc0000 0x0 0x40000>;
};

gpu: gpu@3d00000 {
Expand Down Expand Up @@ -7058,6 +7094,11 @@
redistributor-stride = <0x0 0x20000>;
};

apss_shared_ipc: syscon@17c0000c {
compatible = "qcom,sa8775p-tcsr", "syscon";

@lumag Dmitry Baryshkov (lumag) Sep 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly is behind this address? TCSR is at the other address, so it can't be TCSR.

@sargarram7 sargarram7 Sep 15, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0x17C0000C is SoC level top router APSS HM CSR register used for special event notifications such as boot milestones and runtime events.
APSS NHLOS, HLOS updates the milestone/magic value in TCSR and
triggers doorbell via 0x17C0000C, with the target potentially being OSM, SSC, RTSS, LPASS, Modem, xDSPs, AOP/RPMH or other subsystems.
Since this mechanism is not RTSS mailbox-specific and may be used by multiple APSS services, I would like to avoid introducing coupling through an RTSS mailbox DT reg property.

If syscon is not preferred, would it be acceptable to keep the register local to the driver and map it through platform resources (devm_ioremap_resource()) instead? This would keep the implementation self-contained while avoiding
mailbox specific DT binding for shared SoC resource.

@ricardosalveti Ricardo Salveti (ricardosalveti) Sep 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you going to upstream at least this patch? It is changing a common dtsi, so not really isolated.

@sargarram7 sargarram7 Sep 15, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have plan in 3 phases: phase 1, 2 will have downstream + overlay patches, after phase 2 commit work will be starting on upstreaming work.

@ricardosalveti Ricardo Salveti (ricardosalveti) Sep 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be a pure downstream change affecting a generic dtsi, not something I would recommend doing, but up to Dmitry Baryshkov (@lumag) and Shiraz Hashim (@shashim-quic).

Remember that downstream changes to the generic files can break systemready (dt check).

@sargarram7 sargarram7 Sep 15, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dmitry Baryshkov (@lumag) , Shiraz Hashim (@shashim-quic) could please review this open point.

@lumag Dmitry Baryshkov (lumag) Sep 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, you can't describe this as a TCSR. Also, I don't think that this register space is not page aligned. If you don't want to describe the hardware properly, it might be better to follow PDC example. Other option would be to describe this register space correctly and make PDC use it.

@sargarram7 sargarram7 Sep 16, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dmitry Baryshkov (@lumag)

  1. PDC doesn't appear suitable because the SPI edge/level mapping is fixed to predefined indices zero for pdc base and one for attributes.
  2. Using the register as mailbox reg resource works today but implicitly associates ownership with the mailbox driver, while the register is shared resource and future any services may require access. let me know about this option as well.
  3. Dedicated syscon node with a phandle reference from the RTSS mailbox node provides cleaner ownership modeling and better handing by fixing page alignment issue and changing the compatible string to default.
    e.g. apss_shared_ipc:syscon@17c00000 { compatible = "syscon"; reg = <0x0 0x17c00000 0x0 0x1000>; };
    reference it using qcom,syscon-ipc = <&apss_shared_ipc 0xc>;

@lumag Dmitry Baryshkov (lumag) Sep 16, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't have just a syscon. It needs a hardware-defining compatible in front. Also this resource definition will conflict with the PDC definitions.

reg = <0x0 0x17c0000c 0x0 0x4>;
};

watchdog@17c10000 {
compatible = "qcom,apss-wdt-sa8775p", "qcom,kpss-wdt";
reg = <0x0 0x17c10000 0x0 0x1000>;
Expand Down
65 changes: 0 additions & 65 deletions arch/arm64/boot/dts/qcom/monaco-rtss-mb.dtso
View file
Open in desktop

This file was deleted.

Loading
Loading