From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=205.220.180.131 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792582772; b=WyMvopoeCwZy5rzEdd5DM6IuhvC1w2+4RHcG50vKxAXZ1C0iHwFY6SbcQcExgO8E6ujs G0LInk09gfgNaLirj1VgW52BOSvy1tSmLbHHiKv69y8XeBtKEUjo6Wxvo8BAQWjqJWvit hOOo9xUKFG1iCceGqgCQviYt3D6xpHk0jTtDhCpLzMxygyUhwEeDcFWLufTTIXkwOBzt+ +ZXlPWugLvv90fgP98IpPaKBo8GZZdfF63Rh2IVx4haXJdHyJJjocB+fHw0lUTZwDfoOO pPNJs1r9M5Vjih84B3jkw3xg67M5+yXRYvFLzK4ZU+51DIhJ/7VH/WBHGBwxsssBAsA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792582772; 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-Authority-Analysis:X-Proofpoint-ORIG-GUID: X-Proofpoint-Spam-Details-Enc:X-Proofpoint-GUID: X-Proofpoint-Spam-Info:X-Proofpoint-Virus-Version: X-Proofpoint-Spam-Details; bh=bGXJfjCCrUH5RZmEcReSeM7EPT2qwuvFA/PK6PwffXI=; b=swxDToYXeLoMnq9sO9C2srwiiWBVwAJvQvhchpKr501p991UeS1RZaYKm3FJEN/75AjZ 5NZ7MR9ZzkqbmKVhOsE0s6gv4bCenckjn1/WsM9VDuR/1eNIJUmZLUu+h40sDgoqtYwbZ 9LRgI0+4cvlsI2Ro3p1TQTa/Ugot026N9PrYHn9Q32OQNCagRRsd6aWhtzTJkpBdfyIQi e8L5xPDU102h/v1QMRHfX6q8+npMvFaQdZYQdPa6pd3QAw6bfyokgjEb/Y/8oiw85IHor VvF92EEExae1GxpCI5DGEW1cqbbwXwA6ibYPGuM5kAMzy33b5dZAiSBo61+Ayu8sg3g== 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.180.131 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.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 0FF31606A31F for ; Wed, 21 Oct 2026 11:39:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 0FF31606A31F 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 (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 69LB1DRB401972 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-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4heh5r2sxn-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 21 Oct 2026 11:39:29 +0000 (GMT) Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-cd60e4e8bc3so335077a12.1 for ; Wed, 21 Oct 2026 04:39:29 -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=bnMoOl4m9pBkCqrkbfvgqcr/tZSf5widwIFnqW1qFFvwX8N/TvtpCgbBC//lH57kLv +HyULabA+cVntpI9+e5rA3T6dfgRwAVbASmnZfsSd27ePa7R5Rjo8HO/GqR0cI5+5+EV hvt6IPCi45aUn+1ICjf0PmNrynfuLb4Xb34JAiOhDS76ZGasNZlzCZuJdBls2Uu1QYR8 6DEDsuAjbHmyqgwAF7VA6en/7C/9GF2B+SvGAOXEkPVPIUJT/6ryNrWh9gIYIHmMsoVN xhbgy2I4PguQvRgSqwllrpYWVdU14BGXLKHkxBHdMqt/gsyC1onzSggEQ2mdnGpGQo4y Wx8w== X-Forwarded-Encrypted: i=1; AKwUvBw1twThoWOPkSdnPXALrN3qzetTCqtJfH6rp/blGG8Xlh3sMQFF9xqoiiaAjIXXy+6wjsDu2bzPNpc4YKc=@vger.kernel.org X-Gm-Message-State: AFq9FYJulpH2q5Qopi/8snwOW+d3IYC++0mdRo4VBCvkAOKGN/YrHVPZ JbpMKobwp3bqaMVIx4qV+iNTZL90+mTGx4rUl7YLqldIDHVNR4JSZrV+FOHK0qUxykK/5bEjNYt zIzjIBCP/1SwqSZpVx8hf8JAD7QnQVNZHkNUnpUa3xVxFFrSLz4PlALcAZA46skJd04o= X-Gm-Gg: AYBFou00Of6loU/zl9cr0TuKGnB+NszeYz0Fe2S+oxF/E+F+HbCoyVHjhZkE08LuMun 678djdkHvSQDBL6f/AYIDxTB/vxQ3ntTkiqjZidk3CnMmSLG1ne1KeIhdvr6hmquac6lL0xA3H/ tRYBCn7xOyjC3/222GySXbuBoGgHkgaBJ1GInmcRrnBKT8CZgDWd/OZapeOqydD664gW2grsJYo QTajppysJU1g3doswTMCR2lpli0CcJ2r0iFiNORR9GKDEWo4mhAjP2s1aNrk0x4gocroo7qrPr6 8yx03JLwSySNyOOI5wUaaYD+gwm8cphiBi+kTfg3sebHoZdqVapJFppl+U+s3tRPd1nlNF9OG1o zsh/G1GXvCRt2s9/3yuk2V1uFGow/3sXkKQ== X-Received: by 2002:a05:6a20:6a1b:b0:3de:46cc:b63c with SMTP id adf61e73a8af0-3e287d53782mr1589285637.11.1792582768164; 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: linux-kernel@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-Authority-Analysis: v=2.4 cv=aI5lOr9m c=1 sm=1 tr=0 ts=6ad8a471 cx=c_pps a=rz3CxIlbcmazkYymdCej/Q==:117 a=ZePRamnt/+rB5gQjfz0u9A==:17 a=IkcTkHD0fZMA:10 a=660iZSQnnn4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=gEfo2CItAAAA:8 a=EUspDBNiAAAA:8 a=kn4dWm41NmOkgBkIVkoA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=bFCP_H2QrGi7Okbo017w:22 a=sptkURWiP4Gy88Gu7hUp:22 X-Proofpoint-ORIG-GUID: H30PQMG9atx01lC_1mL00FnqoCnyYZfW X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDIxMDA0NiBTYWx0ZWRfX98xUUMBEBT0z lqtzFHe1f0DDEImfAPH2AeLk7iIm1FsbGZp+iCIryyqqO/si4HMk27UC9VYYQaNwmIZMXeBmhr1 x2JwUFrzcq3Y+SXVp21UUpoEnZe3BdQYqnd3mcg78sa6y5aPeRpYqJi+QofWgV639QTNBFWtWzw ACUpslumi0Yz2DKc8i0u8S6Vs1j6xgYHFhXd1JZFEsJ5v7KuTgr8l3WDntCx9CscOtdmi4ZSy1U oY0TC4BjtrGPdM1FDaQ65St0XmY+O276RW8kNeDR2RQ2CdD6gff7gKQK+bibMagPgOy2i5Q1gsD jzsFjr7vRBZ8TZx12WP5bT8sLPWQLLkS2bohKzFMm+O6rhZ6lPof2Av62ZHc5i6ILkqWNK7x42H 4rfjVK6f/sWLcMmNFsTg7VTpEUOz4n0OB01Azn5tPqzIDnpQJdMcpEk9OZivrCZoW4QB3YJ37cv 4Tub3c0rQEAfbuALuUQ== X-Proofpoint-GUID: H30PQMG9atx01lC_1mL00FnqoCnyYZfW X-Proofpoint-Spam-Info: AW1haW4tMjYxMDIxMDA0NiBTYWx0ZWRfX/mZzTCNiZOZo Qkilnk9/l1kEkUNXONpesqhK6IYUKJtOMTwTUN302j6r1607O5BX+pmJBv61ciaZSeG+gqB+5es nYTHudOKhn+lhRiqPFqJ/6f3qxEskBw= 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 priorityscore=1501 clxscore=1015 impostorscore=0 spamscore=0 bulkscore=0 malwarescore=0 suspectscore=0 adultscore=0 phishscore=0 lowpriorityscore=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>; >>> +                        }; >>> +                    }; >>> +                }; >>> +            }; >>> +        }; >>> +    };