On 15-10-2026 17:47, Dmitry Baryshkov wrote:
On Thu, Oct 15, 2026 at 01:08:21PM +0530, Jayant Shekhar wrote:
DCP platforms place the display pipeline under firmware control, so Linux
cannot discover display resources through direct register access. The DRM
driver therefore needs device-tree descriptions of the firmware transport,
display topology, IOMMU contexts, and panel connections.
Add bindings for the Qualcomm DCP VirtIO display function, including the
INTF graph and DSI host outputs. Document the framebuffer IOMMU context,
IPCC power-notify mailbox and interrupts, firmware display topology, and
firmware-visible IOVA window supplied by the parent VirtIO-MMIO transport.
Signed-off-by: Jayant Shekhar <[email protected]>
Assisted-by: LLM
---
.../bindings/display/msm/qcom,dcp-dsi.yaml | 75 +++++++++++++
.../bindings/display/msm/qcom,dcp-virtio.yaml | 113 +++++++++++++++++++
.../devicetree/bindings/display/msm/qcom,dcp.yaml | 119 +++++++++++++++++++++
3 files changed, 307 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,dcp-dsi.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,dcp-dsi.yaml
new file mode 100644
index 000000000000..f7178c66c09e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,dcp-dsi.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,dcp-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm DCP DSI host
+
+maintainers:
+ - Jayant Shekhar <[email protected]>
+
+description: |
+ A MIPI DSI host exposed by the Qualcomm DCP VirtIO device (see
+ qcom,dcp.yaml). DCP is a firmware protocol shared across multiple
+ Qualcomm SoCs, not specific to any one of them; Hawi is its first
+ platform. The DSI host and its connection to a panel are described
+ using the standard DSI controller and OF graph properties.
+
+allOf:
+ - $ref: /schemas/display/dsi-controller.yaml#
+
+properties:
+ reg:
+ maxItems: 1
+ description: Index of this DSI host among its siblings.
+
+ status: true
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description: |
+ port@0: Input from the DCP virtio device's DPU INTF output port.
+ port@1: Output to the attached panel.
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
Why do we need OF graph here? Would it be enough to link one of the
ports of the root node with the panel's input?
+
+required:
+ - reg
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ dcp-subsystem {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsi@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dcp_dsi0_in: endpoint {
+ remote-endpoint = <&dcp_intf1_out>;
+ };
+ };
+
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/display/msm/qcom,dcp-virtio.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,dcp-virtio.yaml
new file mode 100644
index 000000000000..018694310dfb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,dcp-virtio.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,dcp-virtio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm DCP VirtIO host
+
+maintainers:
+ - Jayant Shekhar <[email protected]>
+
+description: |
+ Qualcomm's DCP VirtIO host provides the generic VirtIO-MMIO transport and
+ the host-side IPCC channel used to wake the DCP firmware.
+
+properties:
+ compatible:
+ contains:
+ const: qcom,dcp-virtio
+
+ reg:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ iommu-ranges:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+
+ interrupts-extended:
+ minItems: 2
+
+ interrupt-names:
+ items:
+ - const: virtio
+ - const: dcp_power_notify_irq
+
+ dma-coherent: true
+
+ mboxes:
+ maxItems: 1
+
+ mbox-names:
+ const: dcp-power-tx
+
+ dcp-subsystem:
+ $ref: qcom,dcp.yaml#
+
+required:
+ - compatible
+ - reg
+ - interrupts-extended
+ - interrupt-names
+ - iommus
+ - dcp-subsystem
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/mailbox/qcom-ipcc.h>
+
+ virtio@9be8000 {
+ compatible = "qcom,dcp-virtio", "virtio,mmio";
Is it really compatible with virtio,mmio? Can it be handled completely
by virtio,mmio?
There are two possible approaches:
Option 1 — Use the standard VirtIO-MMIO parent (preferred)
Keep the parent as:
compatible = "virtio,mmio";
reg = <...>;
interrupts = <...>;
iommus = <...>;
iommu-ranges = <...>;
dma-coherent;
The generic virtio/mmio.yaml binding would be extended only to document
the generic iommu-ranges property.
The DCP-specific resources would be placed on the virtio,deviceXX child:
dcp-subsystem {
compatible = "virtio,deviceXX";
iommus = <...>;
interrupts-extended = <&ipcc ...>;
mboxes = <&ipcc ...>;
mbox-names = "dcp-power-tx";
};
The parent uses the standard VirtIO-MMIO interrupts property. The child
has one DCP-specific interrupt, so interrupt-names is unnecessary and
the driver uses interrupt index 0.
Option 2 — Add a Qualcomm-specific VirtIO-MMIO parent binding
Keep a Qualcomm-specific compatible such as:
compatible = "qcom,dcp-virtio", "virtio,mmio";
and extend the parent binding to describe iommu-ranges, the additional
IPCC interrupt, mailbox, and related DCP resources.
However, this approach duplicates the generic VirtIO-MMIO binding and is
only justified if the transport requires Qualcomm-specific handling.
Since the DCP transport is handled completely by the standard
VirtIO-MMIO driver.
Which one do you prefer?
I will be addressing other comments in v2.
Thanks
Jayant
+ reg = <0x09be8000 0x1000>;
+ interrupts-extended = <&intc GIC_ESPI 956 IRQ_TYPE_LEVEL_HIGH>,
+ <&ipcc 13 5 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "virtio", "dcp_power_notify_irq";
Why do you need names? Can they be dropped in favour of using indices?
+ iommus = <&apps_smmu 0x15a3 0x0>;
+ iommu-ranges = <0x0 0x84000000 0x0 0x04000000>;
+ dma-coherent;
+ mboxes = <&ipcc 13 5>;
+ mbox-names = "dcp-power-tx";
+
+ dcp-subsystem {
+ compatible = "virtio,device34";
+ iommus = <&apps_smmu 0x400 0x2>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ dcp_intf1_out: endpoint {
+ remote-endpoint = <&dcp_dsi0_in>;
Can this point directly to the panel_in? What's the point of describing
internal paths in the DT?
+ };
+ };
+ };
+
+ dsi@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dcp_dsi0_in: endpoint {
+ remote-endpoint = <&dcp_intf1_out>;
+ };
+ };
+ };
+ };
+ };
+ };
