| To: | Thomas Bogendoerfer <tsbogend@alpha.franken.de> |
|---|---|
| Subject: | Re: [REPOST PATCH] gbefb: cmap FIFO timeout |
| From: | Andrew Morton <akpm@linux-foundation.org> |
| Date: | Tue, 29 Jul 2008 17:37:45 -0700 |
| Cc: | linux-fbdev-devel@lists.sourceforge.net, linux-mips@linux-mips.org, adaplas@gmail.com |
| In-reply-to: | <20080729221204.25D97C2F34@solo.franken.de> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <20080729221204.25D97C2F34@solo.franken.de> |
| Sender: | linux-mips-bounce@linux-mips.org |
On Wed, 30 Jul 2008 00:12:04 +0200 (CEST)
Thomas Bogendoerfer <tsbogend@alpha.franken.de> wrote:
> +static void gbe_loadcmap(void)
> +{
> + int i, j;
> +
> + for (i = 0; i < 256; i++) {
> + for (j = 0; j < 1000 && gbe->cm_fifo >= 63; j++)
> + udelay(10);
> + if (j == 1000)
> + printk(KERN_ERR "gbefb: cmap FIFO timeout\n");
> +
> + gbe->cmap[i] = gbe_cmap[i];
> + }
> }
This is polling the hardware, yes?
I'd have thought there's a terrible risk of the compiler "optimising"
the read of gbe->cm_fifo. Shouldn't we be using readl() here?
<looks>
oh. It's declared volatile. ugh.
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [REPOST PATCH] gbefb: cmap FIFO timeout, Thomas Bogendoerfer |
|---|---|
| Next by Date: | Re: [PATCH v4 7/10] Alchemy: split core PM code from sysctl parts., Dmitri Vorobiev |
| Previous by Thread: | [REPOST PATCH] gbefb: cmap FIFO timeout, Thomas Bogendoerfer |
| Next by Thread: | Swarm IDE bug in 2.6.26., Kaz Kylheku |
| Indexes: | [Date] [Thread] [Top] [All Lists] |