diff options
| author | Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> | 2025-07-23 13:05:21 +0300 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2025-11-13 15:34:11 -0500 |
| commit | e6f4716011fd229eb022d0b1e60fff1b5dd24332 (patch) | |
| tree | c7689f8c8e5bb803af78631e47be742139d4e799 /drivers/gpu/drm/bridge | |
| parent | 6827f61b02f4d57d1a1805c68b5f2258a26b86cf (diff) | |
| download | linux-e6f4716011fd229eb022d0b1e60fff1b5dd24332.tar.gz linux-e6f4716011fd229eb022d0b1e60fff1b5dd24332.tar.bz2 linux-e6f4716011fd229eb022d0b1e60fff1b5dd24332.zip | |
drm/bridge: cdns-dsi: Don't fail on MIPI_DSI_MODE_VIDEO_BURST
[ 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@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'drivers/gpu/drm/bridge')
| -rw-r--r-- | drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c | 4 |
1 files changed, 0 insertions, 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 faa0bdfd1937..ddfbb2009c8d 100644 --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c @@ -959,10 +959,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 |