[PATCH 17/41] fbdev: Add drawing functions for framebuffers in system RAM

Antonino A. Daplas

author

2007-04-25 07:41 UTC #0 lore raw

PATCH 17/41 fbdev: Add drawing functions for framebuffers in system RAM

The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect) assume that the framebuffer is in IO memory. However, we have 3 drivers (hecubafb, arcfb, and vfb) where the framebuffer is allocated from system RAM (via vmalloc). Using _raw_read/write and family for these drivers (as used in the cfb* functions) is illegal, especially in other platforms.

Create 3 new drawing functions, based almost entirely from the original except that the framebuffer memory is assumed to be in system RAM. These are named as sysimgblt, syscopyarea, and sysfillrect.

Signed-off-by Antonino Daplas <[email protected]>

---

 drivers/video/Kconfig       |   27 +++
 drivers/video/Makefile      |    3 
 drivers/video/syscopyarea.c |  388 ++++++++++++++++++++++++++++++++++++++++++
 drivers/video/sysfillrect.c |  400 +++++++++++++++++++++++++++++++++++++++++++
 drivers/video/sysimgblt.c   |  291 +++++++++++++++++++++++++++++++
 include/linux/fb.h          |    6 +
 6 files changed, 1115 insertions(+), 0 deletions(-)

drivers/video/Kconfig +27 -0

index 4f6ee88..234502d 100644
@@ -95,6 +95,33 @@ config FB_CFB_IMAGEBLIT
 	  blitting. This is used by drivers that don't provide their own
 	  (accelerated) version.
 
+config FB_SYS_FILLRECT
+	tristate
+	depends on FB
+	default n
+	---help---
+	  Include the sys_fillrect function for generic software rectangle
+	  filling. This is used by drivers that don't provide their own
+	  (accelerated) version and the framebuffer is in system RAM.
+
+config FB_SYS_COPYAREA
+	tristate
+	depends on FB
+	default n
+	---help---
+	  Include the sys_copyarea function for generic software area copying.
+	  This is used by drivers that don't provide their own (accelerated)
+	  version and the framebuffer is in system RAM.
+
+config FB_SYS_IMAGEBLIT
+	tristate
+	depends on FB
+	default n
+	---help---
+	  Include the sys_imageblit function for generic software image
+	  blitting. This is used by drivers that don't provide their own
+	  (accelerated) version and the framebuffer is in system RAM.
+
 config FB_DEFERRED_IO
 	bool
 	depends on FB

drivers/video/Makefile +3 -0

index 3ff0a70..a245cc7 100644
@@ -18,6 +18,9 @@ obj-y				  += backlight/ display/
 obj-$(CONFIG_FB_CFB_FILLRECT)  += cfbfillrect.o
 obj-$(CONFIG_FB_CFB_COPYAREA)  += cfbcopyarea.o
 obj-$(CONFIG_FB_CFB_IMAGEBLIT) += cfbimgblt.o
+obj-$(CONFIG_FB_SYS_FILLRECT)  += sysfillrect.o
+obj-$(CONFIG_FB_SYS_COPYAREA)  += syscopyarea.o
+obj-$(CONFIG_FB_SYS_IMAGEBLIT) += sysimgblt.o
 obj-$(CONFIG_FB_SVGALIB)       += svgalib.o
 obj-$(CONFIG_FB_MACMODES)      += macmodes.o
 obj-$(CONFIG_FB_DDC)           += fb_ddc.o

drivers/video/syscopyarea.c new file +388 -0

388 lines not on this page · raw message

drivers/video/sysfillrect.c new file +400 -0

400 lines not on this page · raw message

drivers/video/sysimgblt.c new file +291 -0

291 lines not on this page · raw message

include/linux/fb.h +6 -0

index 0de4260..c4e1b3d 100644
@@ -895,6 +895,12 @@ extern int fb_blank(struct fb_info *info
 extern void cfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect); 
 extern void cfb_copyarea(struct fb_info *info, const struct fb_copyarea *area); 
 extern void cfb_imageblit(struct fb_info *info, const struct fb_image *image);
+/*
+ * Drawing operations where framebuffer is in system RAM
+ */
+extern void sys_fillrect(struct fb_info *info, const struct fb_fillrect *rect);
+extern void sys_copyarea(struct fb_info *info, const struct fb_copyarea *area);
+extern void sys_imageblit(struct fb_info *info, const struct fb_image *image);
 
 /* drivers/video/fbmem.c */
 extern int register_framebuffer(struct fb_info *fb_info);

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

James Simmons

2007-05-02 20:23 UTC #2 lore raw

Re: [PATCH 17/41] fbdev: Add drawing functions forframebuffers in system RAM

Quoted 13 lines

Hi Tony,
Quoted 9 lines
The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect) assume
that the framebuffer is in IO memory. However, we have 3 drivers (hecubafb,
arcfb, and vfb) where the framebuffer is allocated from system RAM (via
vmalloc). Using _raw_read/write and family for these drivers (as used in
the cfb* functions) is illegal, especially in other platforms.

Quoted 2 lines

This is also true for ps3fb. I'll update the support for that once this patch has hit mainline.

Bloat. It would be much easier to replace the FB_WRITEL and FB_READL macros. Last year I was working on a general solution that I wanted to submit but I have been pushing other patches I considered higher priority. Perhaps I should move them up the que.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Geert Uytterhoeven

2007-05-02 20:31 UTC #3 lore raw

Re: [PATCH 17/41] fbdev: Add drawing functions forframebuffers in system RAM

Quoted 10 lines · James Simmons

Quoted 10 lines
Quoted 9 lines
The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect) assume
that the framebuffer is in IO memory. However, we have 3 drivers (hecubafb,
arcfb, and vfb) where the framebuffer is allocated from system RAM (via
vmalloc). Using _raw_read/write and family for these drivers (as used in
the cfb* functions) is illegal, especially in other platforms.

Quoted 7 lines

Quoted 2 lines
This is also true for ps3fb. I'll update the support for that once this patch has hit mainline.
Bloat. It would be much easier to replace the FB_WRITEL and FB_READL macros. Last year I was working on a general solution that I wanted to submit but I have been pushing other patches I considered higher priority. Perhaps I should move them up the que.

That's true: just replace those macros and recompile...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Antonino A. Daplas

author

2007-05-02 20:32 UTC #4 lore raw

Re: [PATCH 17/41] fbdev: Add drawing functions forframebuffers in system RAM

In reply to James Simmons

Quoted 12 lines · James Simmons

Quoted 12 lines
Hi Tony,
Quoted 9 lines
The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect) assume
that the framebuffer is in IO memory. However, we have 3 drivers (hecubafb,
arcfb, and vfb) where the framebuffer is allocated from system RAM (via
vmalloc). Using _raw_read/write and family for these drivers (as used in
the cfb* functions) is illegal, especially in other platforms.

Quoted 4 lines

Quoted 2 lines
This is also true for ps3fb. I'll update the support for that once this patch has hit mainline.
Bloat.

Only the source gets larger. Only drivers that need it will compile it.

Quoted 2 lines

It would be much easier to replace the FB_WRITEL and FB_READL
macros.

Of course it's not as simple as replacing FB_WRITEL and FB_READL. Think very carefully.

Hint1: #define FB_MAX 32
Hint2: sparse

Tony

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

James Simmons

2007-05-02 20:55 UTC #5 lore raw

Re: [PATCH 17/41] fbdev: Add drawing functions forframebuffers in system RAM

Quoted 20 lines

Quoted 13 lines
Quoted 13 lines
Hi Tony,
Quoted 9 lines
The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect) assume
that the framebuffer is in IO memory. However, we have 3 drivers (hecubafb,
arcfb, and vfb) where the framebuffer is allocated from system RAM (via
vmalloc). Using _raw_read/write and family for these drivers (as used in
the cfb* functions) is illegal, especially in other platforms.
Quoted 4 lines
Quoted 2 lines
This is also true for ps3fb. I'll update the support for that once this patch has hit mainline.
Bloat.
Only the source gets larger. Only drivers that need it will compile it.

Quoted 8 lines

Quoted 2 lines
It would be much easier to replace the FB_WRITEL and FB_READL
macros.
Of course it's not as simple as replacing FB_WRITEL and FB_READL. Think very carefully.
Hint1: #define FB_MAX 32
Hint2: sparse

Yeap. fbwrite/fbread are not flexable enough. The is way I put hooks into struct fb_pixmap for writing/reading the framebuffer.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Antonino A. Daplas

author

2007-05-02 21:08 UTC #6 lore raw

Re: [PATCH 17/41] fbdev: Add drawing functions forframebuffers in system RAM

Quoted 22 lines · James Simmons

Quoted 22 lines
Quoted 12 lines
Quoted 12 lines
Hi Tony,
Quoted 9 lines
The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect) assume
that the framebuffer is in IO memory. However, we have 3 drivers (hecubafb,
arcfb, and vfb) where the framebuffer is allocated from system RAM (via
vmalloc). Using _raw_read/write and family for these drivers (as used in
the cfb* functions) is illegal, especially in other platforms.
Quoted 4 lines
Quoted 2 lines
This is also true for ps3fb. I'll update the support for that once this patch has hit mainline.
Bloat.
Only the source gets larger. Only drivers that need it will compile it.
Quoted 2 lines
It would be much easier to replace the FB_WRITEL and FB_READL
macros.

Quoted 8 lines

Quoted 5 lines
Of course it's not as simple as replacing FB_WRITEL and FB_READL. Think very carefully.
Hint1: #define FB_MAX 32
Hint2: sparse
Yeap. fbwrite/fbread are not flexable enough. The is way I put hooks into struct fb_pixmap for writing/reading the framebuffer.

I did try that too, but the drawing functions are part of the innermost loop, in an extremely hot path. Replacing those macros with function pointers will drop the performance considerably. Remember the memcpy/for-loop replacement? The speed degradation was significant and it's not even in the hottest path.

Secondly, how would you reconcile sparse annotations?

Tony

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/