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 <[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.
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.
