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 <[email protected]> > > > --- > > > .../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. > > > -- With best wishes Dmitry
