From: akemnade@kernel.org
To: 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>
Cc: 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>,
Andreas Kemnade <andreas@kemnade.info>
Subject: [PATCH] drm/omap: dsi: avoid sending bta sync all the time in writes
Date: Thu, 28 May 2026 12:16:13 +0200 [thread overview]
Message-ID: <20260528-vm-upstr-v1-1-fb93ef8cbe47@kernel.org> (raw)
From: Andreas Kemnade <andreas@kemnade.info>
Some chips need configuration commands to be sent first, before they can
send data. TC358762 for example needs PPI_LPTXTIMECNT configured
and PPI_STARTPPI set to 1 to be able to transmit anything. To be able to
configure such chips, do not send bta sync during writes if no acks are
requested. Instead just wait for the packet to be sent to avoid FIFO
overflows. There might be more to do about acks, but there seem to be
virtually no users of that flag.
This came to light when fiddling with the Epson Moverio BT-200 display
which consists of 2 TC358762 bridges with SPI funneled through
to the unknown display chip. With that patch the bridge can be accessed,
Reading back registers works, when the above-mentioned registers are set.
Video mode panel at OMAP4 (BT-200) and video mode at OMAP5 was tested.
Fixes: e70965386353e ("drm/omap: dsi: simplify write function")
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
This was not tested on any command mode display, which IMHO should be
done. So droid4 folks: please give it a try
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 32 +++++++++++++++++++++++---------
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 27fe7bca9e2cf..98362b0157023 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -2194,6 +2194,7 @@ static int dsi_vc_send_null(struct dsi_data *dsi, int vc, int channel)
static int dsi_vc_write_common(struct omap_dss_device *dssdev, int vc,
const struct mipi_dsi_msg *msg)
{
+ DECLARE_COMPLETION_ONSTACK(completion);
struct dsi_data *dsi = to_dsi_data(dssdev);
int r;
@@ -2205,17 +2206,30 @@ static int dsi_vc_write_common(struct omap_dss_device *dssdev, int vc,
if (r < 0)
return r;
- /*
- * TODO: we do not always have to do the BTA sync, for example
- * we can improve performance by setting the update window
- * information without sending BTA sync between the commands.
- * In that case we can return early.
- */
+ /* wait for IRQ for long packet transmission confirmation */
+ r = dsi_register_isr_vc(dsi, vc, dsi_completion_handler,
+ &completion, DSI_VC_IRQ_PACKET_SENT);
+ if (r)
+ return r;
- r = dsi_vc_send_bta_sync(dssdev, vc);
- if (r) {
- DSSERR("bta sync failed\n");
+ if (wait_for_completion_timeout(&completion,
+ msecs_to_jiffies(500)) == 0)
+ r = -EIO;
+
+ dsi_unregister_isr_vc(dsi, vc, dsi_completion_handler,
+ &completion, DSI_VC_IRQ_PACKET_SENT);
+
+ if (r)
return r;
+
+ /* TODO: find out if more needs to be done for MIPI_DIS_MSG_REQ_ACK */
+
+ if (msg->flags & MIPI_DSI_MSG_REQ_ACK) {
+ r = dsi_vc_send_bta_sync(dssdev, vc);
+ if (r) {
+ DSSERR("bta sync failed\n");
+ return r;
+ }
}
/* RX_FIFO_NOT_EMPTY */
---
base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
change-id: 20260528-vm-upstr-c8e7634ebf56
Best regards,
--
Andreas Kemnade <akemnade@kernel.org>
next reply other threads:[~2026-05-28 10:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 10:16 akemnade [this message]
2026-05-28 14:44 ` [PATCH] drm/omap: dsi: avoid sending bta sync all the time in writes 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
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=20260528-vm-upstr-v1-1-fb93ef8cbe47@kernel.org \
--to=akemnade@kernel.org \
--cc=airlied@gmail.com \
--cc=andreas@kemnade.info \
--cc=dri-devel@lists.freedesktop.org \
--cc=hns@goldelico.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