On 10/1/26 02:43, Dmitry Baryshkov wrote:
On Wed, Sep 30, 2026 at 09:18:55PM +0200, Neil Armstrong wrote:
On 9/30/26 21:04, Dmitry Baryshkov wrote:
On Wed, Sep 30, 2026 at 06:43:47PM +0200, Neil Armstrong wrote:
On 9/30/26 09:44, Linus Walleij wrote:
On Tue, Sep 29, 2026 at 3:35 PM Krzysztof Kozlowski <[email protected]> wrote:
This entire binding seems like stitching two devices together, which
might be fine (I don't even remember this stuff... two months old) or
might be artificial grouping of separate devices.
I think that's a good point and fair pushback.
Neil and Jun talk about it yesterday at XDC (1:15 into the stream):
https://www.youtube.com/watch?v=6tNGW8PoSzw
The current binding does not reflect the physical topology of the
actual device, and the bindings need improvements. I have a feeling
there is one display controller with two physical panels.
No there's really 2 controller and 2 separate panels, but they are not
classic panel, they are a pair of panels+lens which are in front of
the eyes which forms a single "image" for the brain, so they are
technically a single display and requires to be hard synchronized.
Yes. However this approach makes it impossible to share the code between
the double-panel drivers and single-panel drivers. I think, that the
panel driver should still reference a single glass+DDIC, while letting
the DSI host driver to handle the bifurcation.
Yes, and no, it must really be considered as a "single panel driven by 2 identical
controllers",
and even this is really purely software implementation issue.
[...]
Describing both panels into separate nodes would only be possible
if we described a "VR display complex" nodes linked to both panels
but this would probably be solved by actually describing the "display"
linked to a DDIC controller and is out of subject for this serie,
and can be added later when we properly define things.
I like the VR complex idea. In the end, you have two modes which you
most likely might want to support:
- L+R, having double-width CRTC scanning over a double-width framebuffer
- Mx2, having a single-width CRTC and a single-width framebuffer
displaying the same picture to both eyes. I can imaging that knowing
about L+R might be an explicit opt-in feature of the DRM interface.
This makes no sense to support both modes, and this will never be used,
and anyway this is purely software implementation.
We're defining bindings here, describing the real reality, not hypothetical
situation that will never happen.
Let's ignore software issues. On the hardware side, you have two
distinct DSI panels, each having its own set of controls, own DSI link
and own backlight control.
OK so let's see the problem in another angle, if we had 2 DS links 2 physical
controllers, 2 physically distinct panels but forms an unique display.
Describing it in separate distincts nodes is wrong since it doesn't reflect
that it's an unified display, so either we define :
- a "combined-display" bridge defined as:
- a separate top node in / like connectors with a graph from the DSI links to
each panel
- a DSI subnode with 2 panels as subnode, port graph from both dsi to both
sub-panels
- a "R63455" panel bindings with 2 subpanels as Linus shared in
https://lore.kernel.org/all/CAD++jLkyEPY5cFg_pHb71yG52iLwS9tQDpcHu=ttbknqmef...@mail.gmail.com/
I think it would be interesting to have the "combined-display", with a
connector-like node,
which will do all the split-dsi dual-panel logic for us and leave use
implementing simple panel
drivers.
The outline would be:
=====><=======================================
/ {
xr-display {
compatible = "combined-display";
ports {
port@0 {
combined_dsi0: endpoint {
remote-endpoint = <&dsi0_out>;
};
};
port@1 {
combined_dsi1: endpoint {
remote-endpoint = <&dsi1_out>;
};
};
port@2 {
combined_panel0: endpoint {
remote-endpoint = <&r63455_right_in>;
};
};
port@3 {
combined_panel1: endpoint {
remote-endpoint = <&r63455_left_in>;
};
};
};
};
};
&mdss_dsi0 {
vdda-supply = <&vreg_l3i_1p2>;
status = "okay";
qcom,dual-dsi-mode;
qcom,master-dsi;
panel_right: panel@0 {
compatible = "sharp,ls026b3sa06", "synaptic
reset-gpios = <&pm8550_gpios 3 GPIO_ACTIVE_HIGH>>;
pos-supply = <&vpos_right>;
neg-supply = <&vneg_right>;
backlight-supply = <&backlight_right>;
vdda-supply = <&vreg_l12b_1p8>;
port {
r63455_right_in: endpoint {
remote-endpoint = <&combined_panel0>;
};
};
};
};
&mdss_dsi0_out {
remote-endpoint = <&combined_dsi0>;
data-lanes = <0 1 2 3>;
};
&mdss_dsi1 {
vdda-supply = <&vreg_l3i_1p2>;
status = "okay";
qcom,dual-dsi-mode;
panel_left: panel@0 {
compatible = "sharp,ls026b3sa06", "synaptic
reset-gpios = <&pm8550_gpios 19 GPIO_ACTIVE_HIGH>>;
pos-supply = <&vpos_left>;
neg-supply = <&vneg_left>;
backlight-supply = <&backlight_left>;
vdda-supply = <&vreg_l12b_1p8>;
port {
r63455_left_in: endpoint {
remote-endpoint = <&combined_panel1>;
};
};
};
};
&mdss_dsi1_out {
remote-endpoint = <&combined_dsi1>;
data-lanes = <0 1 2 3>;
};
=====><=======================================
So this would solve all the similar use-cases.
We can even add the "xr-display" compatible with "combined-fallback" plus some
properties to define how the panels are physically placed.
Neil
