[PATCH 01/10] fbdev: Clean up of sparc FB options

[PATCH 01/10] fbdev: Clean up of sparc FB options

[Antonino A. Daplas]

From: Krzysztof Helt <krzysztof.h1@wp.pl>

This patch puts all SBUS/UPA selection under one option "SBUS/UPA
framebuffers" and moves all sparc specific drivers next to them
in one group.

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
---

 drivers/video/Kconfig |  176 ++++++++++++++++++++++++-------------------------
 1 files changed, 86 insertions(+), 90 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ef8e97a..ce09836 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -711,6 +711,91 @@ config FB_CG6
 	  This is the frame buffer device driver for the CGsix (GX, TurboGX)
 	  frame buffer.
 
+config FB_FFB
+	bool "Creator/Creator3D/Elite3D support"
+	depends on FB_SBUS && SPARC64
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  This is the frame buffer device driver for the Creator, Creator3D,
+	  and Elite3D graphics boards.
+
+config FB_TCX
+	bool "TCX (SS4/SS5 only) support"
+	depends on FB_SBUS
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  This is the frame buffer device driver for the TCX 24/8bit frame
+	  buffer.
+
+config FB_CG14
+	bool "CGfourteen (SX) support"
+	depends on FB_SBUS
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  This is the frame buffer device driver for the CGfourteen frame
+	  buffer on Desktop SPARCsystems with the SX graphics option.
+
+config FB_P9100
+	bool "P9100 (Sparcbook 3 only) support"
+	depends on FB_SBUS
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  This is the frame buffer device driver for the P9100 card
+	  supported on Sparcbook 3 machines.
+
+config FB_LEO
+	bool "Leo (ZX) support"
+	depends on FB_SBUS
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  This is the frame buffer device driver for the SBUS-based Sun ZX
+	  (leo) frame buffer cards.
+
+config FB_IGA
+	bool "IGA 168x display support"
+	depends on FB && SPARC32
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  This is the framebuffer device for the INTERGRAPHICS 1680 and
+	  successor frame buffer cards.
+
+config FB_XVR500
+	bool "Sun XVR-500 3DLABS Wildcat support"
+	depends on FB && PCI && SPARC64
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  This is the framebuffer device for the Sun XVR-500 and similar
+	  graphics cards based upon the 3DLABS Wildcat chipset.  The driver
+	  only works on sparc64 systems where the system firwmare has
+	  mostly initialized the card already.  It is treated as a
+	  completely dumb framebuffer device.
+
+config FB_XVR2500
+	bool "Sun XVR-2500 3DLABS Wildcat support"
+	depends on FB && PCI && SPARC64
+	select FB_CFB_FILLRECT
+	select FB_CFB_COPYAREA
+	select FB_CFB_IMAGEBLIT
+	help
+	  This is the framebuffer device for the Sun XVR-2500 and similar
+	  graphics cards based upon the 3DLABS Wildcat chipset.  The driver
+	  only works on sparc64 systems where the system firwmare has
+	  mostly initialized the card already.  It is treated as a
+	  completely dumb framebuffer device.
+
 config FB_PVR2
 	tristate "NEC PowerVR 2 display support"
 	depends on FB && SH_DREAMCAST
@@ -1202,7 +1287,7 @@ config FB_ATY
 config FB_ATY_CT
 	bool "Mach64 CT/VT/GT/LT (incl. 3D RAGE) support"
 	depends on PCI && FB_ATY
-	default y if SPARC64 && FB_PCI
+	default y if SPARC64 && PCI
 	help
 	  Say Y here to support use of ATI's 64-bit Rage boards (or other
 	  boards based on the Mach64 CT, VT, GT, and LT chipsets) as a
@@ -1491,95 +1576,6 @@ config FB_AU1200
 
 source "drivers/video/geode/Kconfig"
 
-config FB_FFB
-	bool "Creator/Creator3D/Elite3D support"
-	depends on FB_SBUS && SPARC64
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
-	help
-	  This is the frame buffer device driver for the Creator, Creator3D,
-	  and Elite3D graphics boards.
-
-config FB_TCX
-	bool "TCX (SS4/SS5 only) support"
-	depends on FB_SBUS
-	select FB_CFB_FILLRECT
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
-	help
-	  This is the frame buffer device driver for the TCX 24/8bit frame
-	  buffer.
-
-config FB_CG14
-	bool "CGfourteen (SX) support"
-	depends on FB_SBUS
-	select FB_CFB_FILLRECT
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
-	help
-	  This is the frame buffer device driver for the CGfourteen frame
-	  buffer on Desktop SPARCsystems with the SX graphics option.
-
-config FB_P9100
-	bool "P9100 (Sparcbook 3 only) support"
-	depends on FB_SBUS
-	select FB_CFB_FILLRECT
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
-	help
-	  This is the frame buffer device driver for the P9100 card
-	  supported on Sparcbook 3 machines.
-
-config FB_LEO
-	bool "Leo (ZX) support"
-	depends on FB_SBUS
-	select FB_CFB_FILLRECT
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
-	help
-	  This is the frame buffer device driver for the SBUS-based Sun ZX
-	  (leo) frame buffer cards.
-
-config FB_XVR500
-	bool "Sun XVR-500 3DLABS Wildcat support"
-	depends on (FB = y) && PCI && SPARC64
-	select FB_CFB_FILLRECT
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
-	help
-	  This is the framebuffer device for the Sun XVR-500 and similar
-	  graphics cards based upon the 3DLABS Wildcat chipset.  The driver
-	  only works on sparc64 systems where the system firwmare has
-	  mostly initialized the card already.  It is treated as a
-	  completely dumb framebuffer device.
-
-config FB_XVR2500
-	bool "Sun XVR-2500 3DLABS Wildcat support"
-	depends on (FB = y) && PCI && SPARC64
-	select FB_CFB_FILLRECT
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
-	help
-	  This is the framebuffer device for the Sun XVR-2500 and similar
-	  graphics cards based upon the 3DLABS Wildcat chipset.  The driver
-	  only works on sparc64 systems where the system firwmare has
-	  mostly initialized the card already.  It is treated as a
-	  completely dumb framebuffer device.
-
-config FB_PCI
-	bool "PCI framebuffers"
-	depends on (FB = y) && PCI && SPARC
-
-config FB_IGA
-	bool "IGA 168x display support"
-	depends on SPARC32 && FB_PCI
-	select FB_CFB_FILLRECT
-	select FB_CFB_COPYAREA
-	select FB_CFB_IMAGEBLIT
-	help
-	  This is the framebuffer device for the INTERGRAPHICS 1680 and
-	  successor frame buffer cards.
-
 config FB_HIT
 	tristate "HD64461 Frame Buffer support"
 	depends on FB && HD64461


-------------------------------------------------------------------------
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/

Re: [PATCH 01/10] fbdev: Clean up of sparc FB options

[David Miller]

From: "Antonino A. Daplas" <adaplas@gmail.com>
Date: Thu, 17 May 2007 05:17:34 +0800

> From: Krzysztof Helt <krzysztof.h1@wp.pl>
> 
> This patch puts all SBUS/UPA selection under one option "SBUS/UPA
> framebuffers" and moves all sparc specific drivers next to them
> in one group.
> 
> Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
> Signed-off-by: Antonino Daplas <adaplas@gmail.com>

Thanks for cleaning this up.

Signed-off-by: David S. Miller <davem@davemloft.net>

On a related note I've been trying to figure out how to solve a
particular issue on sparc, perhaps you can help?

The firmware has properties that we could use to determine exactly
which framebuffer device is being used as the console in multi-head
situations.

Currently there is no easy way to make use of that so the user just
gets whatever the framebuffer device probing order gives them which
isn't nice and is often wrong.

One idea I have is to provide a way to set some flag in the
fbinfo.  The flag would indicate that this framebuffer should
be used as the primary console by default.  Command line options
et al. could of course override this.

In this way sparc framebuffers could see if a device is the
one the "output-device" firmware property points to, and if
so it would set the flag.

What do you think about this?

-------------------------------------------------------------------------
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/

Re: [PATCH 01/10] fbdev: Clean up of sparc FB options

[Antonino A. Daplas]

On Wed, 2007-05-16 at 14:47 -0700, David Miller wrote:
> From: "Antonino A. Daplas" <adaplas@gmail.com>
> Date: Thu, 17 May 2007 05:17:34 +0800
> 
> > From: Krzysztof Helt <krzysztof.h1@wp.pl>
> > 
> > This patch puts all SBUS/UPA selection under one option "SBUS/UPA
> > framebuffers" and moves all sparc specific drivers next to them
> > in one group.
> > 
> > Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
> > Signed-off-by: Antonino Daplas <adaplas@gmail.com>
> 
> Thanks for cleaning this up.
> 
> Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> On a related note I've been trying to figure out how to solve a
> particular issue on sparc, perhaps you can help?
> 
> The firmware has properties that we could use to determine exactly
> which framebuffer device is being used as the console in multi-head
> situations.
> 
> Currently there is no easy way to make use of that so the user just
> gets whatever the framebuffer device probing order gives them which
> isn't nice and is often wrong.
> 

This is a potential problem for the x86 too, actually.

> One idea I have is to provide a way to set some flag in the
> fbinfo.  The flag would indicate that this framebuffer should
> be used as the primary console by default.  Command line options
> et al. could of course override this.

A flag may be the easiest. But we can also define an arch-specific
function (ie, fb_get_primary_device()) in asm/fb.h. With the x86, this
can be easily done by checking the IORESOURCE_ROM_SHADOW bit flag.  

I'll add this for the x86, and then perhaps others can follow suit.

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/

Re: [PATCH 01/10] fbdev: Clean up of sparc FB options

[David Miller]

From: "Antonino A. Daplas" <adaplas@gmail.com>
Date: Thu, 17 May 2007 07:15:05 +0800

> A flag may be the easiest. But we can also define an arch-specific
> function (ie, fb_get_primary_device()) in asm/fb.h. With the x86, this
> can be easily done by checking the IORESOURCE_ROM_SHADOW bit flag.  
> 
> I'll add this for the x86, and then perhaps others can follow suit.

What would this iterate over?  The list of all registered
fb_info's?

Anyways this sounds great, I'll add the sparc bits once you
push the x86 version.

-------------------------------------------------------------------------
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/

Re: [PATCH 01/10] fbdev: Clean up of sparc FB options

[Antonino A. Daplas]

On Wed, 2007-05-16 at 16:17 -0700, David Miller wrote:
> From: "Antonino A. Daplas" <adaplas@gmail.com>
> Date: Thu, 17 May 2007 07:15:05 +0800
> 
> > A flag may be the easiest. But we can also define an arch-specific
> > function (ie, fb_get_primary_device()) in asm/fb.h. With the x86, this
> > can be easily done by checking the IORESOURCE_ROM_SHADOW bit flag.  
> > 
> > I'll add this for the x86, and then perhaps others can follow suit.
> 
> What would this iterate over?  The list of all registered
> fb_info's?

For each driver that calls register_framebuffer(), fbcon will check if
it is the primary device.  If it is, it will revise the
console-to-framebuffer mapping (with set_con2fbmap()).

So something like this can happen:

fb0 registers and becomes the default console for vc0-vc63, for the
moment.

fb1 registers, and it is the primary device.  fbcon now maps fb1 to
vc0-vc63.

fb2 registers, it is not the primary device.  fbcon ignores fb2.

fb3 registers, it drives the same hardware as fb1, and thus is also the
primary device.  fbcon still ignores fb3 since fb1 is already determined
to be as the primary device.

All the above is overridden by using the fbcon=map: option.

Most of the pieces are already in place (ie the console-to-framebuffer
remapping), so there should be minimal work for fbcon.

The question is, will this work for sparc?

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/

Re: [PATCH 01/10] fbdev: Clean up of sparc FB options

[David Miller]

From: "Antonino A. Daplas" <adaplas@gmail.com>
Date: Thu, 17 May 2007 08:01:58 +0800

> The question is, will this work for sparc?

It can't be just by type, we need to be able to able to select
individual instances of the same kind of device.  I can't tell if
you're saying your scheme handles this or not :-)))

I can have two ffb cards in my machine and I can tell fbcon precisely
which of those ffb instances is the primary one.  That's what I'd need
to work.

-------------------------------------------------------------------------
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/

Re: [PATCH 01/10] fbdev: Clean up of sparc FB options

[Antonino A. Daplas]

On Wed, 2007-05-16 at 17:05 -0700, David Miller wrote:
> From: "Antonino A. Daplas" <adaplas@gmail.com>
> Date: Thu, 17 May 2007 08:01:58 +0800
> 
> > The question is, will this work for sparc?
> 
> It can't be just by type, we need to be able to able to select
> individual instances of the same kind of device.  I can't tell if
> you're saying your scheme handles this or not :-)))
> 
> I can have two ffb cards in my machine and I can tell fbcon precisely
> which of those ffb instances is the primary one.  That's what I'd need
> to work.

As long as each instance is defined by distinct struct fb_info's, it
should work.

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/

Re: [PATCH 01/10] fbdev: Clean up of sparc FB options

[David Miller]

From: "Antonino A. Daplas" <adaplas@gmail.com>
Date: Thu, 17 May 2007 08:10:34 +0800

> On Wed, 2007-05-16 at 17:05 -0700, David Miller wrote:
> > From: "Antonino A. Daplas" <adaplas@gmail.com>
> > Date: Thu, 17 May 2007 08:01:58 +0800
> > 
> > > The question is, will this work for sparc?
> > 
> > It can't be just by type, we need to be able to able to select
> > individual instances of the same kind of device.  I can't tell if
> > you're saying your scheme handles this or not :-)))
> > 
> > I can have two ffb cards in my machine and I can tell fbcon precisely
> > which of those ffb instances is the primary one.  That's what I'd need
> > to work.
> 
> As long as each instance is defined by distinct struct fb_info's, it
> should work.

Excellent.

The only missing piece for sparc is how do I get from an fb_info to
the firmware node for that device.  What we can do is add a "struct
device_node *" or similar to fb_info.  powerpc and all future
openfirmware platforms will be able to make use of this as well.

-------------------------------------------------------------------------
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/

Re: [PATCH 01/10] fbdev: Clean up of sparc FB options

[Antonino A. Daplas]

On Wed, 2007-05-16 at 17:15 -0700, David Miller wrote:
> From: "Antonino A. Daplas" <adaplas@gmail.com>
> Date: Thu, 17 May 2007 08:10:34 +0800
> 
> > On Wed, 2007-05-16 at 17:05 -0700, David Miller wrote:
> > > From: "Antonino A. Daplas" <adaplas@gmail.com>
> > > Date: Thu, 17 May 2007 08:01:58 +0800
> > As long as each instance is defined by distinct struct fb_info's, it
> > should work.
> 
> Excellent.
> 
> The only missing piece for sparc is how do I get from an fb_info to
> the firmware node for that device.  What we can do is add a "struct
> device_node *" or similar to fb_info.  powerpc and all future
> openfirmware platforms will be able to make use of this as well.

struct fb_info already has struct device *device field.  Isn't that
sufficient enough?  Or if you must, just define a flag somewhere in
struct fb_info or struct par which the fb_get_primary_device() can
check.

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/

Re: [PATCH 01/10] fbdev: Clean up of sparc FB options

[David Miller]

From: "Antonino A. Daplas" <adaplas@gmail.com>
Date: Thu, 17 May 2007 08:36:21 +0800

> On Wed, 2007-05-16 at 17:15 -0700, David Miller wrote:
> > Excellent.
> > 
> > The only missing piece for sparc is how do I get from an fb_info to
> > the firmware node for that device.  What we can do is add a "struct
> > device_node *" or similar to fb_info.  powerpc and all future
> > openfirmware platforms will be able to make use of this as well.
> 
> struct fb_info already has struct device *device field.  Isn't that
> sufficient enough?  Or if you must, just define a flag somewhere in
> struct fb_info or struct par which the fb_get_primary_device() can
> check.

Indeed, struct device is sufficient, I store the info I need
in the struct dev_archdata.

-------------------------------------------------------------------------
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/