Re: [PATCH v2 01/23] dt-bindings: display: msm: Add Qualcomm DCP

[Jayant Shekhar]

On 11-11-2026 19:43, Dmitry Baryshkov wrote:
> On Wed, Nov 11, 2026 at 12:38:54PM +0530, Jayant Shekhar wrote:
> > On 26-10-2026 15:27, Dmitry Baryshkov wrote:
> > > On Mon, Oct 26, 2026 at 11:51:11AM +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 Qualcomm transport
> > > > wrapper, display topology, IOMMU contexts, and panel connections.
> > > >
> > > > Add bindings for the Qualcomm DCP transport wrapper and VirtIO display
> > > > subsystem. Document the IPCC power-notify resources, transport and
> > > > framebuffer IOMMU contexts, firmware-visible IOVA range, INTF graph, and
> > > > DSI panel connections. The wrapper creates a standard VirtIO-MMIO child
> > > > after the IPCC power-notify sequence has completed.
> > > >
> > > > Assisted-by: LLM
> > > > Signed-off-by: Jayant Shekhar <jayant.shekhar@xxxxxxxxxxxxxxxx>
> > > > ---
> > > >    .../bindings/display/msm/qcom,dcp-dsi.yaml         |  79 ++++++++++++
> > > >    .../devicetree/bindings/display/msm/qcom,dcp.yaml  | 123 +++++++++++++++++++
> > > >    .../bindings/virtio/qcom,dcp-virtio.yaml           | 132 +++++++++++++++++++++
> > > >    3 files changed, 334 insertions(+)
>
>
> > > > +
> > > > +patternProperties:
> > > > +  "^dsi@[0-9a-f]+$":
> > > > +    $ref: qcom,dcp-dsi.yaml#
> > > When adding DP support, would you add more devices at the same level? If
> > > so, we risk getting a warning about multiple devices using the same
> > > address.
> > Is it good to model each firmware INTF as a single interface@N node carrying
> > the INTF reg, with the protocol-specific DSI or DP description nested
> > beneath it?
> > The driver can then obtain the INTF index from the common parent, avoiding
> > duplicate addresses across protocol types.
> Yes, it might be good, but it's not what is happening here. You are
> adding dsi@0, although, I guess, INTF is 1.

I raised that approach before v3, but the patch still uses dsi@0 
directly. I’ll update it to use a common interface@N node keyed by the 
INTF index, with the protocol-specific DSI/DP description nested beneath it.