Re: [PATCH v5 5/6] dt-bindings: display: Add Synaptics panel support

[Neil Armstrong <neil.armstrong@linaro.org>]

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 <krzk@kernel.org> 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=TTBknQMeFctw@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