From: Tomi Valkeinen tomi.valkeinen@ideasonboard.com
[ Upstream commit 7070f55f294745c5a3c033623b76309f3512be67 ]
While the cdns-dsi does not support DSI burst mode, the burst mode is essentially DSI event mode with more versatile clocking and timings. Thus cdns-dsi doesn't need to fail if the DSI peripheral driver requests MIPI_DSI_MODE_VIDEO_BURST.
In my particular use case, this allows the use of ti-sn65dsi83 driver.
Tested-by: Parth Pancholi parth.pancholi@toradex.com Tested-by: Jayesh Choudhary j-choudhary@ti.com Reviewed-by: Devarsh Thakkar devarsht@ti.com Link: https://lore.kernel.org/r/20250723-cdns-dsi-impro-v5-15-e61cc06074c2@ideason... Signed-off-by: Tomi Valkeinen tomi.valkeinen@ideasonboard.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
Rationale - User-visible bugfix: The driver currently rejects any device that sets `MIPI_DSI_MODE_VIDEO_BURST`, causing attach to fail for many common DSI bridges/panels that default to burst mode (e.g., TI SN65DSI83). This is a functional regression for users of the Cadence DSI host where the sink would work fine in non-burst/event mode. Removing the hard failure allows these devices to work. - Minimal, localized change: The patch only removes an early return in `cdns_dsi_attach()` that rejects `MIPI_DSI_MODE_VIDEO_BURST`: - drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c:956-958 - Comment “We do not support burst mode yet.” - `if (dev->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) return -ENOTSUPP;` - No behavioral change for supported paths: The Cadence driver does not use `MIPI_DSI_MODE_VIDEO_BURST` anywhere else. A search shows the only use is this attach-time rejection (drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c:957). All actual mode programming is driven by: - `MIPI_DSI_MODE_VIDEO` checks (e.g., drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c:890, 907) - `MIPI_DSI_MODE_VIDEO_SYNC_PULSE` (e.g., drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c:479, 529, 593, 817, 824, 890) - `MIPI_DSI_MODE_NO_EOT_PACKET` (e.g., drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c:831, 904) The driver never sets BURST-related registers (e.g., `BURST_MODE`, `VID_VCA_SETTING1`), so ignoring the burst bit simply means the host runs in event/sync-pulse video mode as before. - Proven practical benefit: The commit message cites enabling the TI SN65DSI83 driver. In this tree, that driver sets burst mode by default (drivers/gpu/drm/bridge/ti-sn65dsi83.c:657), so the current Cadence driver categorically fails to attach even though it could operate in non-burst. This change removes an unnecessary blocker.
Risk assessment - Very low regression risk: - Existing working users (who do not request burst) see no change. - Devices requesting burst but able to function in event mode will now work (previously failed to attach). - If a device really requires burst-only operation, it did not work before (attach failed); after this change, the host will attempt event mode; if the link budget is insufficient, mode validation/config will still fail. Users are not worse off than before. - No architectural changes: No clocking or register programming changes, no new behavior at runtime beyond not returning `-ENOTSUPP` on attach. - Subsystem scope: Limited to the Cadence DSI bridge driver; does not touch core DRM or DSI frameworks.
Historical/context notes - The attach-time burst rejection has existed since the original driver (git blame shows it dates back to initial integration). Other DSI hosts generally don’t reject burst flags at attach; they either implement burst or ignore it. - This patch aligns the driver with a more permissive, capability- fallback style: support event/sync-pulse even when the sink asks for burst.
Stable backport fit - Fixes a real, user-facing interoperability issue without adding features. - Small and self-contained with no dependencies on later refactors (the only required change on stable trees is removing the three-line check). - No observable side effects beyond enabling previously blocked configurations.
Conclusion - This is an excellent stable backport candidate: it unblocks real hardware, is minimal and low risk, and does not introduce architectural changes.
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c index 9f1c460d5f0d4..0cc83bdb130fc 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c @@ -1088,10 +1088,6 @@ static int cdns_dsi_attach(struct mipi_dsi_host *host, if (output->dev) return -EBUSY;
- /* We do not support burst mode yet. */ - if (dev->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) - return -ENOTSUPP; - /* * The host <-> device link might be described using an OF-graph * representation, in this case we extract the device of_node from