Patch for review and testing

Patch for review and testing

[James Simmons]

I like to submit this patch to linus today. Could you test it to see if it 
works on ppcs. 

diff -urN -X /home/jsimmons/dontdiff linus-2.6/arch/i386/boot/video.S fbdev-2.6/arch/i386/boot/video.S
--- linus-2.6/arch/i386/boot/video.S	2004-01-27 14:11:30.000000000 -0800
+++ fbdev-2.6/arch/i386/boot/video.S	2004-01-27 13:28:20.000000000 -0800
@@ -1889,6 +1889,7 @@
 	ret
 
 store_edid:
+#ifdef CONFIG_EDID_FIRMWARE
 	pushw	%es				# just save all registers 
 	pushw	%ax				
 	pushw	%bx
@@ -1919,6 +1920,7 @@
 	popw	%bx
 	popw	%ax
 	popw	%es	
+#endif         /* CONFIG_EDID_FIRMWARE */
 	ret
 
 # VIDEO_SELECT-only variables
diff -urN -X /home/jsimmons/dontdiff linus-2.6/arch/i386/kernel/setup.c fbdev-2.6/arch/i386/kernel/setup.c
--- linus-2.6/arch/i386/kernel/setup.c	2004-01-27 14:11:32.000000000 -0800
+++ fbdev-2.6/arch/i386/kernel/setup.c	2004-01-27 13:46:34.000000000 -0800
@@ -105,7 +105,9 @@
 	unsigned short length;
 	unsigned char table[0];
 };
+#ifdef CONFIG_EDID_FIRMWARE
 struct edid_info edid_info;
+#endif /* CONFIG_EDID_FIRMWARE */
 struct ist_info ist_info;
 struct e820map e820;
 
@@ -1060,7 +1062,9 @@
  	ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
  	drive_info = DRIVE_INFO;
  	screen_info = SCREEN_INFO;
+#ifdef CONFIG_EDID_FIRMWARE
 	edid_info = EDID_INFO;
+#endif /* CONFIG_EDID_FIRMWARE */
 	apm_info.bios = APM_BIOS_INFO;
 	ist_info = IST_INFO;
 	saved_videomode = VIDEO_MODE;
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/Kconfig fbdev-2.6/drivers/video/Kconfig
--- linus-2.6/drivers/video/Kconfig	2004-01-27 14:17:11.000000000 -0800
+++ fbdev-2.6/drivers/video/Kconfig	2004-01-27 11:46:36.000000000 -0800
@@ -38,6 +38,18 @@
 	  (e.g. an accelerated X server) and that are not frame buffer
 	  device-aware may cause unexpected results. If unsure, say N.
 
+config EDID_FIRMWARE
+	bool "Get EDID using the platform's firmware"
+	depends on X86
+	default n
+	help
+	  If you choose Y, the EDID (useful for setting video modes) will be
+	  acquired using a BIOS call before the kernel boots to protected mode.
+	  For computers with broken BIOSes, this can hang your computer. This can
+	  also be a very slow process.
+
+	  If unsure, choose N.
+
 config FB_CIRRUS
 	tristate "Cirrus Logic support"
 	depends on FB && (AMIGA || PCI) && BROKEN
diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/fbmon.c fbdev-2.6/drivers/video/fbmon.c
--- linus-2.6/drivers/video/fbmon.c	2004-01-27 14:17:12.000000000 -0800
+++ fbdev-2.6/drivers/video/fbmon.c	2004-01-27 11:55:32.000000000 -0800
@@ -828,42 +828,42 @@
 	printk("========================================\n");
 }
 
-#ifdef CONFIG_PPC_OF
-char *get_EDID_from_OF(struct pci_dev *pdev)
+#ifdef CONFIG_EDID_FIRMWARE
+char *get_EDID_from_Firmware(struct device *dev)
 {
+#ifdef CONFIG_PPC_OF
 	static char *propnames[] =
 	    { "DFP,EDID", "LCD,EDID", "EDID", "EDID1", NULL };
 	unsigned char *pedid = NULL;
 	struct device_node *dp;
+	struct pci_dev *pdev;
 	int i;
 
+	pdev = to_pci_dev(dev);
+	
 	if (pdev == NULL)
 		return NULL;
 	dp = pci_device_to_OF_node(pdev);
-	while (dp != NULL) {
+	while (dp) {
 		for (i = 0; propnames[i] != NULL; ++i) {
 			pedid = (unsigned char *) get_property(dp, propnames[i], NULL);
-			if (pedid != NULL)
+			if (pedid)
 				return pedid;
 		}
 		dp = dp->child;
 	}
-	show_edid(pedid);
-	return pedid;
-}
 #endif
-
 #ifdef CONFIG_X86
-char *get_EDID_from_BIOS(void *dummy)
-{
-	unsigned char *pedid = edid_info.dummy;
-	
+	unsigned char *pedid = NULL;
+
+	pedid = edid_info.dummy;
 	if (!pedid)
 		return NULL;
+#endif	
 	show_edid(pedid);
-	return pedid;				
+	return pedid;
 }
-#endif
+#endif /* CONFIG_EDID_FIRMWARE */
 
 /* 
  * VESA Generalized Timing Formula (GTF) 
@@ -1229,11 +1229,8 @@
 
 EXPORT_SYMBOL(parse_edid);
 EXPORT_SYMBOL(show_edid);
-#ifdef CONFIG_X86
-EXPORT_SYMBOL(get_EDID_from_BIOS);
-#endif
-#ifdef CONFIG_PPC_OF
-EXPORT_SYMBOL(get_EDID_from_OF);
+#ifdef CONFIG_EDID_FIRMWARE
+EXPORT_SYMBOL(get_EDID_from_Firmware);
 #endif
 EXPORT_SYMBOL(fb_get_monitor_limits);
 EXPORT_SYMBOL(fb_get_mode);



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Patch for review and testing

[Benjamin Herrenschmidt]

On Wed, 2004-01-28 at 07:07, James Simmons wrote:
> I like to submit this patch to linus today. Could you test it to see if it 
> works on ppcs. 

Well... you didn't update the drivers calling get_EDID_from_OF (I think
only rivafb at this point). Also, I plan to deprecate that function in
fbmon anyway, so don't bother, leave it alone for now. The way the
display/EDID infos are laid out in the OF device tree isn't that
generic and I'm considering letting each driver has its own version...

Also, that construct is plain wrong:

char *get_EDID_from_Firmware(struct device *dev)
{
        .../...
	pdev = to_pci_dev(dev);

Either pass a pci_dev in, or if not, at least check that you are
dealing with a pci device before casting struct device...

Finally, I don't see the point of submiting things to Linus at this
point, especially this patch which isn't critical (and you didn't even
submit driver changes for _using_ the new feature). Andrew is the
maintainer of current 2.6.x stable, patches have to go to him first,
stage in -mm for a while to be tested, and then go to Linus.

Ben.

> diff -urN -X /home/jsimmons/dontdiff linus-2.6/arch/i386/boot/video.S fbdev-2.6/arch/i386/boot/video.S
> --- linus-2.6/arch/i386/boot/video.S	2004-01-27 14:11:30.000000000 -0800
> +++ fbdev-2.6/arch/i386/boot/video.S	2004-01-27 13:28:20.000000000 -0800
> @@ -1889,6 +1889,7 @@
>  	ret
>  
>  store_edid:
> +#ifdef CONFIG_EDID_FIRMWARE
>  	pushw	%es				# just save all registers 
>  	pushw	%ax				
>  	pushw	%bx
> @@ -1919,6 +1920,7 @@
>  	popw	%bx
>  	popw	%ax
>  	popw	%es	
> +#endif         /* CONFIG_EDID_FIRMWARE */
>  	ret
>  
>  # VIDEO_SELECT-only variables
> diff -urN -X /home/jsimmons/dontdiff linus-2.6/arch/i386/kernel/setup.c fbdev-2.6/arch/i386/kernel/setup.c
> --- linus-2.6/arch/i386/kernel/setup.c	2004-01-27 14:11:32.000000000 -0800
> +++ fbdev-2.6/arch/i386/kernel/setup.c	2004-01-27 13:46:34.000000000 -0800
> @@ -105,7 +105,9 @@
>  	unsigned short length;
>  	unsigned char table[0];
>  };
> +#ifdef CONFIG_EDID_FIRMWARE
>  struct edid_info edid_info;
> +#endif /* CONFIG_EDID_FIRMWARE */
>  struct ist_info ist_info;
>  struct e820map e820;
>  
> @@ -1060,7 +1062,9 @@
>   	ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
>   	drive_info = DRIVE_INFO;
>   	screen_info = SCREEN_INFO;
> +#ifdef CONFIG_EDID_FIRMWARE
>  	edid_info = EDID_INFO;
> +#endif /* CONFIG_EDID_FIRMWARE */
>  	apm_info.bios = APM_BIOS_INFO;
>  	ist_info = IST_INFO;
>  	saved_videomode = VIDEO_MODE;
> diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/Kconfig fbdev-2.6/drivers/video/Kconfig
> --- linus-2.6/drivers/video/Kconfig	2004-01-27 14:17:11.000000000 -0800
> +++ fbdev-2.6/drivers/video/Kconfig	2004-01-27 11:46:36.000000000 -0800
> @@ -38,6 +38,18 @@
>  	  (e.g. an accelerated X server) and that are not frame buffer
>  	  device-aware may cause unexpected results. If unsure, say N.
>  
> +config EDID_FIRMWARE
> +	bool "Get EDID using the platform's firmware"
> +	depends on X86
> +	default n
> +	help
> +	  If you choose Y, the EDID (useful for setting video modes) will be
> +	  acquired using a BIOS call before the kernel boots to protected mode.
> +	  For computers with broken BIOSes, this can hang your computer. This can
> +	  also be a very slow process.
> +
> +	  If unsure, choose N.
> +
>  config FB_CIRRUS
>  	tristate "Cirrus Logic support"
>  	depends on FB && (AMIGA || PCI) && BROKEN
> diff -urN -X /home/jsimmons/dontdiff linus-2.6/drivers/video/fbmon.c fbdev-2.6/drivers/video/fbmon.c
> --- linus-2.6/drivers/video/fbmon.c	2004-01-27 14:17:12.000000000 -0800
> +++ fbdev-2.6/drivers/video/fbmon.c	2004-01-27 11:55:32.000000000 -0800
> @@ -828,42 +828,42 @@
>  	printk("========================================\n");
>  }
>  
> -#ifdef CONFIG_PPC_OF
> -char *get_EDID_from_OF(struct pci_dev *pdev)
> +#ifdef CONFIG_EDID_FIRMWARE
> +char *get_EDID_from_Firmware(struct device *dev)
>  {
> +#ifdef CONFIG_PPC_OF
>  	static char *propnames[] =
>  	    { "DFP,EDID", "LCD,EDID", "EDID", "EDID1", NULL };
>  	unsigned char *pedid = NULL;
>  	struct device_node *dp;
> +	struct pci_dev *pdev;
>  	int i;
>  
> +	pdev = to_pci_dev(dev);
> +	
>  	if (pdev == NULL)
>  		return NULL;
>  	dp = pci_device_to_OF_node(pdev);
> -	while (dp != NULL) {
> +	while (dp) {
>  		for (i = 0; propnames[i] != NULL; ++i) {
>  			pedid = (unsigned char *) get_property(dp, propnames[i], NULL);
> -			if (pedid != NULL)
> +			if (pedid)
>  				return pedid;
>  		}
>  		dp = dp->child;
>  	}
> -	show_edid(pedid);
> -	return pedid;
> -}
>  #endif
> -
>  #ifdef CONFIG_X86
> -char *get_EDID_from_BIOS(void *dummy)
> -{
> -	unsigned char *pedid = edid_info.dummy;
> -	
> +	unsigned char *pedid = NULL;
> +
> +	pedid = edid_info.dummy;
>  	if (!pedid)
>  		return NULL;
> +#endif	
>  	show_edid(pedid);
> -	return pedid;				
> +	return pedid;
>  }
> -#endif
> +#endif /* CONFIG_EDID_FIRMWARE */
>  
>  /* 
>   * VESA Generalized Timing Formula (GTF) 
> @@ -1229,11 +1229,8 @@
>  
>  EXPORT_SYMBOL(parse_edid);
>  EXPORT_SYMBOL(show_edid);
> -#ifdef CONFIG_X86
> -EXPORT_SYMBOL(get_EDID_from_BIOS);
> -#endif
> -#ifdef CONFIG_PPC_OF
> -EXPORT_SYMBOL(get_EDID_from_OF);
> +#ifdef CONFIG_EDID_FIRMWARE
> +EXPORT_SYMBOL(get_EDID_from_Firmware);
>  #endif
>  EXPORT_SYMBOL(fb_get_monitor_limits);
>  EXPORT_SYMBOL(fb_get_mode);
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Patch for review and testing

[James Simmons]

> > I like to submit this patch to linus today. Could you test it to see if it 
> > works on ppcs. 
> 
> Well... you didn't update the drivers calling get_EDID_from_OF (I think
> only rivafb at this point). 

The patch is against the vanilla tree. In the fbdev-2.5 tree I have to 
update rivafb for this. Actually I will remove that code from rivafb. 

> Also, I plan to deprecate that function in
> fbmon anyway, so don't bother, leave it alone for now. The way the
> display/EDID infos are laid out in the OF device tree isn't that
> generic and I'm considering letting each driver has its own version...

Then I will remove it.

> Also, that construct is plain wrong:
> 
> char *get_EDID_from_Firmware(struct device *dev)
> {
>         .../...
> 	pdev = to_pci_dev(dev);
> 
> Either pass a pci_dev in, or if not, at least check that you are
> dealing with a pci device before casting struct device...

That was to make the function generic. Well it doesn't matter as I'm going 
to remove the OF function so the pci stuff can go away.

> Finally, I don't see the point of submiting things to Linus at this
> point, especially this patch which isn't critical (and you didn't even
> submit driver changes for _using_ the new feature). 

Actually it is. The BIOS calls can hang some intel machines or make 
booting  up to 5 seconds longer waiting for the data. If this was not the 
case I wouldn't be submitting it.

> Andrew is the
> maintainer of current 2.6.x stable, patches have to go to him first,
> stage in -mm for a while to be tested, and then go to Linus.

This is just making the code conditional.  I will send another patch in a 
minute then.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Patch for review and testing

[Benjamin Herrenschmidt]

On Wed, 2004-01-28 at 09:09, James Simmons wrote:
> > > I like to submit this patch to linus today. Could you test it to see if it 
> > > works on ppcs. 
> > 
> > Well... you didn't update the drivers calling get_EDID_from_OF (I think
> > only rivafb at this point). 
> 
> The patch is against the vanilla tree. In the fbdev-2.5 tree I have to 
> update rivafb for this. Actually I will remove that code from rivafb. 
> 
> > Also, I plan to deprecate that function in
> > fbmon anyway, so don't bother, leave it alone for now. The way the
> > display/EDID infos are laid out in the OF device tree isn't that
> > generic and I'm considering letting each driver has its own version...
> 
> Then I will remove it.

Not yet, not until the new version is in. It does work someway with the
current code. Let me deal with those OF things please.

> That was to make the function generic. Well it doesn't matter as I'm going 
> to remove the OF function so the pci stuff can go away.

Actually, that may not be a good approach neither... You probably want
to check that you are indeed dealing with the default VGA device so an
additional card don't get an unrelated EDID, no ?

Also, other archs may want to implement this function too. Keep the
struct device as an argument, check for bus_type before casting to PCI,
and we should probably, in the x86 PCI code, "remember" the pci_dev of
the default VGA (if not done already) and compare it on calls to this
function. (To be completely clean, I also need to know if I'm the
primary VGA in radeonfb and aty128fb).
 
> > Finally, I don't see the point of submiting things to Linus at this
> > point, especially this patch which isn't critical (and you didn't even
> > submit driver changes for _using_ the new feature). 
> 
> Actually it is. The BIOS calls can hang some intel machines or make 
> booting  up to 5 seconds longer waiting for the data. If this was not the 
> case I wouldn't be submitting it.

What about a cmdline option then ? it's too early during boot to check
for it ? vendors will build kernels with or without the CONFIG_ option,
and people won't change it, so I'm afraid it will be useless... Is the
BIOS call standard ? There may be a way to workaround the hang, no ? Or
it's one of those calls that Windows never uses and are broken in half
of the BIOSes around ?

> > Andrew is the
> > maintainer of current 2.6.x stable, patches have to go to him first,
> > stage in -mm for a while to be tested, and then go to Linus.
> 
> This is just making the code conditional.  I will send another patch in a 
> minute then.
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Patch for review and testing

[James Simmons]

> > Then I will remove it.
> 
> Not yet, not until the new version is in. It does work someway with the
> current code. Let me deal with those OF things please.

Sorry. I will leave this alone then. I posted it just case there where 
conflicts with peoples work here. I will wait to send that patch. 
 
> Actually, that may not be a good approach neither... You probably want
> to check that you are indeed dealing with the default VGA device so an
> additional card don't get an unrelated EDID, no ?
> 
> Also, other archs may want to implement this function too. Keep the
> struct device as an argument, check for bus_type before casting to PCI,
> and we should probably, in the x86 PCI code, "remember" the pci_dev of
> the default VGA (if not done already) and compare it on calls to this
> function. (To be completely clean, I also need to know if I'm the
> primary VGA in radeonfb and aty128fb).

I knew this was going to be more complex than I written.

> What about a cmdline option then ? it's too early during boot to check
> for it ? 

Yes. The code is run in real mode before linux is started. 

> vendors will build kernels with or without the CONFIG_ option,
> and people won't change it, so I'm afraid it will be useless... Is the
> BIOS call standard ? 

Yes it is standard. 

> There may be a way to workaround the hang, no ? Or
> it's one of those calls that Windows never uses and are broken in half
> of the BIOSes around ?

I don't know of any work arounds. Its a small precentage but I like to 
make life easier for people. 

P.S.
   Have any idea to know which card is the primary one on intel. I have 
been trying to figure that one out for quite some time.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Re: Patch for review and testing

[Benjamin Herrenschmidt]

On Wed, 2004-01-28 at 09:59, James Simmons wrote:

> P.S.
>    Have any idea to know which card is the primary one on intel. I have 
> been trying to figure that one out for quite some time.

AFAIK, we need the arch/i386 PCI probe code to "remember", when probing,
which VGA card had the IO enable bit set. There can be only one, the primary
one since BIOSes only POST one card.

BTW. What about my set of patches ? Did you have time to have a look ?

Ben.
 



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Patch for review and testing

[Benjamin Herrenschmidt]

> Yes. The code is run in real mode before linux is started. 

Ok, I've chatted with some x86 folks, it should still be
possible to check the commandline (cmd_line_ptr defined
in setup.S).

Ben.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Patch for review and testing

[Benjamin Herrenschmidt]

On Wed, 2004-01-28 at 12:01, Benjamin Herrenschmidt wrote:
> > Yes. The code is run in real mode before linux is started. 
> 
> Ok, I've chatted with some x86 folks, it should still be
> possible to check the commandline (cmd_line_ptr defined
> in setup.S).

Actually, I discussed with Andi and he doesn't like the cmdline
neither...

He says that with an exception handler and an interrupt hooked
on the 8253 you can catch the crash and do a timeout :) Also,
we cna just blacklist those BIOSes... or find out how windows
calls this call and do the same (that would work :)

Ben




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Cursor patch.

[James Simmons]

I really like to create a cursor patch and push it main line. With this 
patch I coudl sync several drivers afterwards. What do you think?





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: Cursor patch.

[Andrew Morton]

James Simmons <jsimmons@infradead.org> wrote:
>
> 
> I really like to create a cursor patch and push it main line. With this 
> patch I coudl sync several drivers afterwards. What do you think?
> 

You can write the cursor patch, sync drivers to it, test them all together
then we can merge them all together.  There's no need to submit the cursor
patch earlier.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

New fb.h header

[James Simmons]

This header patch fixes the issue of building userland apps with fb.h. It 
also makes struct fb_pixmap a internal kernel object. Please apply.


--- linus-2.6/include/linux/fb.h	2004-01-27 19:50:11.000000000 -0800
+++ fbdev-2.6/include/linux/fb.h	2004-01-30 18:09:12.000000000 -0800
@@ -1,10 +1,7 @@
 #ifndef _LINUX_FB_H
 #define _LINUX_FB_H
 
-#include <linux/tty.h>
-#include <linux/workqueue.h>
 #include <asm/types.h>
-#include <asm/io.h>
 
 /* Definitions of frame buffers						*/
 
@@ -326,32 +323,49 @@
 	struct fb_image	image;	/* Cursor image */
 };
 
+#ifdef __KERNEL__
+
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/tty.h>
+#include <linux/device.h>
+#include <linux/workqueue.h>
+#include <linux/devfs_fs_kernel.h>
+#include <linux/notifier.h>
+#include <asm/io.h>
+
+struct vm_area_struct;
+struct fb_info;
+struct device;
+struct file;
+
+/*
+ * Pixmap structure definition
+ *
+ * The purpose of this structure is to translate data
+ * from the hardware independent format of fbdev to what
+ * format the hardware needs.
+ */
+
 #define FB_PIXMAP_DEFAULT 1     /* used internally by fbcon */
 #define FB_PIXMAP_SYSTEM  2     /* memory is in system RAM  */
 #define FB_PIXMAP_IO      4     /* memory is iomapped       */
 #define FB_PIXMAP_SYNC    256   /* set if GPU can DMA       */
 
 struct fb_pixmap {
-        __u8  *addr;                      /* pointer to memory             */  
-	__u32 size;                       /* size of buffer in bytes       */
-	__u32 offset;                     /* current offset to buffer      */
-	__u32 buf_align;                  /* byte alignment of each bitmap */
-	__u32 scan_align;                 /* alignment per scanline        */
-	__u32 flags;                      /* see FB_PIXMAP_*               */
+	u8 *addr;		/* pointer to memory                    */
+	u32 size;		/* size of buffer in bytes              */
+	u32 offset;		/* current offset to buffer             */
+	u32 buf_align;		/* byte alignment of each bitmap        */
+	u32 scan_align;		/* alignment per scanline               */
+	u32 access_align;	/* alignment per read/write             */
+	u32 flags;		/* see FB_PIXMAP_*                      */
 					  /* access methods                */
 	void (*outbuf)(u8 *dst, u8 *addr, unsigned int size); 
 	u8   (*inbuf) (u8 *addr);
 	spinlock_t lock;                  /* spinlock                      */
 	atomic_t count;
 };
-#ifdef __KERNEL__
-
-#include <linux/fs.h>
-#include <linux/init.h>
-
-struct fb_info;
-struct vm_area_struct;
-struct file;
 
     /*
      *  Frame buffer operations
@@ -362,37 +376,60 @@
     struct module *owner;
     int (*fb_open)(struct fb_info *info, int user);
     int (*fb_release)(struct fb_info *info, int user);
+
     /* For framebuffers with strange non linear layouts */	
-    ssize_t (*fb_read)(struct file *file, char *buf, size_t count, loff_t *ppos);
-    ssize_t (*fb_write)(struct file *file, const char *buf, size_t count, loff_t *ppos);	
-    /* checks var and creates a par based on it */
-    int (*fb_check_var)(struct fb_var_screeninfo *var, struct fb_info *info);
-    /* set the video mode according to par */
+	ssize_t(*fb_read) (struct file * file, char *buf, size_t count,
+			   loff_t * ppos);
+	ssize_t(*fb_write) (struct file * file, const char *buf,
+			    size_t count, loff_t * ppos);
+	
+	/* checks var and eventually tweaks it to something supported, 
+	 * DO NOT MODIFY PAR */
+	int (*fb_check_var) (struct fb_var_screeninfo * var,
+			     struct fb_info * info);
+	/* set the video mode according to info->var */
     int (*fb_set_par)(struct fb_info *info);
+
     /* set color register */
     int (*fb_setcolreg)(unsigned regno, unsigned red, unsigned green,
-                        unsigned blue, unsigned transp, struct fb_info *info);
+			     unsigned blue, unsigned transp,
+			     struct fb_info * info);
+
     /* blank display */
     int (*fb_blank)(int blank, struct fb_info *info);
+
     /* pan display */
-    int (*fb_pan_display)(struct fb_var_screeninfo *var, struct fb_info *info);
+	int (*fb_pan_display) (struct fb_var_screeninfo * var,
+			       struct fb_info * info);
+
     /* draws a rectangle */
-    void (*fb_fillrect)(struct fb_info *info, const struct fb_fillrect *rect); 
+	void (*fb_fillrect) (struct fb_info * info,
+			     const struct fb_fillrect * rect);
     /* Copy data from area to another */
-    void (*fb_copyarea)(struct fb_info *info,const struct fb_copyarea *region); 
+	void (*fb_copyarea) (struct fb_info * info,
+			     const struct fb_copyarea * region);
     /* Draws a image to the display */
-    void (*fb_imageblit)(struct fb_info *info, const struct fb_image *image);
+	void (*fb_imageblit) (struct fb_info * info,
+			      const struct fb_image * image);
+
     /* Draws cursor */
-    int (*fb_cursor)(struct fb_info *info, struct fb_cursor *cursor);
+	int (*fb_cursor) (struct fb_info * info,
+			  struct fb_cursor * cursor);
+
     /* Rotates the display */
     void (*fb_rotate)(struct fb_info *info, int angle);
+
     /* wait for blit idle, optional */
     int (*fb_sync)(struct fb_info *info);		
+
     /* perform fb specific ioctl (optional) */
-    int (*fb_ioctl)(struct inode *inode, struct file *file, unsigned int cmd,
-		    unsigned long arg, struct fb_info *info);
+	int (*fb_ioctl) (struct inode * inode, struct file * file,
+			 unsigned int cmd, unsigned long arg,
+			 struct fb_info * info);
+
     /* perform fb specific mmap */
-    int (*fb_mmap)(struct fb_info *info, struct file *file, struct vm_area_struct *vma);
+	int (*fb_mmap) (struct fb_info * info, struct file * file,
+			struct vm_area_struct * vma);
 };
 
 struct fb_info {
@@ -405,7 +442,7 @@
    struct fb_monspecs monspecs;         /* Current Monitor specs */
    struct fb_cursor cursor;		/* Current cursor */	
    struct work_struct queue;		/* Framebuffer event queue */
-   struct fb_pixmap pixmap;	        /* Current pixmap */
+	struct fb_pixmap pixmap;	/* Image Hardware Mapper */
    struct fb_cmap cmap;                 /* Current cmap */
    struct fb_ops *fbops;
    char *screen_base;                   /* Virtual address */
@@ -438,7 +475,7 @@
 #define fb_writeq sbus_writeq
 #define fb_memset sbus_memset_io
 
-#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || defined(__hppa__)
+#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || defined(__hppa__) || defined(__powerpc__)
 
 #define fb_readb __raw_readb
 #define fb_readw __raw_readw
@@ -482,11 +519,12 @@
 extern int fb_prepare_logo(struct fb_info *fb_info);
 extern int fb_show_logo(struct fb_info *fb_info);
 extern u32 fb_get_buffer_offset(struct fb_info *info, u32 size);
-extern void move_buf_unaligned(struct fb_info *info, u8 *dst, u8 *src, u32 d_pitch,
-			     	u32 height, u32 mask, u32 shift_high, u32 shift_low,
-				u32 mod, u32 idx);
-extern void move_buf_aligned(struct fb_info *info, u8 *dst, u8 *src, u32 d_pitch,
-			     u32 s_pitch, u32 height);
+extern void move_buf_unaligned(struct fb_info *info, u8 * dst, u8 * src,
+				u32 d_pitch, u32 height, u32 mask,
+				u32 shift_high, u32 shift_low, u32 mod,
+				u32 idx);
+extern void move_buf_aligned(struct fb_info *info, u8 * dst, u8 * src,
+				u32 d_pitch, u32 s_pitch, u32 height);
 extern struct fb_info *registered_fb[FB_MAX];
 extern int num_registered_fb;
 
@@ -517,8 +555,7 @@
 /* drivers/video/fbcmap.c */
 extern int fb_alloc_cmap(struct fb_cmap *cmap, int len, int transp);
 extern void fb_dealloc_cmap(struct fb_cmap *cmap);
-extern int fb_copy_cmap(struct fb_cmap *from, struct fb_cmap *to,
-			int fsfromto);
+extern int fb_copy_cmap(struct fb_cmap *from, struct fb_cmap *to, int fsfromto);
 extern int fb_set_cmap(struct fb_cmap *cmap, int kspc, struct fb_info *fb_info);
 extern struct fb_cmap *fb_default_cmap(int len);
 extern void fb_invert_cmaps(void);
@@ -541,7 +578,8 @@
 
 #ifdef MODULE
 static inline int fb_find_mode(struct fb_var_screeninfo *var,
-			       struct fb_info *info, const char *mode_option,
+			       struct fb_info *info,
+			       const char *mode_option,
 			       const struct fb_videomode *db,
 			       unsigned int dbsize,
 			       const struct fb_videomode *default_mode,
@@ -568,7 +606,8 @@
 }
 #else
 extern int __init fb_find_mode(struct fb_var_screeninfo *var,
-			       struct fb_info *info, const char *mode_option,
+			       struct fb_info *info,
+			       const char *mode_option,
 			       const struct fb_videomode *db,
 			       unsigned int dbsize,
 			       const struct fb_videomode *default_mode,



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: New fb.h header

[Andrew Morton]

James Simmons <jsimmons@infradead.org> wrote:
>
> This header patch fixes the issue of building userland apps with fb.h. It 
>  also makes struct fb_pixmap a internal kernel object. Please apply.

It breaks the ppc64 build.



drivers/video/cfbfillrect.c:141: warning: implicit declaration of function `__raw_writeq'
drivers/video/cfbfillrect.c:141: warning: implicit declaration of function `__raw_readq'
drivers/video/cfbimgblt.c: In function `color_imageblit':
drivers/video/cfbimgblt.c:110: warning: implicit declaration of function `__raw_readl'
drivers/video/cfbimgblt.c:122: warning: implicit declaration of function `__raw_writel'
drivers/video/cfbcopyarea.c: In function `bitcpy':
drivers/video/cfbcopyarea.c:68: warning: implicit declaration of function `__raw_writeq'
drivers/video/cfbcopyarea.c:68: warning: implicit declaration of function `__raw_readq'
drivers/built-in.o(.text+0x162d44): In function `.bitfill32':
: undefined reference to `.__raw_readq'
drivers/built-in.o(.text+0x162d60): In function `.bitfill32':
: undefined reference to `.__raw_writeq'
drivers/built-in.o(.text+0x162dc0): In function `.bitfill32':
: undefined reference to `.__raw_writeq'
drivers/built-in.o(.text+0x162df4): In function `.bitfill32':
: undefined reference to `.__raw_writeq'
drivers/built-in.o(.text+0x162e08): In function `.bitfill32':
: undefined reference to `.__raw_writeq'
drivers/built-in.o(.text+0x162e1c): In function `.bitfill32':
: undefined reference to `.__raw_writeq'
drivers/built-in.o(.text+0x162e30): more undefined references to `.__raw_writeq' follow
drivers/built-in.o(.text+0x162e9c): In function `.bitfill32':


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: New fb.h header

[Benjamin Herrenschmidt]

On Sun, 2004-02-01 at 11:49, Andrew Morton wrote:
> James Simmons <jsimmons@infradead.org> wrote:
> >
> > This header patch fixes the issue of building userland apps with fb.h. It 
> >  also makes struct fb_pixmap a internal kernel object. Please apply.
> 
> It breaks the ppc64 build.
> 
> 
> 
> drivers/video/cfbfillrect.c:141: warning: implicit declaration of function `__raw_writeq'
> drivers/video/cfbfillrect.c:141: warning: implicit declaration of function `__raw_readq'
> drivers/video/cfbimgblt.c: In function `color_imageblit':
> drivers/video/cfbimgblt.c:110: warning: implicit declaration of function `__raw_readl'
> drivers/video/cfbimgblt.c:122: warning: implicit declaration of function `__raw_writel'

I'd say the bug is in the ppc64 headers... I'll check that out tomorrow
with Anton.

Ben.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn