From: James Simmons <hidden> Date: 2007-05-02 20:23:00
Hi Tony,
quoted
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.
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/
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.
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 -- geert@linux-m68k.org
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/
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-05-02 20:32:58
On Wed, 2007-05-02 at 21:22 +0100, James Simmons wrote:
quoted
Hi Tony,
quoted
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.
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.
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/
From: James Simmons <hidden> Date: 2007-05-02 20:55:38
quoted
quoted
Hi Tony,
quoted
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.
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
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/
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-05-02 21:08:23
On Wed, 2007-05-02 at 21:55 +0100, James Simmons wrote:
quoted
quoted
quoted
Hi Tony,
quoted
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.
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
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.
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/