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?
> + 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>;
> + };
> + };
> + };
> + };
> + };
> + };
--
With best wishes
Dmitry
