Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: Andreas Kemnade <andreas@kemnade.info>
To: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Tony Lindgren <tony@atomide.com>,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	Marek Vasut <marex@denx.de>,
	"H. Nikolaus Schaller" <hns@goldelico.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>
Subject: Re: [PATCH] drm/omap: dsi: avoid sending bta sync all the time in writes
Date: Thu, 28 May 2026 22:19:12 +0200	[thread overview]
Message-ID: <20260528221912.1771daa4@kemnade.info> (raw)
In-Reply-To: <20260528220603.6600d45b@kemnade.info>

On Thu, 28 May 2026 22:06:03 +0200
Andreas Kemnade <andreas@kemnade.info> wrote:

> On Thu, 28 May 2026 20:43:12 +0300
> Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> wrote:
> 
> > Hi,
> > 
> > On 28.05.26 г. 20:02 ч., Andreas Kemnade wrote:  
> > > Hi,
> > > 
> > > so this droid4? Or which device is it?
> > >     
> > 
> > Oh, sorry, yes, this is droid4.
> >   
> > > On Thu, 28 May 2026 17:44:14 +0300
> > > Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> wrote:
> > >     
> > >> Applied against 6.18.31, no dice :)
> > >>
> > >> [   11.617523] [drm] Initialized pvr 1.17.4948957 for 56000000.gpu on
> > >> minor 0
> > >> [   11.674652] omapdss_dss 58000000.dss: bound 58001000.dispc (ops
> > >> dispc_component_ops [omapdrm])
> > >> [   11.775085] omapdss_dss 58000000.dss: bound 58001000.dispc (ops
> > >> dsi_vc_flush_receive_data [omapdrm])
> > >> [   12.222930] omapdss_dss 58000000.dss: bound 58001000.dispc (ops
> > >> dsi_vc_flush_receive_data [omapdrm])
> > >> [   12.245117] omapdss_dss 58000000.dss: bound 58001000.dispc (ops
> > >> dsi_vc_flush_receive_data [omapdrm])
> > >> [   12.247375] omapdss_dss 58000000.dss: bound 58004000.encoder (ops
> > >> dsi_vc_flush_receive_data [omapdrm])
> > >> [   12.249267] omapdss_dss 58000000.dss: bound 58006000.encoder (ops
> > >> dsi_vc_flush_receive_data [omapdrm])
> > >> [   12.284729] [drm] Initialized omapdrm 1.0.0 for omapdrm.0 on minor 1
> > >> [   12.311981] [drm] Enabling DMM ywrap scrolling    
> > > 
> > > I would expect some
> > > output from  the panel-dsi-cm driver:
> > > dev_info(&ddata->dsi->dev, "panel revision %02x.%02x.%02x\n",
> > >                          id1, id2, id3);
> > > 
> > > or some error:
> > >          dev_err(&ddata->dsi->dev, "error while enabling panel, issuing HW reset\n");
> > > 
> > > Any explanation why it is missing?
> > >     
> > 
> > It is there, I grep-ed for omapdrm only, didn't want to flood the ML:
> > 
> > 2026-05-28T17:34:45.761932+03:00 devuan-droid4 kernel: [   12.502105] 
> > panel-dsi-cm 58004000.encoder.0: panel revision 70.01.02
> > 
> > Here is the (almost)full boot log: https://paste.debian.net/hidden/e6ca55a7
> >   
> 2026-05-28T17:34:45.763732+03:00 devuan-droid4 kernel: [  112.820404] DSI: omapdss DSI: failed to send nop between frames: -5
> 2026-05-28T17:34:45.763732+03:00 devuan-droid4 kernel: [  113.331726] DSI: omapdss DSI: failed to send nop between frames: -5
> 
> and that is interesting. Apparently no PACKET_SENT_IRQ and the wait
> completion times out. Maybe it is not used with short packets.
> But..
>        /*
>          * Send NOP between the frames. If we don't send something here, the
>          * 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_send_nop(dsi, VC_CMD, dsi->dsidev->channel);
> 
> I do not see a reason why something should go into LP mode here. the
> message will probably be sent in HS mode but the BTA sync (not done anymore)
> is probably the only thing turning something to LP mode.
> 
> So to avoid PACKET_SENT_IRQ trouble, do:
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index dcfcfc0efcdc..37323c9b08a8 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -2200,7 +2200,7 @@ static int dsi_vc_write_common(struct omap_dss_device *dssdev, int vc,
>  	int r;
>  
>  	if (mipi_dsi_packet_format_is_short(msg->type))
> -		r = dsi_vc_send_short(dsi, vc, msg);
> +		return dsi_vc_send_short(dsi, vc, msg);
>  	else
>  		r = dsi_vc_send_long(dsi, vc, msg);
>  
> 
> Also try:
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index dcfcfc0efcdc..37323c9b08a8 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -3283,11 +3283,11 @@ static int dsi_update_channel(struct omap_dss_device *dssdev, int vc)
>  	DSSDBG("dsi_update_channel: %d", vc);
>  
>  	/*
> -	 * Send NOP between the frames. If we don't send something here, the
> +	 * Transition to LP here. If we don't send something here, the
>  	 * 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_send_nop(dsi, VC_CMD, dsi->dsidev->channel);
> +	r = dsi_vc_send_bta_sync(dssdev, vc);

probably rather VC_CMD
>  	if (r < 0) {
>  		DSSWARN("failed to send nop between frames: %d\n", r);
>  		goto err;
> 
> 
> 
> Regards,
> Andreas
> 


  reply	other threads:[~2026-05-28 20:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-28 10:16 [PATCH] drm/omap: dsi: avoid sending bta sync all the time in writes akemnade
2026-05-28 14:44 ` Ivaylo Dimitrov
2026-05-28 17:02   ` Andreas Kemnade
2026-05-28 17:43     ` Ivaylo Dimitrov
2026-05-28 20:06       ` Andreas Kemnade
2026-05-28 20:19         ` Andreas Kemnade [this message]
2026-05-29  6:26           ` Ivaylo Dimitrov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260528221912.1771daa4@kemnade.info \
    --to=andreas@kemnade.info \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hns@goldelico.com \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marex@denx.de \
    --cc=mripard@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=simona@ffwll.ch \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=tomi.valkeinen@ti.com \
    --cc=tony@atomide.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox