1. Patchew
  2. linux
  3. View series

[PATCH v5 0/3] DSI Controller improvements for Rockchip platforms

Chaoyi Chen posted 3 patches 1 week, 4 days ago 
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 72 +++++++++++++++++--
1 file changed, 65 insertions(+), 7 deletions(-)
[PATCH v5 0/3] DSI Controller improvements for Rockchip platforms
Posted by Chaoyi Chen 1 week, 4 days ago 
From: Chaoyi Chen <chaoyi.chen@rock-chips.com>

This series is dedicated to enhancing the DSI controller and PHY timing
interaction, refining the lane rate calculation, and addressing the
associated hardware limitations.

Changes in v5:
- Link to v4: https://lore.kernel.org/all/20260812073002.328-1-kernel@airkyi.com/
- Change the upper bound check for target_mbps from < to <= (sashiko).

Changes in v4:
- Link to v3: https://lore.kernel.org/all/20260810034139.148-1-kernel@airkyi.com/
- Add missing RK3506 timing and the fallback path for get_timing
  (sashiko).
- Fix potential overflow and underflow issues in bandwidth
  calculation(sashiko).

Changes in v3:
- Link to v2: https://lore.kernel.org/all/20260603033532.164-1-kernel@airkyi.com/
- Rebase to Linux v7.2

Changes in v2:
- Link to v1: https://lore.kernel.org/all/20260324085838.90-1-kernel@airkyi.com/
- Fix the unit conversion for max_mbps.
- Split the lane rate calculation into a separate patch.
- Add more comment about timing config.

Chaoyi Chen (3):
  drm/rockchip: dsi: Add maximum per lane bit rate calculation
  drm/rockchip: dsi: Add dphy_get_timing support for multiple PHY types
  drm/rockchip: dsi: Relax the lane rate margin requirements

 .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 72 +++++++++++++++++--
 1 file changed, 65 insertions(+), 7 deletions(-)

-- 
2.53.0
Re: [PATCH v5 0/3] DSI Controller improvements for Rockchip platforms
Posted by Heiko Stübner 1 week, 2 days ago 
Hi,

Am Montag, 14. September 2026, 03:33:28 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> 
> This series is dedicated to enhancing the DSI controller and PHY timing
> interaction, refining the lane rate calculation, and addressing the
> associated hardware limitations.


Took me a bit to finally test all the different variants for a display
that shows strange behaviour. Sorry this gets a bit longer.


The display in question is the ltk050h3148w [0], display in portrait
orientation.

Ever since commit ac87d23694f4 ("drm/bridge: synopsys: dw-mipi-dsi: Use
pixel clock rate to calculate lbcc") [1] and the subsequent fix in commit
93e82bb4de01 ("drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for
burst mode") [2], that display has its output shifted about 20 pixels to
the right, with the line then continuing on the next display line.

We have this display running on all the Theobroma-System modules, so there
is a lot of variant data :-) .

Your series actually fixed the PX30 part of that shifted output, but for
the RK3399 the results are sort of mixed:


What was confusing me was that in the Rockchip vendor kernel, _all_ DSI
variants use the standard px30 phy settings? The whole original lookup
table seems to be gone? And that replicating that setting actually fixes
the shifted output on RK3399 too?


RK3399:
	original:
		shifted
		mode-clock 59400, target_mbps 450

	patches 1+2:
		shifted
		mode-clock 59400, target_mbps 450

	patch 3:
		blank disiplay
		mode-clock 59400, target_mbps 400

	use static px30 phy with patch3:
		image is compressed in height and displayed two times one below the other
		image is _not_ shifted anymore (so left+right alignment are correct)
		mode-clock 59400, target_mbps 400
	
	use static px30 phy without patch3:
		image is _not_ shifted anymore
		output is correct
		mode-clock 59400, target_mbps 450


PX30:
	original
		shifted
		mode-clock 59556, target_mbps 450

	patches 1+2:
		output is correct
		image is _not_ shifted anymore (so left+right alignment are correct)
		mode-clock 59556, target_mbps 450

	patch 3:
		output is still correct
		mode-clock 59556, target_mbps 400

RK3588 (DSI2) for reference:
	output is correct
	mode-clock 59756, lane_mbps 398


Do you have any insight, what could go wrong here?

I'll apply patches 1+2 as they're correct, but will keep patch3 out
for now.

Also Sashiko seems to still be unhappy with patch3.


Thanks a lot
Heiko


[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c#n299
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac87d23694f44af44a98d21dd77016f2756b6b1b
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93e82bb4de0196c4caeca1d8a6eef67863981d8f
Re: [PATCH v5 0/3] DSI Controller improvements for Rockchip platforms
Posted by Chaoyi Chen 1 week, 2 days ago 
Hello Heiko,

On 9/15/2026 9:36 PM, Heiko Stübner wrote:
> Hi,
> 
> Am Montag, 14. September 2026, 03:33:28 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>
>> This series is dedicated to enhancing the DSI controller and PHY timing
>> interaction, refining the lane rate calculation, and addressing the
>> associated hardware limitations.
> 
> 
> Took me a bit to finally test all the different variants for a display
> that shows strange behaviour. Sorry this gets a bit longer.
> 
> 
> The display in question is the ltk050h3148w [0], display in portrait
> orientation.
> 
> Ever since commit ac87d23694f4 ("drm/bridge: synopsys: dw-mipi-dsi: Use
> pixel clock rate to calculate lbcc") [1] and the subsequent fix in commit
> 93e82bb4de01 ("drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for
> burst mode") [2], that display has its output shifted about 20 pixels to
> the right, with the line then continuing on the next display line.
> 
> We have this display running on all the Theobroma-System modules, so there
> is a lot of variant data :-) .
> 
> Your series actually fixed the PX30 part of that shifted output, but for
> the RK3399 the results are sort of mixed:
> 
> 
> What was confusing me was that in the Rockchip vendor kernel, _all_ DSI
> variants use the standard px30 phy settings? The whole original lookup
> table seems to be gone? And that replicating that setting actually fixes
> the shifted output on RK3399 too?
> 

Thanks a lot for the thorough testing!

The RK3399 results are surprising, as the Synopsys databook
configuration actually performs worse than the PX30 PHY configuration.
As for the vendor changes, unfortunately the specific reasons are lost
to history. But what is certain is that the original intent was to
resolve the interoperability issues with INNO PHY on PX30 and
subsequent platforms. 

So I've gone with a compromise in this series to distinguish INNO PHY
and Synopsys PHY. I'm not sure if using the same configuration for both
would work out completely, but so far no related issues have been
reported in the vendor kernel.

I don't have a better idea for patch 3 right now, because different 
platforms and panels may have different requirements for target_mbps. 
In vendor kernel, we read the DTS to override target_mbps like this:

/* optional override of the desired bandwidth */
if (!of_property_read_u32(dev->of_node, "rockchip,lane-rate", &value)) {
	target_mbps = value;
}

Would you consider this modification acceptable as an alternative to
patch 3? Thank you.

> 
> RK3399:
> 	original:
> 		shifted
> 		mode-clock 59400, target_mbps 450
> 
> 	patches 1+2:
> 		shifted
> 		mode-clock 59400, target_mbps 450
> 
> 	patch 3:
> 		blank disiplay
> 		mode-clock 59400, target_mbps 400
> 
> 	use static px30 phy with patch3:
> 		image is compressed in height and displayed two times one below the other
> 		image is _not_ shifted anymore (so left+right alignment are correct)
> 		mode-clock 59400, target_mbps 400
> 	
> 	use static px30 phy without patch3:
> 		image is _not_ shifted anymore
> 		output is correct
> 		mode-clock 59400, target_mbps 450
> 
> 
> PX30:
> 	original
> 		shifted
> 		mode-clock 59556, target_mbps 450
> 
> 	patches 1+2:
> 		output is correct
> 		image is _not_ shifted anymore (so left+right alignment are correct)
> 		mode-clock 59556, target_mbps 450
> 
> 	patch 3:
> 		output is still correct
> 		mode-clock 59556, target_mbps 400
> 
> RK3588 (DSI2) for reference:
> 	output is correct
> 	mode-clock 59756, lane_mbps 398
> 
> 
> Do you have any insight, what could go wrong here?
> 
> I'll apply patches 1+2 as they're correct, but will keep patch3 out
> for now.
> 
> Also Sashiko seems to still be unhappy with patch3.
> 
> 
> Thanks a lot
> Heiko
> 
> 
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c#n299
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac87d23694f44af44a98d21dd77016f2756b6b1b
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93e82bb4de0196c4caeca1d8a6eef67863981d8f

-- 
Best, 
Chaoyi
Re: (subset) [PATCH v5 0/3] DSI Controller improvements for Rockchip platforms
Posted by Heiko Stuebner 1 week, 2 days ago 
On Mon, 14 Sep 2026 09:33:28 +0800, Chaoyi Chen wrote:
> This series is dedicated to enhancing the DSI controller and PHY timing
> interaction, refining the lane rate calculation, and addressing the
> associated hardware limitations.
> 
> Changes in v5:
> - Link to v4: https://lore.kernel.org/all/20260812073002.328-1-kernel@airkyi.com/
> - Change the upper bound check for target_mbps from < to <= (sashiko).
> 
> [...]

Applied, thanks!

[1/3] drm/rockchip: dsi: Add maximum per lane bit rate calculation
      commit: 3c58af05953af5ab120e2c9061d7bdedde0d1bfd
[2/3] drm/rockchip: dsi: Add dphy_get_timing support for multiple PHY types
      commit: 5363e01e4ff03a204cab85292b89cf90c2d1b101

Best regards,
-- 
Heiko Stuebner <heiko@sntech.de>

Patchew 2.1-devel-ea86937

© 2016 - 2026 Red Hat, Inc.