[PATCH 2/5] drivers/char/... convert #include linux/... to #include linux/...
(untested)
There are several files that
#include linux/file not #include linux/file
#include asm/file not #include asm/file
Here's a little script that converts them:
egrep -i -r -l --include=*.[ch] \
^[[:space:]]*\#[[:space:]]*include[[:space:]]*\(linux|asm)/(.*)\ * \
| xargs sed -i -e
's/^[[:space:]]*#[[:space:]]*include[[:space:]]*\(linux\|asm\)\/\(.*
\)/#include \1\/\2/g'
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/char/drm/drm_ioctl.c b/drivers/char/drm/drm_ioctl.c
index b195e10..902c4a1 100644
--- a/drivers/char/drm/drm_ioctl.c
+++ b/drivers/char/drm/drm_ioctl.c
@@ -36,7 +36,7 @@
#include drmP.h
#include drm_core.h
-#include linux/pci.h
+#include linux/pci.h
/**
* Get the bus id.
diff --git a/drivers/char/pcmcia/synclink_cs.c
b/drivers/char/pcmcia/synclink_cs.c
index 2b88931..4a186ed 100644
--- a/drivers/char/pcmcia/synclink_cs.c
+++ b/drivers/char/pcmcia/synclink_cs.c
@@ -87,7 +87,7 @@
#include asm/uaccess.h
-#include linux/synclink.h
+#include linux/synclink.h
static MGSL_PARAMS default_params = {
MGSL_MODE_HDLC, /* unsigned long mode */
diff --git a/drivers/char/synclink.c b/drivers/char/synclink.c
index fdc256b..eb1d90a 100644
--- a/drivers/char/synclink.c
+++ b/drivers/char/synclink.c
@@ -114,7 +114,7 @@
#include asm/uaccess.h
-#include linux/synclink.h
+#include linux/synclink.h
#define RCLRVALUE 0x
diff --git a/drivers/char/synclink_gt.c b/drivers/char/synclink_gt.c
index bbb7f12..cb3d061 100644
--- a/drivers/char/synclink_gt.c
+++ b/drivers/char/synclink_gt.c
@@ -81,7 +81,7 @@
#include asm/types.h
#include asm/uaccess.h
-#include linux/synclink.h
+#include linux/synclink.h
#if defined(CONFIG_HDLC) || (defined(CONFIG_HDLC_MODULE)
defined(CONFIG_SYNCLINK_GT_MODULE))
#define SYNCLINK_GENERIC_HDLC 1
diff --git a/drivers/char/synclinkmp.c b/drivers/char/synclinkmp.c
index c63013b..726581e 100644
--- a/drivers/char/synclinkmp.c
+++ b/drivers/char/synclinkmp.c
@@ -80,7 +80,7 @@
#include asm/uaccess.h
-#include linux/synclink.h
+#include linux/synclink.h
static MGSL_PARAMS default_params = {
MGSL_MODE_HDLC, /* unsigned long mode */
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: uncached page allocator
allocate pixmap gets cached memory copy data into the pixmap pre-use from hardware we flush the cache lines and tlb use the pixmap in hardware pre-free we need to set the page back to cached so we flush the tlb free the memory. Now the big issue here on SMP is that the cache and/or tlb flushes require IPIs and they are very noticeable on the profiles, Blame intel ;) Any other ideas and suggestions? Without knowing exactly what you are doing: - Copies to uncached memory are very expensive on an x86 processor (so it might be faster not to write and flush) - Its not clear from your description how intelligent your transfer system is. I'd expect for example that the process was something like Parse pending commands until either 1. Queue empties 2. A time target passes For each command we need to shove a pixmap over add it to the buffer to transfer Do a single CLFLUSH and maybe IPI Fire up the command queue Keep the buffers hanging around until there is memory pressure if we may reuse that pixmap Can you clarify that ? If the hugepage anti-frag stuff ever gets merged this would also help as you could possibly grab a huge page from the allocator for this purpose and have to flip only one TLB entry. Alan - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10224] r200 driver freezes with Radeon 8500
http://bugs.freedesktop.org/show_bug.cgi?id=10224 --- Comment #4 from [EMAIL PROTECTED] 2007-08-20 02:26 PST --- Mesa-7.0.1 compiled with -fno-strict-aliasing -fno-tree-vrp seems to behave better. I'll run more tests. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 9400] very hi cpu usage with a refreshing window
http://bugs.freedesktop.org/show_bug.cgi?id=9400 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||INVALID -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters Please be sure that if you design this using ioctls the design should be forward and backward compatible. AFAICS the only way to ensure this is some sort of tag-based parameter space (parameters are a list of tag,value pairs, terminated by a special tag). Otherwise you're stuck with one parameter list, which you cannot enhance easily, and version control both in user and kernel space will be a nightmare. With tags you can just ignore the tags you don't know about. I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? Because we won't get an ix86 emulator in kernel space, Linus and others have been pretty clear about that. Graphics hardware sometimes needs BIOS calls, on non-i386 hardware that has to be done by an emulator. This is just one reason. One other is that you want to address graphics in user space anyways for performance reason. Of course, mode setting isn't exactly performance critical. You just cannot compare graphics hardware with any other hardware at all. Graphics chips are more complicated than any CPU on the market, which other hardware type is similar? Even high-speed interconnects like infiniband are trivial compared to that. That said, I'm not 100% confident that the currently discussed way is the right solution. OTOH I don't know the right solution myself either... Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10726] Blender display corrupt
http://bugs.freedesktop.org/show_bug.cgi?id=10726 --- Comment #5 from [EMAIL PROTECTED] 2007-08-20 09:26 PST --- With the 7.0.1 version, blender crash : guessing 'blender-bin' == '/usr/bin/blender-bin' Compiled with Python version 2.4.4. Checking for installed Python... got it! /usr/bin/blender: line 46: 8958 Segmentation fault blender-bin $@ -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote: On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters Please be sure that if you design this using ioctls the design should be forward and backward compatible. AFAICS the only way to ensure this is some sort of tag-based parameter space (parameters are a list of tag,value pairs, terminated by a special tag). Otherwise you're stuck with one parameter list, which you cannot enhance easily, and version control both in user and kernel space will be a nightmare. With tags you can just ignore the tags you don't know about. Well, either that, or you can have a version field as the very first member (think: X11 requests), or simply bump the ioctl number every time you change the API (think: shared libraries). Cheers, Daniel signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote: Because we won't get an ix86 emulator in kernel space, Linus and others have been pretty clear about that. Graphics hardware sometimes needs BIOS calls, on non-i386 hardware that has to be done by an emulator. Post-boot, for the primary card, I don't know what hardware requires BIOS calls at ths point. We certainly shouldn't encourage people to build drivers that do. This is just one reason. One other is that you want to address graphics in user space anyways for performance reason. Of course, mode setting isn't exactly performance critical. Without mode setting capabilities in the kernel, we cannot get S3 support working reliably. What we've done, however, is split the mechanism from the policy so that the kernel piece does no more than actually drive the hardware; configuration and the rest remain in user space where they belong. You just cannot compare graphics hardware with any other hardware at all. Graphics chips are more complicated than any CPU on the market, which other hardware type is similar? Even high-speed interconnects like infiniband are trivial compared to that. The kernel driver manages video mode selection, memory, interrupts, DMA and the basic ring. The rest of the driver is in user space, including all of the complicated language compilation bits. That said, I'm not 100% confident that the currently discussed way is the right solution. OTOH I don't know the right solution myself either... The correct solution is a kernel driver that manages the card configuration and resources. Anything else eliminates many of the desirable benefits of providing a kernel driver in the first place. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
