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

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

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.

> 
>> The R63455 is designed for this exact use case and are only supposed
>> to be use in XR application in pair.
> 
> yes, but no, but yes, but no. I mean, nothing prevents one from using
> this DDIC in some other usecase.

Seriously, no, it's a likely very very improbable situation and
we need to accept to ignore things that will never happen.

> 
>> See it like a single physical panel with 2 controllers which
>> shouldn't be used separately. While technically a controller could
>> be used to driver single panel, it's likely impossible Synaptics
>> would sell this IC for non XR applications.
> 
> I think, this was causing an issue with the DSC too. A normal
> bonded-DSI-panel-with-DSC and this-double-panel require different widths
> to be programmed. Having a panel report real resolution would drop that
> quirk from the DSI host driver.

This is purely software implementation.

> 
>> We want the both panels to be seen at a single big panel because
>> physically the human eye will see it as a single display.
> 
> That's the CRTC side.

This is purely software implementation.

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

Neil