public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: tessolveupstream@gmail.com
To: Luca Ceresoli <luca.ceresoli@bootlin.com>,
	Marek Vasut <marex@nabladev.com>,
	andrzej.hajda@intel.com, neil.armstrong@linaro.org,
	rfoss@kernel.org
Cc: Laurent.pinchart@ideasonboard.com, jonas@kwiboo.se,
	jernej.skrabec@gmail.com, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
	simona@ffwll.ch, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, valentin@compulab.co.il,
	philippe.schenker@toradex.com, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support
Date: Thu, 19 Mar 2026 15:25:22 +0530	[thread overview]
Message-ID: <a937f714-d013-4ac2-a52b-2893fc16f225@gmail.com> (raw)
In-Reply-To: <DH5S3DYT0PJQ.11ABZFGEU6ZPC@bootlin.com>



On 18-03-2026 14:21, Luca Ceresoli wrote:
> Hello Sudarshan,
> 
> On Wed Mar 18, 2026 at 6:45 AM CET, tessolveupstream wrote:
>>>>> You might want to look at recently posted:
>>>>>
>>>>> [PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output
>>>>
>>>> Thanks for pointing this out.
>>>> I tried applying the patch “[PATCH 2/3] drm/bridge: ti-sn65dsi83: halve horizontal syncs for dual LVDS output” on top of the current tree and
>>>> removed the changes that I had previously added in the driver.
>>>> However, with this patch applied, I am currently seeing only the backlight turning on and no image on the LVDS panel.
>>>> For reference, the LVDS panel used on our platform is G133HAN01.1 and the
>>>> DSI-to-dual-link LVDS bridge is SN65DSI84ZXHR.
>>>
>>> Thanks for having tried.
>>>
>>> Can you please test with both the fixes in the series applied + the test
>>> pattern feature and report the results you get with and without test
>>> pattern enabled?
>>>
>>> The patches to apply are:
>>>
>>>  - https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-1-2e15f5a9a6a0@bootlin.com/
>>>  - https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-2-2e15f5a9a6a0@bootlin.com/
>>>  - https://lore.kernel.org/lkml/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-1-e6aaa7e1d181@bootlin.com/
>>>
>>
>> Thanks for the suggestions.
>>
>> I tested the three patches together as mentioned, but the LVDS panel
>> still only shows the backlight and no image. I also tried removing the
>> test-pattern patch and retesting with only the remaining two fixes, but
>> the result remained the same — only the backlight turns on and no image
>> is displayed.
> 
> Sure, the test pattern patch does not change anything, unless you enable
> the test pattern.
> 
>>> The first thing I suggest doing on your side is testing with the 3 patches
>>> mentioned above.
>>>
>>> If you display works, good! Let us know (you can also add your Tested-by /
>>> Reviewed-by tags to the test_pattern patch too if applicable).
>>>
>>> If it doesn't work, compare the individual register values to find the
>>> differences, try to figure out why the working setting works and how to
>>> apply that change to the driver in away that keeps other boards
>>> working. You're welcome to come back here to discuss it in case you can't
>>> find out on your own.
>>>
>>
>> I tested the three patches as suggested, but the panel still shows only the
>> backlight with no visible image. I’m unsure how to translate the working
>> register values into a generic fix based on display timings. Any guidance
>> on the right direction would be helpful.
> 
> What you should do is:
> 
>  1. with your patches, and while the display is enabled (and working) do
> 
>      cat /sys/kernel/debug/regmap/4-002c/registers >regs.working
> 
>  2. remove your patches, add the 3 I mentioned, and while the display is
>     enabled (but only backlight is working) do
> 
>      cat /sys/kernel/debug/regmap/4-002c/registers >regs.broken
> 
> Then compare regs.working and regs.broken. Which registers differ? Can you
> give a reason for the differences?
> 
> You can come back with these values here so we may discuss them.
>

I followed your suggestion and captured the register dumps in both cases.
~# cat regs.working
00: 35
01: 38
02: 49
03: 53
04: 44
05: 20
06: 20
07: 20
08: 01
09: 01
0a: 85
0b: 28
0d: 01
10: 26
11: 00
12: 53
18: 6f
19: 00
1a: 03
1b: 00
20: 80
21: 07
24: 00
25: 00
28: 21
29: 00
2c: 10
2d: 00
30: 0e
31: 00
34: 28
36: 00
38: 00
3a: 00
3c: 00
e0: 00
e1: 00
e5: 00

~# cat regs.broken
00: 35
01: 38
02: 49
03: 53
04: 44
05: 20
06: 20
07: 20
08: 01
09: 01
0a: 85
0b: 28
0d: 01
10: 26
11: 00
12: 55
18: 0f
19: 05
1a: 03
1b: 00
20: 80
21: 07
24: 38
25: 04
28: 21
29: 00
2c: 15
2d: 00
30: 0e
31: 00
34: 2c
36: 0e
38: 1d
3a: 08
3c: 00
e0: 00
e1: 00
e5: 00

In the working case, several of the timing registers remain at 0, 
while in the broken case they are programmed with non-zero values.
> Luca
> 
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com


  reply	other threads:[~2026-03-19  9:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-12  4:37 [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support Sudarshan Shetty
2026-03-12  4:37 ` [PATCH v2 1/2] dt-bindings: display: bridge: ti,sn65dsi83: Add dual-link video mode property Sudarshan Shetty
2026-03-12 15:46   ` [PATCH v2 1/2] dt-bindings: display: bridge: ti, sn65dsi83: " Luca Ceresoli
2026-03-13  8:55     ` Krzysztof Kozlowski
2026-03-18  5:48     ` tessolveupstream
2026-03-18  5:49     ` tessolveupstream
2026-03-12  4:37 ` [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode Sudarshan Shetty
2026-03-12 15:47   ` Luca Ceresoli
2026-03-18  5:53     ` tessolveupstream
2026-03-18  8:52       ` Luca Ceresoli
2026-03-12  5:05 ` [PATCH v2 0/2] drm: bridge: ti-sn65dsi83: Improve dual-link LVDS support Marek Vasut
2026-03-12 12:35   ` tessolveupstream
2026-03-12 15:49     ` Luca Ceresoli
2026-03-18  5:45       ` tessolveupstream
2026-03-18  8:51         ` Luca Ceresoli
2026-03-19  9:55           ` tessolveupstream [this message]
2026-03-19 13:47             ` Luca Ceresoli
2026-03-24 11:00               ` tessolveupstream
2026-03-24 11:10                 ` Alexander Stein
2026-03-25  6:09                   ` tessolveupstream
2026-03-25  7:14                     ` Alexander Stein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a937f714-d013-4ac2-a52b-2893fc16f225@gmail.com \
    --to=tessolveupstream@gmail.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marex@nabladev.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=philippe.schenker@toradex.com \
    --cc=rfoss@kernel.org \
    --cc=robh@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=valentin@compulab.co.il \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox