linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-fbdev@vger.kernel.org, linux-omap@vger.kernel.org
Cc: archit@ti.com, Tomi Valkeinen <tomi.valkeinen@ti.com>
Subject: [PATCH 12/13] OMAPDSS: DSI: improve wait_for_bit_change
Date: Thu, 24 Nov 2011 13:29:40 +0000	[thread overview]
Message-ID: <1322141381-5395-13-git-send-email-tomi.valkeinen@ti.com> (raw)
In-Reply-To: <1322141381-5395-1-git-send-email-tomi.valkeinen@ti.com>

We sometimes get timeout when disabling the DSI interface with video
mode. It looks like the disable will stall until the current frame has
been finished, and this can take multiple milliseconds.

wait_for_bit_change() currently uses a busyloop to wait for a bit to
change. This is used in multiple places. The problem is, we don't have
clear understanding how long particular operations can take, so the
function needs to support longer waits.

Improve wait_for_bit_change() to first busy loop for 100 times to see if
the bit changes almost right away. If the bit hasn't changed, move to a
loop with a sleep of 1ms, and poll for 500ms.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
 drivers/video/omap2/dss/dsi.c |   25 ++++++++++++++++++++-----
 1 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 22055db..a01a011 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -418,14 +418,29 @@ static void dsi_completion_handler(void *data, u32 mask)
 static inline int wait_for_bit_change(struct platform_device *dsidev,
 		const struct dsi_reg idx, int bitnum, int value)
 {
-	int t = 100000;
+	unsigned long timeout;
+	ktime_t wait;
+	int t;
+
+	/* first busyloop to see if the bit changes right away */
+	t = 100;
+	while (t-- > 0) {
+		if (REG_GET(dsidev, idx, bitnum, bitnum) = value)
+			return value;
+	}
+
+	/* then loop for 500ms, sleeping for 1ms in between */
+	timeout = jiffies + msecs_to_jiffies(500);
+	while (time_before(jiffies, timeout)) {
+		if (REG_GET(dsidev, idx, bitnum, bitnum) = value)
+			return value;
 
-	while (REG_GET(dsidev, idx, bitnum, bitnum) != value) {
-		if (--t = 0)
-			return !value;
+		wait = ns_to_ktime(1000 * 1000);
+		set_current_state(TASK_UNINTERRUPTIBLE);
+		schedule_hrtimeout(&wait, HRTIMER_MODE_REL);
 	}
 
-	return value;
+	return !value;
 }
 
 u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
-- 
1.7.4.1


  parent reply	other threads:[~2011-11-24 13:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-24 13:29 [PATCH 00/13] OMAPDSS: DSI fixes Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 01/13] OMAPDSS: DSI: flush posted write when entering ULPS Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 02/13] OMAPDSS: DSI: flush posted write in send_bta Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 03/13] OMAPDSS: DISPC: Flush posted writes when enabling outputs Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 04/13] OMAPDSS: DSI: count with number of lanes Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 05/13] OMAPDSS: DSI: Parse lane config Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 06/13] OMAPDSS: DSI: Use new lane config in dsi_set_lane_config Tomi Valkeinen
2011-11-28  9:08   ` [PATCH 06/13] OMAPDSS: DSI: Use new lane config in Carlos Chinea
2011-11-28 15:43     ` Tomi Valkeinen
2011-11-29  9:09       ` Carlos Chinea
2011-11-24 13:29 ` [PATCH 07/13] OMAPDSS: DSI: use lane config in dsi_get_lane_mask Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 08/13] OMAPDSS: DSI: use lane config in dsi_cio_wait_tx_clk_esc_reset Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 09/13] OMAPDSS: DSI: use lane config in dsi_cio_enable_lane_override Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 10/13] OMAPDSS: DSI: remove dsi_get_num_lanes_used Tomi Valkeinen
2011-11-24 13:29 ` [PATCH 11/13] OMAPDSS: DSI: fix lane handling when entering ULPS Tomi Valkeinen
2011-11-24 13:29 ` Tomi Valkeinen [this message]
2011-11-24 13:29 ` [PATCH 13/13] OMAPDSS: DSI: disable DDR_CLK_ALWAYS_ON " Tomi Valkeinen

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=1322141381-5395-13-git-send-email-tomi.valkeinen@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=archit@ti.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).