Re: [PATCH v4] drm/omap: dsi: avoid sending bta sync all the time in writes

On Tue, 30 Jun 2026 08:42:57 +0300
Ivaylo Dimitrov <[email protected]> wrote:

> Hi,
> With this version of the patch I see:
> 
> [  102.760894] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  303.860321] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  307.071624] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  307.360626] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  307.671142] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  308.660339] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  308.961059] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  313.191314] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  313.700378] DSI: omapdss DSI error: Failed to set dsi_if_enable to 0
> [  313.980346] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  314.791564] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  315.090362] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  322.850952] DSI: omapdss DSI error: Framedone not received for 250ms!
> [  323.111175] DSI: omapdss DSI error: Framedone not received for 250ms!
> 
> while scrolling the (hildon)desktop on droid4, so I would say the change 
> broke command mode.
> 
so let me summarize:
- sending initialisation commands to video mode panel: no problem visible in
  any case, theretical problems (not seen with the tested panels if sending too much data, fixed via v4.
- command mode display: no picture and error messages without any bta sync (patch version 1).
- working display with send_nop() replaced by simply sending bta_sync() and not
  waiting for PACKET_SENT irq for short packets (v2).
- partly working display (with v4), (always waiting for PACKET_SENT)

so there are some situations when waiting for a packet completition is harmful.
In your case these were only siutations when short packets were sent.
Do you have a more complete log of v4 boott?
In the log for v1 which is not accessible anymore, there were other 
more informative timeouts visible.

But maybe as a wild guess also based on Sasikhos AI reviews, maybe
this helps:

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 3f22929c36e2..eb3cd0d23cae 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -3267,7 +3267,7 @@ static int dsi_update_channel(struct omap_dss_device *dssdev, int vc)
 	 * updates stop working. This is probably related to DSI spec stating
 	 * that the DSI host should transition to LP at least once per frame.
 	 */
-	r = dsi_vc_send_bta_sync(dssdev, vc);
+	r = dsi_vc_send_bta_sync(dssdev, VC_CMD);
 	if (r < 0) {
 		DSSWARN("failed to send bta sync between frames: %d\n", r);
 		goto err;



Then the call is equal to the original one done via send_nnop.

Regards,
Andreas