Re: [PATCH v5 1/6] dt-bindings: display: panel: Modify reset gpio number constrain

Re: [PATCH v5 1/6] dt-bindings: display: panel: Modify reset gpio number constrain

[Krzysztof Kozlowski]

On Mon, Jul 27, 2026 at 04:08:40PM +0800, Jun Nie wrote:
> Some panel support 2 reset gpio, such as Synaptics R63455. So modify the

There is no such binding for R63455.

> number constrain of gpio to 1 to avoid check failure.

What check failure? Please paste actual warnings (but not fake ones).

> 
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
>  Documentation/devicetree/bindings/display/panel/panel-common.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> index 087415753d606..7c450d2799808 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> @@ -119,7 +119,7 @@ properties:
>        confused with a backlight enable signal.
>  
>    reset-gpios:
> -    maxItems: 1
> +    minItems: 1

I do not get why all bindings now get completely flexible number of
resets. I am pretty sure not all of them constrain that. It's rather
your task to check it and explain in commit msg.

For example the second random I took to check (ILI7807S) does not
restrict, so you just made that binding accepting 1000 reset lines. Why?

Best regards,
Krzysztof

Re: [PATCH v5 1/6] dt-bindings: display: panel: Modify reset gpio number constrain

[Jun Nie]

Krzysztof Kozlowski <krzk@kernel.org> 于2026年7月28日周二 04:23写道：
>
> On Mon, Jul 27, 2026 at 04:08:40PM +0800, Jun Nie wrote:
> > Some panel support 2 reset gpio, such as Synaptics R63455. So modify the
>
> There is no such binding for R63455.
>
> > number constrain of gpio to 1 to avoid check failure.
>
> What check failure? Please paste actual warnings (but not fake ones).
>
It is a review warning from sashiko.
- [Low] The `reset-gpios` property's `maxItems: 2` constraint
conflicts with the strictly enforced `maxItems: 1` inherited from
`panel-common.yaml`.

> >
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/display/panel/panel-common.yaml | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> > index 087415753d606..7c450d2799808 100644
> > --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> > @@ -119,7 +119,7 @@ properties:
> >        confused with a backlight enable signal.
> >
> >    reset-gpios:
> > -    maxItems: 1
> > +    minItems: 1
>
> I do not get why all bindings now get completely flexible number of
> resets. I am pretty sure not all of them constrain that. It's rather
> your task to check it and explain in commit msg.
>
> For example the second random I took to check (ILI7807S) does not
> restrict, so you just made that binding accepting 1000 reset lines. Why?

I just want to extend the maxItems from 1 to 2 for my case. Do you have
any suggestion? Thanks!

Regards,
Jun

>
> Best regards,
> Krzysztof
>

Re: [PATCH v5 1/6] dt-bindings: display: panel: Modify reset gpio number constrain

[Krzysztof Kozlowski]

On 29/07/2026 10:01, Jun Nie wrote:
> Krzysztof Kozlowski <krzk@kernel.org> 于2026年7月28日周二 04:23写道：
>>
>> On Mon, Jul 27, 2026 at 04:08:40PM +0800, Jun Nie wrote:
>>> Some panel support 2 reset gpio, such as Synaptics R63455. So modify the
>>
>> There is no such binding for R63455.
>>
>>> number constrain of gpio to 1 to avoid check failure.
>>
>> What check failure? Please paste actual warnings (but not fake ones).
>>
> It is a review warning from sashiko.
> - [Low] The `reset-gpios` property's `maxItems: 2` constraint
> conflicts with the strictly enforced `maxItems: 1` inherited from
> `panel-common.yaml`.

I don't understand what comment from sashiko has something to do with
some check failure.

Anyway, we do not create commits because of some review. We write them
because there is a reason related to code, products etc.

> 
>>>
>>> Signed-off-by: Jun Nie <jun.nie@linaro.org>
>>> ---
>>>  Documentation/devicetree/bindings/display/panel/panel-common.yaml | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
>>> index 087415753d606..7c450d2799808 100644
>>> --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
>>> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
>>> @@ -119,7 +119,7 @@ properties:
>>>        confused with a backlight enable signal.
>>>
>>>    reset-gpios:
>>> -    maxItems: 1
>>> +    minItems: 1
>>
>> I do not get why all bindings now get completely flexible number of
>> resets. I am pretty sure not all of them constrain that. It's rather
>> your task to check it and explain in commit msg.
>>
>> For example the second random I took to check (ILI7807S) does not
>> restrict, so you just made that binding accepting 1000 reset lines. Why?
> 
> I just want to extend the maxItems from 1 to 2 for my case. Do you have
> any suggestion? Thanks!

I understand what you wanted, but you did not do that. You changed the
property for every case.

Best regards,
Krzysztof

Re: [PATCH v5 1/6] dt-bindings: display: panel: Modify reset gpio number constrain

[Jun Nie]

Krzysztof Kozlowski <krzk@kernel.org> 于2026年7月29日周三 16:05写道：
>
> On 29/07/2026 10:01, Jun Nie wrote:
> > Krzysztof Kozlowski <krzk@kernel.org> 于2026年7月28日周二 04:23写道：
> >>
> >> On Mon, Jul 27, 2026 at 04:08:40PM +0800, Jun Nie wrote:
> >>> Some panel support 2 reset gpio, such as Synaptics R63455. So modify the
> >>
> >> There is no such binding for R63455.
> >>
> >>> number constrain of gpio to 1 to avoid check failure.
> >>
> >> What check failure? Please paste actual warnings (but not fake ones).
> >>
> > It is a review warning from sashiko.
> > - [Low] The `reset-gpios` property's `maxItems: 2` constraint
> > conflicts with the strictly enforced `maxItems: 1` inherited from
> > `panel-common.yaml`.
>
> I don't understand what comment from sashiko has something to do with
> some check failure.
>
> Anyway, we do not create commits because of some review. We write them
> because there is a reason related to code, products etc.
>
> >
> >>>
> >>> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> >>> ---
> >>>  Documentation/devicetree/bindings/display/panel/panel-common.yaml | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> >>> index 087415753d606..7c450d2799808 100644
> >>> --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> >>> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> >>> @@ -119,7 +119,7 @@ properties:
> >>>        confused with a backlight enable signal.
> >>>
> >>>    reset-gpios:
> >>> -    maxItems: 1
> >>> +    minItems: 1
> >>
> >> I do not get why all bindings now get completely flexible number of
> >> resets. I am pretty sure not all of them constrain that. It's rather
> >> your task to check it and explain in commit msg.
> >>
> >> For example the second random I took to check (ILI7807S) does not
> >> restrict, so you just made that binding accepting 1000 reset lines. Why?
> >
> > I just want to extend the maxItems from 1 to 2 for my case. Do you have
> > any suggestion? Thanks!
>
> I understand what you wanted, but you did not do that. You changed the
> property for every case.
>
So changing to this is OK?     maxItems: 2

Regards,
Jun

Re: [PATCH v5 1/6] dt-bindings: display: panel: Modify reset gpio number constrain

[Krzysztof Kozlowski]

On Mon, Jul 27, 2026 at 04:08:40PM +0800, Jun Nie wrote:
> Some panel support 2 reset gpio, such as Synaptics R63455. So modify the
> number constrain of gpio to 1 to avoid check failure.

Also:
Subject - anything is "modify" be specific.

Best regards,
Krzysztof

Re: [PATCH v5 6/6] drm/panel: Add driver for Synaptics R63455 DSI panel

[Jun Nie]

<sashiko-bot@kernel.org> 于2026年7月27日周一 16:20写道：
>
> Thank you for your contribution! Sashiko AI review found 8 potential issue(s) to consider:
> - [High] A copy-paste error in the BOE panel initialization sequence duplicates command bytes, corrupting the DSI payload.
> - [High] Concurrent non-atomic read-modify-write operations on DSI `mode_flags` can corrupt the transmission mode state.
> - [High] Missing IS_ERR() check on the return value of devm_drm_panel_alloc() leads to an immediate dereference of an error pointer.
> - [High] The backlight sysfs interface is exposed to userspace before the DSI device is fully configured and attached.
> - [Medium] The macros LE16_BYTE0/1 and BE16_BYTE0/1 use endianness conversion functions before bitwise masking, causing incorrect byte order on Big Endian architectures.
> - [Medium] Returning PTR_ERR() on a valid pointer when the GPIO array size is incorrect leaks a kernel heap address and produces a positive error code.
> - [Medium] The backlight update_status callback blindly sends DCS commands without checking the panel's power state.
> - [Low] An early return in the panel disable path on DSI command failure skips disabling the backlight.
> --
>
> --- Patch [6]: [PATCH v5 6/6] drm/panel: Add driver for Synaptics R63455 DSI panel ---
> commit 89f5e4df3241a9188e302ee5028a24a7b0bc9542
> Author: Jun Nie <jun.nie@linaro.org>
> Subject: drm/panel: Add driver for Synaptics R63455 DSI panel
>
> This commit adds support for the Synaptics R63455 DSI panel used in virtual
> reality devices. It exposes a dual-panel configuration as a single logical
> panel to the DRM framework.
>
> > --- a/drivers/gpu/drm/panel/panel-synaptics-r63455.c
> > +++ b/drivers/gpu/drm/panel/panel-synaptics-r63455.c
> [ ... ]
> > +/*
> > + * Extract the low byte and high byte of the 16bit number converted
> > + * to the cpu endianness.
> > + */
> > +#define LE16_BYTE0(val) (le16_to_cpu(val) & 0xff)
> > +#define LE16_BYTE1(val) ((le16_to_cpu(val) >> 8) & 0xff)
> > +#define BE16_BYTE0(val) (be16_to_cpu(val) & 0xff)
> > +#define BE16_BYTE1(val) ((be16_to_cpu(val) >> 8) & 0xff)
>
> [Severity: Medium]
> Will this generate the correct byte order on Big Endian architectures?
>
> Since be16_to_cpu is a no-op on Big Endian systems, applying the bitwise
> shift and mask afterward will extract the bytes in Little Endian order
> rather than Big Endian. This will cause the panel initialization sequence to
> receive payload bytes in reversed order.
>
> Could we directly shift and mask without the endian conversion macros to
> safely serialize CPU-native integers across all architectures?

From Neil:
No we extract the low byte and high byte of the 16bit number converted
to the cpu endianness,
so it's the right code here.

>
> [ ... ]
> > +static int r63455_panel_on_boe_vs026c4m_n52_26000(struct drm_panel *panel)
> > +{
> [ ... ]
> > +     r63455_dsi_write_seq(ctx, dsi_ctx, R63455_GEN_OUTPIN_SET,
> > +                          0xf, 0xe4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                          0xf, 0xb2,
> > +                          0xf, 0xb2, 0x00, 0x64);
>
> [Severity: High]
> Does this sequence intentionally send the 0xf, 0xb2 bytes twice for the BOE
> panel initialization?
>
> This looks like it could be a copy-paste error that sends 14 bytes instead
> of the expected 12 bytes. Could this transmit malformed configuration data
> to the display controller and cause initialization failures?

Yes, the sequence is send twice intentionally. As there are 2 panel controllers
as 1 logic panel in DRM high level system.
>
> [ ... ]
> > +static int r63455_set_brightness(struct r63455_ctx *ctx, u16 brightness,
> > +                               u16 pulse_offset_rows)
> > +{
> [ ... ]
> > +     ctx->dsi[0]->mode_flags &= ~MIPI_DSI_MODE_LPM;
> > +     ctx->dsi[1]->mode_flags &= ~MIPI_DSI_MODE_LPM;
>
> [Severity: High]
> Are these bitwise operations on mode_flags safe from race conditions?
>
> Since r63455_set_brightness executes under the backlight sysfs lock, it can
> run concurrently with DRM atomic commit handlers like r63455_enable or
> r63455_disable which use independent locks.
>
> Could a concurrent read-modify-write here corrupt the transmission mode state,
> such as unintentionally dropping the MIPI_DSI_MODE_VIDEO flag?

It's very improbable this happens, panel cmds and backlight are called
at very different times.
>
> [ ... ]
> > +static int r63455_disable(struct drm_panel *panel)
> > +{
> [ ... ]
> > +     r63455_dsi_write_seq(ctx, dsi_ctx, MIPI_DCS_ENTER_SLEEP_MODE);
> > +
> > +     mipi_dsi_msleep(&dsi_ctx, 200);
> > +
> > +     if (dsi_ctx.accum_err)
> > +             return dsi_ctx.accum_err;
> > +
> > +     /* required by hardware to be after MIPI_DCS_ENTER_SLEEP_MODE */
> > +     return backlight_disable(ctx->backlight);
>
> [Severity: Low]
> Does returning early here leave the backlight subsystem in an active state?
>
> If the DSI ENTER_SLEEP_MODE sequence fails, the driver skips calling
> backlight_disable. While the physical regulators are disabled later in
> r63455_unprepare, could this leave the backlight framework out of sync?

Technically yes, but practically it is an unrecoverable hardware state. So it is
a low risk issue and can be ignored.

>
> [ ... ]
> > +static int r63455_bl_update_status(struct backlight_device *bl)
> > +{
> > +     struct mipi_dsi_device *dsi = bl_get_data(bl);
> > +     struct r63455_ctx *r63455_ctx = mipi_dsi_get_drvdata(dsi);
> > +
> > +     return r63455_set_brightness(r63455_ctx, bl->props.brightness,
> > +                                  bl->props.pulse_offset_rows);
> > +}
>
> [Severity: Medium]
> Does this function need to verify the panel power state before sending DCS
> commands?
>
> Userspace can modify the brightness via sysfs while the DRM display is
> disabled. If this occurs, it might trigger MIPI DSI transmissions to a
> powered-off panel or unclocked DSI host.
>
> Could this lead to hardware lockups or DSI timeouts?

Yes, I will add below logic in next version.

+++ b/drivers/gpu/drm/panel/panel-synaptics-r63455.c
@@ -456,6 +456,9 @@ static int r63455_bl_update_status(struct
backlight_device *bl)
        struct mipi_dsi_device *dsi = bl_get_data(bl);
        struct r63455_ctx *r63455_ctx = mipi_dsi_get_drvdata(dsi);

+       if (!r63455_ctx->panel.enabled)
+               return 0;
+

>
> [ ... ]
> > +static int r63455_panel_add(struct r63455_ctx *ctx)
> > +{
> [ ... ]
> > +     ctx->reset_gpios = devm_gpiod_get_array(dev, "reset", GPIOD_OUT_LOW);
> > +     if (IS_ERR(ctx->reset_gpios) || ctx->reset_gpios->ndescs != 2)
> > +             return PTR_ERR(ctx->reset_gpios);
>
> [Severity: Medium]
> If the GPIO array has a count other than 2, will this return a positive value
> derived from a valid heap pointer?
>
> When devm_gpiod_get_array succeeds but returns an unexpected number of
> descriptors, ctx->reset_gpios is a valid pointer rather than an error pointer.
>
> Could we return an explicit error code like -EINVAL here instead of leaking
> the pointer address through PTR_ERR?

Right, -EINVAL is proper value to return.
>
> [ ... ]
> > +static int r63455_probe(struct mipi_dsi_device *dsi)
> > +{
> [ ... ]
> > +     ctx = devm_drm_panel_alloc(&dsi->dev, __typeof(*ctx), panel,
> > +                                &r63455_drm_funcs, DRM_MODE_CONNECTOR_DSI);
> > +
> > +     ctx->dsi_init_seq = of_device_get_match_data(dev);
>
> [Severity: High]
> Should we check the return value of devm_drm_panel_alloc for an error pointer?
>
> If memory allocation fails during driver probe, devm_drm_panel_alloc returns
> ERR_PTR(-ENOMEM). Dereferencing ctx on the very next line to assign
> dsi_init_seq will result in a kernel panic.
>
Right, a check shall be added in next version.

> [ ... ]
> > +     ret = r63455_panel_add(ctx);
> > +     if (ret) {
> > +             DRM_DEV_ERROR(dev, "failed to add panel %d\n", ret);
> > +             return ret;
> > +     }
> > +
> > +     for (i = 0; i < 2; i++) {
> > +             dsi_dev = ctx->dsi[i];
> > +             dsi_dev->lanes = 3;
> > +             dsi_dev->format = MIPI_DSI_FMT_RGB888;
> > +             dsi_dev->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_LPM |
> > +                     MIPI_DSI_CLOCK_NON_CONTINUOUS;
> > +             ret = devm_mipi_dsi_attach(dev, dsi_dev);
>
> [Severity: High]
> Is it safe to register the backlight device before the DSI host is configured
> and attached?
>
> Calling r63455_panel_add exposes the backlight sysfs interface to userspace.
> However, the lanes, format, mode_flags, and devm_mipi_dsi_attach are not
> set up until the loop that follows.
>
> If a udev rule writes to the brightness node during this window, could it
> trigger DSI transmissions on an unattached device and lock up the host?

It is OK per Neil's answer.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260727-sm8650-7-1-bonded-dsi-v5-0-c042266b9eeb@linaro.org?part=6

Re: [PATCH v5 6/6] drm/panel: Add driver for Synaptics R63455 DSI panel

[Linus Walleij]

Hi Jun,

thanks for your patch!

On Mon, Jul 27, 2026 at 10:09 AM Jun Nie <jun.nie@linaro.org> wrote:

> +#define R63455_MF_CMD_ACCESS_PROTECT   0xb0
> +#define R63455_SEQ_CTL                 0xd6
> +#define R63455_DSI_CTL                 0xb6
> +#define R63455_DISP_MODE               0xb7
> +#define R63455_GEN_OUTPIN_SET          0xb9
> +#define R63455_DISP_SET1               0xc0
> +#define R63455_DISP_SET2               0xf1
> +#define R63455_DISP_SET3               0xc6
> +#define R63455_DISP_SET3_2             0xcd
> +#define R63455_DISP_SET4               0xcf
> +#define R63455_DISP_SET5               0xec
> +#define R63455_DISP_SET6               0xef
> +#define R63455_TE_GPIO_CTL             0xbe
> +#define R63455_PPS_SET                 0xe6

This is more details than we usually get, which is nice.

> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_MF_CMD_ACCESS_PROTECT, 0x00);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_SEQ_CTL, 0x00);
> +       r63455_dsi_write_seq(ctx, dsi_ctx,
> +                            R63455_DSI_CTL,
> +                            0x20, 0x6b, 0x80, 0x06, 0x33, 0x9a, 0x00, 0x1a,
> +                            0x7a);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_MODE,
> +                            0x54, 0x00, 0x00, 0x00);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_GEN_OUTPIN_SET,
> +                            0xf, 0xe4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                            0xf, 0xb2, 0x00, 0x64);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET3,
> +                            0x08, 0x70, 0x28, 0x48, 0x00, 0x00, 0x13, 0x21,
> +                            0xff, 0x00, 0x0f, 0x01, 0x14, 0x17, 0x00, 0x00,
> +                            0x00, 0x02, 0x40, 0x0C, 0x00, 0x00, 0x00, 0x20,
> +                            0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x70, 0x08,
> +                            0xD0, 0x02, 0x21, 0x6F, 0x08, 0x5A, 0x00, 0x00,
> +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                            0x00, 0x00, 0x00, 0x00, 0x00);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET1,
> +                            RTN, 0x86, LE16_BYTE0(VBP), LE16_BYTE1(VBP), 0x08,
> +                            0x70, BE16_BYTE0(VFP), BE16_BYTE1(VFP), 0x00,
> +                            0x00, 0x08, 0x3B, 0x00, 0x00, 0x19, 0x01, 0x22);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET3_2, 0x00);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET4,
> +                            0x8b, 0x00, 0x80, 0x46, 0x61, 0x00, 0x8b);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET5,
> +                            BE16_BYTE0(VID_VS_DELAY),
> +                            BE16_BYTE1(VID_VS_DELAY),
> +                            0x00, 0x00, 0x00);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET6,
> +                            0x00, 0x24, 0x00, 0x00, 0x1f, 0x00, 0x00, 0x00,
> +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                            0x03, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> +                            0x00, 0x00, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x03,
> +                            0x1D, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
> +                            0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00,
> +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> +                            0x00);
> +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_TE_GPIO_CTL,
> +                            0x00, 0x6A, 0x02);

So for the commands above we have a little more knowledge than just
opaque numbers about what the display controller is doing.

If you have a datasheet for this display controller, then please add some
one-line comments before each command to explain what is being set
up.

It still bugs me that we accept this much magic numbers in panel
drivers but I guess I just take a deep breath and live with it.

Yours,
Linus Walleij

Re: [PATCH v5 6/6] drm/panel: Add driver for Synaptics R63455 DSI panel

[Jun Nie]

Linus Walleij <linusw@kernel.org> 于2026年9月29日周二 21:03写道：
>
> Hi Jun,
>
> thanks for your patch!
>
> On Mon, Jul 27, 2026 at 10:09 AM Jun Nie <jun.nie@linaro.org> wrote:
>
> > +#define R63455_MF_CMD_ACCESS_PROTECT   0xb0
> > +#define R63455_SEQ_CTL                 0xd6
> > +#define R63455_DSI_CTL                 0xb6
> > +#define R63455_DISP_MODE               0xb7
> > +#define R63455_GEN_OUTPIN_SET          0xb9
> > +#define R63455_DISP_SET1               0xc0
> > +#define R63455_DISP_SET2               0xf1
> > +#define R63455_DISP_SET3               0xc6
> > +#define R63455_DISP_SET3_2             0xcd
> > +#define R63455_DISP_SET4               0xcf
> > +#define R63455_DISP_SET5               0xec
> > +#define R63455_DISP_SET6               0xef
> > +#define R63455_TE_GPIO_CTL             0xbe
> > +#define R63455_PPS_SET                 0xe6
>
> This is more details than we usually get, which is nice.
>
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_MF_CMD_ACCESS_PROTECT, 0x00);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_SEQ_CTL, 0x00);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx,
> > +                            R63455_DSI_CTL,
> > +                            0x20, 0x6b, 0x80, 0x06, 0x33, 0x9a, 0x00, 0x1a,
> > +                            0x7a);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_MODE,
> > +                            0x54, 0x00, 0x00, 0x00);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_GEN_OUTPIN_SET,
> > +                            0xf, 0xe4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                            0xf, 0xb2, 0x00, 0x64);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET3,
> > +                            0x08, 0x70, 0x28, 0x48, 0x00, 0x00, 0x13, 0x21,
> > +                            0xff, 0x00, 0x0f, 0x01, 0x14, 0x17, 0x00, 0x00,
> > +                            0x00, 0x02, 0x40, 0x0C, 0x00, 0x00, 0x00, 0x20,
> > +                            0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x70, 0x08,
> > +                            0xD0, 0x02, 0x21, 0x6F, 0x08, 0x5A, 0x00, 0x00,
> > +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                            0x00, 0x00, 0x00, 0x00, 0x00);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET1,
> > +                            RTN, 0x86, LE16_BYTE0(VBP), LE16_BYTE1(VBP), 0x08,
> > +                            0x70, BE16_BYTE0(VFP), BE16_BYTE1(VFP), 0x00,
> > +                            0x00, 0x08, 0x3B, 0x00, 0x00, 0x19, 0x01, 0x22);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET3_2, 0x00);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET4,
> > +                            0x8b, 0x00, 0x80, 0x46, 0x61, 0x00, 0x8b);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET5,
> > +                            BE16_BYTE0(VID_VS_DELAY),
> > +                            BE16_BYTE1(VID_VS_DELAY),
> > +                            0x00, 0x00, 0x00);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_DISP_SET6,
> > +                            0x00, 0x24, 0x00, 0x00, 0x1f, 0x00, 0x00, 0x00,
> > +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                            0x03, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> > +                            0x00, 0x00, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x03,
> > +                            0x1D, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00,
> > +                            0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00,
> > +                            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> > +                            0x00);
> > +       r63455_dsi_write_seq(ctx, dsi_ctx, R63455_TE_GPIO_CTL,
> > +                            0x00, 0x6A, 0x02);
>
> So for the commands above we have a little more knowledge than just
> opaque numbers about what the display controller is doing.
>
> If you have a datasheet for this display controller, then please add some
> one-line comments before each command to explain what is being set
> up.

I hope I had datasheet, but the answer is no. All I have is an init sequence
with the information in the above macro definition. Let just live with it @_@

>
> It still bugs me that we accept this much magic numbers in panel
> drivers but I guess I just take a deep breath and live with it.
>
> Yours,
> Linus Walleij

Re: [PATCH v5 6/6] drm/panel: Add driver for Synaptics R63455 DSI panel

[Linus Walleij]

On Wed, Sep 30, 2026 at 6:31 PM Jun Nie <jun.nie@linaro.org> wrote:
> > On Mon, Jul 27, 2026 at 10:09 AM Jun Nie <jun.nie@linaro.org> wrote:

> > If you have a datasheet for this display controller, then please add some
> > one-line comments before each command to explain what is being set
> > up.
>
> I hope I had datasheet, but the answer is no. All I have is an init sequence
> with the information in the above macro definition. Let just live with it @_@

I would send the message "upward" that you need a proper datasheet
for this, from whoever wants this to happen.

I have seen from the presentation that you will be working on
compensation for chromatic aberration for this device, and that is only
going to have a point if the color representation on the display can be
trusted to begin with. Which means
gamma correction. (Which we don't yet support in the panels,
but hey, another opportunity to be first!)

Gamma is invariably going to be one of these
"magic commands", at that point of depth you really need the manual
to see what is going on.

Yours,
Linus Walleij

Re: [PATCH v5 2/6] drm/msm/dsi: support DSC configurations with slice_per_pkt > 1

[Dmitry Baryshkov]

On Mon, Jul 27, 2026 at 04:08:41PM +0800, Jun Nie wrote:
> Some panels require multiple slice to be sent in a single DSC packet. And
> this feature is a must for specific panels, such as Sharp ls026b3sa06. Add
> a dsc_slice_per_pkt member into struct drm_dsc_config and support the
> feature in msm mdss driver.
> 
> Co-developed-by: Jonathan Marek <jonathan@marek.ca>
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 27 ++++++++++++---------------
>  include/drm/display/drm_dsc.h      |  7 +++++++
>  2 files changed, 19 insertions(+), 15 deletions(-)
> 
> @@ -1719,8 +1709,14 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
>  	msm_host->lanes = dsi->lanes;
>  	msm_host->format = dsi->format;
>  	msm_host->mode_flags = dsi->mode_flags;
> -	if (dsi->dsc)
> +	if (dsi->dsc) {
>  		msm_host->dsc = dsi->dsc;
> +		/* for backwards compatibility, assume 1 if not set */
> +		msm_host->dsc_slice_per_pkt = dsi->dsc->dsc_slice_per_pkt ?: 1;
> +	} else {
> +		msm_host->dsc = NULL;
> +		msm_host->dsc_slice_per_pkt = 0;
> +	}

Why do you need the else branch? Isn't it already NULL / 0 by default?

>  
>  	if (msm_host->format == MIPI_DSI_FMT_RGB101010) {
>  		if (!msm_dsi_host_version_geq(msm_host, MSM_DSI_VER_MAJOR_6G,
> @@ -1757,6 +1753,7 @@ static int dsi_host_detach(struct mipi_dsi_host *host,
>  	struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
>  
>  	dsi_dev_detach(msm_host->pdev);
> +	msm_host->dsc = NULL;

If you are fixing something, it should come as a separate commit.

>  
>  	DBG("id=%d", msm_host->id);
>  
> diff --git a/include/drm/display/drm_dsc.h b/include/drm/display/drm_dsc.h
> index bbbe7438473d3..c522ab3d71853 100644
> --- a/include/drm/display/drm_dsc.h
> +++ b/include/drm/display/drm_dsc.h
> @@ -267,6 +267,13 @@ struct drm_dsc_config {
>  	 * Offset adjustment for second line in Native 4:2:0 mode
>  	 */
>  	u16 second_line_offset_adj;
> +
> +	/**
> +	 * @dsc_slice_per_pkt:
> +	 * Number of DSC slices to be sent in a single packet. This is not
> +	 * part of DSC standard, and only used in some DSI panels so far.
> +	 */
> +	unsigned int dsc_slice_per_pkt;

If it's not a part of the standard, I think, it should not be a part of
drm_dsc_config. In the end, drm_dsc_config is also being used by other
parties, e.g. DP or HDMI. A year ago I saw a version of this patch,
having this field in the struct mipi_dsi_device. I think it's a more
correct place.

-- 
With best wishes
Dmitry

Re: [PATCH v5 2/6] drm/msm/dsi: support DSC configurations with slice_per_pkt > 1

[Jun Nie]

Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年9月30日周三 00:03写道：
>
> On Mon, Jul 27, 2026 at 04:08:41PM +0800, Jun Nie wrote:
> > Some panels require multiple slice to be sent in a single DSC packet. And
> > this feature is a must for specific panels, such as Sharp ls026b3sa06. Add
> > a dsc_slice_per_pkt member into struct drm_dsc_config and support the
> > feature in msm mdss driver.
> >
> > Co-developed-by: Jonathan Marek <jonathan@marek.ca>
> > Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > ---
> >  drivers/gpu/drm/msm/dsi/dsi_host.c | 27 ++++++++++++---------------
> >  include/drm/display/drm_dsc.h      |  7 +++++++
> >  2 files changed, 19 insertions(+), 15 deletions(-)
> >
> > @@ -1719,8 +1709,14 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
> >       msm_host->lanes = dsi->lanes;
> >       msm_host->format = dsi->format;
> >       msm_host->mode_flags = dsi->mode_flags;
> > -     if (dsi->dsc)
> > +     if (dsi->dsc) {
> >               msm_host->dsc = dsi->dsc;
> > +             /* for backwards compatibility, assume 1 if not set */
> > +             msm_host->dsc_slice_per_pkt = dsi->dsc->dsc_slice_per_pkt ?: 1;
> > +     } else {
> > +             msm_host->dsc = NULL;
> > +             msm_host->dsc_slice_per_pkt = 0;
> > +     }
>
> Why do you need the else branch? Isn't it already NULL / 0 by default?

AI bot review comments reminding a case that panel device may be switched
to another panel. Not sure whether it is possible in real world. Just add this
for safe.
>
> >
> >       if (msm_host->format == MIPI_DSI_FMT_RGB101010) {
> >               if (!msm_dsi_host_version_geq(msm_host, MSM_DSI_VER_MAJOR_6G,
> > @@ -1757,6 +1753,7 @@ static int dsi_host_detach(struct mipi_dsi_host *host,
> >       struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
> >
> >       dsi_dev_detach(msm_host->pdev);
> > +     msm_host->dsc = NULL;
>
> If you are fixing something, it should come as a separate commit.

The same case as above.
>
> >
> >       DBG("id=%d", msm_host->id);
> >
> > diff --git a/include/drm/display/drm_dsc.h b/include/drm/display/drm_dsc.h
> > index bbbe7438473d3..c522ab3d71853 100644
> > --- a/include/drm/display/drm_dsc.h
> > +++ b/include/drm/display/drm_dsc.h
> > @@ -267,6 +267,13 @@ struct drm_dsc_config {
> >        * Offset adjustment for second line in Native 4:2:0 mode
> >        */
> >       u16 second_line_offset_adj;
> > +
> > +     /**
> > +      * @dsc_slice_per_pkt:
> > +      * Number of DSC slices to be sent in a single packet. This is not
> > +      * part of DSC standard, and only used in some DSI panels so far.
> > +      */
> > +     unsigned int dsc_slice_per_pkt;
>
> If it's not a part of the standard, I think, it should not be a part of
> drm_dsc_config. In the end, drm_dsc_config is also being used by other
> parties, e.g. DP or HDMI. A year ago I saw a version of this patch,
> having this field in the struct mipi_dsi_device. I think it's a more
> correct place.

I will move to struct mipi_dsi_device in next version.
>
> --
> With best wishes
> Dmitry

Re: [PATCH v5 2/6] drm/msm/dsi: support DSC configurations with slice_per_pkt > 1

[Dmitry Baryshkov]

On Wed, Sep 30, 2026 at 09:42:41PM +0800, Jun Nie wrote:
> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年9月30日周三 00:03写道：
> >
> > On Mon, Jul 27, 2026 at 04:08:41PM +0800, Jun Nie wrote:
> > > Some panels require multiple slice to be sent in a single DSC packet. And
> > > this feature is a must for specific panels, such as Sharp ls026b3sa06. Add
> > > a dsc_slice_per_pkt member into struct drm_dsc_config and support the
> > > feature in msm mdss driver.
> > >
> > > Co-developed-by: Jonathan Marek <jonathan@marek.ca>
> > > Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> > > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > > ---
> > >  drivers/gpu/drm/msm/dsi/dsi_host.c | 27 ++++++++++++---------------
> > >  include/drm/display/drm_dsc.h      |  7 +++++++
> > >  2 files changed, 19 insertions(+), 15 deletions(-)
> > >
> > > @@ -1719,8 +1709,14 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
> > >       msm_host->lanes = dsi->lanes;
> > >       msm_host->format = dsi->format;
> > >       msm_host->mode_flags = dsi->mode_flags;
> > > -     if (dsi->dsc)
> > > +     if (dsi->dsc) {
> > >               msm_host->dsc = dsi->dsc;
> > > +             /* for backwards compatibility, assume 1 if not set */
> > > +             msm_host->dsc_slice_per_pkt = dsi->dsc->dsc_slice_per_pkt ?: 1;
> > > +     } else {
> > > +             msm_host->dsc = NULL;
> > > +             msm_host->dsc_slice_per_pkt = 0;
> > > +     }
> >
> > Why do you need the else branch? Isn't it already NULL / 0 by default?
> 
> AI bot review comments reminding a case that panel device may be switched
> to another panel. Not sure whether it is possible in real world. Just add this
> for safe.

No, thank you. Either it can happen (and so it should be handled, maybe
at some other place) or it's just a pure AI dillusion.

> >
> > >
> > >       if (msm_host->format == MIPI_DSI_FMT_RGB101010) {
> > >               if (!msm_dsi_host_version_geq(msm_host, MSM_DSI_VER_MAJOR_6G,
> > > @@ -1757,6 +1753,7 @@ static int dsi_host_detach(struct mipi_dsi_host *host,
> > >       struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
> > >
> > >       dsi_dev_detach(msm_host->pdev);
> > > +     msm_host->dsc = NULL;
> >
> > If you are fixing something, it should come as a separate commit.
> 
> The same case as above.
> >
> > >
> > >       DBG("id=%d", msm_host->id);
> > >
> > > diff --git a/include/drm/display/drm_dsc.h b/include/drm/display/drm_dsc.h
> > > index bbbe7438473d3..c522ab3d71853 100644
> > > --- a/include/drm/display/drm_dsc.h
> > > +++ b/include/drm/display/drm_dsc.h
> > > @@ -267,6 +267,13 @@ struct drm_dsc_config {
> > >        * Offset adjustment for second line in Native 4:2:0 mode
> > >        */
> > >       u16 second_line_offset_adj;
> > > +
> > > +     /**
> > > +      * @dsc_slice_per_pkt:
> > > +      * Number of DSC slices to be sent in a single packet. This is not
> > > +      * part of DSC standard, and only used in some DSI panels so far.
> > > +      */
> > > +     unsigned int dsc_slice_per_pkt;
> >
> > If it's not a part of the standard, I think, it should not be a part of
> > drm_dsc_config. In the end, drm_dsc_config is also being used by other
> > parties, e.g. DP or HDMI. A year ago I saw a version of this patch,
> > having this field in the struct mipi_dsi_device. I think it's a more
> > correct place.
> 
> I will move to struct mipi_dsi_device in next version.

Thanks

> >
> > --
> > With best wishes
> > Dmitry

-- 
With best wishes
Dmitry

Re: [PATCH v5 3/6] drm/mipi-dsi: Add flag to support dual-panel configurations

[Dmitry Baryshkov]

On Mon, Jul 27, 2026 at 04:08:42PM +0800, Jun Nie wrote:
> Some devices treat two independent physical DSI panels as a single
> logical panel from the CRTC's perspective. However, two separate DSI
> hosts are still required to drive the panels individually.
> 
> Introduce a `dual_panel` flag to the `mipi_dsi_device` struct. This
> allows a panel driver to inform the DSI host that it is part of a
> dual-panel setup, enabling the host to coordinate both physical
> displays as one.
> 
> This change does not force individual panel driver to manage
> system-level display topology if the driver does not intended to
> support dual panel topology. Only the driver that set the flag to
> true need to take care of panel topology.
> 
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
>  include/drm/drm_mipi_dsi.h | 2 ++
>  1 file changed, 2 insertions(+)

Do you have a single MIPI DSI device, or are there two independent MIPI
DSI devices? In the latter case, the flag is wrongly placed.

> 
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 2ab651a36115d..889ef1421207a 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -169,6 +169,7 @@ struct mipi_dsi_device_info {
>   * @host: DSI host for this peripheral
>   * @dev: driver model device node for this peripheral
>   * @attached: the DSI device has been successfully attached
> + * @dual_panel: the DSI device is one instance of dual panel
>   * @name: DSI peripheral chip type
>   * @channel: virtual channel assigned to the peripheral
>   * @format: pixel format for video mode
> @@ -186,6 +187,7 @@ struct mipi_dsi_device {
>  	struct mipi_dsi_host *host;
>  	struct device dev;
>  	bool attached;
> +	bool dual_panel;
>  
>  	char name[DSI_DEV_NAME_SIZE];
>  	unsigned int channel;
> 
> -- 
> 2.43.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH v5 3/6] drm/mipi-dsi: Add flag to support dual-panel configurations

[Jun Nie]

Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年9月30日周三 00:05写道：
>
> On Mon, Jul 27, 2026 at 04:08:42PM +0800, Jun Nie wrote:
> > Some devices treat two independent physical DSI panels as a single
> > logical panel from the CRTC's perspective. However, two separate DSI
> > hosts are still required to drive the panels individually.
> >
> > Introduce a `dual_panel` flag to the `mipi_dsi_device` struct. This
> > allows a panel driver to inform the DSI host that it is part of a
> > dual-panel setup, enabling the host to coordinate both physical
> > displays as one.
> >
> > This change does not force individual panel driver to manage
> > system-level display topology if the driver does not intended to
> > support dual panel topology. Only the driver that set the flag to
> > true need to take care of panel topology.
> >
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > ---
> >  include/drm/drm_mipi_dsi.h | 2 ++
> >  1 file changed, 2 insertions(+)
>
> Do you have a single MIPI DSI device, or are there two independent MIPI
> DSI devices? In the latter case, the flag is wrongly placed.

Yes, there are 2 mipi devices, and 2 mipi hosts. This flag is used for
mipi device
to notify host they are one of dual panels, so that horizontal
configuration(width)
in mipi host can be handled correctly. Where do you suggest to put this flag?
Thanks!

Jun
>
> >
> > diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> > index 2ab651a36115d..889ef1421207a 100644
> > --- a/include/drm/drm_mipi_dsi.h
> > +++ b/include/drm/drm_mipi_dsi.h
> > @@ -169,6 +169,7 @@ struct mipi_dsi_device_info {
> >   * @host: DSI host for this peripheral
> >   * @dev: driver model device node for this peripheral
> >   * @attached: the DSI device has been successfully attached
> > + * @dual_panel: the DSI device is one instance of dual panel
> >   * @name: DSI peripheral chip type
> >   * @channel: virtual channel assigned to the peripheral
> >   * @format: pixel format for video mode
> > @@ -186,6 +187,7 @@ struct mipi_dsi_device {
> >       struct mipi_dsi_host *host;
> >       struct device dev;
> >       bool attached;
> > +     bool dual_panel;
> >
> >       char name[DSI_DEV_NAME_SIZE];
> >       unsigned int channel;
> >
> > --
> > 2.43.0
> >
>
> --
> With best wishes
> Dmitry

Re: [PATCH v5 3/6] drm/mipi-dsi: Add flag to support dual-panel configurations

[Dmitry Baryshkov]

On Wed, Sep 30, 2026 at 09:52:48PM +0800, Jun Nie wrote:
> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年9月30日周三 00:05写道：
> >
> > On Mon, Jul 27, 2026 at 04:08:42PM +0800, Jun Nie wrote:
> > > Some devices treat two independent physical DSI panels as a single
> > > logical panel from the CRTC's perspective. However, two separate DSI
> > > hosts are still required to drive the panels individually.
> > >
> > > Introduce a `dual_panel` flag to the `mipi_dsi_device` struct. This
> > > allows a panel driver to inform the DSI host that it is part of a
> > > dual-panel setup, enabling the host to coordinate both physical
> > > displays as one.
> > >
> > > This change does not force individual panel driver to manage
> > > system-level display topology if the driver does not intended to
> > > support dual panel topology. Only the driver that set the flag to
> > > true need to take care of panel topology.
> > >
> > > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > > ---
> > >  include/drm/drm_mipi_dsi.h | 2 ++
> > >  1 file changed, 2 insertions(+)
> >
> > Do you have a single MIPI DSI device, or are there two independent MIPI
> > DSI devices? In the latter case, the flag is wrongly placed.
> 
> Yes, there are 2 mipi devices, and 2 mipi hosts. This flag is used for
> mipi device
> to notify host they are one of dual panels, so that horizontal
> configuration(width)
> in mipi host can be handled correctly. Where do you suggest to put this flag?
> Thanks!

Into the msm DSI structures. We already have several Qualcomm-specific
flags. I'm thinking from the 'generic device' point of view. The
'dual_panel' doesn't mean anything if the device has more than two DSI
hosts. You need to specify which hosts are mapped to L or R channels, etc.

-- 
With best wishes
Dmitry

Re: [PATCH v5 3/6] drm/mipi-dsi: Add flag to support dual-panel configurations

[Jun Nie]

Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年10月1日周四 03:43写道：
>
> On Wed, Sep 30, 2026 at 09:52:48PM +0800, Jun Nie wrote:
> > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年9月30日周三 00:05写道：
> > >
> > > On Mon, Jul 27, 2026 at 04:08:42PM +0800, Jun Nie wrote:
> > > > Some devices treat two independent physical DSI panels as a single
> > > > logical panel from the CRTC's perspective. However, two separate DSI
> > > > hosts are still required to drive the panels individually.
> > > >
> > > > Introduce a `dual_panel` flag to the `mipi_dsi_device` struct. This
> > > > allows a panel driver to inform the DSI host that it is part of a
> > > > dual-panel setup, enabling the host to coordinate both physical
> > > > displays as one.
> > > >
> > > > This change does not force individual panel driver to manage
> > > > system-level display topology if the driver does not intended to
> > > > support dual panel topology. Only the driver that set the flag to
> > > > true need to take care of panel topology.
> > > >
> > > > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > > > ---
> > > >  include/drm/drm_mipi_dsi.h | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > >
> > > Do you have a single MIPI DSI device, or are there two independent MIPI
> > > DSI devices? In the latter case, the flag is wrongly placed.
> >
> > Yes, there are 2 mipi devices, and 2 mipi hosts. This flag is used for
> > mipi device
> > to notify host they are one of dual panels, so that horizontal
> > configuration(width)
> > in mipi host can be handled correctly. Where do you suggest to put this flag?
> > Thanks!
>
> Into the msm DSI structures. We already have several Qualcomm-specific
> flags. I'm thinking from the 'generic device' point of view. The
> 'dual_panel' doesn't mean anything if the device has more than two DSI
> hosts. You need to specify which hosts are mapped to L or R channels, etc.

How about to add below 3 members regarding multiple physical panels in
single logic panel. We have h*v panels in a panel wall. The index start from
0 when we iterate panel from left to right of the top array of panel wall. In
XR case, we have num_panel_h = 2;  num_panel_v = 1; and
panel_index = 0 for left channel, panel_index = 1 for right channel. The
original framebuffer is divided into width/num_panel_h and
height/num_panel_v for each panel's DSI link.

u32 num_panel_h;
u32 num_panel_v;
u32 panel_index;

>
> --
> With best wishes
> Dmitry

Re: [PATCH v5 3/6] drm/mipi-dsi: Add flag to support dual-panel configurations

[Dmitry Baryshkov]

On Sun, Oct 04, 2026 at 09:58:04PM +0800, Jun Nie wrote:
> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年10月1日周四 03:43写道：
> >
> > On Wed, Sep 30, 2026 at 09:52:48PM +0800, Jun Nie wrote:
> > > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年9月30日周三 00:05写道：
> > > >
> > > > On Mon, Jul 27, 2026 at 04:08:42PM +0800, Jun Nie wrote:
> > > > > Some devices treat two independent physical DSI panels as a single
> > > > > logical panel from the CRTC's perspective. However, two separate DSI
> > > > > hosts are still required to drive the panels individually.
> > > > >
> > > > > Introduce a `dual_panel` flag to the `mipi_dsi_device` struct. This
> > > > > allows a panel driver to inform the DSI host that it is part of a
> > > > > dual-panel setup, enabling the host to coordinate both physical
> > > > > displays as one.
> > > > >
> > > > > This change does not force individual panel driver to manage
> > > > > system-level display topology if the driver does not intended to
> > > > > support dual panel topology. Only the driver that set the flag to
> > > > > true need to take care of panel topology.
> > > > >
> > > > > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > > > > ---
> > > > >  include/drm/drm_mipi_dsi.h | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > >
> > > > Do you have a single MIPI DSI device, or are there two independent MIPI
> > > > DSI devices? In the latter case, the flag is wrongly placed.
> > >
> > > Yes, there are 2 mipi devices, and 2 mipi hosts. This flag is used for
> > > mipi device
> > > to notify host they are one of dual panels, so that horizontal
> > > configuration(width)
> > > in mipi host can be handled correctly. Where do you suggest to put this flag?
> > > Thanks!
> >
> > Into the msm DSI structures. We already have several Qualcomm-specific
> > flags. I'm thinking from the 'generic device' point of view. The
> > 'dual_panel' doesn't mean anything if the device has more than two DSI
> > hosts. You need to specify which hosts are mapped to L or R channels, etc.
> 
> How about to add below 3 members regarding multiple physical panels in
> single logic panel. We have h*v panels in a panel wall. The index start from
> 0 when we iterate panel from left to right of the top array of panel wall. In
> XR case, we have num_panel_h = 2;  num_panel_v = 1; and
> panel_index = 0 for left channel, panel_index = 1 for right channel. The
> original framebuffer is divided into width/num_panel_h and
> height/num_panel_v for each panel's DSI link.
> 
> u32 num_panel_h;
> u32 num_panel_v;
> u32 panel_index;

You have seen drm_connector's tile-related fields used by
drm_connector_set_tile_property(), haven't you? If we are to use num_h
and num_v, I'd also use h_loc an v_loc instead of a single panel_index.

The driver needs to distinguish (for the DSC params) if it's a single
panel spanning two DSI links or if there are several DSI panels, bundled
together, so you also have to add h_size / v_size style of params.

But then the real question becomes, do we really need this complexity?
Will there be any use for it other than representing the XR vs non-XR
cases? This all doesn't concern userspace or uAPI, so, if anybody needs
actual DSI panel walls (maybe also using DSI subchannels to driver more
than two pannels), we can extend the solution on the kernel side.

If we take the dual-LVDS panels in mind, I can propose the following
API:

struct drm_panel {
	/**
	  * @dual_channel: set for the DSI or LVDS panels which use two
	  * host interfaces to be driven
	  */
	bool dual_channel;
};

struct drm_bridge {
	/**
	  * @dual_channel: set for the bridges which use two host
	  * interfaces to be driven, e.g. dual LVDS panel or bonded DSI
	  * bridge.
	  */
	bool dual_channel;
};

Devices like LT9611/LT9611UXC or panels like hx8279 will set that flag.
The DSI host driver can use it to determine whether to use width or
2*width in the DSI calculation.

At the same time, in your case, you won't set this flag. The DSI host
driver, fidning bonded DSI link and non-dual-channel bridge will
determine that it's a panel bifurcation case and handle it
appropriately.

What do you think?

-- 
With best wishes
Dmitry

Re: [PATCH v5 4/6] drm/msm/dsi: Support dual panel use case with single CRTC

[Dmitry Baryshkov]

On Mon, Jul 27, 2026 at 04:08:43PM +0800, Jun Nie wrote:
> Support a hardware configuration where two independent DSI panels are
> driven by a single, synchronous CRTC. This configuration uses a bonded
> DSI link to provide a unified vblank for both displays.
> 
> This allows application software to treat the two displays as a single,
> wide framebuffer with a synchronized refresh cycle, simplifying rendering
> logic for side-by-side panel arrangements.
> 
> At the DSI host level, the frame width for each link must be that of an
> individual panel. The driver therefore halves the CRTC's horizontal
> resolution before configuring the DSI host and any DSC encoders, ensuring
> each panel receives the correct half of the framebuffer.

I guess, the flag from the previous patch should be coming from the DT
node of the DSI host. The DSI should then get the mode from a single
panel and then set the adjusted_mode for the CRTC (note sure how this
will work for the compositors though).


Also please note that the are other possible configurations. For
example, for some time I've had a setup using two Raspberry panels
attached to two DSI hosts for exactly the same purpose (please check, I
think Neil might still have it, or maybe somebody else from the team).
Each channel is an I2C-controlled DSI-to-DPI bridge + a DPI panel. I
understand that it's not your target, but it's something to keep in
mind. I'd say, the bare minimum would be to resolve a second bridge (be
it a full bridge or a panel bridge), possibly create a second bridge
chain (remember, bridges don't support branching, so you are a bit on
your own here) and at least manually call the callbacks. This would
ensure that the second panel (or a second bridge) is properly controlled
(and thus would get rid of the second reset GPIO from your patches).

> The pic_width is used to calculated DSC parameter for DPU DSC controller
>  together with panel's parameter. While panel driver that support dual
> panel shall provide slice_width parameter of single panel. This patch
> only impact DSC configuration, so crtc is not aware of it and not impacted
> by it.
> 
> While the DSI panel driver should manage two panels togehter.
> 1. During probe, the driver finds the sibling dsi host via device tree
> phandle and register the 2nd panel to get another mipi_dsi_device.
> 2. Set dual_panel flag on both mipi_dsi_device.
> 3. Prepare DSC data per requirement from single panel.
> 4. All DSI commands should be send on every DSI link.

broadcasting of DSI commands is controlled by the DT flag.

> 5. Handle power supply for 2 panels in one shot, the same is true to
>    brightness.
> 6. From the CRTC's perspective, the two panels appear as one wide display.
>    The driver exposes a DRM mode where the horizontal timings (hdisplay,
>    hsync_start, etc.) are doubled, while the vertical timings remain those
>    of a single panel. Because 2 panels are expected to be mounted in
>    left/right position.
> 
> To maintain synchronization, both DSI links are configured to share a
> single clock source, with the DSI1 controller using the clock provided
> to DSI0 as below.
> 
> &mdss_dsi1 {
>    assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
> 		     <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
>    assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;
> }
> 
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index e39938fb0f502..a3c56c3dc7904 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -186,6 +186,7 @@ struct msm_dsi_host {
>  	bool registered;
>  	bool power_on;
>  	bool enabled;
> +	bool is_dual_panel;
>  	int irq;
>  };
>  
> @@ -1024,7 +1025,10 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
>  			return;
>  		}
>  
> -		dsc->pic_width = mode->hdisplay;
> +		if (msm_host->is_dual_panel)
> +			dsc->pic_width = hdisplay;
> +		else
> +			dsc->pic_width = mode->hdisplay;
>  		dsc->pic_height = mode->vdisplay;
>  		DBG("Mode %dx%d\n", dsc->pic_width, dsc->pic_height);
>  
> @@ -1705,6 +1709,7 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
>  	if (dsi->lanes > msm_host->num_data_lanes)
>  		return -EINVAL;
>  
> +	msm_host->is_dual_panel = dsi->dual_panel;
>  	msm_host->channel = dsi->channel;
>  	msm_host->lanes = dsi->lanes;
>  	msm_host->format = dsi->format;
> @@ -2600,6 +2605,9 @@ enum drm_mode_status msm_dsi_host_check_dsc(struct mipi_dsi_host *host,
>  	if (!msm_host->dsc)
>  		return MODE_OK;
>  
> +	if (msm_host->is_dual_panel)
> +		pic_width = mode->hdisplay / 2;
> +
>  	if (pic_width % dsc->slice_width) {
>  		pr_err("DSI: pic_width %d has to be multiple of slice %d\n",
>  		       pic_width, dsc->slice_width);
> 
> -- 
> 2.43.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH v5 4/6] drm/msm/dsi: Support dual panel use case with single CRTC

[Jun Nie]

Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年9月30日周三 00:20写道：
>
> On Mon, Jul 27, 2026 at 04:08:43PM +0800, Jun Nie wrote:
> > Support a hardware configuration where two independent DSI panels are
> > driven by a single, synchronous CRTC. This configuration uses a bonded
> > DSI link to provide a unified vblank for both displays.
> >
> > This allows application software to treat the two displays as a single,
> > wide framebuffer with a synchronized refresh cycle, simplifying rendering
> > logic for side-by-side panel arrangements.
> >
> > At the DSI host level, the frame width for each link must be that of an
> > individual panel. The driver therefore halves the CRTC's horizontal
> > resolution before configuring the DSI host and any DSC encoders, ensuring
> > each panel receives the correct half of the framebuffer.
>
> I guess, the flag from the previous patch should be coming from the DT
> node of the DSI host. The DSI should then get the mode from a single
> panel and then set the adjusted_mode for the CRTC (note sure how this
> will work for the compositors though).

The original information comes from the panel. Panel driver exposes
the flag to dsi host. Because the panel driver hides all dual physical
panels stuff and exposes a single panel to DRM framework, so it exposes
the doubled mode to DRM framework level too. This simplifies the
handling of 2 physical panels in DRM level and compositors level.
>
>
> Also please note that the are other possible configurations. For
> example, for some time I've had a setup using two Raspberry panels
> attached to two DSI hosts for exactly the same purpose (please check, I
> think Neil might still have it, or maybe somebody else from the team).
> Each channel is an I2C-controlled DSI-to-DPI bridge + a DPI panel. I
> understand that it's not your target, but it's something to keep in
> mind. I'd say, the bare minimum would be to resolve a second bridge (be
> it a full bridge or a panel bridge), possibly create a second bridge
> chain (remember, bridges don't support branching, so you are a bit on
> your own here) and at least manually call the callbacks. This would
> ensure that the second panel (or a second bridge) is properly controlled
> (and thus would get rid of the second reset GPIO from your patches).

I asked Neil but he has no idea on this. Per your description, you have 2
DRM connectors/bridges for 2 physical panels. I guess you have topology:
1 CRTC + 2*(encoder / connector / bridge). The handling of 2 physical
panels falls into DRM level, not inside panel driver as this patch set.
This 2 methodology does not conflict in theory. Do you see and conflict in
implementation?
>
> > The pic_width is used to calculated DSC parameter for DPU DSC controller
> >  together with panel's parameter. While panel driver that support dual
> > panel shall provide slice_width parameter of single panel. This patch
> > only impact DSC configuration, so crtc is not aware of it and not impacted
> > by it.
> >
> > While the DSI panel driver should manage two panels togehter.
> > 1. During probe, the driver finds the sibling dsi host via device tree
> > phandle and register the 2nd panel to get another mipi_dsi_device.
> > 2. Set dual_panel flag on both mipi_dsi_device.
> > 3. Prepare DSC data per requirement from single panel.
> > 4. All DSI commands should be send on every DSI link.
>
> broadcasting of DSI commands is controlled by the DT flag.

Do you mean the property, qcom,sync-dual-dsi? It is QCOM specific
feature to send DSI commands twice in host driver. It can be done
in panel side as well. The bonus to do in panel side is that the
panel driver is more generic and can work with other SoC in theory.
And the DSI commands can be handled together with regulators
etc for 2 physical panels in a centric way. The panel driver is
more self-contained, minimizing dependency on the dsi host.

>
> > 5. Handle power supply for 2 panels in one shot, the same is true to
> >    brightness.
> > 6. From the CRTC's perspective, the two panels appear as one wide display.
> >    The driver exposes a DRM mode where the horizontal timings (hdisplay,
> >    hsync_start, etc.) are doubled, while the vertical timings remain those
> >    of a single panel. Because 2 panels are expected to be mounted in
> >    left/right position.
> >
> > To maintain synchronization, both DSI links are configured to share a
> > single clock source, with the DSI1 controller using the clock provided
> > to DSI0 as below.
> >
> > &mdss_dsi1 {
> >    assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>,
> >                    <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>;
> >    assigned-clock-parents = <&mdss_dsi0_phy 0>, <&mdss_dsi0_phy 1>;
> > }
> >
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > ---
> >  drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > index e39938fb0f502..a3c56c3dc7904 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > @@ -186,6 +186,7 @@ struct msm_dsi_host {
> >       bool registered;
> >       bool power_on;
> >       bool enabled;
> > +     bool is_dual_panel;
> >       int irq;
> >  };
> >
> > @@ -1024,7 +1025,10 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool is_bonded_dsi)
> >                       return;
> >               }
> >
> > -             dsc->pic_width = mode->hdisplay;
> > +             if (msm_host->is_dual_panel)
> > +                     dsc->pic_width = hdisplay;
> > +             else
> > +                     dsc->pic_width = mode->hdisplay;
> >               dsc->pic_height = mode->vdisplay;
> >               DBG("Mode %dx%d\n", dsc->pic_width, dsc->pic_height);
> >
> > @@ -1705,6 +1709,7 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
> >       if (dsi->lanes > msm_host->num_data_lanes)
> >               return -EINVAL;
> >
> > +     msm_host->is_dual_panel = dsi->dual_panel;
> >       msm_host->channel = dsi->channel;
> >       msm_host->lanes = dsi->lanes;
> >       msm_host->format = dsi->format;
> > @@ -2600,6 +2605,9 @@ enum drm_mode_status msm_dsi_host_check_dsc(struct mipi_dsi_host *host,
> >       if (!msm_host->dsc)
> >               return MODE_OK;
> >
> > +     if (msm_host->is_dual_panel)
> > +             pic_width = mode->hdisplay / 2;
> > +
> >       if (pic_width % dsc->slice_width) {
> >               pr_err("DSI: pic_width %d has to be multiple of slice %d\n",
> >                      pic_width, dsc->slice_width);
> >
> > --
> > 2.43.0
> >
>
> --
> With best wishes
> Dmitry

Re: [PATCH v5 4/6] drm/msm/dsi: Support dual panel use case with single CRTC

[Dmitry Baryshkov]

On Thu, Oct 01, 2026 at 12:10:13AM +0800, Jun Nie wrote:
> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> 于2026年9月30日周三 00:20写道：
> >
> > On Mon, Jul 27, 2026 at 04:08:43PM +0800, Jun Nie wrote:
> > > Support a hardware configuration where two independent DSI panels are
> > > driven by a single, synchronous CRTC. This configuration uses a bonded
> > > DSI link to provide a unified vblank for both displays.
> > >
> > > This allows application software to treat the two displays as a single,
> > > wide framebuffer with a synchronized refresh cycle, simplifying rendering
> > > logic for side-by-side panel arrangements.
> > >
> > > At the DSI host level, the frame width for each link must be that of an
> > > individual panel. The driver therefore halves the CRTC's horizontal
> > > resolution before configuring the DSI host and any DSC encoders, ensuring
> > > each panel receives the correct half of the framebuffer.
> >
> > I guess, the flag from the previous patch should be coming from the DT
> > node of the DSI host. The DSI should then get the mode from a single
> > panel and then set the adjusted_mode for the CRTC (note sure how this
> > will work for the compositors though).
> 
> The original information comes from the panel. Panel driver exposes
> the flag to dsi host. Because the panel driver hides all dual physical
> panels stuff and exposes a single panel to DRM framework, so it exposes
> the doubled mode to DRM framework level too. This simplifies the
> handling of 2 physical panels in DRM level and compositors level.

It simplifies the compositor, but it complicates the kernel code.
Handling this exctra flag becomes non-obvious, sorry. Also, how does all
of this map to any other vendor? Or to the case of non-DCS controlled
DSI output?

> >
> >
> > Also please note that the are other possible configurations. For
> > example, for some time I've had a setup using two Raspberry panels
> > attached to two DSI hosts for exactly the same purpose (please check, I
> > think Neil might still have it, or maybe somebody else from the team).
> > Each channel is an I2C-controlled DSI-to-DPI bridge + a DPI panel. I
> > understand that it's not your target, but it's something to keep in
> > mind. I'd say, the bare minimum would be to resolve a second bridge (be
> > it a full bridge or a panel bridge), possibly create a second bridge
> > chain (remember, bridges don't support branching, so you are a bit on
> > your own here) and at least manually call the callbacks. This would
> > ensure that the second panel (or a second bridge) is properly controlled
> > (and thus would get rid of the second reset GPIO from your patches).
> 
> I asked Neil but he has no idea on this. Per your description, you have 2
> DRM connectors/bridges for 2 physical panels. I guess you have topology:
> 1 CRTC + 2*(encoder / connector / bridge). The handling of 2 physical
> panels falls into DRM level, not inside panel driver as this patch set.
> This 2 methodology does not conflict in theory. Do you see and conflict in
> implementation?

Frankly, I don't think that the fake-double-panel sould land. The device
has two actual panels, tiled into L+R. So, exporting that information
would sounds like a better choice (I might be wrong here, though).
It feels like your patchset is trying to cover a single usecase, which
is understandable, but it's not a typical way we work (or accept
patches).

I *think* that the fact that having two panels should be visible.

BUT, there is a more important part. From the userspace point of view,
you have a stereo monitor, supporting the 3D SBS full mode (and
hopefully a single non-3D mode).

The compositors need to set DRM_CLIENT_CAP_STEREO_3D, then it will see
the 3D mode, etc. All other compositors will see a non-3D mode,
outputting the same image to both eyes.

> >
> > > The pic_width is used to calculated DSC parameter for DPU DSC controller
> > >  together with panel's parameter. While panel driver that support dual
> > > panel shall provide slice_width parameter of single panel. This patch
> > > only impact DSC configuration, so crtc is not aware of it and not impacted
> > > by it.
> > >
> > > While the DSI panel driver should manage two panels togehter.
> > > 1. During probe, the driver finds the sibling dsi host via device tree
> > > phandle and register the 2nd panel to get another mipi_dsi_device.
> > > 2. Set dual_panel flag on both mipi_dsi_device.
> > > 3. Prepare DSC data per requirement from single panel.
> > > 4. All DSI commands should be send on every DSI link.
> >
> > broadcasting of DSI commands is controlled by the DT flag.
> 
> Do you mean the property, qcom,sync-dual-dsi? It is QCOM specific
> feature to send DSI commands twice in host driver. It can be done
> in panel side as well. The bonus to do in panel side is that the
> panel driver is more generic and can work with other SoC in theory.
> And the DSI commands can be handled together with regulators
> etc for 2 physical panels in a centric way. The panel driver is
> more self-contained, minimizing dependency on the dsi host.

And then the panel driver becomes specific to the L+R configuration.

> 
> >
> > > 5. Handle power supply for 2 panels in one shot, the same is true to
> > >    brightness.
> > > 6. From the CRTC's perspective, the two panels appear as one wide display.
> > >    The driver exposes a DRM mode where the horizontal timings (hdisplay,
> > >    hsync_start, etc.) are doubled, while the vertical timings remain those
> > >    of a single panel. Because 2 panels are expected to be mounted in
> > >    left/right position.
> > >

-- 
With best wishes
Dmitry

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

[Krzysztof Kozlowski]

On Mon, Jul 27, 2026 at 04:08:44PM +0800, Jun Nie wrote:
> Add support for the dual-panel system found in the virtual reality device.
> This system consists of two physical 2160x2160 panels, each connected via
> a MIPI DSI interface. The backlight is managed through DSI link.
> 
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
>  .../bindings/display/panel/synaptics,r63455.yaml   | 133 +++++++++++++++++++++
>  1 file changed, 133 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml b/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml
> new file mode 100644
> index 0000000000000..c3bc8df981df7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml
> @@ -0,0 +1,133 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/synaptics,r63455.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synaptics R63455 based dual 2160x2160 MIPI-DSI Panel
> +
> +maintainers:
> +  - Jun Nie <jun.nie@linaro.org>
> +
> +description:
> +  Synaptics R63455 is a Virtual Reality Display Driver and VR Bridge, used in
> +  pair in Headset devices. The Virtual Reality Display complex is composed of
> +  two strictly identical display panels, each driven by its own DSI interface
> +  but forms a single virtual display for the human eye perception and thus
> +  requires a strict synchronization of the two display panel content update.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +        - sharp,ls026b3sa06
> +        - boe,vs026c4m-n52-6000

Not build checked. Please use tools, not humans for trivial things.

> +      - const: synaptics,r63455
> +
> +  reg:
> +    maxItems: 1
> +    description: DSI virtual channel
> +
> +  reset-gpios:
> +    maxItems: 2
> +    description: 2 reset pins for 2 physical panels

Won't work. gpio-consumer-common expects only one reset line. You need
two separate properties.

> +
> +  left-pos-supply:
> +    description: Positive 5.7V supply for left panel
> +
> +  right-pos-supply:
> +    description: Positive 5.7V supply for right panel
> +
> +  left-neg-supply:
> +    description: Negative 5.7V supply for left panel
> +
> +  right-neg-supply:
> +    description: Negative 5.7V supply for right panel
> +
> +  left-backlight-supply:
> +    description: Backlight 21V supply for left panel
> +
> +  right-backlight-supply:
> +    description: Backlight 21V supply for right panel
> +
> +  vdda-supply:
> +    description: core 1.8V supply for panels
> +
> +  ports:
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: DSI input port for primary DSI link
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: DSI input port for secondary DSI link
> +
> +    required:
> +      - port@0
> +      - port@1
> +
> +required:
> +  - compatible
> +  - reset-gpios
> +  - left-pos-supply
> +  - left-neg-supply
> +  - right-pos-supply
> +  - right-neg-supply
> +  - left-backlight-supply
> +  - right-backlight-supply
> +  - vdda-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +

---

> +    dsi@ae94000 {
> +        vdda-supply = <&vreg_l3i_1p2>;
> +        status = "okay";
> +
> +        qcom,dual-dsi-mode;
> +        qcom,master-dsi;

None of above is relevant. Drop

> +
> +        panel: panel@0 {

Unused label.

> +            compatible = "sharp,ls026b3sa06", "synaptics,r63455";
> +            reg = <0>;
> +
> +            reset-gpios = <&pm8550_gpios 3 GPIO_ACTIVE_HIGH>,
> +                          <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
> +
> +            left-pos-supply = <&vpos_left>;
> +            left-neg-supply = <&vneg_left>;
> +            right-pos-supply = <&vpos_right>;
> +            right-neg-supply = <&vneg_right>;
> +            left-backlight-supply = <&backlight_left>;
> +            right-backlight-supply = <&backlight_right>;
> +
> +            vdda-supply = <&vreg_l12b_1p8>;
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +                port@0 {
> +                    reg = <0>;
> +                    panel0_in: endpoint {
> +                        remote-endpoint = <&dsi0_out>;
> +                    };
> +                };
> +
> +                port@1 {
> +                    reg = <1>;
> +                    panel1_in: endpoint {
> +                        remote-endpoint = <&dsi1_out>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> +
> +...
> 
> -- 
> 2.43.0
> 

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

[Linus Walleij]

On Mon, Jul 27, 2026 at 10:29 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Jul 27, 2026 at 04:08:44PM +0800, Jun Nie wrote:

> > +  reset-gpios:
> > +    maxItems: 2
> > +    description: 2 reset pins for 2 physical panels
>
> Won't work. gpio-consumer-common expects only one reset line. You need
> two separate properties.

Hm that is a big confusion for the head.

reset-gpios is by it's very nature plural, because we structured
all GPIOs like that, exactly in order to indicate that they can be
arrays. :/

I think it's appropriate to patch gpio-consumer-common to accept
> 1 gpios, in a separate patch, can even be sent outside
of this series.

Unless the DT maintainers have some good reason to slap my
hands for that suggestion...

Yours,
Linus Walleij

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

[Krzysztof Kozlowski]

On 29/09/2026 14:54, Linus Walleij wrote:
> On Mon, Jul 27, 2026 at 10:29 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Mon, Jul 27, 2026 at 04:08:44PM +0800, Jun Nie wrote:
> 
>>> +  reset-gpios:
>>> +    maxItems: 2
>>> +    description: 2 reset pins for 2 physical panels
>>
>> Won't work. gpio-consumer-common expects only one reset line. You need
>> two separate properties.
> 
> Hm that is a big confusion for the head.
> 
> reset-gpios is by it's very nature plural, because we structured

So GPIOs are plural, but not reset-gpios. Just like shutdown-gpios. If
you have two pins to turn off one device, how does it work? Maybe you
have simple two devices?

> all GPIOs like that, exactly in order to indicate that they can be
> arrays. :/

Yes, in many cases.

> 
> I think it's appropriate to patch gpio-consumer-common to accept
>> 1 gpios, in a separate patch, can even be sent outside
> of this series.
> 
> Unless the DT maintainers have some good reason to slap my
> hands for that suggestion...

Make a case, can be an exception in gpio-consumer-common. But if you
have two panels, why can't it go to the graph for each of them?

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.

Best regards,
Krzysztof

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

[Linus Walleij]

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.

In that case I think it's better if we do:

panel: panel@0 {
    /* This is the two-panel package with one display controller */
    compatible = "sharp,ls026b3sa06", "synaptics,r63455";
    reg = <0>;
    #address-cells = <1>;
    #size-cells = <0>;

    panel@0 {
        reset-gpios = <&pm8550_gpios 3 GPIO_ACTIVE_HIGH>;
        reg = <0>;
         ....
    };

    panel@1 {
        reset-gpios = <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
        reg = <1>;
        ....
    };

...
};


Yours,
Linus Walleij

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

[Jun Nie]

Linus Walleij <linusw@kernel.org> 于2026年9月30日周三 15:44写道：
>
> 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.

Sorry to confuse you. There are 2 r63455 DSI controllers for 2 physical
panels. This patch set aims to hide 2 set of DSI host/device and
associated backlight/power/reset handling in a single panel driver. So
that it is much simpler for DRM CRTC/connector and compositor to
handle 2 physical panels, just as they handle a single panel. No change
is expected at all.

>
> In that case I think it's better if we do:
>
> panel: panel@0 {
>     /* This is the two-panel package with one display controller */
>     compatible = "sharp,ls026b3sa06", "synaptics,r63455";
>     reg = <0>;
>     #address-cells = <1>;
>     #size-cells = <0>;
>
>     panel@0 {
>         reset-gpios = <&pm8550_gpios 3 GPIO_ACTIVE_HIGH>;
>         reg = <0>;
>          ....
>     };
>
>     panel@1 {
>         reset-gpios = <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
>         reg = <1>;
>         ....
>     };
>
> ...
> };
>
>
> Yours,
> Linus Walleij

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

[Neil Armstrong]

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.

The R63455 is designed for this exact use case and are only supposed
to be use in XR application in pair.

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.

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.

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.

Nei

> 
> In that case I think it's better if we do:
> 
> panel: panel@0 {
>      /* This is the two-panel package with one display controller */
>      compatible = "sharp,ls026b3sa06", "synaptics,r63455";
>      reg = <0>;
>      #address-cells = <1>;
>      #size-cells = <0>;
> 
>      panel@0 {
>          reset-gpios = <&pm8550_gpios 3 GPIO_ACTIVE_HIGH>;
>          reg = <0>;
>           ....
>      };
> 
>      panel@1 {
>          reset-gpios = <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
>          reg = <1>;
>          ....
>      };
> 
> ...
> };
> 
> 
> Yours,
> Linus Walleij

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

[Dmitry Baryshkov]

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.

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

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

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

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

-- 
With best wishes
Dmitry

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

[Neil Armstrong]

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

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

[Dmitry Baryshkov]

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. 

-- 
With best wishes
Dmitry

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

[Neil Armstrong]

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

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

[Linus Walleij]

Hi Neil,

On Sun, Oct 4, 2026 at 5:51 PM Neil Armstrong <neil.armstrong@linaro.org> wrote:

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

Overall I really like the looks of this!

>         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>;
>                                 };
>                         };
>                 };
>         };

The core of the crux is to make the argument that this node represents
the hardware and isn't just something put in there to make it easier
to implement a driver.

If I break open the headset, will I find something like this, some wires
going around in there or so.

If yes, this is a go.

Yours,
Linus Walleij

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

[Neil Armstrong]

On 10/4/26 22:22, Linus Walleij wrote:
> Hi Neil,
> 
> On Sun, Oct 4, 2026 at 5:51 PM Neil Armstrong <neil.armstrong@linaro.org> wrote:
> 
>> 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:
> 
> Overall I really like the looks of this!
> 
>>          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>;
>>                                  };
>>                          };
>>                  };
>>          };
> 
> The core of the crux is to make the argument that this node represents
> the hardware and isn't just something put in there to make it easier
> to implement a driver.
> 
> If I break open the headset, will I find something like this, some wires
> going around in there or so.

Well you'll find 2 lens modules with embedded panels, they are separate because they go
for each eye, since it's technically a single display for the brain. You can't
really use each panel separately, they are mounted in a specific way to be looked
closely by human eyes.

Neil

> 
> If yes, this is a go.
> 
> Yours,
> Linus Walleij

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

[Dmitry Baryshkov]

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

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.

-- 
With best wishes
Dmitry

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

[Neil Armstrong]

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

> 

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

[Dmitry Baryshkov]

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.

-- 
With best wishes
Dmitry

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

[Neil Armstrong]

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

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

[Dmitry Baryshkov]

On Thu, Oct 08, 2026 at 10:27:05AM +0200, Neil Armstrong wrote:
> 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.

Yes. But if we are trying to define the ABI (and DT is an ABI). I'm
using this usecase as an example of what needs to be defined as a part
of the enclosure. Otherwise the case becomes a bit strange: we are
defining XR enclosure, but only for the sake of defining that there are
two panels and one of them is the left one. From my point of view, if we
are defining the enclosure, it should be a (more or less) complete
definition. If we say that we know all the details for now (because the
whole system is the XR headset), then we also don't seem to require
defining the panels setup.

Having that in mind, I'd still ask you to try the following experiment:

Add two separate panels, each describing one eye. Add msm-specific
connector driver, proxying both panels. If possible proxy bridges
instead of panels. The primary goal would be to handle get_modes() in a
consistent way. I still suggest using a DRM_MODE_FLAG_3D_foo to describe
the mode. Maybe we need to a new 3D_XR flag for the cases where the
panels don't provide an L-R picture without significant additional
processing on the host side. I'd still suggest having a single-eye
resolution mode too, just to let non-XR compositors to display
_something_ on the screen (even if it will be mostly unusable). Use this
connector instead of drm_bridge_connector. This should let MSM DSI
driver to clearly use the dimensions of the panel for DSC calculation
instead of depending on extra flags to derive them from the CRTC mode.

One of the ideas that was briefly discussed during LPC would be to
define ROI for the connector and use two connectors for a single CRTC
(each specifying its own region to be displayed). I think, this might
clean up a lot of the hacky code. For example, each of the connectors
would have its own backlight, each of them will have its own mode and
its own bridge chain. The major drawback is that from the userspace
point of view both connectors are independent. It would be a big
question, how the kernel should behave if the userspace would try
lighting up only a single connector out of two.

-- 
With best wishes
Dmitry

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

[Linus Walleij]

On Wed, Sep 30, 2026 at 6:43 PM Neil Armstrong
<neil.armstrong@linaro.org> 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:

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

OK

> See it like a single physical panel with 2 controllers which
> shouldn't be used separately.

If you have one reset line to them each, and as proven
by the driver in this series also grab and assert both, they
are by definition *already* used separately.

DT needs to describe the hardware.

Defining two nodes below the main node for the two
controllers and adding a reset line to each describes the
hardware perfectly fine?

It's not like I don't understand that this will complicate things
on the drivers side, of course it does. But a binding is a binding
is a binding. It needs to describe the hardware.

Yours,
Linus Walleij

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

[Krzysztof Kozlowski]

On Mon, Jul 27, 2026 at 04:47:19AM -0500, Rob Herring (Arm) wrote:
> 
> On Mon, 27 Jul 2026 16:08:44 +0800, Jun Nie wrote:
> > Add support for the dual-panel system found in the virtual reality device.
> > This system consists of two physical 2160x2160 panels, each connected via
> > a MIPI DSI interface. The backlight is managed through DSI link.
> > 
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
> > ---
> >  .../bindings/display/panel/synaptics,r63455.yaml   | 133 +++++++++++++++++++++
> >  1 file changed, 133 insertions(+)
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> ./Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml:26:9: [warning] wrong indentation: expected 10 but found 8 (indentation)
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml: properties:ports: 'anyOf' conditional failed, one must be fixed:
> 	'type' is a required property
> 	'$ref' is a required property
> 	hint: node schemas must have a type or $ref
> 	from schema $id: http://devicetree.org/meta-schemas/core.yaml

Seems nothing here was build-tested :/

Best regards,
Krzysztof

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

[Dmitry Baryshkov]

On Mon, Jul 27, 2026 at 04:08:44PM +0800, Jun Nie wrote:
> Add support for the dual-panel system found in the virtual reality device.
> This system consists of two physical 2160x2160 panels, each connected via
> a MIPI DSI interface. The backlight is managed through DSI link.
> 
> Signed-off-by: Jun Nie <jun.nie@linaro.org>
> ---
>  .../bindings/display/panel/synaptics,r63455.yaml   | 133 +++++++++++++++++++++
>  1 file changed, 133 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml b/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml
> new file mode 100644
> index 0000000000000..c3bc8df981df7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/synaptics,r63455.yaml
> @@ -0,0 +1,133 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/synaptics,r63455.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synaptics R63455 based dual 2160x2160 MIPI-DSI Panel
> +
> +maintainers:
> +  - Jun Nie <jun.nie@linaro.org>
> +
> +description:
> +  Synaptics R63455 is a Virtual Reality Display Driver and VR Bridge, used in
> +  pair in Headset devices. The Virtual Reality Display complex is composed of
> +  two strictly identical display panels, each driven by its own DSI interface
> +  but forms a single virtual display for the human eye perception and thus
> +  requires a strict synchronization of the two display panel content update.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +        - sharp,ls026b3sa06
> +        - boe,vs026c4m-n52-6000
> +      - const: synaptics,r63455

Judging by the Synaptics presentation at MIPI devcon 2018, R63455 is a
DDIC which supports only one panel. The VR bridge (in their case it was
VXR7200) drives two separate R63455-based panels. As such, I'd assume,
that this hardware description is not 100% correct.

> +
> +  reg:
> +    maxItems: 1
> +    description: DSI virtual channel
> +
> +  reset-gpios:
> +    maxItems: 2
> +    description: 2 reset pins for 2 physical panels
> +
> +  left-pos-supply:
> +    description: Positive 5.7V supply for left panel
> +
> +  right-pos-supply:
> +    description: Positive 5.7V supply for right panel
> +
> +  left-neg-supply:
> +    description: Negative 5.7V supply for left panel
> +
> +  right-neg-supply:
> +    description: Negative 5.7V supply for right panel
> +
> +  left-backlight-supply:
> +    description: Backlight 21V supply for left panel
> +
> +  right-backlight-supply:
> +    description: Backlight 21V supply for right panel
> +
> +  vdda-supply:
> +    description: core 1.8V supply for panels
> +
> +  ports:
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: DSI input port for primary DSI link
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: DSI input port for secondary DSI link
> +
> +    required:
> +      - port@0
> +      - port@1
> +
> +required:
> +  - compatible
> +  - reset-gpios
> +  - left-pos-supply
> +  - left-neg-supply
> +  - right-pos-supply
> +  - right-neg-supply
> +  - left-backlight-supply
> +  - right-backlight-supply
> +  - vdda-supply
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    dsi@ae94000 {
> +        vdda-supply = <&vreg_l3i_1p2>;
> +        status = "okay";

There is no need for the status in DT examples.

> +
> +        qcom,dual-dsi-mode;
> +        qcom,master-dsi;
> +
> +        panel: panel@0 {
> +            compatible = "sharp,ls026b3sa06", "synaptics,r63455";
> +            reg = <0>;
> +
> +            reset-gpios = <&pm8550_gpios 3 GPIO_ACTIVE_HIGH>,
> +                          <&pm8550_gpios 11 GPIO_ACTIVE_HIGH>;
> +
> +            left-pos-supply = <&vpos_left>;
> +            left-neg-supply = <&vneg_left>;
> +            right-pos-supply = <&vpos_right>;
> +            right-neg-supply = <&vneg_right>;
> +            left-backlight-supply = <&backlight_left>;
> +            right-backlight-supply = <&backlight_right>;
> +
> +            vdda-supply = <&vreg_l12b_1p8>;
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +                port@0 {
> +                    reg = <0>;
> +                    panel0_in: endpoint {
> +                        remote-endpoint = <&dsi0_out>;
> +                    };
> +                };
> +
> +                port@1 {
> +                    reg = <1>;
> +                    panel1_in: endpoint {
> +                        remote-endpoint = <&dsi1_out>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> +
> +...
> 
> -- 
> 2.43.0
> 

-- 
With best wishes
Dmitry