On Sun, 25 Oct 2026 14:38:50 +0000, [email protected] wrote: > For a 4-lane non-burst panel using MIPI_DSI_FMT_RGB666_PACKED (bpp = 18), > (bpp / lanes) truncates from 4.5 to 4, giving a lane rate of 5 * mpclk Mbps. > That is only 11.1% (1/9) above the 4.5 * mode->clock pixel bandwidth, rather > than 25%. [...] > If the slack is only meant to ignore lane_mbps being rounded up to the next > MHz, should the check compare dsi->lane_mbps against > DIV_ROUND_UP_ULL(pixel_kbps, MSEC_PER_SEC) instead of adding pixel_kbps / 8?
Right, the 1/8 slack misses that case. v2 will use the lane rate when lane_mbps is above the pixel bandwidth rounded up to the next MHz, which keeps i.MX93, Meson and STM in non-burst mode on the pixel clock formula. > Should pixel_kbps and the pixel-clock lbcc calculation divide by > dw_mipi_dsi_get_lanes(dsi) instead of dsi->lanes to handle dual-DSI panels? With dsi->lanes the patch doesn't change the timing of the dual-DSI Gru Scarlet panel: its lane rate stays below the per-link pixel bandwidth, so it keeps the current computation. Switching to the total lane count would change that timing, and I can't test it, so I'll keep dsi->lanes in this patch and leave the dual-DSI accounting to a separate one. I'll send v2 in about a week. Romain
