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

[Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>]

On 7.07.26 г. 13:22 ч., Andreas Kemnade wrote:
> On Tue, 30 Jun 2026 08:42:57 +0300
> Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> 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.
> 

With that change it seems to work properly, will keep that version of 
the driver for the time being.

> Regards,
> Andreas