[Bug 17889] s3v dri module calls undefined function s3vInitSpanFuncs
http://bugs.freedesktop.org/show_bug.cgi?id=17889 --- Comment #5 from Ian Romanick i...@freedesktop.org 2009-10-21 23:56:25 PST --- (In reply to comment #4) You probably won't ever get the code dropped from Mesa. I'd recommend finding somebody adventurous with the proper HW that wouldn't mind updating the driver and actually attempting to keep it. I'm not at home so I can't really check to see if I have one. Since this driver was never finish and has never worked, I vote to 'git rm -r' it. It's just an annoyance at this point. The last actually development commit to this driver (not just compile fixes) was in 2004. I won't hold my breath while we wait for someone to come along and care about this driver. If you want to finish it, anholt and I can give you a PILE of Virge cards next time you're in Portland. :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24281] Random noise on image when using clutter-gst
http://bugs.freedesktop.org/show_bug.cgi?id=24281 Andre Maasikas amaasi...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Andre Maasikas amaasi...@gmail.com 2009-10-21 23:56:53 PST --- Should be fixed in 869e20bcb7db9c6540eb6b538104303df738d302 7_6_branch currently -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24542] r600 vertex processing broken in mesa 7.7
http://bugs.freedesktop.org/show_bug.cgi?id=24542 --- Comment #4 from Andre Maasikas amaasi...@gmail.com 2009-10-22 00:04:55 PST --- The messages output are normal currently. Some of these will be fixed/removed in the future. The vp* mesa test programs currently don't work on r600 as the code doesn't yet support NV_vertex_program correctly. arb* variants should work though. I will add a TODO item for this also. Some simple programs will probaly only need loading correct NV parameters. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] drm/i915: support zero flicker boot
If the BIOS programs the native panel mode at boot and the boot loader
leaves it alone, we should be able to boot with zero flicker. This
patch fixes up the mode_switch test in drm_crtc_helper's set_config
function and adds code to the i915 display init function to set the
current CRTC mode and enable flag. If the eventual mode programmed
matches the current mode, we should have no need to turn the display
off and then on again.
Any thoughts? Peter you may already have a similar bit of code for the
testing you've been doing?
Jesse
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index fe86974..3c5abd8 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -753,9 +753,8 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
/* We should be able to check here if the fb has the same properties
* and then just flip_or_move it */
if (set-crtc-fb != set-fb) {
- /* If we have no fb then treat it as a full mode set */
- if (set-crtc-fb == NULL) {
- DRM_DEBUG_KMS(crtc has no fb, full mode set\n);
+ /* If the CRTC is off then treat it as a full mode set */
+ if (!set-crtc-enabled) {
mode_changed = true;
} else if (set-fb == NULL) {
mode_changed = true;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 298d317..ed60508 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3573,11 +3573,15 @@ struct drm_display_mode *intel_crtc_mode_get(struct
drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc-pipe;
struct drm_display_mode *mode;
+ int pipeconf = I915_READ((pipe == 0) ? PIPEACONF : PIPEBCONF);
int htot = I915_READ((pipe == 0) ? HTOTAL_A : HTOTAL_B);
int hsync = I915_READ((pipe == 0) ? HSYNC_A : HSYNC_B);
int vtot = I915_READ((pipe == 0) ? VTOTAL_A : VTOTAL_B);
int vsync = I915_READ((pipe == 0) ? VSYNC_A : VSYNC_B);
+ if (!(pipeconf PIPEACONF_ENABLE))
+ return NULL;
+
mode = kzalloc(sizeof(*mode), GFP_KERNEL);
if (!mode)
return NULL;
@@ -4310,6 +4314,29 @@ static void intel_init_display(struct drm_device *dev)
}
}
+/**
+ * intel_get_current_modes - get current mode timings for each CRTC
+ * @dev: DRM device
+ *
+ * Setting each CRTC's mode field with the current values can help us avoid
+ * flicker in the case where the BIOS already put us in a native mode.
+ */
+static void intel_get_current_modes(struct drm_device *dev)
+{
+ struct drm_crtc *crtc;
+ struct drm_display_mode *mode;
+
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
+ mode = intel_crtc_mode_get(dev, crtc);
+ if (!mode) {
+ crtc-enabled = false;
+ continue;
+ }
+ crtc-mode = *mode; /* copy the mode over */
+ kfree(mode);
+ }
+}
+
void intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -4362,6 +4389,8 @@ void intel_modeset_init(struct drm_device *dev)
intel_init_clock_gating(dev);
+ intel_get_current_modes(dev);
+
INIT_WORK(dev_priv-idle_work, intel_idle_update);
setup_timer(dev_priv-idle_timer, intel_gpu_idle_timer,
(unsigned long)dev);
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] drm/i915: support zero flicker boot
On Thu, 22 Oct 2009 08:24:42 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: Unfortunately it's basically a requirement for us to come up in VGA text mode right now - otherwise printk doesn't do anything until after i915 is up, which is a little excessive. Does the hardware absolutely require the LVDS be killed for programming? We have to fix up the LVDS -prepare hook to just un-write protect the timing regs. That should work on most chips for most operations (though I think we still have to shut things down to enable or disable the panel fitter). The early printk thing is a good point; we'll probably want to do something like ppc for debugging purposes: map the framebuffer passed to the kernel and use btext on it to catch early problems. Jesse -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
Ingo Molnar wrote:
* Jan Beulich jbeul...@novell.com wrote:
I'm perfectly fine with just handling the aligned case, as long as the
code checks that the alignment constraints are met.
It could even emit a debug warning if they are not met - that way we'll
see how important the unaligned case is.
OK, so I think the attached patches should do it. Hopefully I have addressed
all your comments.
This series works for my test machine, without it, or without X running, I
have these MTRR entries:
reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
reg01: base=0x06ff0 ( 1791MB), size=1MB, count=1: uncachable
reg02: base=0x07000 ( 1792MB), size= 256MB, count=1: uncachable
With the patches applied and X running I get these:
reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
reg01: base=0x06ff0 ( 1791MB), size=1MB, count=1: uncachable
reg02: base=0x07000 ( 1792MB), size= 256MB, count=1: uncachable
reg03: base=0x0d000 ( 3328MB), size= 256MB, count=1: write-combining
Best regards,
Thomas
From e946206915e3b023eb331499d73014105429200c Mon Sep 17 00:00:00 2001
From: Thomas Schlichter thomas.schlich...@web.de
Date: Sat, 17 Oct 2009 12:36:05 +0200
Subject: [PATCH 1/3] Make num_var_ranges accessible outside MTRR code
Code outside MTRR will have to remember which MTRR entries are used for a
given purpose. Therefore it has to access num_var_ranges which holds the
value of the maximum count of MTRR entries available. So we make this value
accessible from outside the core MTRR code.
Signed-off-by: Thomas Schlichter thomas.schlich...@web.de
---
arch/x86/include/asm/mtrr.h |2 ++
arch/x86/kernel/cpu/mtrr/mtrr.h |1 -
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index 4365ffd..1e7a824 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -72,6 +72,8 @@ typedef __u8 mtrr_type;
#define MTRR_NUM_FIXED_RANGES 88
#define MTRR_MAX_VAR_RANGES 256
+extern unsigned int num_var_ranges;
+
struct mtrr_state_type {
struct mtrr_var_range var_ranges[MTRR_MAX_VAR_RANGES];
mtrr_type fixed_ranges[MTRR_NUM_FIXED_RANGES];
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.h b/arch/x86/kernel/cpu/mtrr/mtrr.h
index a501dee..ba6a8a5 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.h
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.h
@@ -61,7 +61,6 @@ extern struct mtrr_ops *mtrr_if;
#define is_cpu(vnd) (mtrr_if mtrr_if-vendor == X86_VENDOR_##vnd)
#define use_intel() (mtrr_if mtrr_if-use_intel_if == 1)
-extern unsigned int num_var_ranges;
extern u64 mtrr_tom2;
extern struct mtrr_state_type mtrr_state;
--
1.6.5.1
From 7210888ded750f87f5509bdd5b95363a476ce307 Mon Sep 17 00:00:00 2001
From: Thomas Schlichter thomas.schlich...@web.de
Date: Sat, 17 Oct 2009 12:39:11 +0200
Subject: [PATCH 2/3] Provide per-file private data for bin sysfs files
For binary sysfs files, provide a per-file private field in struct bin_buffer.
To be easily accessible, it is located on head of the struct. Additionally add
a release() callback that may be used to e.g. free the private data on file
release.
Signed-off-by: Thomas Schlichter thomas.schlich...@web.de
---
fs/sysfs/bin.c| 10 +-
include/linux/sysfs.h |3 +++
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/fs/sysfs/bin.c b/fs/sysfs/bin.c
index 60c702b..28c039a 100644
--- a/fs/sysfs/bin.c
+++ b/fs/sysfs/bin.c
@@ -37,6 +37,7 @@
static DEFINE_MUTEX(sysfs_bin_lock);
struct bin_buffer {
+ void*private;
struct mutex mutex;
void*buffer;
intmmapped;
@@ -438,6 +439,13 @@ static int open(struct inode * inode, struct file * file)
static int release(struct inode * inode, struct file * file)
{
struct bin_buffer *bb = file-private_data;
+ struct sysfs_dirent *attr_sd = file-f_path.dentry-d_fsdata;
+ struct bin_attribute *attr = attr_sd-s_bin_attr.bin_attr;
+ struct kobject *kobj = attr_sd-s_parent-s_dir.kobj;
+ int rc = 0;
+
+ if (attr-release)
+ rc = attr-release(kobj, attr, file);
mutex_lock(sysfs_bin_lock);
hlist_del(bb-list);
@@ -445,7 +453,7 @@ static int release(struct inode * inode, struct file * file)
kfree(bb-buffer);
kfree(bb);
- return 0;
+ return rc;
}
const struct file_operations bin_fops = {
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 9d68fed..751ea68 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -19,6 +19,7 @@
struct kobject;
struct module;
+struct file;
/* FIXME
* The *owner field is no longer used.
@@ -72,6 +73,8 @@ struct bin_attribute {
char *, loff_t, size_t);
int (*mmap)(struct kobject *, struct bin_attribute *attr,
struct vm_area_struct *vma);
+ int (*release)(struct kobject *, struct bin_attribute *attr,
+ struct file *file);
};
struct sysfs_ops {
--
1.6.5.1
From e3317e73726152380cd05f75c87c433b9185b291 Mon Sep 17 00:00:00 2001
From: Thomas Schlichter
Re: [RFC] drm/i915: support zero flicker boot
Unfortunately it's basically a requirement for us to come up in VGA text mode right now - otherwise printk doesn't do anything until after i915 is up, which is a little excessive. Does the hardware absolutely require the LVDS be killed for programming? -- Matthew Garrett | mj...@srcf.ucam.org -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] drm/i915: support zero flicker boot
On 10/22/2009 03:42 PM, Jesse Barnes wrote: If the BIOS programs the native panel mode at boot and the boot loader leaves it alone, we should be able to boot with zero flicker. This patch fixes up the mode_switch test in drm_crtc_helper's set_config function and adds code to the i915 display init function to set the current CRTC mode and enable flag. If the eventual mode programmed matches the current mode, we should have no need to turn the display off and then on again. Any thoughts? Peter you may already have a similar bit of code for the testing you've been doing? Jesse I haven't, no, but when I get back to the U.S. I will test it with the native-video-mode bootloader I have. Unfortunately I don't have that machine with me. -hpa -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] drm/i915: support zero flicker boot
On Thu, 22 Oct 2009 16:45:49 +0900 H. Peter Anvin h...@zytor.com wrote: On 10/22/2009 03:42 PM, Jesse Barnes wrote: If the BIOS programs the native panel mode at boot and the boot loader leaves it alone, we should be able to boot with zero flicker. This patch fixes up the mode_switch test in drm_crtc_helper's set_config function and adds code to the i915 display init function to set the current CRTC mode and enable flag. If the eventual mode programmed matches the current mode, we should have no need to turn the display off and then on again. Any thoughts? Peter you may already have a similar bit of code for the testing you've been doing? Jesse I haven't, no, but when I get back to the U.S. I will test it with the native-video-mode bootloader I have. Unfortunately I don't have that machine with me. Oh and drm_modes_equal needs fixing to prevent it failing if just DRM_MODE_PREFERRED is different and everything else is equal. We should probably split flags for that between actual mode information and metadata like preferred. Jesse -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] drm/i915: support zero flicker boot
On Thu, 22 Oct 2009 16:45:49 +0900 H. Peter Anvin h...@zytor.com wrote: On 10/22/2009 03:42 PM, Jesse Barnes wrote: If the BIOS programs the native panel mode at boot and the boot loader leaves it alone, we should be able to boot with zero flicker. This patch fixes up the mode_switch test in drm_crtc_helper's set_config function and adds code to the i915 display init function to set the current CRTC mode and enable flag. If the eventual mode programmed matches the current mode, we should have no need to turn the display off and then on again. Any thoughts? Peter you may already have a similar bit of code for the testing you've been doing? Jesse I haven't, no, but when I get back to the U.S. I will test it with the native-video-mode bootloader I have. Unfortunately I don't have that machine with me. Arg, and I need to set crtc-enabled = true in the init function, not just false if the pipe is off. Jesse -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Changing radeon KMS cs+gem ioctl to merge read write domain
On Wed, 2009-10-21 at 18:49 -0700, Corbin Simpson wrote:
On 10/21/2009 03:49 PM, Jerome Glisse wrote:
Hi,
I think we should merge the read write domain of radeon KMS
into a single domains information. I don't think there is a
good reason for separate read write domain, we did copy intel
model for that and intel use this mostly for cache coherency
cache flushing as far as i understand. We make no good use of
this inside the kernel. In order to make this change less disruptive
and easier to introduce i propose we keep libdrm-radeon api
intact thus userspace xf86video-ati mesa 3d driver doesn't
need a single line patch to adapt. Attached is a proof of concept,
a patch against libdrm which merge read write domain and only
use the read domain to communicate with the kernel. I am still
in process of stress testing this patch but so far neither X
or 3D had any glitches.
I want to take advantage of this change to the cs reloc to the
following:
struct drm_radeon_cs_reloc {
»···uint32_t»···»···handle;
»···uint32_t»···»···domains;
»···uint32_t»···»···unused;
»···uint32_t»···»···flags;
};
With the following rules: a domain is a 4bit value (more than
enough i believe). Userspace can then provide domain preference
for each relocation. For instance :
0 Invalid|CPU
1 VRAM
2 GTT
domains = (VRAM 0) | (GTT 4)
would mean try to place object in VRAM first, if not enough
VRAM place it in GTT.
domains = (GTT 0)
object can only be in GTT
...
I believe this would be a lot more useful information that
read|write domain. We would also now assume that userspace
knows what it's doing inside a single submited cs and that
userspace issue necessary flush if a bo is used in different
way. Which is what the ddx does.
I believe the only argument in favor of read write split
is broken AGP chipset where GPU can't write to GART. So far
we don't use this information to work around the issue,
we don't even always test AGP writeback. Thus i believe this
change won't impact current user. Note that i am working on
code to work around bad AGP chipset (fallback to PCI GART
for GPU write + detection of broken writeback).
I really think we should take advantage of being in staging
driver to get the ioctl right before we have to freeze them.
No objections from me. If you have further ioctl changes, raising them
sooner rather than later would be *greatly* appreciated since I'm
probably the only person touching them in Gallium.
~ C.
This change should work without any update to gallium code. But
to take advantages of the placement list you would need to use
a new libdrm-radeon API for reloc.
Beside this merge i don't have in mind any other API change. Others
things i am working on are mostly kernel side only.
Cheers,
Jerome
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
On Wed, 2009-10-21 at 13:01 -0700, Thomas Schlichter wrote: OK, so I think the attached patches should do it. Hopefully I have addressed all your comments. Thomas, I have couple of issues with this patchset still. pci_mmap_page_range() doesn't get called for each fork(). So, we won't be ref counting the mtrr usage properly. I need to think a bit more carefully on this. Can I get back to you early next week on this, as I am traveling and need to think through this? We already keep track of some of the PAT ref counting using track_pfn_vma_copy(). And we need to extend/use something similar here. Even if we need to extend sysfs or pci vma ops, we need to increment and decrement the ref count of the mtrr register that gets used. There is no need to go through num_var_ranges etc. thanks, suresh -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24535] [KMS] KDE 4.3 causes lock up on RV620 (M82)
http://bugs.freedesktop.org/show_bug.cgi?id=24535 Stefano Carignano scary@gmail.com changed: What|Removed |Added CC||scary@gmail.com --- Comment #7 from Stefano Carignano scary@gmail.com 2009-10-22 04:42:21 PST --- Out of curiosity, are you using a preemptive kernel ? Do you observe a change in the behavior/survival rate when enabling preempt ? As I mentioned in bug #24587, enabling a preemptive kernel for me reduces the chance of survival to ~ 5% (I won't say 0 because I managed to have a working session with it once, out of 10-15 tries) Also, does suspend/resume work for you ? Or you too upon resume get the same lockup after a few seconds ? Is there something I could do to help debugging this thing a bit? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
On Thu, 2009-10-22 at 05:08 -0700, Thomas Schlichter wrote: When forking, what happens with the struct file? If it is being copied, then the processes share the same private data which would be freed during the first release(). I think this would be a problem whereever file-private data are used. So I think it must be shared between the forked processes and some reference counting must exist. This reference counting must ensure that release() is only called when all processes did close() their file. And in that case (shared struct file, one single release() call in the end) this implementation should be completely safe... I am referring to the refcount getting incremented. Also, let me think about your direction (as the pci_mmap_page_rane() is explicitly adding the mtrr, we should perhaps do the ref counting there, perhaps) There is no need to go through num_var_ranges etc. Well I have to remember wich file added which MTRR entries. Because I have to remove them if the file is being closed. Therefore I need an array of size num_var_ranges (or MTRR_MAX_VAR_RANGES which is the uper bound). No. the private data for example can keep track of a struct containing mtrr number and ref count etc. Exporting var_ranges and going through var ranges elements in an array is not clean, especially when you are populating only one element. thanks suresh -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
On 10/22/2009 09:08 PM, Thomas Schlichter wrote: I have couple of issues with this patchset still. pci_mmap_page_range() doesn't get called for each fork(). So, we won't be ref counting the mtrr usage properly. When forking, what happens with the struct file? If it is being copied, then the processes share the same private data which would be freed during the first release(). I think this would be a problem whereever file-private data are used. So I think it must be shared between the forked processes and some reference counting must exist. This reference counting must ensure that release() is only called when all processes did close() their file. And in that case (shared struct file, one single release() call in the end) this implementation should be completely safe... struct file is shared between forked processes. -hpa -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
On Thu, 2009-10-22 at 05:14 -0700, H. Peter Anvin wrote: On 10/22/2009 09:08 PM, Thomas Schlichter wrote: I have couple of issues with this patchset still. pci_mmap_page_range() doesn't get called for each fork(). So, we won't be ref counting the mtrr usage properly. When forking, what happens with the struct file? If it is being copied, then the processes share the same private data which would be freed during the first release(). I think this would be a problem whereever file-private data are used. So I think it must be shared between the forked processes and some reference counting must exist. This reference counting must ensure that release() is only called when all processes did close() their file. And in that case (shared struct file, one single release() call in the end) this implementation should be completely safe... struct file is shared between forked processes. That is correct. But I am referring to the ref-count getting incremented in Thomas's patch only in the pci_mmap_page_range() which will be called only during first mmap. We need to keep track of the counts of later forks too. For PAT, we keep track of this ref counting in track_pfn_vma_copy(). We shouldn't use different tracking mechanisms for PAT and non-PAT. We should cleanly tap into track_pfn_vma_copy() or extend that to cover this case aswell. thanks, suresh -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
Suresh Siddha wrote: On Wed, 2009-10-21 at 13:01 -0700, Thomas Schlichter wrote: OK, so I think the attached patches should do it. Hopefully I have addressed all your comments. Thomas, I have couple of issues with this patchset still. pci_mmap_page_range() doesn't get called for each fork(). So, we won't be ref counting the mtrr usage properly. When forking, what happens with the struct file? If it is being copied, then the processes share the same private data which would be freed during the first release(). I think this would be a problem whereever file-private data are used. So I think it must be shared between the forked processes and some reference counting must exist. This reference counting must ensure that release() is only called when all processes did close() their file. And in that case (shared struct file, one single release() call in the end) this implementation should be completely safe... I need to think a bit more carefully on this. Can I get back to you early next week on this, as I am traveling and need to think through this? Of course you can. But as I do this just in my spare time, I can only work on this in the evenings... We already keep track of some of the PAT ref counting using track_pfn_vma_copy(). And we need to extend/use something similar here. Even if we need to extend sysfs or pci vma ops, we need to increment and decrement the ref count of the mtrr register that gets used. The MTRR register ref count is already incremented with each mtrr_add() or mtrr_add_page() that has the increment parameter set to true. Which is the case in my implementation. There is no need to go through num_var_ranges etc. Well I have to remember wich file added which MTRR entries. Because I have to remove them if the file is being closed. Therefore I need an array of size num_var_ranges (or MTRR_MAX_VAR_RANGES which is the uper bound). Btw. if there really is a problem in my reference counting code, it also exists in the current code in: arch/x86/kernel/cpu/mtrr/if.c My patch borrows its ref-counting parts from there... Kind regards, Thomas -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24682] New: Xorg crashes with VirtualBox Client through tunneled ssh X11 session
http://bugs.freedesktop.org/show_bug.cgi?id=24682 Summary: Xorg crashes with VirtualBox Client through tunneled ssh X11 session Product: DRI Version: XOrg CVS Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: libdrm AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: emre...@gmail.com Created an attachment (id=30625) -- (http://bugs.freedesktop.org/attachment.cgi?id=30625) Xorg Crash Log SSH from Fedora 11 32-bit, xorg-x11-server-Xorg-1.6.4-0.1.fc11, to a server running CentOS EL 5.3 64-bit. I have an X11 tunnel set up so that I can start xclock, kdevelop, gedit with no problems and have it show up locally. However, when I attempt to start VirtualBox GUI through VirtualBox-3.0.8_53138_rhel5-1 it crashes my local Xserver. (The virtualbox gui is used to manage and control VirtualBox guests running on the remote server - there are no guests running yet because I can't get the manager to stop crashing my Xserver.) Other weirdness is that I must use a stock kernel 2.6.30* compiled from scratch in order to keep KMS enabled. Disabling KMS does not prevent the above reproducible crash. The crash does not happen if I start the VirtualBox manager locally on my box for guests located on my desktop: VirtualBox-3.0.8_53138_fedora11-1.i586 Video Card: 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) (prog-if 00 [VGA controller]) Subsystem: Compaq Computer Corporation Evo D510 SFF Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f000 (32-bit, prefetchable) [size=128M] Region 1: Memory at fc40 (32-bit, non-prefetchable) [size=512K] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 Kernel modules: i915 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24682] Xorg crashes with VirtualBox Client through tunneled ssh X11 session
http://bugs.freedesktop.org/show_bug.cgi?id=24682 Alan Coopersmith alan.coopersm...@sun.com changed: What|Removed |Added AssignedTo|dri-|gordon@intel.com |de...@lists.sourceforge.net | Component|libdrm |DRM/Intel --- Comment #1 from Alan Coopersmith alan.coopersm...@sun.com 2009-10-22 08:44:52 PST --- Log shows this backtrace: 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812d8eb] 1: /usr/bin/Xorg(xf86SigHandler+0x9e) [0x80c0e0e] 2: [0xb804e400] 3: /usr/lib/dri/i915_dri.so(intelDestroyContext+0x104) [0xb7e89388] 4: /usr/lib/dri/i915_dri.so [0xb7e6b476] 5: /usr/lib/xorg/modules/extensions//libglx.so [0xb7ffa359] 6: /usr/lib/xorg/modules/extensions//libglx.so(__glXFreeContext+0x91) [0xb7fee3d1] 7: /usr/lib/xorg/modules/extensions//libglx.so [0xb7fee427] 8: /usr/bin/Xorg(FreeClientResources+0xdf) [0x806e10f] 9: /usr/bin/Xorg(CloseDownClient+0x6f) [0x808108f] 10: /usr/bin/Xorg(Dispatch+0x1f0) [0x8086870] 11: /usr/bin/Xorg(main+0x395) [0x806bbf5] 12: /lib/libc.so.6(__libc_start_main+0xe6) [0x4c439a66] 13: /usr/bin/Xorg [0x806b0a1] Fatal server error: Caught signal 11. Server aborting -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24281] Random noise on image when using clutter-gst
http://bugs.freedesktop.org/show_bug.cgi?id=24281 --- Comment #6 from Kevin DeKorte kdeko...@yahoo.com 2009-10-22 10:59:01 PST --- commit f8bee0e412ef1e8d5aed884561999fd1bd182494 Merge: 5e77b61 1f5b568 Author: Alex Deucher alexdeuc...@gmail.com Date: Thu Oct 22 12:29:36 2009 -0400 Merge branch 'master' of git+ssh://ag...@git.freedesktop.org/git/mesa/mesa Appears to have fixed this issue... Thank you... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17889] s3v dri module calls undefined function s3vInitSpanFuncs
http://bugs.freedesktop.org/show_bug.cgi?id=17889 Corbin Simpson mostawesomed...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Corbin Simpson mostawesomed...@gmail.com 2009-10-22 12:32:08 PST --- Ah. If it doesn't work, then mercy killing is probably the way to go. Can always revive it from history if anybody decides to start caring about it. Closing as FIXED with commit 8e4657a. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms/r7xx: add regs for 40 bit CUR/GRPH addresses
From a8a7d447d4f781670a849e345f5f31edb975c397 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 22 Oct 2009 16:12:34 -0400
Subject: [PATCH] drm/radeon/kms/r7xx: add regs for 40 bit CUR/GRPH addresses
The *_HIGH regs are reversed. The secondary ones are in the
primary block and vice versa.
We currently only use a 32 bit internal address, so these are
0 for now.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/atombios_crtc.c | 10 ++
drivers/gpu/drm/radeon/r500_reg.h |9 +
drivers/gpu/drm/radeon/radeon_cursor.c | 10 --
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 0a9df66..e5a3c30 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -621,6 +621,16 @@ int atombios_crtc_set_base(struct drm_crtc *crtc,
int x, int y,
WREG32(AVIVO_D1VGA_CONTROL, 0);
else
WREG32(AVIVO_D2VGA_CONTROL, 0);
+
+ if (rdev-family = CHIP_RV770) {
+ if (radeon_crtc-crtc_id) {
+ WREG32(R700_D2GRPH_PRIMARY_SURFACE_ADDRESS_HIGH, 0);
+ WREG32(R700_D2GRPH_SECONDARY_SURFACE_ADDRESS_HIGH, 0);
+ } else {
+ WREG32(R700_D1GRPH_PRIMARY_SURFACE_ADDRESS_HIGH, 0);
+ WREG32(R700_D1GRPH_SECONDARY_SURFACE_ADDRESS_HIGH, 0);
+ }
+ }
WREG32(AVIVO_D1GRPH_PRIMARY_SURFACE_ADDRESS + radeon_crtc-crtc_offset,
(u32) fb_location);
WREG32(AVIVO_D1GRPH_SECONDARY_SURFACE_ADDRESS +
diff --git a/drivers/gpu/drm/radeon/r500_reg.h
b/drivers/gpu/drm/radeon/r500_reg.h
index 868add6..7baa739 100644
--- a/drivers/gpu/drm/radeon/r500_reg.h
+++ b/drivers/gpu/drm/radeon/r500_reg.h
@@ -384,9 +384,16 @@
# define AVIVO_D1GRPH_TILED (1 20)
# define AVIVO_D1GRPH_MACRO_ADDRESS_MODE (1 21)
+/* The R7xx *_HIGH surface regs are backwards; the D1 regs are in the D2
+ * block and vice versa. This applies to GRPH, CUR, etc.
+ */
#define AVIVO_D1GRPH_LUT_SEL0x6108
#define AVIVO_D1GRPH_PRIMARY_SURFACE_ADDRESS0x6110
+#define R700_D1GRPH_PRIMARY_SURFACE_ADDRESS_HIGH0x6914
+#define R700_D2GRPH_PRIMARY_SURFACE_ADDRESS_HIGH0x6114
#define AVIVO_D1GRPH_SECONDARY_SURFACE_ADDRESS 0x6118
+#define R700_D1GRPH_SECONDARY_SURFACE_ADDRESS_HIGH 0x691c
+#define R700_D2GRPH_SECONDARY_SURFACE_ADDRESS_HIGH 0x611c
#define AVIVO_D1GRPH_PITCH 0x6120
#define AVIVO_D1GRPH_SURFACE_OFFSET_X 0x6124
#define AVIVO_D1GRPH_SURFACE_OFFSET_Y 0x6128
@@ -404,6 +411,8 @@
# define AVIVO_D1CURSOR_MODE_MASK (3 8)
# define AVIVO_D1CURSOR_MODE_24BPP2
#define AVIVO_D1CUR_SURFACE_ADDRESS 0x6408
+#define R700_D1CUR_SURFACE_ADDRESS_HIGH 0x6c0c
+#define R700_D2CUR_SURFACE_ADDRESS_HIGH 0x640c
#define AVIVO_D1CUR_SIZE0x6410
#define AVIVO_D1CUR_POSITION0x6414
#define AVIVO_D1CUR_HOT_SPOT0x6418
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon_cursor.c
index b13c79e..28772a3 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -109,9 +109,15 @@ static void radeon_set_cursor(struct drm_crtc
*crtc, struct drm_gem_object *obj,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_device *rdev = crtc-dev-dev_private;
- if (ASIC_IS_AVIVO(rdev))
+ if (ASIC_IS_AVIVO(rdev)) {
+ if (rdev-family = CHIP_RV770) {
+ if (radeon_crtc-crtc_id)
+ WREG32(R700_D2CUR_SURFACE_ADDRESS_HIGH, 0);
+ else
+ WREG32(R700_D1CUR_SURFACE_ADDRESS_HIGH, 0);
+ }
WREG32(AVIVO_D1CUR_SURFACE_ADDRESS + radeon_crtc-crtc_offset,
gpu_addr);
- else {
+ } else {
radeon_crtc-legacy_cursor_offset = gpu_addr -
radeon_crtc-legacy_display_base_addr;
/* offset is from DISP(2)_BASE_ADDRESS */
WREG32(RADEON_CUR_OFFSET + radeon_crtc-crtc_offset,
radeon_crtc-legacy_cursor_offset);
--
1.5.6.3
From a8a7d447d4f781670a849e345f5f31edb975c397 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 22 Oct 2009 16:12:34 -0400
Subject: [PATCH] drm/radeon/kms/r7xx: add regs for 40 bit CUR/GRPH addresses
The *_HIGH regs are reversed. The secondary ones are in the
primary block and vice versa.
We currently only use a 32 bit internal address, so these are
0 for now.
Signed-off-by: Alex
Re: [RFC Patch] use MTRR for write combining if PAT is not available
On Thu, 22 Oct 2009 14:47:30 -0700 Suresh Siddha suresh.b.sid...@intel.com wrote: On Thu, 2009-10-22 at 08:34 -0700, Eric Anholt wrote: Can we just not create the _wc sysfs entry if we don't have PAT? I don't think there's userland relying on its presence as opposed to the non-_wc entry. Yes indeed. Jesse do you see an issue with this? This is simple and clean. Thanks Eric. Yeah, I think that will be fine. In fact, older versions of libpciaccess will behave better if we do it that way (iirc it only allocates an MTRR if the resource_wc file doesn't exist or fails to get mapped). Jesse -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
On Thu, 2009-10-22 at 17:11 -0700, Suresh Siddha wrote: On Thu, 2009-10-22 at 16:10 -0700, Jesse Barnes wrote: On Thu, 22 Oct 2009 14:47:30 -0700 Suresh Siddha suresh.b.sid...@intel.com wrote: On Thu, 2009-10-22 at 08:34 -0700, Eric Anholt wrote: Can we just not create the _wc sysfs entry if we don't have PAT? I don't think there's userland relying on its presence as opposed to the non-_wc entry. Yes indeed. Jesse do you see an issue with this? This is simple and clean. Thanks Eric. Yeah, I think that will be fine. In fact, older versions of libpciaccess will behave better if we do it that way (iirc it only allocates an MTRR if the resource_wc file doesn't exist or fails to get mapped). Eric, care to send the patch? I don't have a patch, I was just suggesting a way to handle the submitter's problem that won't involve complicated changes that nobody else will be testing since everyone *should* have a graphics driver for their graphics hardware. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
On Thu, 22 Oct 2009 18:53:19 -0700
Eric Anholt e...@anholt.net wrote:
On Thu, 2009-10-22 at 17:11 -0700, Suresh Siddha wrote:
On Thu, 2009-10-22 at 16:10 -0700, Jesse Barnes wrote:
On Thu, 22 Oct 2009 14:47:30 -0700
Suresh Siddha suresh.b.sid...@intel.com wrote:
On Thu, 2009-10-22 at 08:34 -0700, Eric Anholt wrote:
Can we just not create the _wc sysfs entry if we don't have
PAT? I don't think there's userland relying on its presence
as opposed to the non-_wc entry.
Yes indeed. Jesse do you see an issue with this? This is simple
and clean. Thanks Eric.
Yeah, I think that will be fine. In fact, older versions of
libpciaccess will behave better if we do it that way (iirc it only
allocates an MTRR if the resource_wc file doesn't exist or fails
to get mapped).
Eric, care to send the patch?
I don't have a patch, I was just suggesting a way to handle the
submitter's problem that won't involve complicated changes that nobody
else will be testing since everyone *should* have a graphics driver
for their graphics hardware.
Here's a quick dirty version, totally untested. A cleaner approach
would be to separate the WC mapping routines and hide the return
-EINVAL in arch specific code...
Jesse
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 0f6382f..41010bb 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -23,6 +23,9 @@
#include linux/mm.h
#include linux/capability.h
#include linux/pci-aspm.h
+#ifdef CONFIG_X86
+#include asm/pat.h
+#endif
#include pci.h
static int sysfs_initialized; /* = 0 */
@@ -730,6 +733,10 @@ static int
pci_mmap_resource_wc(struct kobject *kobj, struct bin_attribute *attr,
struct vm_area_struct *vma)
{
+#ifdef CONFIG_X86
+ if (!pat_enabled)
+ return -EINVAL;
+#endif
return pci_mmap_resource(kobj, attr, vma, 1);
}
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
