kyrofb support

This patch adds support for the Kyro graphics boards (STG4000/PowerVR 3/etc.) to 2.6.1. This is a direct port and substantial cleanup / rewrite of the 2.4 driver that's available in the sh64 tree at linux-sh.bkbits.net. Some of the overlay code and the STG4000 bits are still a bit ugly, so be forewarned.

Andrew, please consider for -mm unless anyone has any glaring objections.

 drivers/video/Kconfig                     |   10 
 drivers/video/Makefile                    |    1 
 drivers/video/fbmem.c                     |    6 
 drivers/video/kyro/Makefile               |   13 
 drivers/video/kyro/STG4000InitDevice.c    |  328 ++++++++++++
 drivers/video/kyro/STG4000Interface.h     |   60 ++
 drivers/video/kyro/STG4000OverlayDevice.c |  609 ++++++++++++++++++++++
 drivers/video/kyro/STG4000Ramdac.c        |  176 ++++++
 drivers/video/kyro/STG4000Reg.h           |  285 ++++++++++
 drivers/video/kyro/STG4000VTG.c           |  173 ++++++
 drivers/video/kyro/fbdev.c                |  812 ++++++++++++++++++++++++++++++
 include/video/kyro.h                      |  101 +++
 12 files changed, 2574 insertions(+)

@@ -734,6 +734,16 @@ config FB_NEOMAGIC
 	  To compile this driver as a module, choose M here: the
 	  module will be called neofb.
 
+config FB_KYRO
+	tristate "IMG Kyro support"
+	depends on FB && PCI
+	help
+	  Say Y here if you have a STG4000 / Kyro / PowerVR 3 based
+	  graphics board.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called kyrofb.
+
 config FB_3DFX
 	tristate "3Dfx Banshee/Voodoo3 display support"
 	depends on FB && PCI

@@ -70,6 +70,7 @@ obj-$(CONFIG_FB_VIRTUAL)          += vfb
 obj-$(CONFIG_FB_HIT)              += hitfb.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o
 obj-$(CONFIG_FB_E1355)            += epson1355fb.o
 obj-$(CONFIG_FB_PVR2)             += pvr2fb.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o
+obj-$(CONFIG_FB_KYRO)             += kyro/ cfbfillrect.o cfbcopyarea.o cfbimgblt.o
 obj-$(CONFIG_FB_VOODOO1)          += sstfb.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o
 
 obj-$(CONFIG_FB_FFB)               += ffb.o sbuslib.o cfbimgblt.o cfbcopyarea.o

@@ -159,6 +159,8 @@ extern int tcx_init(void);
 extern int tcx_setup(char*);
 extern int leo_init(void);
 extern int leo_setup(char*);
+extern int kyrofb_init(void);
+extern int kyrofb_setup(char*);
 
 static struct {
 	const char *name;

@@ -360,6 +362,10 @@ static struct {
 #ifdef CONFIG_FB_VOODOO1
 	{ "sstfb", sstfb_init, sstfb_setup },
 #endif
+#ifdef CONFIG_FB_KYRO
+	{ "kyrofb", kyrofb_init, kyrofb_setup },
+#endif
+
 	/*
 	 * Generic drivers that don't use resource management (yet)
 	 */

@@ -0,0 +1,13 @@
+#
+# Makefile for the Kyro framebuffer driver
+#
+# Note! Dependencies are done automagically by 'make dep', which also
+# removes any old dependencies. DON'T put your own dependencies here
+# unless it's something special (ie not a .c file).
+#
+# Note 2! The CFLAGS definitions are now in the main makefile...
+
+obj-$(CONFIG_FB_KYRO)	+= kyrofb.o
+
+kyrofb-objs	:= STG4000Ramdac.o STG4000VTG.o STG4000OverlayDevice.o \
+		   STG4000InitDevice.o fbdev.o

OK. Problem is that the fbdev guys seem to be cooking up an internal API change. I guess we may as well merge this driver up now and modify it if and when that API change hits the tree.

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html

Merge it in. The new changes don't hit the drivers that much. Mainly the new changes are:

1) Finalized cursor api.
2) i2c support :-)
3) DMA and memory allocation in general.
4) sysfs support.

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html

Why is kyro_modedb[] and the code which touches it under #ifdef MODULE?

kyrofb_pci_tbl[] cannot be marked __devinitdata - it is linked into system-wide PCI tables and will be walked at various times in the kernel. If it is in a discarded section the kernel oopses.

Shouldn't the module_exit(kyrofb_exit); be inside #ifdef MODULE too?

In general, what are the fbdev drivers doing here btw? It's very strange that some core file (fbmem.c) has to "know" about individual card drivers. It should be sufficient for the driver to just register itself with the core at the drivers's module_init() time.

Sigh. Too late to fix that now I guess.

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html

No particular reason, really. I hadn't been following some of the recent fbdev changes, so I wasn't sure if this was necessary or not (I was using tdfxfb as a reference when tracking API changes, and noticed that it did the #ifdef MODULE stuff which it never did earlier). I'll happily drop the #ifdef MODULE bits if this isn't necessary. James?

Okay, I'll remove that.

Yes, I suppose.

This is done for device ordering as far as I recall. Devices listed first on the command line are numbered first, with the rest coming up in the order that they're listed in fb_drivers[].

I had some patches against this awhile ago that redid some of this, getting rid of fb_drivers[], putting ordered devices in a list and logically assigning IDs based off of that, etc. but still letting the drivers come up on their own through module_init(). I was planning on working on this for 2.7, as I didn't have enough time under 2.5.

I'll send you another patch for this as soon as I hear back from James or someone else about the modedb / #ifdef MODULE stuff, I don't see any reason why it would be required, though.

Indeed. It's there so people can choose which is their primary display, if they have multiple cards.

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: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html

Also cards that lack proper resource management can be initalized last.

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html

Yes. You can drop the MODULE ifdef. The latest modedb code can work with modules and well as without.

Drop it and send me another patch.

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html

Pre-historical junk that should be killed for 2.7 (I hope).

There isn't that a bad internal API change, the main of it is the allocation and freeing of the fbdev, adapting the driver to that should be trivial. I hope James will feed you with the new stuff asap now. Most of my concerns about the core stuff are adressed at this point (though I didn't look at individual drivers). The fbcon resize stuff is still broken in subtle ways, but that shouldn't prevent merging what we have now.

Ben.

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html