linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	linux-fbdev-devel@lists.sourceforge.net
Cc: adaplas@gmail.com, hskinnemoen@atmel.com, linux@maxim.org.za,
	linux-kernel@vger.kernel.org
Subject: [PATCH] atmel_lcdfb: FIFO underflow management rework
Date: Tue, 20 May 2008 15:54:15 +0200	[thread overview]
Message-ID: <4832D807.7000703@atmel.com> (raw)
In-Reply-To: <20080519160006.12a30e71.akpm@linux-foundation.org>

Manage atmel_lcdfb FIFO underflow rework

Resetting the LCD and DMA allows to fix screen shifting after 
a FIFO underflow. It follows reset sequence from errata
"LCD Screen Shifting After a Reset".

Reworked following Andrew Morton comments.

Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---

Andrew Morton :
> On Fri, 16 May 2008 14:34:12 +0200
> Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> 
>> Manage atmel_lcdfb FIFO underflow
>>
>> Resetting the LCD and DMA allows to fix screen shifting after a 
>> FIFO underflow. It follows reset sequence from errata 
>> "LCD Screen Shifting After a Reset".
>>
> 
> This looks like 2.6.26-worthy bugfix to me?  But as commonly happens,
> that isn't terribly clear.

This error may append in latency sensitive cases : slow clock, 
matrix slot cycle bad configuration, too high pixel clock...

>> +	if (status & ATMEL_LCDC_UFLWI) {
>> +		dev_warn(info->device, "FIFO underflow %#x\n", status);
>> +		/* reset DMA and FIFO to avoid screen shifting */
>> +		schedule_work(&sinfo->task);
>> +	}
>> +	lcdc_writel(sinfo, ATMEL_LCDC_ICR, status);
>>  	return IRQ_HANDLED;
>>  }
> 
> Shouldn't there be a cancel_work_sync() in atmel_lcdfb_exit()?

Ok incremental patch follows. Tell me if you prefer that I send 
a reworked one.

I also added  might_sleep() annotation functions.

>> +	/* Initialize bottom half workqueue */
> 
> Well.  "bottom half" is an ancient term for softirqs, not for the
> new-fangled process-context callbacks.

Ok, I try to adapt this comment in the reworked patch.


Index: drivers/video/atmel_lcdfb.c
===================================================================
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -361,6 +361,8 @@ static int atmel_lcdfb_check_var(struct 
  */
 static void atmel_lcdfb_reset(struct atmel_lcdfb_info *sinfo)
 {
+	might_sleep();
+
 	/* LCD power off */
 	lcdc_writel(sinfo, ATMEL_LCDC_PWRCON, sinfo->guard_time << ATMEL_LCDC_GUARDT_OFFSET);
 
@@ -405,6 +407,8 @@ static int atmel_lcdfb_set_par(struct fb
 	unsigned long clk_value_khz;
 	unsigned long bits_per_line;
 
+	might_sleep();
+
 	dev_dbg(info->device, "%s:\n", __func__);
 	dev_dbg(info->device, "  * resolution: %ux%u (%ux%u virtual)\n",
 		 info->var.xres, info->var.yres,
@@ -840,7 +844,8 @@ static int __init atmel_lcdfb_probe(stru
 		goto unmap_mmio;
 	}
 
-	/* Initialize bottom half workqueue */
+	/* Some operations on the LCDC might sleep and 
+	 * require a preemptible task context */
 	INIT_WORK(&sinfo->task, atmel_lcdfb_task);
 
 	ret = atmel_lcdfb_init_fbinfo(sinfo);
@@ -885,6 +890,7 @@ static int __init atmel_lcdfb_probe(stru
 free_cmap:
 	fb_dealloc_cmap(&info->cmap);
 unregister_irqs:
+	cancel_work_sync(&sinfo->task);
 	free_irq(sinfo->irq_base, info);
 unmap_mmio:
 	exit_backlight(sinfo);
@@ -922,6 +928,7 @@ static int __exit atmel_lcdfb_remove(str
 	if (!sinfo)
 		return 0;
 
+	cancel_work_sync(&sinfo->task);
 	exit_backlight(sinfo);
 	if (sinfo->atmel_lcdfb_power_control)
 		sinfo->atmel_lcdfb_power_control(0);

      reply	other threads:[~2008-05-20 13:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-16 12:34 [PATCH] atmel_lcdfb: FIFO underflow management Nicolas Ferre
2008-05-19 23:00 ` Andrew Morton
2008-05-20 13:54   ` Nicolas Ferre [this message]

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=4832D807.7000703@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --cc=adaplas@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hskinnemoen@atmel.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@maxim.org.za \
    /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).