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

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

On 10/5/26 04:22, Dmitry Baryshkov wrote:
> On Sun, Oct 04, 2026 at 05:51:44PM +0200, Neil Armstrong wrote:
>> 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.
> 
> Imaging the case: through the time the backlight LEDs on the right eye
> age faster than the ones on the left eye, so we need to apply dynamic
> correction to the backlight, dynamically calibrating the coefficient to
> be applied to the LED brightness (or even worse, dynamically applieing
> the _curve_ to compensate for the brightness difference).
> 
> Note, I don't have any information here, if such a difference can exist
> or if it can appear through the time, or if the xR DDICs can handle it
> on its own via a pre-programmed LUT, so you can totally say that the
> argument is moot and I won't even argue here.
> 
>>
>> 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>;
>> 				};
>> 			};
>> 		};
>> 	};
>> };
> 
> This is an interesting approach and it would be a requirement, if we
> ever have a device with 4 DSI hosts which can driver two sets of XR
> panels (there would be no other way to understand, which pairs of panels
> are bundled together). I am not sure if it needs to be an OF graph
> device or if it can simply reference the DSI devices. Or if it can
> reference panels (which is not the same).

I mean we could imagine combine any number of panels to form a combined display,
2 or 4 DSI links would be handled the same.

> 
> Another question, do we need to list any other devices here? regulators?
> sensors? maybe proximity sensor? cameras? I'm thinking from the
> 4-host-2-xr point of view, because if we don't have 4 DSI hosts, we
> don't need to describe anything. We already know all the hardware
> properies and connections, the rest is really just a software plumbing.

The regulators would be in the panel nodes, for the associated peripherals
like sensors & cameras they are not physically tied to the display so
it's only software plumbing.

Neil

>