* [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way)
@ 2004-05-12 23:45 David Eger
2004-05-12 23:47 ` [PATCH 1/3] fb accel capabilities (radeonfb copyarea() fix) David Eger
2004-05-13 11:15 ` [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way) Geert Uytterhoeven
0 siblings, 2 replies; 9+ messages in thread
From: David Eger @ 2004-05-12 23:45 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, jsimmons; +Cc: Benjamin Herrenschmidt
I fleshed out Geert's idea from the last radeonfb thread on bringing
fbcon's interaction with the underlying framebuffer drivers up-to-date.
Now fbcon should be smart and actually *use* fb-driver provided accel
functions ;-)
Specifically, I've added a .hwaccel field to fb_fix_screeninfo, which
should serve as the way framebuffers pass hints to higher layers.
This should totally obsolete the accel_flags in var (which till now has
had one half-heartedly used value FB_ACCELF_TEXT).
The patches that follow are:
1) my radeonfb copyarea() fix. this is already in -mm.
2) James's fbcon init cleanup, modified for benh's tree.
3) my fb-accel-capabilities patch
When I boot with this, I have a nice accelerated framebuffer, huzzah.
This *shouldn't* break anyone's setup. Please, test this patch!
Look good? Comments?
Still not done:
- get rid of old comments in include/linux/fb.h
- get rid of all old references to useless var.accel_flags
- update other drivers to indicate if they have fast accel() funcs
-dte
---
getting bounce messages from me? let me know and you'll go on my whitelist
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 1/3] fb accel capabilities (radeonfb copyarea() fix)
2004-05-12 23:45 [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way) David Eger
@ 2004-05-12 23:47 ` David Eger
2004-05-12 23:49 ` [PATCH 2/3] fb accel capabilities (james' fbcon init cleanup) David Eger
2004-05-12 23:50 ` [PATCH 3/3] fb accel capabilities (the main patch) David Eger
2004-05-13 11:15 ` [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way) Geert Uytterhoeven
1 sibling, 2 replies; 9+ messages in thread
From: David Eger @ 2004-05-12 23:47 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, jsimmons; +Cc: Benjamin Herrenschmidt
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/05/12 14:19:47+02:00 eger@rosencrantz.theboonies.us
# radeonfb bug fix: screen corruption when copyarea() gets overlapping rectangles
#
# drivers/video/aty/radeon_accel.c
# 2004/05/12 14:15:32+02:00 eger@rosencrantz.theboonies.us +17 -4
# radeonfb bug fix: screen corruption when copyarea() gets overlapping rectangles
#
diff -Nru a/drivers/video/aty/radeon_accel.c b/drivers/video/aty/radeon_accel.c
--- a/drivers/video/aty/radeon_accel.c Wed May 12 15:51:32 2004
+++ b/drivers/video/aty/radeon_accel.c Wed May 12 15:51:32 2004
@@ -53,6 +53,18 @@
static void radeonfb_prim_copyarea(struct radeonfb_info *rinfo,
const struct fb_copyarea *area)
{
+ int xdir, ydir;
+ u32 sx, sy, dx, dy, w, h;
+
+ w = area->width; h = area->height;
+ dx = area->dx; dy = area->dy;
+ sx = area->sx; sy = area->sy;
+ xdir = sx - dx;
+ ydir = sy - dy;
+
+ if ( xdir < 0 ) { sx += w-1; dx += w-1; }
+ if ( ydir < 0 ) { sy += h-1; dy += h-1; }
+
radeon_fifo_wait(3);
OUTREG(DP_GUI_MASTER_CNTL,
rinfo->dp_gui_master_cntl /* i.e. GMC_DST_32BPP */
@@ -60,12 +72,13 @@
| ROP3_S
| DP_SRC_RECT );
OUTREG(DP_WRITE_MSK, 0xffffffff);
- OUTREG(DP_CNTL, (DST_X_LEFT_TO_RIGHT | DST_Y_TOP_TO_BOTTOM));
+ OUTREG(DP_CNTL, (xdir>=0 ? DST_X_LEFT_TO_RIGHT : 0)
+ | (ydir>=0 ? DST_Y_TOP_TO_BOTTOM : 0));
radeon_fifo_wait(3);
- OUTREG(SRC_Y_X, (area->sy << 16) | area->sx);
- OUTREG(DST_Y_X, (area->dy << 16) | area->dx);
- OUTREG(DST_HEIGHT_WIDTH, (area->height << 16) | area->width);
+ OUTREG(SRC_Y_X, (sy << 16) | sx);
+ OUTREG(DST_Y_X, (dy << 16) | dx);
+ OUTREG(DST_HEIGHT_WIDTH, (h << 16) | w);
}
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 2/3] fb accel capabilities (james' fbcon init cleanup)
2004-05-12 23:47 ` [PATCH 1/3] fb accel capabilities (radeonfb copyarea() fix) David Eger
@ 2004-05-12 23:49 ` David Eger
2004-05-12 23:50 ` [PATCH 3/3] fb accel capabilities (the main patch) David Eger
1 sibling, 0 replies; 9+ messages in thread
From: David Eger @ 2004-05-12 23:49 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, jsimmons; +Cc: Benjamin Herrenschmidt
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/05/12 14:43:14+02:00 eger@rosencrantz.theboonies.us
# fbcon init sequence cleanup (James Simmon / May 2004)
#
# drivers/video/fbmem.c
# 2004/05/12 14:42:59+02:00 eger@rosencrantz.theboonies.us +2 -2
# fbcon init cleanup
#
# drivers/video/console/fbcon.h
# 2004/05/12 14:42:59+02:00 eger@rosencrantz.theboonies.us +1 -1
# fbcon init cleanup
#
# drivers/video/console/fbcon.c
# 2004/05/12 14:42:59+02:00 eger@rosencrantz.theboonies.us +22 -35
# fbcon init cleanup:
# factor out retrieving the vc_data from the fbcon_event_notify path
# remove fbcon_event_notifier_registered cruft
#
diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
--- a/drivers/video/console/fbcon.c Wed May 12 15:51:14 2004
+++ b/drivers/video/console/fbcon.c Wed May 12 15:51:14 2004
@@ -296,15 +296,17 @@
* Maps a virtual console @unit to a frame buffer device
* @newidx.
*/
-int set_con2fb_map(int unit, int newidx)
+int set_con2fb_map(int start, int end, int newidx)
{
- struct vc_data *vc = vc_cons[unit].d;
+ struct vc_data *vc = vc_cons[start].d;
+ int i;
if (!vc)
return -ENODEV;
- con2fb_map[unit] = newidx;
+ for (i = start; i < end; i++)
+ con2fb_map[i] = newidx;
fbcon_is_default = (vc->vc_sw == &fb_con) ? 1 : 0;
- take_over_console(&fb_con, unit, unit, fbcon_is_default);
+ take_over_console(&fb_con, start, end, fbcon_is_default);
return 0;
}
@@ -2235,33 +2237,21 @@
return 0;
}
-static void fbcon_suspended(struct fb_info *info)
+static void fbcon_suspended(struct fb_info *info, struct vc_data *vc)
{
/* Clear cursor, restore saved data */
- info->cursor.enable = 0;
- info->fbops->fb_cursor(info, &info->cursor);
+ fbcon_cursor(vc, CM_ERASE);
}
-static void fbcon_resumed(struct fb_info *info)
+static void fbcon_resumed(struct fb_info *info, struct vc_data *vc)
{
- struct vc_data *vc;
-
- if (info->currcon < 0)
- return;
- vc = vc_cons[info->currcon].d;
-
update_screen(vc->vc_num);
}
-static void fbcon_mode_changed(struct fb_info *info)
+static void fbcon_mode_changed(struct fb_info *info, struct vc_data *vc)
{
- struct vc_data *vc;
int rows, cols;
- if (info->currcon < 0)
- return;
- vc = vc_cons[info->currcon].d;
-
/* This isn't perfect yet. If we change one console, we
* don't change them all and we switch back to the wrong
* mode on next console switch. We need to either keep a
@@ -2291,16 +2281,21 @@
unsigned long action, void *data)
{
struct fb_info *info = (struct fb_info *) data;
+ struct vc_data *vc;
+
+ if (info->currcon < 0)
+ return 0;
+ vc = vc_cons[info->currcon].d;
switch(action) {
case FB_EVENT_MODE_CHANGE:
- fbcon_mode_changed(info);
+ fbcon_mode_changed(info, vc);
break;
case FB_EVENT_SUSPEND:
- fbcon_suspended(info);
+ fbcon_suspended(info, vc);
break;
case FB_EVENT_RESUME:
- fbcon_resumed(info);
+ fbcon_resumed(info, vc);
break;
}
return 0;
@@ -2336,20 +2331,15 @@
.notifier_call = fbcon_event_notify,
};
-static int fbcon_event_notifier_registered;
-
int __init fb_console_init(void)
{
+ acquire_console_sem();
+ fb_register_client(&fbcon_event_notifer);
+ release_console_sem();
+
if (!num_registered_fb)
return -ENODEV;
-
take_over_console(&fb_con, first_fb_vc, last_fb_vc, fbcon_is_default);
- acquire_console_sem();
- if (!fbcon_event_notifier_registered) {
- fb_register_client(&fbcon_event_notifer);
- fbcon_event_notifier_registered = 1;
- }
- release_console_sem();
return 0;
}
@@ -2358,10 +2348,7 @@
void __exit fb_console_exit(void)
{
acquire_console_sem();
- if (fbcon_event_notifier_registered) {
- fb_unregister_client(&fbcon_event_notifer);
- fbcon_event_notifier_registered = 0;
- }
+ fb_unregister_client(&fbcon_event_notifer);
release_console_sem();
give_up_console(&fb_con);
}
diff -Nru a/drivers/video/console/fbcon.h b/drivers/video/console/fbcon.h
--- a/drivers/video/console/fbcon.h Wed May 12 15:51:14 2004
+++ b/drivers/video/console/fbcon.h Wed May 12 15:51:14 2004
@@ -38,7 +38,7 @@
/* drivers/video/console/fbcon.c */
extern char con2fb_map[MAX_NR_CONSOLES];
-extern int set_con2fb_map(int unit, int newidx);
+extern int set_con2fb_map(int start, int end, int newidx);
/*
* Attribute Decoding
diff -Nru a/drivers/video/fbmem.c b/drivers/video/fbmem.c
--- a/drivers/video/fbmem.c Wed May 12 15:51:14 2004
+++ b/drivers/video/fbmem.c Wed May 12 15:51:14 2004
@@ -1108,9 +1108,9 @@
if (!registered_fb[con2fb.framebuffer])
return -EINVAL;
if (con2fb.console != 0)
- set_con2fb_map(con2fb.console-1, con2fb.framebuffer);
+ set_con2fb_map(con2fb.console-1, con2fb.console-1, con2fb.framebuffer);
else
- fb_console_init();
+ set_con2fb_map(0, MAX_NR_CONSOLES, con2fb.framebuffer);
return 0;
#endif /* CONFIG_FRAMEBUFFER_CONSOLE */
case FBIOBLANK:
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 3/3] fb accel capabilities (the main patch)
2004-05-12 23:47 ` [PATCH 1/3] fb accel capabilities (radeonfb copyarea() fix) David Eger
2004-05-12 23:49 ` [PATCH 2/3] fb accel capabilities (james' fbcon init cleanup) David Eger
@ 2004-05-12 23:50 ` David Eger
2004-05-13 11:39 ` [PATCH 4/3] fb accel capabilities (more fb.h flags) David Eger
2004-05-13 11:39 ` [PATCH 5/3] fb accel capabilities (aty/aty*, aty/mach64*) David Eger
1 sibling, 2 replies; 9+ messages in thread
From: David Eger @ 2004-05-12 23:50 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, jsimmons; +Cc: Benjamin Herrenschmidt
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/05/13 00:13:46+02:00 eger@rosencrantz.theboonies.us
# Tell fbcon to read hints about hardware capabilities given by framebuffer devices
#
# include/linux/fb.h
# 2004/05/13 00:13:25+02:00 eger@rosencrantz.theboonies.us +7 -2
# fb_fix_screeninfo change - now we have accel hints to say which
# accel functions are actually hw supported.
#
# drivers/video/console/fbcon.h
# 2004/05/13 00:13:25+02:00 eger@rosencrantz.theboonies.us +4 -5
# rework console accel hints to be sane
#
# drivers/video/console/fbcon.c
# 2004/05/13 00:13:24+02:00 eger@rosencrantz.theboonies.us +18 -13
# fix broken divides() logic
# rework fbcon to work from accel hints given by fb's
#
# drivers/video/aty/radeon_base.c
# 2004/05/13 00:13:24+02:00 eger@rosencrantz.theboonies.us +1 -9
# update radeonfb for new acceleration hint semantics
#
diff -Nru a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
--- a/drivers/video/aty/radeon_base.c Thu May 13 00:18:35 2004
+++ b/drivers/video/aty/radeon_base.c Thu May 13 00:18:35 2004
@@ -1798,17 +1798,9 @@
info->fix.type_aux = 0;
info->fix.mmio_start = rinfo->mmio_base_phys;
info->fix.mmio_len = RADEON_REGSIZE;
- if (radeon_accel_disabled())
- info->fix.accel = FB_ACCEL_NONE;
- else
- info->fix.accel = FB_ACCEL_ATI_RADEON;
+ info->fix.hwaccel = FB_HWACCEL_COPYAREA | FB_HWACCEL_FILLRECT;
fb_alloc_cmap(&info->cmap, 256, 0);
-
- if (radeon_accel_disabled())
- info->var.accel_flags &= ~FB_ACCELF_TEXT;
- else
- info->var.accel_flags |= FB_ACCELF_TEXT;
return 0;
}
diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
--- a/drivers/video/console/fbcon.c Thu May 13 00:18:35 2004
+++ b/drivers/video/console/fbcon.c Thu May 13 00:18:35 2004
@@ -140,7 +140,7 @@
static int vbl_cursor_cnt;
-#define divides(a, b) ((!(a) || (b)%(a)) ? 0 : 1)
+#define divides(a, b) ((a && (b)%(a)) ? 0 : 1)
/*
* Interface used by the world
@@ -607,8 +607,10 @@
/* on which frame buffer will we open this console? */
info = registered_fb[(int) con2fb_map[unit]];
- if (info->var.accel_flags)
- fb_display[unit].scrollmode = SCROLL_YNOMOVE;
+ if (info->fix.hwaccel & FB_HWACCEL_COPYAREA)
+ fb_display[unit].scrollmode = SCROLL_YACCEL;
+ else if (info->var.accel_flags)
+ fb_display[unit].scrollmode = SCROLL_YPANWRAP;
else
fb_display[unit].scrollmode = SCROLL_YREDRAW;
fbcon_set_display(vc, init, !init);
@@ -624,20 +626,23 @@
static __inline__ void updatescrollmode(struct display *p, struct vc_data *vc)
{
struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
-
int m;
- if (p->scrollmode & __SCROLL_YFIXED)
- return;
+
+ switch (p->scrollmode & __SCROLL_YMASK) {
+ case __SCROLL_YACCEL:
+ case __SCROLL_YREDRAW:
+ return;
+ }
+
+ /* assume we should do wrap/pan if we can */
if (divides(info->fix.ywrapstep, vc->vc_font.height) &&
- divides(vc->vc_font.height, info->var.yres_virtual))
+ divides(vc->vc_font.height, info->var.yres_virtual))
m = __SCROLL_YWRAP;
else if (divides(info->fix.ypanstep, vc->vc_font.height) &&
info->var.yres_virtual >= info->var.yres + vc->vc_font.height)
m = __SCROLL_YPAN;
- else if (p->scrollmode & __SCROLL_YNOMOVE)
+ else
m = __SCROLL_YREDRAW;
- else
- m = __SCROLL_YMOVE;
p->scrollmode = (p->scrollmode & ~__SCROLL_YMASK) | m;
}
@@ -1364,7 +1369,7 @@
if (logo_shown >= 0)
goto redraw_up;
switch (p->scrollmode & __SCROLL_YMASK) {
- case __SCROLL_YMOVE:
+ case __SCROLL_YACCEL:
accel_bmove(vc, info, t + count, 0, t, 0,
b - t - count, vc->vc_cols);
accel_clear(vc, info, b - count, 0, count,
@@ -1431,7 +1436,7 @@
if (count > vc->vc_rows) /* Maximum realistic size */
count = vc->vc_rows;
switch (p->scrollmode & __SCROLL_YMASK) {
- case __SCROLL_YMOVE:
+ case __SCROLL_YACCEL:
accel_bmove(vc, info, t, 0, t + count, 0,
b - t - count, vc->vc_cols);
accel_clear(vc, info, t, 0, count, vc->vc_cols);
iff -Nru a/drivers/video/console/fbcon.h b/drivers/video/console/fbcon.h
--- a/drivers/video/console/fbcon.h Thu May 13 00:18:35 2004
+++ b/drivers/video/console/fbcon.h Thu May 13 00:18:35 2004
@@ -71,11 +71,9 @@
/* Internal flags */
#define __SCROLL_YPAN 0x001
#define __SCROLL_YWRAP 0x002
-#define __SCROLL_YMOVE 0x003
+#define __SCROLL_YACCEL 0x003
#define __SCROLL_YREDRAW 0x004
#define __SCROLL_YMASK 0x00f
-#define __SCROLL_YFIXED 0x010
-#define __SCROLL_YNOMOVE 0x020
#define __SCROLL_YPANREDRAW 0x040
#define __SCROLL_YNOPARTIAL 0x080
@@ -92,8 +90,9 @@
with every line covering all screen columns, it would not be the right
benchmark).
*/
-#define SCROLL_YREDRAW (__SCROLL_YFIXED|__SCROLL_YREDRAW)
-#define SCROLL_YNOMOVE (__SCROLL_YNOMOVE|__SCROLL_YPANREDRAW)
+#define SCROLL_YACCEL (__SCROLL_YACCEL)
+#define SCROLL_YPANWRAP (__SCROLL_YPANREDRAW)
+#define SCROLL_YREDRAW (__SCROLL_YREDRAW)
/* SCROLL_YNOPARTIAL, used in combination with the above, is for video
cards which can not handle using panning to scroll a portion of the
diff -Nru a/include/linux/fb.h b/include/linux/fb.h
--- a/include/linux/fb.h Thu May 13 00:18:35 2004
+++ b/include/linux/fb.h Thu May 13 00:18:35 2004
@@ -109,6 +109,9 @@
#define FB_ACCEL_NEOMAGIC_NM2360 97 /* NeoMagic NM2360 */
#define FB_ACCEL_NEOMAGIC_NM2380 98 /* NeoMagic NM2380 */
+#define FB_HWACCEL_COPYAREA 0x0001
+#define FB_HWACCEL_FILLRECT 0x0002
+#define FB_HWACCEL_ROTATE 0x0004
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
@@ -125,8 +128,10 @@
unsigned long mmio_start; /* Start of Memory Mapped I/O */
/* (physical address) */
__u32 mmio_len; /* Length of Memory Mapped I/O */
- __u32 accel; /* Type of acceleration available */
- __u16 reserved[3]; /* Reserved for future compatibility */
+ __u32 accel; /* Indicate to driver which */
+ /* specific chip/card we have */
+ __u16 hwaccel; /* Which accel ops are hw-supported? */
+ __u16 reserved[2]; /* Reserved for future compatibility */
};
/* Interpretation of offset for color fields: All offsets are from the right,
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way)
2004-05-12 23:45 [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way) David Eger
2004-05-12 23:47 ` [PATCH 1/3] fb accel capabilities (radeonfb copyarea() fix) David Eger
@ 2004-05-13 11:15 ` Geert Uytterhoeven
2004-05-13 12:26 ` David Eger
2004-05-13 22:52 ` Benjamin Herrenschmidt
1 sibling, 2 replies; 9+ messages in thread
From: Geert Uytterhoeven @ 2004-05-13 11:15 UTC (permalink / raw)
To: David Eger
Cc: Linux Frame Buffer Device Development, James Simmons,
Benjamin Herrenschmidt
On Thu, 13 May 2004, David Eger wrote:
> I fleshed out Geert's idea from the last radeonfb thread on bringing
> fbcon's interaction with the underlying framebuffer drivers up-to-date.
> Now fbcon should be smart and actually *use* fb-driver provided accel
> functions ;-)
Nice!
> Specifically, I've added a .hwaccel field to fb_fix_screeninfo, which
> should serve as the way framebuffers pass hints to higher layers.
I think we agreed to put it in fb_info instead, since it doesn't really matter
for user space.
> This should totally obsolete the accel_flags in var (which till now has
> had one half-heartedly used value FB_ACCELF_TEXT).
Well, we still need a way to know when the fbdev has to reinitialize its accel
engine, when switching the console from graphics mode (user space does accel)
to text mode (kernel uses accel). Currently this is done when FB_ACCELF_TEXT is
set.
BTW, we've been talking about allowing kernel messages (mainly oops and panic)
to show up under X. Since we cannot use the accel engine for that, perhaps we
need different routines for fb_{fillrect,copyarea,imageblit}() for the
accelerated vs. non-accelerated cases? And fbcon could compare the function
pointers, instead of looking at .hwaccel.
(Yes, I know it's still possible to lock up your card when using unaccelerated
drawing while an accelerated operation is in progress on some cards).
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: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 4/3] fb accel capabilities (more fb.h flags)
2004-05-12 23:50 ` [PATCH 3/3] fb accel capabilities (the main patch) David Eger
@ 2004-05-13 11:39 ` David Eger
2004-05-13 11:39 ` [PATCH 5/3] fb accel capabilities (aty/aty*, aty/mach64*) David Eger
1 sibling, 0 replies; 9+ messages in thread
From: David Eger @ 2004-05-13 11:39 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, jsimmons; +Cc: Benjamin Herrenschmidt
I guess I needed a few more flags for hwaccel ;-)
And I guess there will be more than three patches in this series... ;-)
-dte
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/05/13 13:25:46+02:00 eger@rosencrantz.theboonies.us
# update fb.h with some new flags needed during ATI upgrade
# to new fix.hwaccel semantics
#
# include/linux/fb.h
# 2004/05/13 13:25:22+02:00 eger@rosencrantz.theboonies.us +4 -2
# added some FB_HWACCEL_ flags: DISABLED, IMAGEBLIT
# marked var.accel_flags obsolete
#
diff -Nru a/include/linux/fb.h b/include/linux/fb.h
--- a/include/linux/fb.h Thu May 13 13:28:07 2004
+++ b/include/linux/fb.h Thu May 13 13:28:07 2004
@@ -109,9 +109,11 @@
#define FB_ACCEL_NEOMAGIC_NM2360 97 /* NeoMagic NM2360 */
#define FB_ACCEL_NEOMAGIC_NM2380 98 /* NeoMagic NM2380 */
+#define FB_HWACCEL_DISABLED 0x0000
#define FB_HWACCEL_COPYAREA 0x0001
#define FB_HWACCEL_FILLRECT 0x0002
#define FB_HWACCEL_ROTATE 0x0004
+#define FB_HWACCEL_IMAGEBLIT 0x0008
struct fb_fix_screeninfo {
char id[16]; /* identification string eg "TT Builtin" */
@@ -160,7 +162,7 @@
#define FB_ACTIVATE_ALL 64 /* change all VCs on this fb */
#define FB_ACTIVATE_FORCE 128 /* force apply even when no change*/
-#define FB_ACCELF_TEXT 1 /* text mode acceleration */
+#define FB_ACCELF_TEXT 1 /* text mode acceleration (OBSOLETE) */
#define FB_SYNC_HOR_HIGH_ACT 1 /* horizontal sync high active */
#define FB_SYNC_VERT_HIGH_ACT 2 /* vertical sync high active */
@@ -206,7 +208,7 @@
__u32 height; /* height of picture in mm */
__u32 width; /* width of picture in mm */
- __u32 accel_flags; /* acceleration flags (hints) */
+ __u32 accel_flags; /* (OBSOLETE) see fix.hwaccel */
/* Timing: All values in pixclocks, except pixclock (of course) */
__u32 pixclock; /* pixel clock in ps (pico seconds) */
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 5/3] fb accel capabilities (aty/aty*, aty/mach64*)
2004-05-12 23:50 ` [PATCH 3/3] fb accel capabilities (the main patch) David Eger
2004-05-13 11:39 ` [PATCH 4/3] fb accel capabilities (more fb.h flags) David Eger
@ 2004-05-13 11:39 ` David Eger
1 sibling, 0 replies; 9+ messages in thread
From: David Eger @ 2004-05-13 11:39 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, jsimmons
This patch (dependent on patches 3 and 4) updates the ATI drivers aside from
radeon to the new fix.hwaccel semantics. Please test.
-dte
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/05/13 13:25:46+02:00 eger@rosencrantz.theboonies.us
# ATI drivers: convert from var.accel_flags to new fix.hwaccel semantics
#
# drivers/video/aty/mach64_gx.c
# 2004/05/13 13:25:22+02:00 eger@rosencrantz.theboonies.us +5 -8
# mach64: convert from var.accel_flags to fix.hwaccel semantics
#
# drivers/video/aty/mach64_accel.c
# 2004/05/13 13:25:22+02:00 eger@rosencrantz.theboonies.us +3 -3
# mach64: convert from var.accel_flags to fix.hwaccel semantics
#
# drivers/video/aty/atyfb_base.c
# 2004/05/13 13:25:22+02:00 eger@rosencrantz.theboonies.us +8 -18
# atyfb: convert from var.accel_flags to fix.hwaccel semantics
#
# drivers/video/aty/atyfb.h
# 2004/05/13 13:25:22+02:00 eger@rosencrantz.theboonies.us +1 -2
# atyfb: convert from var.accel_flags to fix.hwaccel semantics
#
# drivers/video/aty/aty128fb.c
# 2004/05/13 13:25:22+02:00 eger@rosencrantz.theboonies.us +3 -8
# atyfb: convert from var.accel_flags to fix.hwaccel semantics
#
diff -Nru a/drivers/video/aty/aty128fb.c b/drivers/video/aty/aty128fb.c
--- a/drivers/video/aty/aty128fb.c Thu May 13 13:28:07 2004
+++ b/drivers/video/aty/aty128fb.c Thu May 13 13:28:07 2004
@@ -339,6 +339,7 @@
.ypanstep = 1,
.mmio_len = 0x2000,
.accel = FB_ACCEL_ATI_RAGE128,
+ .hwaccel = FB_HWACCEL_DISABLED,
};
static char *mode_option __initdata = NULL;
@@ -395,7 +396,6 @@
struct aty128_crtc crtc;
struct aty128_pll pll;
struct aty128_ddafifo fifo_reg;
- u32 accel_flags;
struct aty128_constants constants; /* PLL and others */
void *regbase; /* remapped mmio */
u32 vram_size; /* onboard video ram */
@@ -1532,8 +1532,8 @@
aty128_set_lcd_enable(par, par->lcd_on);
}
#endif
- if (par->accel_flags & FB_ACCELF_TEXT)
- aty128_init_engine(par);
+
+ aty128_init_engine(par);
#ifdef CONFIG_BOOTX_TEXT
btext_update_display(info->fix.smem_start,
@@ -1569,7 +1569,6 @@
par->crtc = crtc;
par->pll = pll;
par->fifo_reg = fifo_reg;
- par->accel_flags = var->accel_flags;
return 0;
}
@@ -1591,7 +1590,6 @@
var->height = -1;
var->width = -1;
- var->accel_flags = par->accel_flags;
return 0;
}
@@ -1829,9 +1827,6 @@
0, &defaultmode, 8) == 0)
var = default_var;
}
-
- var.accel_flags &= ~FB_ACCELF_TEXT;
-// var.accel_flags |= FB_ACCELF_TEXT;/* FIXME Will add accel later */
if (aty128fb_check_var(&var, info)) {
printk(KERN_ERR "aty128fb: Cannot set default mode.\n");
diff -Nru a/drivers/video/aty/atyfb.h b/drivers/video/aty/atyfb.h
--- a/drivers/video/aty/atyfb.h Thu May 13 13:28:07 2004
+++ b/drivers/video/aty/atyfb.h Thu May 13 13:28:07 2004
@@ -108,7 +108,6 @@
u8 bus_type;
u8 ram_type;
u8 mem_refresh_rate;
- u32 accel_flags;
int blitter_may_be_busy;
int asleep;
int lock_blank;
@@ -231,7 +230,7 @@
struct aty_dac_ops {
int (*set_dac) (const struct fb_info * info,
- const union aty_pll * pll, u32 bpp, u32 accel);
+ const union aty_pll * pll, u32 bpp);
};
extern const struct aty_dac_ops aty_dac_ibm514; /* IBM RGB514 */
diff -Nru a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
--- a/drivers/video/aty/atyfb_base.c Thu May 13 13:28:07 2004
+++ b/drivers/video/aty/atyfb_base.c Thu May 13 13:28:07 2004
@@ -1108,14 +1108,12 @@
return err;
}
- par->accel_flags = var->accel_flags; /* hack */
-
if (par->blitter_may_be_busy)
wait_for_idle(par);
aty_set_crtc(par, &par->crtc);
- par->dac_ops->set_dac(info, &par->pll, var->bits_per_pixel, par->accel_flags);
+ par->dac_ops->set_dac(info, &par->pll, var->bits_per_pixel);
par->pll_ops->set_pll(info, &par->pll);
#ifdef DEBUG
@@ -1224,7 +1222,7 @@
FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
/* Initialize the graphics engine */
- if (par->accel_flags & FB_ACCELF_TEXT)
+ if (info->fix.hwaccel != FB_HWACCEL_DISABLED)
aty_init_engine(par, info);
#ifdef CONFIG_BOOTX_TEXT
@@ -1304,11 +1302,6 @@
return err;
}
- if (var->accel_flags & FB_ACCELF_TEXT)
- info->var.accel_flags = FB_ACCELF_TEXT;
- else
- info->var.accel_flags = 0;
-
#if 0 /* fbmon is not done. uncomment for 2.5.x -brad */
if (!fbmon_valid_timings(pixclock, htotal, vtotal, info))
return -EINVAL;
@@ -1369,10 +1362,6 @@
* correctly.
*/
var = default_var;
- if (noaccel)
- var.accel_flags &= ~FB_ACCELF_TEXT;
- else
- var.accel_flags |= FB_ACCELF_TEXT;
if (var.yres == var.yres_virtual) {
u32 vram = (info->fix.smem_len - (PAGE_SIZE << 2));
var.yres_virtual = ((vram * 8) / var.bits_per_pixel) / var.xres_virtual;
@@ -2163,6 +2152,12 @@
aty_st_le32(MEM_CNTL, i, par);
}
+ if (noaccel)
+ info->fix.hwaccel = FB_HWACCEL_DISABLED;
+ else
+ info->fix.hwaccel = FB_HWACCEL_COPYAREA
+ | FB_HWACCEL_FILLRECT
+ | FB_HWACCEL_IMAGEBLIT ;
/*
* Reg Block 0 (CT-compatible block) is at mmio_start
* Reg Block 1 (multimedia extensions) is at mmio_start - 0x400
@@ -2272,11 +2267,6 @@
#endif /* !CONFIG_PPC */
if (!fb_find_mode(&var, info, mode_option, NULL, 0, &defmode, 8))
var = default_var;
-
- if (noaccel)
- var.accel_flags &= ~FB_ACCELF_TEXT;
- else
- var.accel_flags |= FB_ACCELF_TEXT;
if (var.yres == var.yres_virtual) {
u32 vram = (info->fix.smem_len - (PAGE_SIZE << 2));
diff -Nru a/drivers/video/aty/mach64_accel.c b/drivers/video/aty/mach64_accel.c
--- a/drivers/video/aty/mach64_accel.c Thu May 13 13:28:07 2004
+++ b/drivers/video/aty/mach64_accel.c Thu May 13 13:28:07 2004
@@ -199,7 +199,7 @@
return;
if (!area->width || !area->height)
return;
- if (!par->accel_flags) {
+ if (!(info->fix.hwaccel & FB_HWACCEL_COPYAREA)) {
if (par->blitter_may_be_busy)
wait_for_idle(par);
cfb_copyarea(info, area);
@@ -249,7 +249,7 @@
return;
if (!rect->width || !rect->height)
return;
- if (!par->accel_flags) {
+ if (!(info->fix.hwaccel & FB_HWACCEL_FILLRECT)) {
if (par->blitter_may_be_busy)
wait_for_idle(par);
cfb_fillrect(info, rect);
@@ -290,7 +290,7 @@
return;
if (!image->width || !image->height)
return;
- if (!par->accel_flags ||
+ if (!(info->fix.hwaccel & FB_HWACCEL_IMAGEBLIT) ||
(image->depth != 1 && info->var.bits_per_pixel != image->depth)) {
if (par->blitter_may_be_busy)
wait_for_idle(par);
diff -Nru a/drivers/video/aty/mach64_gx.c b/drivers/video/aty/mach64_gx.c
--- a/drivers/video/aty/mach64_gx.c Thu May 13 13:28:07 2004
+++ b/drivers/video/aty/mach64_gx.c Thu May 13 13:28:07 2004
@@ -78,7 +78,7 @@
}
static int aty_set_dac_514(const struct fb_info *info,
- const union aty_pll *pll, u32 bpp, u32 accel)
+ const union aty_pll *pll, u32 bpp)
{
struct atyfb_par *par = (struct atyfb_par *) info->par;
static struct {
@@ -204,8 +204,7 @@
*/
static int aty_set_dac_ATI68860_B(const struct fb_info *info,
- const union aty_pll *pll, u32 bpp,
- u32 accel)
+ const union aty_pll *pll, u32 bpp)
{
struct atyfb_par *par = (struct atyfb_par *) info->par;
u32 gModeReg, devSetupRegA, temp, mask;
@@ -237,7 +236,7 @@
break;
}
- if (!accel) {
+ if (info->fix.hwaccel != FB_HWACCEL_DISABLED) {
gModeReg = 0x80;
devSetupRegA = 0x61;
}
@@ -287,8 +286,7 @@
*/
static int aty_set_dac_ATT21C498(const struct fb_info *info,
- const union aty_pll *pll, u32 bpp,
- u32 accel)
+ const union aty_pll *pll, u32 bpp)
{
struct atyfb_par *par = (struct atyfb_par *) info->par;
u32 dotClock;
@@ -883,8 +881,7 @@
*/
static int aty_set_dac_unsupported(const struct fb_info *info,
- const union aty_pll *pll, u32 bpp,
- u32 accel)
+ const union aty_pll *pll, u32 bpp)
{
struct atyfb_par *par = (struct atyfb_par *) info->par;
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way)
2004-05-13 11:15 ` [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way) Geert Uytterhoeven
@ 2004-05-13 12:26 ` David Eger
2004-05-13 22:52 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 9+ messages in thread
From: David Eger @ 2004-05-13 12:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Frame Buffer Device Development, James Simmons,
Benjamin Herrenschmidt
Quoting Geert Uytterhoeven <geert@linux-m68k.org>:
> > Specifically, I've added a .hwaccel field to fb_fix_screeninfo, which
> > should serve as the way framebuffers pass hints to higher layers.
>
> I think we agreed to put it in fb_info instead, since it doesn't really
> matter for user space.
It doesn't so much matter to me. I just saw some built-in padding in
fb_fix_screeninfo I could steal..
> > This should totally obsolete the accel_flags in var (which till now has
> > had one half-heartedly used value FB_ACCELF_TEXT).
>
> Well, we still need a way to know when the fbdev has to reinitialize its
> accel engine, when switching the console from graphics mode (user space
> does accel) to text mode (kernel uses accel). Currently this is done when
> FB_ACCELF_TEXT is set.
thought this was changed to KD_GRAPHICS and KD_TEXT...
> BTW, we've been talking about allowing kernel messages (mainly oops and
> panic) to show up under X. Since we cannot use the accel engine for that,
> perhaps we need different routines for fb_{fillrect,copyarea,imageblit}()
> for the accelerated vs. non-accelerated cases? And fbcon could compare
> the function pointers, instead of looking at .hwaccel.
If we want the console to display an oops under X then the drawing functions
need to be smart enough to grok the current mode/state of the accel engine and
not rely on var. Is that what we want?
Comparing pointers just won't work, though. For example, the radeon driver
decides whether to call the cfb_fillrect() functions or do real hw accel from
within radeonfb_fillrect().
-dte
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way)
2004-05-13 11:15 ` [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way) Geert Uytterhoeven
2004-05-13 12:26 ` David Eger
@ 2004-05-13 22:52 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 9+ messages in thread
From: Benjamin Herrenschmidt @ 2004-05-13 22:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David Eger, Linux Frame Buffer Device Development, James Simmons
> Well, we still need a way to know when the fbdev has to reinitialize its accel
> engine, when switching the console from graphics mode (user space does accel)
> to text mode (kernel uses accel). Currently this is done when FB_ACCELF_TEXT is
> set.
Current fbcon should do a set_var with FB_ACTIVATE_FORCE (thus forcing a
call to set_par) when switching from KD_TEXT to KD_GRAPHICS
> BTW, we've been talking about allowing kernel messages (mainly oops and panic)
> to show up under X. Since we cannot use the accel engine for that, perhaps we
> need different routines for fb_{fillrect,copyarea,imageblit}() for the
> accelerated vs. non-accelerated cases? And fbcon could compare the function
> pointers, instead of looking at .hwaccel.
>
> (Yes, I know it's still possible to lock up your card when using unaccelerated
> drawing while an accelerated operation is in progress on some cards).
Comparing function pointers ? That's evil ;)
Ben.
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-05-13 22:55 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-12 23:45 [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way) David Eger
2004-05-12 23:47 ` [PATCH 1/3] fb accel capabilities (radeonfb copyarea() fix) David Eger
2004-05-12 23:49 ` [PATCH 2/3] fb accel capabilities (james' fbcon init cleanup) David Eger
2004-05-12 23:50 ` [PATCH 3/3] fb accel capabilities (the main patch) David Eger
2004-05-13 11:39 ` [PATCH 4/3] fb accel capabilities (more fb.h flags) David Eger
2004-05-13 11:39 ` [PATCH 5/3] fb accel capabilities (aty/aty*, aty/mach64*) David Eger
2004-05-13 11:15 ` [PATCH 0/3] fb accel capabilities (aka fast radeon fb, the right way) Geert Uytterhoeven
2004-05-13 12:26 ` David Eger
2004-05-13 22:52 ` Benjamin Herrenschmidt
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).