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

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

On 10/5/26 13:15, Dmitry Baryshkov wrote:
> On Mon, Oct 05, 2026 at 10:54:41AM +0200, Neil Armstrong wrote:
>> 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.
> 
> I was thinking about 2 combined display example. In this case you can't
> figure it out in software without extra hint.
> 
>>
>>>
>>> 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.
> 
> regulators yes, they are described. Think about the 2 XR units being
> driven by the same "base". I think, you would at least need to link the
> cameras to the enclosure. Otherwise you will have a 2x number of cameras
> and no idea which of the enclosures they belong to.
> 

This is highly improbable, and I don't think it's the priority right now anyway.

Neil