From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=205.220.168.131 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792582770; b=mFw50hPzZ9rBQY3cB3zv+B29SOfvpZZcMx7U8Wwz7eL0kHLeBKsOh29D1IVmTB6Zcz6f URGqa+MJb4kXMB1QkPJKHBsaQo5Ng0M9hDsY0cLKELWDcM3qfoQGJ1S50BzjBYBumCaXe KWRUXu00KtIU+x5t+/RaHFeIZaSSvSteGaT2M7QYu3ceUQ2YJIUBTQ3pzPugeE8+ziSdS N9Z1SqMmvemiQMyZLMpmuxw2Nsn6KM5ldCSBgKA92H/VvoTvX8POl1CPX/AkXMF/PPzl9 qdVaVuqswD1qDwGzJiEV++s4oGw+v2fS+jgMQEgC0/Lg43/VC5wY6t+jq7yq1R1AfoQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792582770; h=DMARC-Filter:Received:DKIM-Signature:Received:Received: DKIM-Signature:X-Google-DKIM-Signature:X-Forwarded-Encrypted: X-Gm-Message-State:X-Gm-Gg:X-Received:X-Received:Received:From: X-Google-Original-From:Message-ID:Date:MIME-Version:User-Agent: Subject:To:Cc:References:Content-Language:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-Proofpoint-ORIG-GUID:X-Proofpoint-GUID: X-Proofpoint-Spam-Info:X-Authority-Analysis: X-Proofpoint-Spam-Details-Enc:X-Proofpoint-Virus-Version: X-Proofpoint-Spam-Details; bh=bGXJfjCCrUH5RZmEcReSeM7EPT2qwuvFA/PK6PwffXI=; b=aQYebIzdekawUagKP27VI4KdLkn2ulLsbtCivVCS85CYBhA8Ez5OPT5narc1/JoK2LHR 0gsn89sMUTaDepKHe3FlfkPKMXNcooeeIwITxSCUJgBbkEZ3d9JCqPbnt0xMK9KcNsORU 3+Um3OO4e72FO/L52AU3z9gkOTJIK+pVJv9BSkXM3K9C+mpf1EKMQ/v6Gu7TjaKR1hg9Y c0ch6nRfNg2BPEU6l3m9KWBjGOxZoSRLm0XrQFO6yHsvShjnHx3VBj8FMOmEAUcLBy0/R 7QIfpIyuGH2cOIHv1+VJo0ulTCpYPoDGpSYMj9Dy2Ly6681QC/pC2UhDWUKD3z4HvWA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass header.d=qualcomm.com header.i=@qualcomm.com header.a=rsa-sha256 header.s=qcppdkim1 header.b=T9VRn1QL; dkim=pass header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.a=rsa-sha256 header.s=google header.b=HnOGRBnv; arc=none smtp.remote-ip=205.220.168.131 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DBE86606A319 for ; Wed, 21 Oct 2026 11:39:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org DBE86606A319 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=qualcomm.com header.i=@qualcomm.com header.a=rsa-sha256 header.s=qcppdkim1 header.b=T9VRn1QL; dkim=pass (2048-bit key, unprotected) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.a=rsa-sha256 header.s=google header.b=HnOGRBnv Received: from pps.filterd (m0279865.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69LA630k1358647 for ; Wed, 21 Oct 2026 11:39:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= bGXJfjCCrUH5RZmEcReSeM7EPT2qwuvFA/PK6PwffXI=; b=T9VRn1QLoZ3qsW1g 7n1m07aEUz0lY+4t+8Oe1+aBdXw9JEmYIQnw6ZkxlTM4byCoWqImniHAyYrLeGHz 8nrooNDQ0kSJvUSTpw3Pv1i38317ZFO1LJ6BYSzejBh59oEGQgCKptPeIWL3Znlc WD2Vw0Fqb16vKs+6YDgQwN0DfK4HnT6Z5uWYUvCaq9kFuuiw7MPh8+Ovc6j2HcM2 GCn0bRvkJVmP186Zn7rL82ZhDfmZ6LTxyHJeKWRelnS5ADJISfORmV9o23G04RCC ai93GFgIIN22kofHu3LBpjMkloNAPsWhUVek8QWEM0fk0kPuenN+WRZqMKWbyOmY qHxjcQ== Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4heda4upna-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 21 Oct 2026 11:39:28 +0000 (GMT) Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-cd652c0385bso352469a12.2 for ; Wed, 21 Oct 2026 04:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1792582768; x=1793187568; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=bGXJfjCCrUH5RZmEcReSeM7EPT2qwuvFA/PK6PwffXI=; b=HnOGRBnvJsKgrR45CSTnp2NkHUf3lcYfG1DI6rFx6wDDUIiqxcUtBX2XGoAAAInPKF wQD/UCeOw79sW96yI6ztVPwMRb0UdeUyMS47n/7A3Ay0monkRjmxXfwaKceDO3wz9D5f LfhgZ/8E0D2AWRd7kJzaFNBP1mMMOipH6zfvVViHTb52iVTEA39CAoCud+N7kB41k7eA wdpoKT4B7Nvj2MvD2bVqSfhq0/gLEpc1ZQ5SlWlrig4tiTH2DnVVIIzr+D6LS74vqXw9 UsvhBelgQcvX3wQ+1zbg2WMsLDCOSXoUlCB8UOPZdjOuggSdIgeybLGAETxsAgsofNao 5K0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792582768; x=1793187568; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=bGXJfjCCrUH5RZmEcReSeM7EPT2qwuvFA/PK6PwffXI=; b=baaO4/Frm1izZqaNwS2Bw8lTZfFNk4Nn+qPbWotJUfL11LY52RS1+sEAX5bv/ThxOt kYmfR5oOrTHCP0GO+o7rChbEGqPkLDh70X6uezw6lrEdYlM3+1QBEJPRnyEJuXqGCcSI 9tDyDWxySJc2DP9r5QmDtF309JDEwVYK1S1vnCYfAQOxA1wy1JzojivNPl+dUvO/6UH4 KEeiAZ2HibboNulJ+PdKBAX5VeD/03f7gbyLQNqq+NCyV92Uj4ojVEl+y8fR+tyWrmOU Nlrlkwo6N6eCHTSZDMtc7VUN81XWNLOOXIA31qFykuhtiNWdQrJeR4ARGbH9dBjnDIZh jezQ== X-Forwarded-Encrypted: i=1; AKwUvBybi8o7dN5Sc0tO8akFITJp1d5emHEVtx2AMjS29wLbo0olq/Z46BnTQEC1Yx+x/WqFSy58LNVQ7BAH@vger.kernel.org X-Gm-Message-State: AFq9FYJ/qyXcQS3OkNaop2MPcEK0rrj4PJRqIU2lGtqOgwYKEo94yg8J s74TzWu2sLW0NpjhML7B2y25BASkr+/LvAhx4Iav5f0nYzk9cNQbEY1CulbyJQ8rCenTUtAH1ja Admwrr1QT6eJlWDKYIf+V3xgCRjgbVE9AeAuKXyH/wuZtyGHj5ZL+RI8Sit9J3klW X-Gm-Gg: AYBFou2S7uUHyBR2yXNpZxsz5wiu1nIk/cBH2E0wGQuTLYHziwqXhmAS6J4VUgrP5Jg l9gl03eysbzK9Sj8twqdbxbjhsk6wWdzSCgCypBawpA9zzjlCft7+r6AGHwqaSI3oVt4n8GZyHW 0mVIZqV6MWIK1ZUAAnsr3O+n+4g8Nc0nBHb4iTo6FxjxNSM/k3oxY1knflfRngGuT6E+wa8uDLh fN+QDS0P7oDnkR9DuxYoGhkiWW/Sdu2SielGzoNYxOzTj9po14E9b0UZVtckYp52q4A3hRv/WOz LBYVl6YzADVW07E/Qak92ovtF+PV+wfUZ7ldVF6AazCoVDsoBvaYFytlfKZ1iEZ/enfek0akPiA LxJSCeR7mNeCleYt9gFkOEZTe4sm3E0VNcQ== X-Received: by 2002:a05:6a20:6a1b:b0:3de:46cc:b63c with SMTP id adf61e73a8af0-3e287d53782mr1589251637.11.1792582768098; Wed, 21 Oct 2026 04:39:28 -0700 (PDT) X-Received: by 2002:a05:6a20:6a1b:b0:3de:46cc:b63c with SMTP id adf61e73a8af0-3e287d53782mr1589233637.11.1792582767612; Wed, 21 Oct 2026 04:39:27 -0700 (PDT) Received: from [10.204.79.28] ([202.46.23.25]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cd6a85a32b2sm712484a12.8.2026.10.21.04.39.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Oct 2026 04:39:27 -0700 (PDT) From: Jayant Shekhar X-Google-Original-From: Jayant Shekhar Message-ID: Date: Wed, 21 Oct 2026 17:09:15 +0530 X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 01/13] dt-bindings: display: msm: Add Qualcomm DCP bindings To: Dmitry Baryshkov , Jayant Shekhar Cc: Rob Clark , Dmitry Baryshkov , Abhinav Kumar , Jessica Zhang , Sean Paul , Marijn Suijten , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , Philipp Stanner , Bjorn Andersson , Konrad Dybcio , Abel Vesa , "Joerg Roedel (AMD)" , Will Deacon , Robin Murphy , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, iommu@lists.linux.dev References: <20261015-jshekhar-drm-msm-dcp-v1-v1-0-48aad0fe4f72@oss.qualcomm.com> <20261015-jshekhar-drm-msm-dcp-v1-v1-1-48aad0fe4f72@oss.qualcomm.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: Bjec6ZeH5fwObcwc5HLFSr_FC5tcss6u X-Proofpoint-GUID: Bjec6ZeH5fwObcwc5HLFSr_FC5tcss6u X-Proofpoint-Spam-Info: AW1haW4tMjYxMDIxMDA0NiBTYWx0ZWRfXyxxUAIIbnCq9 rR3CAgJ86GbrDCDzoHY4GkLsF3XXZ36uXAmfpmO2glpLx270459Ih+csRIq4Nnd1gpUTsunVd9j OSOpXxVCWC5/NJG4S+gE/49cCn96iUE= X-Authority-Analysis: v=2.4 cv=R7aWitRX c=1 sm=1 tr=0 ts=6ad8a470 cx=c_pps a=oF/VQ+ItUULfLr/lQ2/icg==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=Um2Pa8k9VHT-vaBCBUpS:22 a=gEfo2CItAAAA:8 a=EUspDBNiAAAA:8 a=kn4dWm41NmOkgBkIVkoA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=3WC7DwWrALyhR5TkjVHa:22 a=sptkURWiP4Gy88Gu7hUp:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDIxMDA0NiBTYWx0ZWRfX6LTe01Yz4P3N hNEae9f4gnDzIclEii+ytsZezsw48a/y3+ywMY7WQV2mzYvPGv91e3/yl8QlIixZfoj05CsVKq9 p1var1pOeFz3OfjKRqBRxUr+hZsxkBG+4LMHVcUceHr4yYgICZSGaCaf94WgmrAPsfx9gfNjgCW ENHHawfq4jD9V/OVPYMQt7RiDB/HJMPw7xV4rR1iIP/pfvwkkQ1kgMYOMRm3AAwmF01Xx4tPlj+ SmDgMfEHDN7JTCdEPnBObY34nWjvCJzb43+g5TLrsCiQ5gquWyRszzZWDcbj91Erqn4l82mclSC s9oSzePdVLT055U21caa1/owa74CcTsmCFyJo/1P+rPjJ3bymDt3m2RGN8IEcYYOEdzomXUWFYs fvZbmFgwcgxyDKTHWpl89Jm+2/LG4HI+jq6eZmL7rL1/DH9rv5v4iYLw6u0hA/YdwSjxZyAAstL uk4I6TglTOKR/GBi7eg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-10-21_03,2026-10-19_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 clxscore=1015 impostorscore=0 bulkscore=0 spamscore=0 suspectscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610210046 On 21-10-2026 14:15, Jayant Shekhar wrote: > > 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 >>> 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 >>> + >>> +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 >>> + >>> +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 >>> +    #include >>> + >>> +    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 > > I think Option 1 is not suitable because the IPCC power-notify sequence is required before the first VirtIO-MMIO register access. The standard VirtIO-MMIO driver would otherwise probe the DT node directly and access the registers before Qualcomm-specific initialization is complete.   Would the following Qualcomm-specific transport approach be acceptable?   - qcom,dcp-virtio is the DT-compatible Qualcomm wrapper. It initializes IPCC and sends the required power notification before creating a synthetic virtio-mmio platform device.   - The unchanged generic VirtIO-MMIO driver probes the synthetic child, accesses the MMIO registers, creates the VirtIO queues, and registers the VirtIO device.   - The DCP VirtIO driver binds to the resulting VirtIO device through its VirtIO device/vendor ID table and initializes HFI, firmware capabilities, and DRM/KMS.   - The virtio,deviceXX DT child is discovered by the VirtIO core and describes the DCP-specific IOMMU context, DSI hosts, display graph, and panels.   The flow is:   qcom,dcp-virtio       → IPCC power-up       → synthetic virtio-mmio device       → generic VirtIO-MMIO driver       → virtio,deviceXX DT child       → DCP HFI/DRM driver   Since the Qualcomm wrapper creates and owns the synthetic VirtIO-MMIO device, the parent node uses only:   compatible = "qcom,dcp-virtio";   It should not also advertise "virtio,mmio", because the generic driver must not probe the parent directly before IPCC initialization. >>> +        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>; >>> +                        }; >>> +                    }; >>> +                }; >>> +            }; >>> +        }; >>> +    };