Add RTSS mailbox FIT image support for iq-8275-evk and iq-9075-evk

[snegi-qti]

The RTSS (Real Time Subsystem) mailbox driver uses a dedicated DT overlay (lemans-rtss-mb.dtbo/monaco-rtss-mb.dtbo). These changes wire up the overlay into the FIT image selection flow for platforms with RTSS mailbox IPC support enabled.

• Add rtssmb FIT DTB compatible entries in fit-dtb-compatible-linux-qcom.inc for both qcs9075 and qcs8275 platforms, extending the base compatible strings with the rtss-mb DTB overlay so the bootloader can select the correct DTB
  bundle at boot
• Include monaco-rtss-mb.dtbo in LINUX_QCOM_KERNEL_DEVICETREE for the iq-8275-evk machine config
• Include lemans-rtss-mb.dtbo in LINUX_QCOM_KERNEL_DEVICETREE for the iq-9075-evk machine config
• EFIVAR "rtssmb" activates the configuration

[Dmitry Baryshkov (lumag)]

Why is it an overlay rather than a part of the main DT?

[Dmitry Baryshkov (lumag)]

Describe why, not what. Why is this a separate overlay, why is it enabled via UEFI variable, etc.

[Viswanath Kraleti (vkraleti)]

*** No rule to make target 'arch/arm64/boot/dts/qcom/lemans-rtss-mb.dtbo'. Stop.

There is no DT in linux-qcom-6.18

[snegi-qti]

*** No rule to make target 'arch/arm64/boot/dts/qcom/lemans-rtss-mb.dtbo'. Stop.

There is no DT in linux-qcom-6.18

DTs are already merged : QCLINUX: arm64: dts: qcom: lemans: Add RTSS Mailbox device tree overlay · qualcomm-linux/kernel@f9e0…

But the current meta-qcom linux-qcom recipe is pointing to older hash (https://github.com/qualcomm-linux/meta-qcom/blob/master/recipes-kernel/linux/linux-qcom_6.18.bb#L20), once it moves to latest, we will have the required changes.

[snegi-qti]

Why is it an overlay rather than a part of the main DT?

Describe why, not what. Why is this a separate overlay, why is it enabled via UEFI variable, etc.

The RTSS Devicetree change is submitted as an overlay, as it cannot be added to intree kernel devicetree since the RTSS Devicetree and Driver are downstream, as of today. Hence, we have followed the existing precedent for "camx" which follows a similar approach of overlay + efivar activation to bring in this feature. Once this driver can be upstreamed, we shall move to intree approach.

[Dmitry Baryshkov (lumag)]

snegi-qti You are still describing that the driver is the out-of-tree module, etc. Describe, why do we want it in this way. What are the benefits. What is the usecase. Why the DTs are specified as an overlay rather than being merged in the base DTs in qcom-next, etc. CamX has an overlay DT, because the upstream kernel uses different bindings to desvribe the camera devices. If there are no conflicting upstream bindings, then the DT should be a part of the default DT.

[snegi-qti]

snegi-qti You are still describing that the driver is the out-of-tree module, etc. Describe, why do we want it in this way. What are the benefits. What is the usecase. Why the DTs are specified as an overlay rather than being merged in the base DTs in qcom-next, etc. CamX has an overlay DT, because the upstream kernel uses different bindings to desvribe the camera devices. If there are no conflicting upstream bindings, then the DT should be a part of the default DT.

sargarram7 Could you please help answer the above queries for your RTSS driver ?

[snegi-qti]

qli-2.0 GA Critical Fix

[Dmitry Baryshkov (lumag)]

qli-2.0 GA Critical Fix

No, it's a new features, submitted pas the cut-off date.

[sargarram7]

Apologies for the delayed and lengthy response and thank you for your valuable feedback.
I fully agree that upstreaming RTSS drivers is the correct long-term direction, and this remains our clear objective.
At this stage, we are intentionally pursuing a downstream approach to allow the RTSS architecture and APIs to mature before proposing them upstream. The RTSS driver and middleware stack are still under active development as part of a broader effort to build a unified APSS–RTSS IPC software stack across Automotive, IoT, Robotics, and Linux (LA) platforms. Both the internal design and external interfaces are evolving significantly.
Upstreaming the current implementation prematurely would introduce unstable and frequently changing user-space APIs, which goes against upstream expectations for long-term stability. We want to avoid unnecessary churn and disruptive API changes after initial inclusion.

Why RTSS:
RTSS is designed to handle deterministic, latency-sensitive workloads, while the APSS handles higher-level applications. Key use cases include:
• Offloading time-critical workloads such as sensor processing, audio pipeline staging, control loops, and industrial I/O
• Supporting safety-critical (ASIL) functions with strong fault isolation from Linux/Android, Enabling always-on, low-power features
• Providing a scalable solution across multiple domains (Automotive, IoT, Robotics, Mobile)

Limitations of the Current Design:
The submitted patches represent an interim solution based on a legacy Android/Linux-Metal architecture, with the following limitations:
• Heavy reliance on user-space middleware
• Kernel-to-user signaling via mechanisms such as eventfd
• Split-domain routing and fragmented control flow
This design does not align with upstream kernel principles and effectively represents an architectural dead-end. Specifically:
• It introduces a volatile, non-standard uAPI that would need to be deprecated and replaced shortly
• It does not fully leverage native kernel abstractions
• It includes temporary Device Tree dependencies that will be removed in the upcoming re-architecture
For these reasons, we want to avoid upstreaming this interim model.

Ongoing Architectural Rework:
In parallel, we are developing a clean, upstream-aligned design with:
• A kernel-native driver model based on standard misc/character device frameworks
• Elimination of custom uAPIs
• Dynamic device creation using self-describing metadata from shared memory at boot
• Native interrupt handling within the kernel
• A unified architecture across QNX, Android, and Linux
We are also working on integrated page table management to support RTSS requirements such as IOMMU pass-through or scatter gather buffer mapping support. This is still under development.

Why Downstream Is Needed Now:
Completing this unified architecture requires significant cross-platform development and validation. Forcing immediate upstream readiness would delay critical hardware enablement.
Our immediate priorities are to:
• Enable RTSS Support
• Support downstream FIT configuration and IPC functionality
• Allow early evaluation and OTA workflows
The current downstream implementation serves strictly as a temporary bridge to support these needs.

Commitment:
We remain fully committed to upstreaming once the architecture stabilizes. At that stage, we will:
• Refactor the implementation to meet kernel standards
• Remove all legacy dependencies and interim design elements
• Submit a clean, unified RTSS IPC driver stack for upstream review
We expect to propose this upstream-quality solution by end of next year or earlier.

Request:
Given that the current submission is strictly an isolated, interim solution (including temporary Device Tree dependencies) intended for early bring-up, we kindly request approval to proceed with the downstream integration. This will allow us to meet immediate product needs without introducing long-term technical debt into the upstream ecosystem.

Please consider this as common response to RTSS enablement PRs.

[Dmitry Baryshkov (lumag)]

RTSS is designed to handle deterministic, latency-sensitive workloads, while the APSS handles higher-level applications. Key use cases include:
• Offloading time-critical workloads such as sensor processing, audio pipeline staging, control loops, and industrial I/O
• Supporting safety-critical (ASIL) functions with strong fault isolation from Linux/Android, Enabling always-on, low-power features
• Providing a scalable solution across multiple domains (Automotive, IoT, Robotics, Mobile)

This doesn't answer on the question, why is it necessary. In the end, sensor processing is handled by the SDSP or ADSP. Audio pipeline staging is also handled by the Linux / ASoC stack. How does it fit the IIO subsystem? What do you mean by control loops? How does it work? Does one submit a workload to the separate processor? Then you should be using remoteproc / rpmsg. Is it purely a synchronisation with the separate processor? How does it fit the programming model.

Regarding the meta-qcom acceptance. Why is it a separate DT overlay? Granted that Linux already supports qcom,ipcc cores, adding a second qcom,ipcc should be easy and upstreamable. Then the RTSS DT bindings can be aligned to the upstream. Please do that homework and align them to something that can be sent upstream in future. DT convergence is a must, not a leisure.

There should be no need for any DT overlays (nor toggling via the UEFI variables). If the hardware is there, it should be enabled. The driver can be a part of a separate DLKM (for now).

[snegi-qti]

Regarding the meta-qcom acceptance. Why is it a separate DT overlay? Granted that Linux already supports qcom,ipcc cores, adding a second qcom,ipcc should be easy and upstreamable. Then the RTSS DT bindings can be aligned to the upstream. Please do that homework and align them to something that can be sent upstream in future. DT convergence is a must, not a leisure.

There should be no need for any DT overlays (nor toggling via the UEFI variables). If the hardware is there, it should be enabled. The driver can be a part of a separate DLKM (for now).

Hi Dmitry Baryshkov (@lumag) , thanks for your guidance here.

We understand the suggested direction for upstreaming the second qcom,ipcc instance.
One question from our side is whether a standalone IPCC DTS addition is likely to be accepted upstream when there are currently no upstream consumers for that IPCC instance. Our understanding has generally been that upstream prefers hardware descriptions to have a real upstream user, and code/DT that is not consumed by anything is often difficult to justify.

Since the existing RTSS use case is not upstreamed, we are concerned that the IPCC node itself may not be accepted in isolation. If our understanding is incorrect and a standalone qcom,ipcc provider node is expected to be acceptable upstream even without a current consumer, please let us know so that we can proceed accordingly.

[Dmitry Baryshkov (lumag)]

One question from our side is whether a standalone IPCC DTS addition is likely to be accepted upstream when there are currently no upstream consumers for that IPCC instance.

There is a user, it's called IPCC driver.

[snegi-qti]

One question from our side is whether a standalone IPCC DTS addition is likely to be accepted upstream when there are currently no upstream consumers for that IPCC instance.

There is a user, it's called IPCC driver.

Understood, thanks for clarifying. Our concern was around acceptance of a standalone IPCC DTS addition without any current upstream client DT nodes (like RTSS) referencing it. If the existing IPCC driver is sufficient justification for the second IPCC instance, that answers our question.