linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: James Simmons <jsimmons@infradead.org>
Cc: Richard Henderson <rth@twiddle.net>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [FB PATCH] cfbimgblt isn't 64-bit clean
Date: 29 Dec 2002 22:58:43 +0800	[thread overview]
Message-ID: <1041173861.1013.9.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44.0212290027590.14098-100000@phoenix.infradead.org>

On Sun, 2002-12-29 at 09:16, James Simmons wrote:
> 
> > The text is written as if it's thinking about handling 64-bit
> > unsigned long, but it doesn't.  The tables that map bits to
> > pixels are completely unprepared for this.
> > 
> > I thought about widening the tables, but I thought they'd get
> > unreasonably large.  There's no reason not to go ahead and 
> > handle this 32-bits at a time.
> 
> I thought the tables would come back to haunt us. The only reason the 
> tables where introduced was for speed enhancements. I reason the code is 
> extra complex was so you could pass 64 bits of data across the bus. I 
> still like to see that happen still. What do you think?
> 

Only fast_imageblit() should be affected.  color_imageblit() and
slow_imageblit() will not be affected.  

fast_imageblit() is used only for 8, 16 and 32 bpp.  We can remove
fast_imageblit() and just use slow_imageblit() for all color depths, but
it will suffer a significant slowdown. 

Or we can change fast_imageblit() to always access the framebuffer
memory 32-bits at a time. The attached patch should fix this.

Tony

diff -Naur linux-2.5.42/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.42/drivers/video/cfbimgblt.c	2002-12-29 14:44:04.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2002-12-29 14:44:23.000000000 +0000
@@ -88,11 +88,13 @@
 
 #if defined (__BIG_ENDIAN)
 #define LEFT_POS(bpp)          (BITS_PER_LONG - bpp)
+#define LEFT_POS32(bpp)        (32 - bpp)
 #define NEXT_POS(pos, bpp)     ((pos) -= (bpp))
 #define SHIFT_HIGH(val, bits)  ((val) >> (bits))
 #define SHIFT_LOW(val, bits)   ((val) << (bits))
 #else
 #define LEFT_POS(bpp)          (0)
+#define LEFT_POS32(bpp)        (0)
 #define NEXT_POS(pos, bpp)     ((pos) += (bpp))
 #define SHIFT_HIGH(val, bits)  ((val) << (bits))
 #define SHIFT_LOW(val, bits)   ((val) >> (bits))
@@ -223,25 +225,25 @@
 }
 
 static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1, 
-				  unsigned long fgcolor, unsigned long bgcolor) 
+				  u32 fgcolor, u32 bgcolor) 
 {
 	int i, j, k, l = 8, n;
-	unsigned long bit_mask, end_mask, eorx; 
-	unsigned long fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
-	unsigned long tmp = (1 << bpp) - 1;
-	unsigned long ppw = BITS_PER_LONG/bpp, ppos;
-	unsigned long *dst;
+	u32 bit_mask, end_mask, eorx; 
+	u32 fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
+	u32 tmp = (1 << bpp) - 1;
+	u32 ppw = 32/bpp, ppos;
+	u32 *dst;
 	u32 *tab = NULL;
 	char *src = image->data;
 		
-	switch (ppw) {
-	case 4:
+	switch (bpp) {
+	case 8:
 		tab = cfb_tab8;
 		break;
-	case 2:
+	case 16:
 		tab = cfb_tab16;
 		break;
-	case 1:
+	case 32:
 		tab = cfb_tab32;
 		break;
 	}
@@ -263,17 +265,17 @@
 	k = image->width/ppw;
 
 	for (i = image->height; i--; ) {
-		dst = (unsigned long *) dst1;
+		dst = (u32 *) dst1;
 		
 		for (j = k; j--; ) {
 			l -= ppw;
 			end_mask = tab[(*src >> l) & bit_mask]; 
-			FB_WRITEL((end_mask & eorx)^bgx, dst++);
+			fb_writel((end_mask & eorx)^bgx, dst++);
 			if (!l) { l = 8; src++; }
 		}
 		if (n) {
 			end_mask = 0;	
-			ppos = LEFT_POS(bpp);
+			ppos = LEFT_POS32(bpp);
 			for (j = n; j > 0; j--) {
 				l--;
 				if (*src & (1 << l))
@@ -281,7 +283,7 @@
 				NEXT_POS(ppos, bpp);
 				if (!l) { l = 8; src++; }
 			}
-			FB_WRITEL((end_mask & eorx)^bgx, dst++);
+			fb_writel((end_mask & eorx)^bgx, dst++);
 		}
 		l -= pad;		
 		dst1 += p->fix.line_length;	
@@ -337,7 +339,7 @@
 		
 		if (BITS_PER_LONG % bpp == 0 && !start_index && !pitch_index && 
 		    bpp >= 8 && bpp <= 32 && (image->width & 7) == 0) 
-			fast_imageblit(image, p, dst1, fgcolor, bgcolor);
+			fast_imageblit(image, p, dst1, (u32) fgcolor, (u32) bgcolor);
 		else 
 			slow_imageblit(image, p, dst1, fgcolor, bgcolor, start_index, pitch_index);
 	}



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

  reply	other threads:[~2002-12-29 15:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-27 23:18 [FB PATCH] cfbimgblt isn't 64-bit clean Richard Henderson
2002-12-29  1:16 ` [Linux-fbdev-devel] " James Simmons
2002-12-29 14:58   ` Antonino Daplas [this message]
2002-12-31  9:33     ` Richard Henderson

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=1041173861.1013.9.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rth@twiddle.net \
    /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).