* [PATCH v2 1/3] drm/rockchip: dsi: Add maximum per lane bit rate calculation
2026-06-03 3:35 [PATCH v2 0/3] DSI Controller improvements for Rockchip platforms Chaoyi Chen
@ 2026-06-03 3:35 ` Chaoyi Chen
2026-06-04 1:57 ` Claude review: " Claude Code Review Bot
2026-06-03 3:35 ` [PATCH v2 2/3] drm/rockchip: dsi: Add dphy_get_timing support for multiple PHY types Chaoyi Chen
` (2 subsequent siblings)
3 siblings, 1 reply; 8+ messages in thread
From: Chaoyi Chen @ 2026-06-03 3:35 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Guochun Huang
Cc: dri-devel, linux-arm-kernel, linux-rockchip, linux-kernel,
Chaoyi Chen
From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Different chips have varying support for the maximum bit rate per lane.
Add calculation for the maximum per lane bit rate for various chip
platforms.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
---
Changes in v2:
- Fix the unit conversion for max_mbps.
- Split the lane rate calculation into a separate patch.
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 3547d91b25d3..1060abec9f29 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -268,6 +268,7 @@ struct rockchip_dw_dsi_chip_data {
unsigned int flags;
unsigned int max_data_lanes;
+ unsigned long max_bit_rate_per_lane;
};
struct dw_mipi_dsi_rockchip {
@@ -565,7 +566,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
int bpp;
unsigned long mpclk, tmp;
unsigned int target_mbps = 1000;
- unsigned int max_mbps = dppa_map[ARRAY_SIZE(dppa_map) - 1].max_mbps;
+ unsigned int max_mbps;
unsigned long best_freq = 0;
unsigned long fvco_min, fvco_max, fin, fout;
unsigned int min_prediv, max_prediv;
@@ -573,6 +574,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
unsigned long _fbdiv, best_fbdiv;
unsigned long min_delta = ULONG_MAX;
+ max_mbps = dsi->cdata->max_bit_rate_per_lane / USEC_PER_SEC;
dsi->format = format;
bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
if (bpp < 0) {
@@ -1503,6 +1505,7 @@ static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
PX30_DSI_FORCETXSTOPMODE), 0),
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1000000000UL,
},
{ /* sentinel */ }
};
@@ -1515,6 +1518,7 @@ static const struct rockchip_dw_dsi_chip_data rk3128_chip_data[] = {
RK3128_DSI_FORCERXMODE |
RK3128_DSI_FORCETXSTOPMODE), 0),
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1000000000UL,
},
{ /* sentinel */ }
};
@@ -1527,6 +1531,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
.lcdsel_lit = FIELD_PREP_WM16_CONST(RK3288_DSI0_LCDC_SEL, 1),
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1500000000UL,
},
{
.reg = 0xff964000,
@@ -1535,6 +1540,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
.lcdsel_lit = FIELD_PREP_WM16_CONST(RK3288_DSI1_LCDC_SEL, 1),
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1500000000UL,
},
{ /* sentinel */ }
};
@@ -1547,6 +1553,7 @@ static const struct rockchip_dw_dsi_chip_data rk3368_chip_data[] = {
RK3368_DSI_FORCETXSTOPMODE |
RK3368_DSI_FORCERXMODE), 0),
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1500000000UL,
},
{ /* sentinel */ }
};
@@ -1634,6 +1641,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
.flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1500000000UL,
},
{
.reg = 0xff968000,
@@ -1658,6 +1666,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
.flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1500000000UL,
.dphy_rx_init = rk3399_dphy_tx1rx1_init,
.dphy_rx_power_on = rk3399_dphy_tx1rx1_power_on,
@@ -1674,6 +1683,7 @@ static const struct rockchip_dw_dsi_chip_data rk3506_chip_data[] = {
FIELD_PREP_WM16_CONST(RK3506_DSI_FORCERXMODE, 0) |
FIELD_PREP_WM16_CONST(RK3506_DSI_FORCETXSTOPMODE, 0)),
.max_data_lanes = 2,
+ .max_bit_rate_per_lane = 1500000000UL,
},
{ /* sentinel */ }
};
@@ -1687,6 +1697,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
FIELD_PREP_WM16_CONST(RK3568_DSI0_TURNDISABLE, 0) |
FIELD_PREP_WM16_CONST(RK3568_DSI0_FORCERXMODE, 0)),
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1200000000UL,
},
{
.reg = 0xfe070000,
@@ -1696,6 +1707,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
FIELD_PREP_WM16_CONST(RK3568_DSI1_TURNDISABLE, 0) |
FIELD_PREP_WM16_CONST(RK3568_DSI1_FORCERXMODE, 0)),
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1200000000UL,
},
{ /* sentinel */ }
};
@@ -1708,6 +1720,7 @@ static const struct rockchip_dw_dsi_chip_data rv1126_chip_data[] = {
FIELD_PREP_WM16_CONST(RV1126_DSI_FORCERXMODE, 0) |
FIELD_PREP_WM16_CONST(RV1126_DSI_FORCETXSTOPMODE, 0)),
.max_data_lanes = 4,
+ .max_bit_rate_per_lane = 1000000000UL,
},
{ /* sentinel */ }
};
--
2.53.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Claude review: drm/rockchip: dsi: Add maximum per lane bit rate calculation
2026-06-03 3:35 ` [PATCH v2 1/3] drm/rockchip: dsi: Add maximum per lane bit rate calculation Chaoyi Chen
@ 2026-06-04 1:57 ` Claude Code Review Bot
0 siblings, 0 replies; 8+ messages in thread
From: Claude Code Review Bot @ 2026-06-04 1:57 UTC (permalink / raw)
To: dri-devel-reviews
Patch Review
**Status: Looks good overall**
This patch replaces the hard-coded max lane rate (previously derived from `dppa_map[ARRAY_SIZE(dppa_map) - 1].max_mbps`, which was always 1500 Mbps) with a per-chip `max_bit_rate_per_lane` field. The values assigned per SoC are:
- PX30, RK3128, RV1126: 1000 Mbps (1000000000UL)
- RK3568: 1200 Mbps (1200000000UL)
- RK3288, RK3368, RK3399, RK3506: 1500 Mbps (1500000000UL)
The unit conversion is correct:
```c
max_mbps = dsi->cdata->max_bit_rate_per_lane / USEC_PER_SEC;
```
`USEC_PER_SEC` = 1,000,000, so e.g. 1,500,000,000 / 1,000,000 = 1500 Mbps. This is correct.
**Minor observation**: For chips that previously had a max of 1500 from `dppa_map`, this is a no-op. For PX30/RK3128/RV1126, this is now a *functional change* that lowers the max from 1500 to 1000 Mbps — this will cause the "out of range" error path to trigger earlier on those chips, which is actually the correct behavior since they can't actually drive 1500 Mbps.
No issues found in this patch.
---
---
Generated by Claude Code Patch Reviewer
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2 2/3] drm/rockchip: dsi: Add dphy_get_timing support for multiple PHY types
2026-06-03 3:35 [PATCH v2 0/3] DSI Controller improvements for Rockchip platforms Chaoyi Chen
2026-06-03 3:35 ` [PATCH v2 1/3] drm/rockchip: dsi: Add maximum per lane bit rate calculation Chaoyi Chen
@ 2026-06-03 3:35 ` Chaoyi Chen
2026-06-04 1:57 ` Claude review: " Claude Code Review Bot
2026-06-03 3:35 ` [PATCH v2 3/3] drm/rockchip: dsi: Relax the lane rate margin requirements Chaoyi Chen
2026-06-04 1:57 ` Claude review: DSI Controller improvements for Rockchip platforms Claude Code Review Bot
3 siblings, 1 reply; 8+ messages in thread
From: Chaoyi Chen @ 2026-06-03 3:35 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Guochun Huang
Cc: dri-devel, linux-arm-kernel, linux-rockchip, linux-kernel,
Chaoyi Chen
From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Currently, there are generally two types of DPHY for Rockchip. One is
the DPHY used by RK3288/RK3399, whose timing is described by Table A-3
High-Speed Transition Times in the databook. The other is the DPHY used
by PX30 and its successors. If its timing is still described using
RK3288/RK3399, it may not perform correctly on some DSI panel.
Add dphy_get_timing for different D-PHY types to adapt to timing
differences. The configuration details are as follows:
- RK3288/RK3399: Select the corresponding entry from the timing table based
on the data rate.
- PX30 and later platforms: Use a fixed timing configuration.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
---
Changes in v2:
- Add more comment about timing config.
---
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 45 ++++++++++++++++++-
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 1060abec9f29..e64dfc327891 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -247,6 +247,7 @@ enum {
BIASEXTR_127_7,
};
+struct dw_mipi_dsi_rockchip;
struct rockchip_dw_dsi_chip_data {
u32 reg;
@@ -262,6 +263,9 @@ struct rockchip_dw_dsi_chip_data {
u32 lanecfg2_grf_reg;
u32 lanecfg2;
+ int (*dphy_get_timing)(struct dw_mipi_dsi_rockchip *dsi, unsigned int lane_mbps,
+ struct dw_mipi_dsi_dphy_timing *timing);
+
int (*dphy_rx_init)(struct phy *phy);
int (*dphy_rx_power_on)(struct phy *phy);
int (*dphy_rx_power_off)(struct phy *phy);
@@ -721,8 +725,9 @@ static struct hstt hstt_table[] = {
};
static int
-dw_mipi_dsi_phy_get_timing(void *priv_data, unsigned int lane_mbps,
- struct dw_mipi_dsi_dphy_timing *timing)
+dw_mipi_dsi_phy_rk3288_get_timing(struct dw_mipi_dsi_rockchip *dsi,
+ unsigned int lane_mbps,
+ struct dw_mipi_dsi_dphy_timing *timing)
{
int i;
@@ -738,6 +743,32 @@ dw_mipi_dsi_phy_get_timing(void *priv_data, unsigned int lane_mbps,
return 0;
}
+static const struct dw_mipi_dsi_dphy_timing dphy_timing_px30 = {
+ .clk_lp2hs = 0x40,
+ .clk_hs2lp = 0x40,
+ .data_lp2hs = 0x10,
+ .data_hs2lp = 0x14,
+};
+
+static int
+dw_mipi_dsi_phy_px30_get_timing(struct dw_mipi_dsi_rockchip *dsi,
+ unsigned int lane_mbps,
+ struct dw_mipi_dsi_dphy_timing *timing)
+{
+ *timing = dphy_timing_px30;
+
+ return 0;
+}
+
+static int
+dw_mipi_dsi_phy_get_timing(void *priv_data, unsigned int lane_mbps,
+ struct dw_mipi_dsi_dphy_timing *timing)
+{
+ struct dw_mipi_dsi_rockchip *dsi = priv_data;
+
+ return dsi->cdata->dphy_get_timing(dsi, lane_mbps, timing);
+}
+
static const struct dw_mipi_dsi_phy_ops dw_mipi_dsi_rockchip_phy_ops = {
.init = dw_mipi_dsi_phy_init,
.power_on = dw_mipi_dsi_phy_power_on,
@@ -1506,6 +1537,7 @@ static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
.max_data_lanes = 4,
.max_bit_rate_per_lane = 1000000000UL,
+ .dphy_get_timing = dw_mipi_dsi_phy_px30_get_timing,
},
{ /* sentinel */ }
};
@@ -1519,6 +1551,7 @@ static const struct rockchip_dw_dsi_chip_data rk3128_chip_data[] = {
RK3128_DSI_FORCETXSTOPMODE), 0),
.max_data_lanes = 4,
.max_bit_rate_per_lane = 1000000000UL,
+ .dphy_get_timing = dw_mipi_dsi_phy_px30_get_timing,
},
{ /* sentinel */ }
};
@@ -1532,6 +1565,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
.max_data_lanes = 4,
.max_bit_rate_per_lane = 1500000000UL,
+ .dphy_get_timing = dw_mipi_dsi_phy_rk3288_get_timing,
},
{
.reg = 0xff964000,
@@ -1541,6 +1575,7 @@ static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
.max_data_lanes = 4,
.max_bit_rate_per_lane = 1500000000UL,
+ .dphy_get_timing = dw_mipi_dsi_phy_rk3288_get_timing,
},
{ /* sentinel */ }
};
@@ -1554,6 +1589,7 @@ static const struct rockchip_dw_dsi_chip_data rk3368_chip_data[] = {
RK3368_DSI_FORCERXMODE), 0),
.max_data_lanes = 4,
.max_bit_rate_per_lane = 1500000000UL,
+ .dphy_get_timing = dw_mipi_dsi_phy_px30_get_timing,
},
{ /* sentinel */ }
};
@@ -1642,6 +1678,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
.flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
.max_data_lanes = 4,
.max_bit_rate_per_lane = 1500000000UL,
+ .dphy_get_timing = dw_mipi_dsi_phy_rk3288_get_timing,
},
{
.reg = 0xff968000,
@@ -1671,6 +1708,7 @@ static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
.dphy_rx_init = rk3399_dphy_tx1rx1_init,
.dphy_rx_power_on = rk3399_dphy_tx1rx1_power_on,
.dphy_rx_power_off = rk3399_dphy_tx1rx1_power_off,
+ .dphy_get_timing = dw_mipi_dsi_phy_rk3288_get_timing,
},
{ /* sentinel */ }
};
@@ -1698,6 +1736,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
FIELD_PREP_WM16_CONST(RK3568_DSI0_FORCERXMODE, 0)),
.max_data_lanes = 4,
.max_bit_rate_per_lane = 1200000000UL,
+ .dphy_get_timing = dw_mipi_dsi_phy_px30_get_timing,
},
{
.reg = 0xfe070000,
@@ -1708,6 +1747,7 @@ static const struct rockchip_dw_dsi_chip_data rk3568_chip_data[] = {
FIELD_PREP_WM16_CONST(RK3568_DSI1_FORCERXMODE, 0)),
.max_data_lanes = 4,
.max_bit_rate_per_lane = 1200000000UL,
+ .dphy_get_timing = dw_mipi_dsi_phy_px30_get_timing,
},
{ /* sentinel */ }
};
@@ -1721,6 +1761,7 @@ static const struct rockchip_dw_dsi_chip_data rv1126_chip_data[] = {
FIELD_PREP_WM16_CONST(RV1126_DSI_FORCETXSTOPMODE, 0)),
.max_data_lanes = 4,
.max_bit_rate_per_lane = 1000000000UL,
+ .dphy_get_timing = dw_mipi_dsi_phy_px30_get_timing,
},
{ /* sentinel */ }
};
--
2.53.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Claude review: drm/rockchip: dsi: Add dphy_get_timing support for multiple PHY types
2026-06-03 3:35 ` [PATCH v2 2/3] drm/rockchip: dsi: Add dphy_get_timing support for multiple PHY types Chaoyi Chen
@ 2026-06-04 1:57 ` Claude Code Review Bot
0 siblings, 0 replies; 8+ messages in thread
From: Claude Code Review Bot @ 2026-06-04 1:57 UTC (permalink / raw)
To: dri-devel-reviews
Patch Review
**Status: BUG — NULL pointer dereference on RK3506**
The design is sound: the monolithic `dw_mipi_dsi_phy_get_timing()` is refactored into per-DPHY-type callbacks (`dw_mipi_dsi_phy_rk3288_get_timing` for the table-based RK3288/RK3399 DPHY, and `dw_mipi_dsi_phy_px30_get_timing` with fixed values for PX30 and successors). The dispatch function unconditionally dereferences the callback:
```c
static int
dw_mipi_dsi_phy_get_timing(void *priv_data, unsigned int lane_mbps,
struct dw_mipi_dsi_dphy_timing *timing)
{
struct dw_mipi_dsi_rockchip *dsi = priv_data;
return dsi->cdata->dphy_get_timing(dsi, lane_mbps, timing);
}
```
**`rk3506_chip_data` does not set `.dphy_get_timing`**, so `dsi->cdata->dphy_get_timing` is NULL on RK3506. This will cause a kernel oops. Looking at the applied tree at line 1716-1727:
```c
static const struct rockchip_dw_dsi_chip_data rk3506_chip_data[] = {
{
...
.max_data_lanes = 2,
.max_bit_rate_per_lane = 1500000000UL,
/* .dphy_get_timing is missing! */
},
{ /* sentinel */ }
};
```
Every other chip_data entry has `.dphy_get_timing` set. RK3506 should presumably use `dw_mipi_dsi_phy_px30_get_timing` given it's a newer SoC, consistent with the pattern used for RK3128, RK3368, RK3568, and RV1126.
**Other notes on this patch:**
The forward declaration `struct dw_mipi_dsi_rockchip;` before `struct rockchip_dw_dsi_chip_data` is necessary and correctly placed.
The PX30 fixed timing values (`clk_lp2hs=0x40, clk_hs2lp=0x40, data_lp2hs=0x10, data_hs2lp=0x14`) are just magic numbers with no explanation of where they come from — a brief comment referencing the specific hardware documentation or downstream source would help reviewers, but the commit message does mention "fixed timing configuration" for PX30, so this is minor.
---
---
Generated by Claude Code Patch Reviewer
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2 3/3] drm/rockchip: dsi: Relax the lane rate margin requirements
2026-06-03 3:35 [PATCH v2 0/3] DSI Controller improvements for Rockchip platforms Chaoyi Chen
2026-06-03 3:35 ` [PATCH v2 1/3] drm/rockchip: dsi: Add maximum per lane bit rate calculation Chaoyi Chen
2026-06-03 3:35 ` [PATCH v2 2/3] drm/rockchip: dsi: Add dphy_get_timing support for multiple PHY types Chaoyi Chen
@ 2026-06-03 3:35 ` Chaoyi Chen
2026-06-04 1:57 ` Claude review: " Claude Code Review Bot
2026-06-04 1:57 ` Claude review: DSI Controller improvements for Rockchip platforms Claude Code Review Bot
3 siblings, 1 reply; 8+ messages in thread
From: Chaoyi Chen @ 2026-06-03 3:35 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Guochun Huang
Cc: dri-devel, linux-arm-kernel, linux-rockchip, linux-kernel,
Chaoyi Chen
From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
The lane rate is calculated as follows:
Lane_Rate = Pixel_Clk * BPP / lanes * Overhead
The overhead factor is set to 1/0.8, equivalent to a 25% overhead.
Now let's consider the case of RGB888 (BPP24) with a pclk of 148.5MHz.
The lane rate equals 148.5M * 24 / 4 * 1.25 = 1113.75 Mbps.
However, this is beyond the capability of certain platforms limited to a
1Gbps lane rate. On the other hand, we have observed that some DSI panel
actually perform worse with higher overhead.
So we are considering relaxing the bandwidth margin requirements.
According to the downstream test results, adopting 1/0.9 seems to
be a sound approach, corresponding to an overhead of about 11%.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index e64dfc327891..8af9d6934d27 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -590,8 +590,8 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
if (mpclk) {
- /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
- tmp = mpclk * (bpp / lanes) * 10 / 8;
+ /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
+ tmp = mpclk * (bpp / lanes) * 10 / 9;
if (tmp < max_mbps)
target_mbps = tmp;
else
@@ -601,7 +601,7 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
/* for external phy only a the mipi_dphy_config is necessary */
if (dsi->phy) {
- phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 8,
+ phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 9,
bpp, lanes,
&dsi->phy_opts.mipi_dphy);
dsi->lane_mbps = target_mbps;
--
2.53.0
^ permalink raw reply related [flat|nested] 8+ messages in thread* Claude review: drm/rockchip: dsi: Relax the lane rate margin requirements
2026-06-03 3:35 ` [PATCH v2 3/3] drm/rockchip: dsi: Relax the lane rate margin requirements Chaoyi Chen
@ 2026-06-04 1:57 ` Claude Code Review Bot
0 siblings, 0 replies; 8+ messages in thread
From: Claude Code Review Bot @ 2026-06-04 1:57 UTC (permalink / raw)
To: dri-devel-reviews
Patch Review
**Status: Looks correct, accept with caveats**
Changes the overhead factor from `10/8` (25% margin, i.e. 1/0.8) to `10/9` (~11% margin, i.e. 1/0.9) in two places:
```c
/* Internal PHY path */
tmp = mpclk * (bpp / lanes) * 10 / 9;
/* External PHY path */
phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 9,
bpp, lanes,
&dsi->phy_opts.mipi_dphy);
```
The commit message gives a concrete justification: RGB888 at 148.5 MHz with 4 lanes at 1/0.8 overhead = 1113.75 Mbps, which exceeds the 1000 Mbps limit on PX30/RK3128/RV1126. With 1/0.9, it becomes ~990 Mbps, which fits.
**Concerns:**
- The MIPI DSI spec recommends that the data rate should exceed the required bandwidth to account for protocol overhead (LP escape, ECC, CRC, etc.). 11% margin is tighter than typical. The commit message says "downstream test results" validate this, but it would be helpful to know on which panels/SoCs this was tested.
- The comment `/* since mbps must big than bandwidth of RGB */` (grammar aside) is retained but the meaning changes — the margin is now significantly tighter.
- This is ordered as patch 3/3, so it depends on patch 1 having already set the correct per-chip max. The combination works: chips limited to 1000 Mbps can now drive 148.5 MHz RGB888 panels, which was the motivating use case.
---
## SUMMARY
| Patch | Verdict |
|-------|---------|
| 1/3 — max lane bit rate | **OK** |
| 2/3 — dphy_get_timing | **BUG: rk3506_chip_data missing `.dphy_get_timing` — will NULL deref** |
| 3/3 — relax margin | **OK with caveat** (tighter margin; needs tested panel coverage noted) |
The series should not be merged until `rk3506_chip_data` gets its `.dphy_get_timing` assignment added (likely `dw_mipi_dsi_phy_px30_get_timing`).
---
Generated by Claude Code Patch Reviewer
^ permalink raw reply [flat|nested] 8+ messages in thread
* Claude review: DSI Controller improvements for Rockchip platforms
2026-06-03 3:35 [PATCH v2 0/3] DSI Controller improvements for Rockchip platforms Chaoyi Chen
` (2 preceding siblings ...)
2026-06-03 3:35 ` [PATCH v2 3/3] drm/rockchip: dsi: Relax the lane rate margin requirements Chaoyi Chen
@ 2026-06-04 1:57 ` Claude Code Review Bot
3 siblings, 0 replies; 8+ messages in thread
From: Claude Code Review Bot @ 2026-06-04 1:57 UTC (permalink / raw)
To: dri-devel-reviews
Overall Series Review
Subject: DSI Controller improvements for Rockchip platforms
Author: Chaoyi Chen <kernel@airkyi.com>
Patches: 4
Reviewed: 2026-06-04T11:57:41.999506
---
This is a 3-patch series for the Rockchip DSI controller driver (`dw-mipi-dsi-rockchip.c`). It adds per-chip maximum lane bit rate specifications, refactors DPHY timing to use chip-specific callbacks, and reduces the lane rate overhead margin from 25% (1/0.8) to ~11% (1/0.9).
The series is well-motivated and the patches are logically structured. However, **Patch 2 has a critical bug**: the `rk3506_chip_data` entry is missing the `.dphy_get_timing` assignment, which will cause a NULL pointer dereference at runtime on RK3506 platforms.
---
Generated by Claude Code Patch Reviewer
^ permalink raw reply [flat|nested] 8+ messages in thread