framebuffer: new driver for cyberblade/i1 core
Subsystems (2)
PATCH 1/1 framebuffer: new driver for cyberblade/i1 core
Currently tridenfb claims to support the cyberblade/i1 graphics core. This is of very limited truth. There is a great number of bugs, even vesafb is faster and provides more working modes and much better quality of the video signal.
Tridentfb seems to be unmaintained,and documentation for most of the supported chips is not available. Fixing cyberblade/i1 support inside of tridentfb was not an option, it would have caused numerous if(CYBERBLADEi1) else ... cases and would have rendered the code to be almost unmaintainable.
This code does support the graphics core of a single north bridge and has been tested and developed on a system equipped with that chip. It cannot break anything but the broken cyberblade/i1 support of tridentfb, and even if that would be the case, there is still vesafb as a working alternative. On the other hand it provides significant improvements. Because of this I believe that there is no reason to keep it out of 2.6.13 just because it is presented a bit late in the development cycle.
Documentation/fb/cyblafb.txt +354 -0
@@ -0,0 +1,354 @@ +CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated +into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and +tested using a VIA EPIA 5000 board. + + +Why CyBlaFB? +============ + +I tried the following framebuffer drivers: + + - TRIDENTFB is full of bugs. Acceleration is broken for Blade3D + graphics cores like the cyberblade/i1. It claims to support a great + number of devices, but documentation for most of these devices is + unfortunately not available. There is _no_ reason to use tridentfb + for cyberblade/i1 + CRT users. VESAFB is faster, and the one + advantage, mode switching, is broken in tridentfb. + + - VESAFB is used by many distributions as a standard. Vesafb does + not support mode switching. VESAFB is a bit faster than the working + configurations of TRIDENTFB, but it is still too slow, even if you + use ypan. + + - EPIAFB (you'll find it on sourceforge) supports the Cyberblade/i1 + graphics core, but it still has serious bugs and developement seems + to have stopped. This is the one driver with TV-out support. If you + do need this feature, use epiafb. + +None of these drivers was a real option for me. + +I believe that is unreasonable to change code that announces to support 20 +devices if I only have more or less sufficient documentation for exactly one +of these. The risk of breaking device foo while fixing device bar is too high. + +So I decided to start CyBlaFB as a stripped down tridentfb. + +All code specific to other Trident chips has been removed. After that there +were a lot of cosmetic changes to increase the readability of the code. All +register names were changed to those mnemonics used in the datasheet. Function +and macro names were changed if they hindered easy understanding of the code. + +After that I debugged the code and implemented some new features. I'll try to +give a little summary of the main changes: + + - calculation of vertical and horizontal timings was fixed + + - video signal quality has been improved dramatically + + - acceleration: + + - fillrect and copyarea were fixed and reenabled + + - color expanding imageblit was newly implemented, color + imageblit (only used to draw the penguine) still uses the + generic code. + + - init of the acceleration engine was improved and moved to a + place where it really works ... + + - sync function has a timeout now and tries to reset and + reinit the accel engine if necessary + + - fewer slow copyarea calls when doing ypan scrolling by using + undocumented bit d21 of screen start address stored in + CR2B[5]. BIOS does use it also, so this should be safe. + + - cyblafb rejects any attempt to set modes that would cause vclk + values above reasonable 230 MHz. 32bit modes use a clock + multiplicator of 2, so fbset does show the correct values for + pixclock but not for vclk in this case. The fbset limit is 115 MHz + for 32 bpp modes. + + - cyblafb rejects modes known to be broken or unimplemented (all + interlaced modes, all doublescan modes for now) + + - cyblafb now works independant of the video mode in effect at startup + time (tridentfb does not init all needed registers to reasonable + values) + + - switching between video modes does work reliably now + + - the first video mode now is the one selected on startup using the + vga=???? mechanism or any of + - 640x480, 800x600, 1024x768, 1280x1024 + - 8, 16, 24 or 32 bpp + - refresh between 50 Hz and 85 Hz, 1 Hz steps (1280x1024-32 + is limited to 63Hz) + + - pci retry and pci burst mode are settable (try to disable if you + experience latency problems) + + - built as a module cyblafb might be unloaded and reloaded using + the vfb module and con2vt or might be used together with vesafb + +Speed +===== + +CyBlaFB is much faster than tridentfb and vesafb. Compare the performance data +for mode 1280x1024-[8,16,32]@61 Hz. + +Test 1: Cat a file with 2000 lines of 0 characters. +Test 2: Cat a file with 2000 lines of 80 characters. +Test 3: Cat a file with 2000 lines of 160 characters. + +All values show system time use in seconds, kernel 2.6.12 was used for +the measurements. 2.6.13-rc4 is much slower, but this problem has been +solved, and 2.6.13 should be actually faster than 2.6.12. + ++-----------+-----------------------------------------------------+ +| | not accelerated | +| TRIDENTFB +-----------------+-----------------+-----------------+ +| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | +| | noypan | ypan | noypan | ypan | noypan | ypan | ++-----------+--------+--------+--------+--------+--------+--------+ +| Test 1 | 4.31 | 4.33 | 6.05 | 12.81 | ---- | ---- | +| Test 2 | 67.94 | 5.44 | 123.16 | 14.79 | ---- | ---- | +| Test 3 | 131.36 | 6.55 | 240.12 | 16.76 | ---- | ---- | ++-----------+--------+--------+--------+--------+--------+--------+ +| Comments | | | completely bro- | +| | | | ken, monitor | +| | | | switches off | ++-----------+-----------------+-----------------+-----------------+ + + ++-----------+-----------------------------------------------------+ +| | accelerated | +| TRIDENTFB +-----------------+-----------------+-----------------+ +| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | +| | noypan | ypan | noypan | ypan | noypan | ypan | ++-----------+--------+--------+--------+--------+--------+--------+ +| Test 1 | ---- | ---- | 20.62 | 1.22 | ---- | ---- | +| Test 2 | ---- | ---- | 22.61 | 3.19 | ---- | ---- | +| Test 3 | ---- | ---- | 24.59 | 5.16 | ---- | ---- | ++-----------+--------+--------+--------+--------+--------+--------+ +| Comments | broken, writing | broken, ok only | completely bro- | +| | to wrong places | if bgcolor is | ken, monitor | +| | on screen + bug | black, bug in | switches off | +| | in fillrect() | fillrect() | | ++-----------+-----------------+-----------------+-----------------+ + + ++-----------+-----------------------------------------------------+ +| | not accelerated | +| VESAFB +-----------------+-----------------+-----------------+ +| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | +| | noypan | ypan | noypan | ypan | noypan | ypan | ++-----------+--------+--------+--------+--------+--------+--------+ +| Test 1 | 4.26 | 3.76 | 5.99 | 7.23 | ---- | ---- | +| Test 2 | 65.65 | 4.89 | 120.88 | 9.08 | ---- | ---- | +| Test 3 | 126.91 | 5.94 | 235.77 | 11.03 | ---- | ---- | ++-----------+--------+--------+--------+--------+--------+--------+ +| Comments | vga=0x307 | vga=0x31a | vga=0x31b not | +| | fh=80kHz | fh=80kHz | supported by | +| | fv=75kHz | fv=75kHz | video BIOS and | +| | | | hardware | ++-----------+-----------------+-----------------+-----------------+ + + ++-----------+-----------------------------------------------------+ +| | accelerated | +| CYBLAFB +-----------------+-----------------+-----------------+ +| | 8 bpp | 16 bpp | 32 bpp | +| | noypan | ypan | noypan | ypan | noypan | ypan | ++-----------+--------+--------+--------+--------+--------+--------+ +| Test 1 | 8.02 | 0.23 | 19.04 | 0.61 | 57.12 | 2.74 | +| Test 2 | 8.38 | 0.55 | 19.39 | 0.92 | 57.54 | 3.13 | +| Test 3 | 8.73 | 0.86 | 19.74 | 1.24 | 57.95 | 3.51 | ++-----------+--------+--------+--------+--------+--------+--------+ +| Comments | | | | +| | | | | +| | | | | +| | | | | ++-----------+-----------------+-----------------+-----------------+ + +Startup Mode +============ + +Tridentfb uses modedb.c to allow the user to specify a startup video mode. +Unfortunately a lot of the video mode specifyed there do not display +correctly, including the default video mode. My first idea was to implement +some code in check_var() to alter these modes to values acceptable for the +graphics core. I wrote some code, but I dumped it completely. If you tweak the +modes, you need to provide at least kernel parameters to disable those +helpers. If you don't want to force the user to reboot in those cases you have +to provide some ioctls and a special control program as fbset etc do not know +about the new ioctls. No, this is not the perfect solution. But we already +have a video mode selection mechanism in the kernel. Why shouldn't we use +vga=xxx to select an initial video mode? This way we get a reasonable +collection of startup modes (every mode the bios supports) and those people +who really need to use fbset are not hindered by some magic in check_var() +that alters the parameters they provide. You might also specify an inital +video mode, see section "parameters" + + +Untested features +================= + +All LCD stuff is untested. If it worked in tridentfb, it should work in +cyblafb. Please test and report the results + + +known BUGS +========== + +I don't know of any bug, but please do send reports to both LKML and [email protected]. + + +TODO / Missing features +======================= + +Interlaced video modes The reason that interleaved + modes are disabled is that I do not know + the meaning of the vertical interlace + parameter. Also the datasheet mentions a + bit d8 of a horizontal interlace parameter, + but nowhere the lower 8 bits. Please help + if you can. + +low-res double scan modes Who needs it? + +accelerated color blitting Who needs it? The console driver does use color + blitting for nothing but drawing the penguine, + everything else is done using color expanding + blitting of 1bpp character bitmaps. + +xpanning Who needs it? + +ioctls Who needs it? + +TV-out Will be done later + + +Available Documentation +======================= + +Apollo PLE 133 Chipset VT8601A North Bridge Datasheet, Rev. 1.82, October 22, +2001, available from VIA. The datasheet is incomplete, some registers that +need to be programmed are not explained at all or important bits are listed +as "reserved". But you really need the datasheet to understand the code. +"p. xxx comments refer to page numbers of this document." + +XFree/XOrg drivers are available and of good quality, looking at the code +there is a good idea if the documentation does not provide enough information +or if the documentation seems to be wrong. + +Parameters +========== + + +crt don't autodetect, assume monitor connected to + standard VGA connector + +fp don't autodetect, assume flat panel display + connected to flat panel monitor interface + +nativex inform driver about native x resolution of + flat panel monitor connected to special + interface + +stretch stretch image to adapt low resolution modes to + higer resolutions of flat panel monitors + connected to special interface + +center center image to adapt low resolution modes to + higer resolutions of flat panel monitors + connected to special interface + +memsize use if autodetected memsize is wrong ... + should never be necessary + +nopcirr disable PCI read retry +nopciwr disable PCI write retry +nopcirb disable PCI read bursts +nopciwb disable PCI write bursts + +regdumps This will print a listing of the contents of + most registers to syslog immediately after startup + and after a new mode is set. Please do include if + you send a bugreport + +bpp bpp for specified modes + +ref refresh rate for specified mode + +mode 640x480 or 800x600 or 1024x768 or 1280x1024 + if not specified, the startup mode will be detected + and used, so you might also use the vga=??? parameter + described in vesafb.txt. If you do not specify a mode, + bpp and ref parameters are ignored. + +verbosity 0 is the default, increase to at least 2 for every + bug report! + +vesafb allows cyblafb to be loaded after vesafb has been + loaded. See sections "Module unloading ...". + +Module unloading, the vfb method +================================ + +If you want to unload/reload cyblafb, you need to enable vfb support in the +kernel first. After that, load the modules as shown below: + + modprobe vfb vfb_enable=1 + modprobe fbcon + modprobe cyblafb + fbset -fb /dev/fb1 1280x1024-60 -vyres 2662 + con2fb /dev/fb1 /dev/tty1 + ... + +If you now made some changes to cyblafb and want to reload it, you might do it +as show below: + + con2fb /dev/fb0 /dev/tty1 + ... + rmmod cyblafb + modprobe cyblafb + con2fb /dev/fb1 /dev/tty1 + ... + +Of course, you might choose another mode, and most certainly you also want to +map some other /dev/tty* to the real framebuffer device. You might also choose +to compile fbcon as a kernel module or place it permanently in the kernel. + +I do not know of any way to unload fbcon, and fbcon will prevent the +framebuffer device loaded first from unloading. [If there is a way, then +please add a description here!] + +Module unloading, the vesafb method +=================================== + +Configure the kernel: + + <*> Support for frame buffer devices + [*] VESA VGA graphics support + <M> Cyberblade/i1 support + +Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan +parameter is important, choose any vga parameter you like as long as it is +a graphics mode. + +After booting, load cyblafb without any mode and bpp parameter and assign +cyblafb to individual ttys using con2fb, e.g.: + + modprobe cyblafb vesafb=1 + con2fb /dev/fb1 /dev/tty1 + +Unloading cyblafb works without problems after you assign vesafb to all +ttys again, e.g.: + + con2fb /dev/fb0 /dev/tty1 + rmmod cyblafb + + +
MAINTAINERS +0 -0
@@ -627,6 +627,12 @@
W: http://www.arm.linux.org.uk/
S: Maintained
+CYBLAFB FRAMEBUFFER DRIVER
+P: Knut Petersen
+M: [email protected]
+L: [email protected]
+S: Maintained
+
CYCLADES 2X SYNC CARD DRIVER
P: Arnaldo Carvalho de Melo
M: [email protected]
drivers/video/Kconfig +0 -0
@@ -1180,6 +1180,32 @@
Please read the <file:Documentation/fb/README-sstfb.txt> for supported options and other important info support.
+config FB_CYBLA
+ tristate "Cyberblade/i1 support"
+ depends on FB && PCI
+ select FB_CFB_IMAGEBLIT
+ select FB_SOFT_CURSOR
+ select VIDEO_SELECT
+ ---help---
+ This driver is supposed to support the Trident Cyberblade/i1 + graphics core integrated in the VIA VT8601A North Bridge, + also known als VIA Apollo PLE133. + + Status:
+ - Developed, tested and working on EPIA 5000 and EPIA 800.
+ - Does work reliable on all systems with CRT/LCD connected to
+ normal VGA ports. + - Should work on systems that do use the internal LCD port, but
+ this is absolutely not tested.
+
+ Character imageblit, copyarea and rectangle fill are hw accelerated,
+ ypan scrolling is used by default.
+
+ Please do read <file:Documentation/fb/cyblafb.txt>.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cyblafb.
+
config FB_TRIDENT
tristate "Trident support" depends on FB && PCI
@@ -1193,8 +1219,12 @@
but also on some motherboards. For more information, read <file:Documentation/fb/tridentfb.txt>
+ Attention: Cyberblade/i1 support has been removed, choose the + cyblafb driver instead.
+
Say Y if you have such a graphics board.
+
To compile this driver as a module, choose M here: the module will be called tridentfb.
@@ -1205,7 +1235,6 @@
This will compile the Trident frame buffer device with acceleration functions.
-
config FB_PM3
tristate "Permedia3 support" depends on FB && PCI && BROKEN
drivers/video/Makefile +0 -0
@@ -50,7 +50,8 @@
obj-$(CONFIG_FB_IMSTT) += imsttfb.o obj-$(CONFIG_FB_S3TRIO) += S3triofb.o obj-$(CONFIG_FB_FM2) += fm2fb.o -obj-$(CONFIG_FB_TRIDENT) += tridentfb.o +obj-$(CONFIG_FB_CYBLA) += cyblafb.o +obj-$(CONFIG_FB_TRIDENT) += tridentfb.o obj-$(CONFIG_FB_STI) += stifb.o obj-$(CONFIG_FB_FFB) += ffb.o sbuslib.o obj-$(CONFIG_FB_CG6) += cg6.o sbuslib.o
drivers/video/cyblafb.c +1438 -0
1,438 lines not on this page · raw message
drivers/video/tridentfb.c +0 -0
@@ -98,7 +98,7 @@
(id == CYBER9397) || (id == CYBER9397DVD) || (id == CYBER9520) || (id == CYBER9525DVD) || (id == IMAGE975) || (id == IMAGE985) || - (id == CYBERBLADEi1) || (id == CYBERBLADEi1D) || + (id == CYBERBLADEi1D) || (id == CYBERBLADEAi1) || (id == CYBERBLADEAi1D) || (id == CYBERBLADEXPm8) || (id == CYBERBLADEXPm16) || (id == CYBERBLADEXPAi1)); @@ -116,7 +116,6 @@ case CYBER9525DVD: case CYBERBLADEE4: case CYBERBLADEi7D:
- case CYBERBLADEi1:
case CYBERBLADEi1D:
case CYBERBLADEAi1:
case CYBERBLADEAi1D:
@@ -1187,7 +1186,6 @@
{PCI_VENDOR_ID_TRIDENT, BLADE3D, PCI_ANY_ID,PCI_ANY_ID,0,0,0},
{PCI_VENDOR_ID_TRIDENT, CYBERBLADEi7, PCI_ANY_ID,PCI_ANY_ID,0,0,0},
{PCI_VENDOR_ID_TRIDENT, CYBERBLADEi7D, PCI_ANY_ID,PCI_ANY_ID,0,0,0},
- {PCI_VENDOR_ID_TRIDENT, CYBERBLADEi1, PCI_ANY_ID,PCI_ANY_ID,0,0,0},
{PCI_VENDOR_ID_TRIDENT, CYBERBLADEi1D, PCI_ANY_ID,PCI_ANY_ID,0,0,0},
{PCI_VENDOR_ID_TRIDENT, CYBERBLADEAi1, PCI_ANY_ID,PCI_ANY_ID,0,0,0},
{PCI_VENDOR_ID_TRIDENT, CYBERBLADEAi1D, PCI_ANY_ID,PCI_ANY_ID,0,0,0},include/video/cyblafb.h +174 -0
174 lines not on this page · raw message
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Quoted 31 lines · Knut Petersen
Currently tridenfb claims to support the cyberblade/i1 graphics core. This is of very limited truth. There is a great number of bugs, even vesafb is faster and provides more working modes and much better quality of the video signal.
Tridentfb seems to be unmaintained,and documentation for most of the supported chips is not available. Fixing cyberblade/i1 support inside of tridentfb was not an option, it would have caused numerous if(CYBERBLADEi1) else ... cases and would have rendered the code to be almost unmaintainable.
This code does support the graphics core of a single north bridge and has been tested and developed on a system equipped with that chip. It cannot break anything but the broken cyberblade/i1 support of tridentfb, and even if that would be the case, there is still vesafb as a working alternative. On the other hand it provides significant improvements. Because of this I believe that there is no reason to keep it out of 2.6.13 just because it is presented a bit late in the development cycle.
Signed-off-by Knut Petersen <[email protected]>diff -urN
linux-2.6.13-rc4/Documentation/fb/cyblafb.txtlinux-2.6.13-rc4-tfix/Documentation/fb/cyblafb.txt
---linux-2.6.13-rc4/Documentation/fb/cyblafb.txt1970-01-01
01:00:00.000000000 +0100
+++linux-2.6.13-rc4-tfix/Documentation/fb/cyblafb.txt2005-07-31
09:38:44.000000000 +0200(quoted diff) +1
-0@@ -0,0 +1,354 @@ +CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics coreintegrated
Documentation/fb/cyblafb.txt line 3
Quoted 2 lines
Documentation/fb/cyblafb.txt +2
-0+into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and +tested using a VIA EPIA 5000 board.
Nice docs :-)
<snip>
Review line 1224
Quoted 11 lines
+
configFB_TRIDENT
tristate "Trident support"
depends on FB && PCI(quoted diff) +3
-0@@ -1193,8 +1219,12 @@ but also on some motherboards. For more information, read <file:Documentation/fb/tridentfb.txt> + Attention: Cyberblade/i1 support has been removed, choose the + cyblafb driver instead. +
Is it really necessary to remove it from tridentfb so soon? Maybe you can add a warning first, then remove it after a few development cycles.
<snip>
Quoted 8 lines
drivers/video/cyblafb.c +8
-0+ +#include <linux/config.h> +#include <linux/module.h> +#include <linux/string.h> +#include <linux/fb.h> +#include <linux/init.h> +#include <linux/pci.h> +#include <asm/types.h>
drivers/video/cyblafb.c line 33
Quoted 10 lines
drivers/video/cyblafb.c +10
-0+#include <video/cyblafb.h> + +#define VERSION "0.50" + +struct cyblafb_par { +void __iomem * io_virt;//iospace virtual memory address +}; + +static struct cyblafb_par default_par; +static struct fb_info fb_info;
Do this in the beginning of cybla_pci_probe()
struct fb_info *info;
info = framebuffer_alloc(sizeof(struct cyblafb_par), dev->dev); if (info)
exit;
Then do a corresponding framebuffer_dealloc() on exit/unload.
This way, you need not statically allocate memory for the par and info, which increases the kernel image size unnecessarily.
And so you don't lose your info structure, do this:
pci_set_drvdata(dev, info) at the end of cybla_pci_probe()
To get your info back (ie. in cybla_pci_remove()), do this:
struct fb_info *info = pci_get_drvdata(dev);
Quoted 1 line
+static struct
fb_var_screeninfodefault_var;
You also don't need to allocate this. default_var is used only during init. Why not use info->var? Or if you can't, mark it __devinitdata.
drivers/video/cyblafb.c line 41
Quoted 7 lines
drivers/video/cyblafb.c +7
-0+static struct fb_fix_screeninfo cyblafb_fix = { + .id ="CyBla" , + .type =FB_TYPE_PACKED_PIXELS , + .ypanstep =1 , + .visual =FB_VISUAL_PSEUDOCOLOR , + .accel =FB_ACCEL_NONE , +};
Same with the above. You can mark it __devinitdata and don't reference it again after saving it in info->fix.
Quoted 10 lines
drivers/video/cyblafb.c +10
-0+ +static u32 pseudo_pal[16 ]; + +static int displaytype; + +static char *mode =NULL ; +static int bpp =8 ; +static int ref =75 ; +static int fp; +static int crt;
drivers/video/cyblafb.c line 61
Quoted 10 lines
drivers/video/cyblafb.c +10
-0+static int nativex; +static int center; +static int stretch; +static int pciwb =1 ; +static int pcirb =1 ; +static int pciwr =1 ; +static int pcirr =1 ; +static int memsize; +static int verbosity; +static int vesafb;
Any of the above that can be marked __devinitdata? For those that you need after initialization, place them in info->par.
Quoted 25 lines
drivers/video/cyblafb.c +25
-0+ +module_param (mode, charp,0 ); +module_param (bpp, int,0 ); +module_param (ref, int,0 ); +module_param (fp, int,0 ); +module_param (crt, int,0 ); +module_param (nativex, int,0 ); +module_param (center, int,0 ); +module_param (stretch, int,0 ); +module_param (pciwb, int,0 ); +module_param (pcirb, int,0 ); +module_param (pciwr, int,0 ); +module_param (pcirr, int,0 ); +module_param (memsize, int,0 ); +module_param (verbosity, int,0 ); +module_param (vesafb, int,0 ); + + +//========================================= +// +// Port access macros for memory mapped io +// +//========================================= + +#define out8 (r,v) writeb(v,((struct cyblafb_par
Quoted 6 lines
*)fb_info.par)->io_virt+r)
+#defineout32(r,v)writel(v,((structcyblafb_par
*)fb_info.par)->io_virt+r)
+#define in8(r) readb(((structcyblafb_par
*)fb_info.par)->io_virt+r)
+#define in32(r)readl(((struct cyblafb_par *)fb_info.par)->io_virt+r)
If you use framebuffer_alloc(), you can change the above macros to (struct cyblafb_par *)info->par->io_virt+r, for example.
<snip>
drivers/video/cyblafb.c line 184
Quoted 5 lines
drivers/video/cyblafb.c +5
-0+//===================================================================== +// +// Although this is a .fb_sync function that could be enabled in +// cyblafb_ops, we do not include it there. We sync immediately before +// new GE operations to improve performance.
I wonder. I thought that avoiding to sync as much as possible improves performance...
<snip>
Quoted 15 lines
drivers/video/cyblafb.c +15
-0+static int cyblafb_check_var (struct fb_var_screeninfo *var, +struct fb_info *info) +{ +int bpp = var->bits_per_pixel; +int s,t,maxvyres; + +// +// we try to support 8, 16, 24 and 32 bpp modes, +// default to 8 +// +// there is a 24 bpp mode, but for now we change requests to 32 bpp +// (This is what tridentfb does ... will be changed in the future) +// +// +if ( bpp %8 !=0 || bpp <8 || bpp >32 )
drivers/video/cyblafb.c line 532
Quoted 10 lines
drivers/video/cyblafb.c +10
-0+ bpp =8 ; +if (bpp ==24 ) + bpp = var->bits_per_pixel =32 ; + + +// +// interlaced modes are broken, fail if one is requested +// +if (var->vmode &FB_VMODE_INTERLACED ) +return -EINVAL ;
You are too strict :-) You can always clear FB_VMODE_INTERLACED and return success. This is acceptable behavior.
drivers/video/cyblafb.c line 540
Quoted 8 lines
drivers/video/cyblafb.c +8
-0+ +// +// fail if requested resolution is higher than physical +// flatpanel resolution +// +if (flatpanel && nativex && var->xres > nativex) +return -EINVAL ; +
This is acceptable behavior, but you can always return with var->xres = nativex.
drivers/video/cyblafb.c line 546
Quoted 6 lines
drivers/video/cyblafb.c +6
-0+// +// xres != xres_virtual is broken, fail if such an +// unusual mode is requested +// +if (var->xres != var->xres_virtual) +return -EINVAL ;
Same here, var->xres = var->xres_virtual.
Quoted 40 lines
drivers/video/cyblafb.c +40
-0+ +// +// we do not allow vclk to exceed 230 MHz +// +if ((bpp==32 ?200000000 :100000000 ) / var->pixclock >23000 ) +return -EINVAL ; + +// +// calc max yres_virtual that would fit in memory +// and max yres_virtual that could be used for scrolling +// and use minimum of the results as maxvyres +// +// adjust vyres_virtual to maxvyres if necessary +// fail if requested yres is bigger than maxvyres +// + s = (0x1fffff / (var->xres * bpp/8 )) + var->yres; + t = info->fix.smem_len / (var->xres * bpp/8 ); + maxvyres = t < s ? t : s; +if (maxvyres < var->yres_virtual) + var->yres_virtual=maxvyres; +if (maxvyres < var->yres) +return -EINVAL ; + +switch (bpp) { +case 8 : + var->red.offset =0 ; + var->green.offset =0 ; + var->blue.offset =0 ; + var->red.length =6 ; + var->green.length =6 ; + var->blue.length =6 ; +break ; +case 16 : + var->red.offset =11 ; + var->green.offset =5 ; + var->blue.offset =0 ; + var->red.length =5 ; + var->green.length =6 ; + var->blue.length =5 ; +break ;
drivers/video/cyblafb.c line 596
Quoted 10 lines
drivers/video/cyblafb.c +10
-0+case 32 : + var->red.offset =16 ; + var->green.offset =8 ; + var->blue.offset =0 ; + var->red.length =8 ; + var->green.length =8 ; + var->blue.length =8 ; +break ; +default : +return -EINVAL ;
Again, you can always round off bits_per_pixel to
ones that the driver can support.
<snip>
Quoted 4 lines
drivers/video/cyblafb.c +3
-0+//========================================================================== +// +// getstartupmode() decides about the inital video mode
drivers/video/cyblafb.c line 713
Quoted 10 lines
drivers/video/cyblafb.c +10
-0+// +// There is no reason to use modedb, a lot of video modes there would +// need altered timings to display correctly. So I decided that it is much +// better to provide a limited optimized set of modes plus the option of +// using the mode in effect at startup time (might be selected using the +// vga=??? paramter). After that the user might use fbset to select any +// mode he likes, check_var will not try to alter geometry parameters as +// it would be necessary otherwise. +// +//==========================================================================
You can get the correct set of video modes from the EDID. If you can't add DDC/I2C support, I will submit a patch that will grab the EDID from the BIOS. Should be usable by all x86 drivers. This way you don't need to massage the timings.
<snip>
drivers/video/cyblafb.c line 1212
Quoted 5 lines
drivers/video/cyblafb.c +5
-0+static int __devinit cybla_pci_probe (struct pci_dev * dev, +const struct pci_device_id * id) +{ + + fb_info.par = &default_par;
As mentioned in the beginning, you don't need to do the above.
Quoted 37 lines
drivers/video/cyblafb.c +37
-0+ +if (pci_enable_device (dev)) { +output ("could not enable device!\n" ); + goto errout_enable; + } + +// might already be requested by vga console or vesafb, +// so we do care about success +request_region (0x3c0 ,32 ,"cyblafb" ); + +// +// Graphics Engine Registers +// +request_region (GEBase,0x100 ,"cyblafb" ); + +regdump (); + +enable_mmio (); + +/* setup MMIO region */ + cyblafb_fix.mmio_start =pci_resource_start (dev,1 ); + cyblafb_fix.mmio_len =0x20000 ; + +if (!request_mem_region (cyblafb_fix.mmio_start, + cyblafb_fix.mmio_len,"cyblafb" )) { +output ("request_mem_region failed for mmio region!\n" ); + goto errout_mmio_reqmem; + } + + default_par.io_virt =ioremap_nocache (cyblafb_fix.mmio_start, + cyblafb_fix.mmio_len); + +if (!default_par.io_virt) { +output ("ioremap failed for mmio region\n" ); + goto errout_mmio_remap; + } +
drivers/video/cyblafb.c line 1259
Quoted 10 lines
drivers/video/cyblafb.c +10
-0+// setup framebuffer memory ... might already be requested +// by vesafb. Not to fail in case of an unsuccessful request +// is useful for the development cycle + cyblafb_fix.smem_start =pci_resource_start (dev,0 ); + cyblafb_fix.smem_len =get_memsize (); + +if (!request_mem_region (cyblafb_fix.smem_start, + cyblafb_fix.smem_len,"cyblafb" )) { +output ("request_mem_region failed for smem region!\n" ); +if (!vesafb)
Instead of testing for the vesafb boot option, you can test for screen_info.orig_video_isVGA == VIDEO_TYPE_VLFB. This is set when screen is in VESA VGA graphics mode. See include/linux/tty.h.
Quoted 54 lines
drivers/video/cyblafb.c +54
-0+ goto errout_smem_req; + } + + fb_info.screen_base =ioremap_nocache (cyblafb_fix.smem_start, + cyblafb_fix.smem_len); + +if (!fb_info.screen_base) { +output ("ioremap failed for smem region\n" ); + goto errout_smem_remap; + } + + displaytype =get_displaytype (); + +if (flatpanel) + nativex =get_nativex (); + + fb_info.fix = cyblafb_fix; + fb_info.fbops = &cyblafb_ops; + +// +// FBINFO_HWACCEL_YWRAP .... does not work (could be made to work) +// FBINFO_PARTIAL_PAN_OK .... is not ok +// FBINFO_READS_FAST .... is necessary for optimal scrolling +// + fb_info.flags =FBINFO_DEFAULT |FBINFO_HWACCEL_YPAN + |FBINFO_HWACCEL_COPYAREA |FBINFO_HWACCEL_FILLRECT + |FBINFO_HWACCEL_IMAGEBLIT |FBINFO_READS_FAST ; + + fb_info.pseudo_palette = pseudo_pal; + +if (getstartupmode ()) + goto errout_findmode; + +fb_alloc_cmap (&fb_info.cmap,256 ,0 ); + + fb_info.var = default_var; + fb_info.device = &dev->dev; + +if (register_framebuffer (&fb_info)) { +output ("Could not register CyBla framebuffer\n" ); + goto errout_register; + } + +return 0 ; + +// +// error paths +// + + errout_register: + errout_findmode: +iounmap (fb_info.screen_base); + errout_smem_remap: + release_mem_region(cyblafb_fix.smem_start,
drivers/video/cyblafb.c line 1323
Quoted 10 lines
drivers/video/cyblafb.c +10
-0+ cyblafb_fix.smem_len); + errout_smem_req: +iounmap (default_par.io_virt); + errout_mmio_remap: +release_mem_region (cyblafb_fix.mmio_start, + cyblafb_fix.mmio_len); + errout_mmio_reqmem: +// release_region(0x3c0, 32); + errout_enable: +
Don't forget fb_dealloc_cmap() in the exit path, especially if you like to load/unload the driver. You can insert framebuffer_dealloc() here also if you use framebuffer_alloc().
drivers/video/cyblafb.c line 1330
Quoted 7 lines
drivers/video/cyblafb.c +7
-0+output ("CyblaFB version %s aborting init.\n" ,VERSION ); +return -ENODEV ; +} + +static void __devexit cybla_pci_remove(struct pci_dev * dev) +{ +struct cyblafb_par *par = (struct cyblafb_par *)fb_info.par;
or
struct fb_info *info = pci_get_drvdata(dev); struct cyblafb_par *par = info->par;
And to please Linus, try to compile the driver with sparse checking on.
Tony
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Quoted 9 lines · Antonino A. Daplas
drivers/video/cyblafb.c line 532
Quoted 5 lines · Knut Petersen
drivers/video/cyblafb.c +5
-0+// +// interlaced modes are broken, fail if one is requested +// +if (var->vmode &FB_VMODE_INTERLACED ) +return -EINVAL ;You are too strict :-) You can always clear
FB_VMODE_INTERLACEDand return success. This is acceptable behavior.
I would not try to modify the passed FB_VMODE_* flags.
Quoted 11 lines
drivers/video/cyblafb.c line 540
Quoted 7 lines
drivers/video/cyblafb.c +7
-0+// +// fail if requested resolution is higher than physical +// flatpanel resolution +// +if (flatpanel && nativex && var->xres > nativex) +return -EINVAL ; +This is acceptable behavior, but you can always return with
var->xres= nativex.
Quoted 8 lines
drivers/video/cyblafb.c line 546
Quoted 6 lines
drivers/video/cyblafb.c +6
-0+// +// xres != xres_virtual is broken, fail if such an +// unusual mode is requested +// +if (var->xres != var->xres_virtual) +return -EINVAL ;Same here,
var->xres=var->xres_virtual.
Only when rounding _up_. Rounding down is not allowed.
Quoted 42 lines
Quoted 32 lines
drivers/video/cyblafb.c +32
-0+// calc max yres_virtual that would fit in memory +// and max yres_virtual that could be used for scrolling +// and use minimum of the results as maxvyres +// +// adjust vyres_virtual to maxvyres if necessary +// fail if requested yres is bigger than maxvyres +// + s = (0x1fffff / (var->xres * bpp/8 )) + var->yres; + t = info->fix.smem_len / (var->xres * bpp/8 ); + maxvyres = t < s ? t : s; +if (maxvyres < var->yres_virtual) + var->yres_virtual=maxvyres; +if (maxvyres < var->yres) +return -EINVAL ; + +switch (bpp) { +case 8 : + var->red.offset =0 ; + var->green.offset =0 ; + var->blue.offset =0 ; + var->red.length =6 ; + var->green.length =6 ; + var->blue.length =6 ; +break ; +case 16 : + var->red.offset =11 ; + var->green.offset =5 ; + var->blue.offset =0 ; + var->red.length =5 ; + var->green.length =6 ; + var->blue.length =5 ; +break ;drivers/video/cyblafb.c line 596
Quoted 10 lines
drivers/video/cyblafb.c +10
-0+case 32 : + var->red.offset =16 ; + var->green.offset =8 ; + var->blue.offset =0 ; + var->red.length =8 ; + var->green.length =8 ; + var->blue.length =8 ; +break ; +default : +return -EINVAL ;
Quoted 2 lines
Again, you can always round off
bits_per_pixelto
ones that the driver can support.
Only when rounding _up_.
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
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click