Re: [git pull] drm request 3
On Thu, Mar 04, 2010 at 03:53:32PM -0800, Linus Torvalds wrote: Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are you guys simply planning on never supporting F12 with 2.6.34? I'd expect it to be a _major_ pain to have that whole hardcoded X and kernel must always change in lockstep. Frankly, I completely agree with you. This kind of shit makes it extremely difficult for users to run, say, 2.6.33 on F-12 without us doing a backport. Thankfully Ben takes care of that for me, usually, by keeping nouveau up to date with upstream in the various Fedora's, but it's still a set of shackles that I'm pretty sure none of us want. (Not only that, but it means if you update, you may need to do a full reboot before you can start X again, which is pretty disappointing.) For example, right now, Fedora 11's 2.6.30 kernel has nouveau 12, with nouveau 12 userspace. For Fedora 11's 2.6.32 kernel, instead of updating the userspace stuff, I forward ported the old DRM entirely, bringing with it whatever bugs it had, simply because DRM is such a nightmare. It's already impossible to run Fedora 13's 2.6.33 kernel on 12 since Ben put the nouveau git changes for the new ABI in there already. So we'll have to drop those from the F-13 2.6.33 for the F-12 2.6.33... This situation /sucks/ for users. Personally, I think we committed to a stable update ABI when nouveau got a MODULE_DEVICE_TABLE and started binding by default. But hey, I'm just the kernel maintainer, and I didn't pipe up then, which was my mistake. If we're going to ram something at users by default, we should at least try to guarantee that they'll be able to restart X and have things continue to work. That said, whether you think it's a lame excuse or not, staging was clearly labelled as buyer beware. I'm personally sorry that you got burned by nouveau on Fedora both these times, but we're really just trying to help, and not hinder things. (Maybe I should commit a patch to rip out the module aliases for nouveau, but I suspect I'd have more people screaming for blood that way. Sigh.) regards, Kyle -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vgaarb: fix target=default passing
From: Kyle McMartin k...@redhat.com
Commit 77c1ff3982c6b36961725dd19e872a1c07df7f3b fixed the userspace
pointer dereference, but introduced another bug pointed out by Eugene Teo
in RH bug #564264. Instead of comparing the point we were at in the string,
we instead compared the beginning of the string to default.
Signed-off-by: Kyle McMartin k...@redhat.com
Reported-by: Eugene Teo e...@redhat.com
---
drivers/gpu/vga/vgaarb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 24b56dc..2f6cf69 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -961,7 +961,7 @@ static ssize_t vga_arb_write(struct file *file, const char
__user * buf,
remaining -= 7;
pr_devel(client 0x%p called 'target'\n, priv);
/* if target is default */
- if (!strncmp(kbuf, default, 7))
+ if (!strncmp(curr_pos, default, 7))
pdev = pci_dev_get(vga_default_device());
else {
if (!vga_pci_str_to_vars(curr_pos, remaining,
--
1.6.6
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On Thu, Dec 10, 2009 at 04:32:56PM -0800, Linus Torvalds wrote: patches welcome The problem is that I have never even heard a Red Hat or Fedora person actually acknoledge that yes, they should be trying to upstream it. Have Red Hat and Fedora just decided that upstream first simply doesn't matter any more? Because quite frankly, that was kind of the feeling I came away with from the Kernel summit. Well, given that none of the Fedora kernel people were able to attend this year for a variety of reasons, this is an interesting revelation to me, I wasn't aware I thought this. I, for one, would very much like nouveau to be upstream. It would certainly make my life easier not having to worry about subtlely breaking graphics adapters I can't test whenever we rebase to new git changes in the DRM. Thankfully Ben and Dave have been ninja at dealing with it, otherwise I probably would have punted it by now. It's like they _want_ to keep it internal. regards, Kyle -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE
On Wed, May 27, 2009 at 10:40:12AM -0700, Eric Anholt wrote: On Wed, 2009-05-27 at 08:42 +0800, Shaohua Li wrote: On Wed, May 27, 2009 at 08:18:40AM +0800, Kyle McMartin wrote: On Tue, May 26, 2009 at 11:55:50PM +0100, Hugh Dickins wrote: I'm confused: I thought GFP_DMA32 only applies on x86_64: my 32-bit PAE machine with (slightly!) 4GB shows no ZONE_DMA32. Does this patch perhaps depend on another, to enable DMA32 on 32-bit PAE, or am I just in a muddle? No, you're exactly right, I'm just a muppet and missed the obvious. Looks like the correct fix is the fact that the allocation is thus filled out with GFP_USER, therefore, from ZONE_NORMAL, and below max_low_pfn. Looks like we'll need some additional thinking to get true ZONE_DMA32 on i386... ugh, I'll look into it tonight. For i386, GFP_USER is enough. But 945G GART can only map to physical page 4G, so for x64, we need GFP_DMA32. This is the reason I add extra GFP_DMA32. Those 945Gs don't have memory located above 4G, from my reading of the chipset specs. Indeed, I thought they were clipped to 3G memory, max. (I assume we mean 945 in the strictest sense, and not son of 945 like the G33 series?) (But yeah, the ifdef in my patch should be nuked strictly, I guess.) cheers, Kyle -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE
On Tue, May 26, 2009 at 11:41:25PM +0200, Peter Zijlstra wrote: On Tue, 2009-05-26 at 14:35 -0700, Eric Anholt wrote: On Tue, 2009-05-26 at 21:17 +0200, Peter Zijlstra wrote: On Tue, 2009-05-26 at 12:27 -0400, Kyle McMartin wrote: From: Kyle McMartin k...@redhat.com Ensure we allocate GEM objects below 4GB on PAE machines, otherwise misery ensues. This patch is based on a patch found on dri-devel by Shaohua Li, but Keith P. expressed reticence that the changes unfairly penalized other hardware. (The mm/shmem.c hunk is necessary to ensure the DMA32 flag isn't used by the slab allocator via radix_tree_preload, which will hit a WARN_ON.) Why is this, is the gart not PAE friendly? Seems to me its a grand way of promoting 64bit hard/soft-ware. No, the GART's fine. But the APIs required to make the AGP code PAE-friendly got deprecated, so the patches to fix the AGP code got NAKed, and Venkatesh never sent out his patches to undeprecate the APIs and use them. It's been like 6 months now, and it's absurd. I'd like to see this patch go in so people's graphics can start working again and stop corrupting system memory. For .30 yes, for .31 we need to resolve that AGP issue, 6 months does seem excessive to get something like that sorted. Yeah, sorry, I should have explained it in the description better, this is just a paper-over fix for the problem on 4GB 32-bit machines (which is why I CC'd sta...@.) Thanks, Kyle -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: i915: ensure objects are allocated below 4GB on PAE
From: Kyle McMartin k...@redhat.com
Ensure we allocate GEM objects below 4GB on PAE machines, otherwise
misery ensues. This patch is based on a patch found on dri-devel by
Shaohua Li, but Keith P. expressed reticence that the changes unfairly
penalized other hardware.
(The mm/shmem.c hunk is necessary to ensure the DMA32 flag isn't used
by the slab allocator via radix_tree_preload, which will hit a
WARN_ON.)
Signed-off-by: Kyle McMartin k...@redhat.com
---
We're shipping a variant of this in Fedora 11 to fix a myriad of bugs on
PAE hardware.
cheers, Kyle
---
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4984aa8..ae52edc 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -142,6 +142,9 @@ drm_gem_object_alloc(struct drm_device *dev, size_t size)
return NULL;
}
+ if (dev-gem_flags)
+ mapping_set_gfp_mask(obj-filp-f_mapping, dev-gem_flags);
+
kref_init(obj-refcount);
kref_init(obj-handlecount);
obj-size = size;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 53d5445..c89ae3d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1153,12 +1153,12 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
}
#ifdef CONFIG_HIGHMEM64G
- /* don't enable GEM on PAE - needs agp + set_memory_* interface fixes */
- dev_priv-has_gem = 0;
-#else
+ /* avoid allocating buffers above 4GB on PAE */
+ dev-gem_flags = GFP_USER | GFP_DMA32;
+#endif
+
/* enable GEM by default */
dev_priv-has_gem = 1;
-#endif
dev-driver-get_vblank_counter = i915_get_vblank_counter;
if (IS_GM45(dev))
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c8c4221..3744c1f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1019,6 +1019,7 @@ struct drm_device {
uint32_t gtt_total;
uint32_t invalidate_domains;/* domains pending invalidation */
uint32_t flush_domains; /* domains pending flush */
+ gfp_t gem_flags;/* object allocation flags */
/*...@} */
};
diff --git a/mm/shmem.c b/mm/shmem.c
index b25f95c..e615887 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1241,7 +1241,7 @@ repeat:
* Try to preload while we can wait, to not make a habit of
* draining atomic reserves; but don't latch on to this cpu.
*/
- error = radix_tree_preload(gfp ~__GFP_HIGHMEM);
+ error = radix_tree_preload(gfp ~(__GFP_HIGHMEM|__GFP_DMA32));
if (error)
goto failed;
radix_tree_preload_end();
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE
On Tue, May 26, 2009 at 11:55:50PM +0100, Hugh Dickins wrote: I'm confused: I thought GFP_DMA32 only applies on x86_64: my 32-bit PAE machine with (slightly!) 4GB shows no ZONE_DMA32. Does this patch perhaps depend on another, to enable DMA32 on 32-bit PAE, or am I just in a muddle? No, you're exactly right, I'm just a muppet and missed the obvious. Looks like the correct fix is the fact that the allocation is thus filled out with GFP_USER, therefore, from ZONE_NORMAL, and below max_low_pfn. Looks like we'll need some additional thinking to get true ZONE_DMA32 on i386... ugh, I'll look into it tonight. regards, Kyle -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH trivial] drm: i915: i915_modeset is signed
From: Kyle McMartin k...@redhat.com Signed-off-by: Kyle McMartin k...@redhat.com --- drivers/gpu/drm/i915/i915_drv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 98560e1..06600d1 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -36,7 +36,7 @@ #include drm_pciids.h #include linux/console.h -static unsigned int i915_modeset = -1; +static int i915_modeset = -1; module_param_named(modeset, i915_modeset, int, 0400); unsigned int i915_fbpercrtc = 0; -- 1.6.2.2 -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: edid: don't fail to build on big endian
From: Kyle McMartin k...@redhat.com
Currently, DRM only accidently builds on powerpc/sparc64/etc, because
the #ifdef in drm_edid.h was using BIG_ENDIAN instead of __BIG_ENDIAN.
Since there's currently no driver which can use this on powerpc at the
moment (radeon modesetting is not upstream yet...) instead of failing to
build the entire DRM because of it, just bail out in the individual
EDID functions.
Signed-off-by: Kyle McMartin k...@redhat.com
---
I'll try update the drm_edid.h header to properly handle big endian, but
since I'm lacking a powerpc box at the moment, and I can't currently
test the DRM on parisc, someone else will have to test it for me. :)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a839a28..3357394 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -551,6 +551,7 @@ static int add_detailed_info(struct drm_connector
*connector,
#define DDC_ADDR 0x50
+#ifdef __LITTLE_ENDIAN
unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter *adapter)
{
unsigned char start = 0x0;
@@ -582,6 +583,13 @@ unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter
*adapter)
kfree(buf);
return NULL;
}
+#else
+unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter *adapter)
+{
+ dev_info(adapter-dev, EDID unsupported on big endian.\n);
+ return NULL;
+}
+#endif /*__BIG_ENDIAN*/
EXPORT_SYMBOL(drm_do_probe_ddc_edid);
static unsigned char *drm_ddc_read(struct i2c_adapter *adapter)
@@ -653,6 +661,7 @@ static unsigned char *drm_ddc_read(struct i2c_adapter
*adapter)
*
* Return edid data or NULL if we couldn't find any.
*/
+#ifdef __LITTLE_ENDIAN
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
@@ -675,6 +684,15 @@ struct edid *drm_get_edid(struct drm_connector *connector,
return edid;
}
+#else
+struct edid *drm_get_edid(struct drm_connector *connector,
+ struct i2c_adapter *adapter)
+{
+ dev_warn(connector-dev-pdev-dev, %s: EDID unsupported on big
endian.\n,
+ drm_get_connector_name(connector));
+ return NULL;
+}
+#endif /*__BIG_ENDIAN*/
EXPORT_SYMBOL(drm_get_edid);
/**
@@ -686,6 +704,7 @@ EXPORT_SYMBOL(drm_get_edid);
*
* Return number of modes added or 0 if we couldn't find any.
*/
+#ifdef __LITTLE_ENDIAN
int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
{
int num_modes = 0;
@@ -729,4 +748,12 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
return num_modes;
}
+#else
+int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
+{
+ dev_warn(connector-dev-pdev-dev, %s: EDID unsupported on big
endian.\n,
+drm_get_connector_name(connector));
+ return 0;
+}
+#endif /*__BIG_ENDIAN*/
EXPORT_SYMBOL(drm_add_edid_modes);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index ff8d27a..244133b 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -28,10 +28,6 @@
#define EDID_LENGTH 128
#define DDC_ADDR 0x50
-#ifdef BIG_ENDIAN
-#error EDID structure is little endian, need big endian versions
-#else
-
struct est_timings {
u8 t1;
u8 t2;
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: edid: don't fail to build on big endian
On Thu, Feb 26, 2009 at 12:23:27PM -0500, Kyle McMartin wrote:
From: Kyle McMartin k...@redhat.com
Currently, DRM only accidently builds on powerpc/sparc64/etc, because
the #ifdef in drm_edid.h was using BIG_ENDIAN instead of __BIG_ENDIAN.
Since there's currently no driver which can use this on powerpc at the
moment (radeon modesetting is not upstream yet...) instead of failing to
build the entire DRM because of it, just bail out in the individual
EDID functions.
Signed-off-by: Kyle McMartin k...@redhat.com
Ugh, I noviced a hand-edit of that email. My bad.
---
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a839a28..3357394 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -551,6 +551,7 @@ static int add_detailed_info(struct drm_connector
*connector,
#define DDC_ADDR 0x50
+#ifdef __LITTLE_ENDIAN
unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter *adapter)
{
unsigned char start = 0x0;
@@ -582,6 +583,13 @@ unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter
*adapter)
kfree(buf);
return NULL;
}
+#else
+unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter *adapter)
+{
+ dev_info(adapter-dev, EDID unsupported on big endian.\n);
+ return NULL;
+}
+#endif /*__BIG_ENDIAN*/
EXPORT_SYMBOL(drm_do_probe_ddc_edid);
static unsigned char *drm_ddc_read(struct i2c_adapter *adapter)
@@ -653,6 +661,7 @@ static unsigned char *drm_ddc_read(struct i2c_adapter
*adapter)
*
* Return edid data or NULL if we couldn't find any.
*/
+#ifdef __LITTLE_ENDIAN
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
@@ -675,6 +684,15 @@ struct edid *drm_get_edid(struct drm_connector *connector,
return edid;
}
+#else
+struct edid *drm_get_edid(struct drm_connector *connector,
+ struct i2c_adapter *adapter)
+{
+ dev_warn(connector-dev-pdev-dev, %s: EDID unsupported on big
endian.\n,
+ drm_get_connector_name(connector));
+ return NULL;
+}
+#endif /*__BIG_ENDIAN*/
EXPORT_SYMBOL(drm_get_edid);
/**
@@ -686,6 +704,7 @@ EXPORT_SYMBOL(drm_get_edid);
*
* Return number of modes added or 0 if we couldn't find any.
*/
+#ifdef __LITTLE_ENDIAN
int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
{
int num_modes = 0;
@@ -729,4 +748,12 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
return num_modes;
}
+#else
+int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid)
+{
+ dev_warn(connector-dev-pdev-dev, %s: EDID unsupported on big
endian.\n,
+drm_get_connector_name(connector));
+ return 0;
+}
+#endif /*__BIG_ENDIAN*/
EXPORT_SYMBOL(drm_add_edid_modes);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index ff8d27a..918b619 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -28,10 +28,6 @@
#define EDID_LENGTH 128
#define DDC_ADDR 0x50
-#ifdef BIG_ENDIAN
-#error EDID structure is little endian, need big endian versions
-#else
-
struct est_timings {
u8 t1;
u8 t2;
@@ -195,8 +191,6 @@ struct edid {
u8 checksum;
} __attribute__((packed));
-#endif /* little endian structs */
-
#define EDID_PRODUCT_ID(e) ((e)-prod_code[0] | ((e)-prod_code[1] 8))
#endif /* __DRM_EDID_H__ */
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: edid revision 0 is valid
From: Kyle McMartin k...@redhat.com
edid-revision == 0 should be valid (at least, so the error message
indicates. :) and wikipedia seems to indicate that EDID 1.0 existed.
We can dump the entire check, since edid-revision is a u8, so
it can't ever be less than 0.
Marko reports in RH bz#476735 that his monitor claims to be
EDID 1.0, and therefore hits the check and is stuck at 800x600 because
of it.
Reported-by: Marko Ristola marko.rist...@kolumbus.fi
Signed-off-by: Kyle McMartin k...@redhat.com
---
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5a4d324..ec14dd8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -125,7 +125,7 @@ static bool edid_is_valid(struct edid *edid)
DRM_ERROR(EDID has major version %d, instead of 1\n,
edid-version);
goto bad;
}
- if (edid-revision = 0 || edid-revision 3) {
+ if (edid-revision 3) {
DRM_ERROR(EDID has minor version %d, which is not between
0-3\n, edid-revision);
goto bad;
}
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
i915: fix invalid opcode exception on cpus without clflush
i915_flush_ttm was unconditionally executing a clflush instruction
to (obviously) flush the cache. Instead, check if the cpu supports
clflush, and if not, fall back to calling wbinvd to flush the entire
cache.
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
--- a/linux-core/i915_buffer.c
+++ b/linux-core/i915_buffer.c
@@ -286,7 +286,18 @@ void i915_flush_ttm(struct drm_ttm *ttm)
return;
DRM_MEMORYBARRIER();
+
+#ifdef CONFIG_X86_32
+ /* Hopefully nobody has built an x86-64 processor without clflush */
+ if (!cpu_has_clflush) {
+ wbinvd();
+ DRM_MEMORYBARRIER();
+ return;
+ }
+#endif
+
for (i = ttm-num_pages - 1; i = 0; i--)
drm_cache_flush_page(drm_ttm_get_page(ttm, i));
+
DRM_MEMORYBARRIER();
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: G33 graphics broken after 2.6.23-rc6
On Fri, Oct 05, 2007 at 08:20:01PM -0400, Matthew Reppert wrote: It works fine in the Ubuntu kernels (pre 2.6.22-13) and in mainline through 2.6.23-rc6; since 2.6.23-rc7 (and Ubuntu 2.6.22-13), the X server won't start up, and I get this at the end of my Xorg.log: AOL. And I was in the middle of watching a bloody movie too. commit f443675affe3f16dd428e46f0f7fd3f4d703eeab Author: Zhenyu Wang [EMAIL PROTECTED] Date: Tue Sep 11 15:23:57 2007 -0700 intel_agp: fix stolen mem range on G33 G33 GTT stolen memory is below graphics data stolen memory and be seperate, so don't subtract it in stolen mem counting. Signed-off-by: Zhenyu Wang [EMAIL PROTECTED] Acked-by: Dave Airlie [EMAIL PROTECTED] Cc: Dave Jones [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] Looks to be the commit that breaks things. Regards, Kyle M. - 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: G33 graphics broken after 2.6.23-rc6
On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote: commit f443675affe3f16dd428e46f0f7fd3f4d703eeab intel_agp: fix stolen mem range on G33 G33 GTT stolen memory is below graphics data stolen memory and be seperate, so don't subtract it in stolen mem counting. Found it, without this corresponding change to xf86-video-intel, this breaks utterly: commit 2a8592f2ebcba86b1127aa889155d58a3dc186ca Author: Zhenyu Wang [EMAIL PROTECTED] Date: Wed Sep 5 14:52:56 2007 +0800 Fix G33 GTT stolen mem range G33 GTT table lives in seperate stolen mem with graphics data stolen mem. I think this should be reverted for 2.6.23, it certainly doesn't seem to have been appropriate for 2.6.23-rc6. Cheers, Kyle M. - 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
Revert intel_agp: fix stolen mem range on G33
This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
breaks horribly if you aren't running an unreleased xf86-video-intel
driver out of git.
Conflicts:
drivers/char/agp/intel-agp.c
Signed-off-by: Kyle McMartin [EMAIL PROTECTED]
---
drivers/char/agp/intel-agp.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index a5d0e95..141ca17 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -506,11 +506,6 @@ static void intel_i830_init_gtt_entries(void)
break;
}
} else {
- /* G33's GTT stolen memory is separate from gfx data
-* stolen memory.
-*/
- if (IS_G33)
- size = 0;
switch (gmch_ctrl I855_GMCH_GMS_MASK) {
case I855_GMCH_GMS_STOLEN_1M:
gtt_entries = MB(1) - KB(size);
--
1.5.3.3
On Sat, Oct 06, 2007 at 01:34:10AM -0400, Kyle McMartin wrote:
On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote:
commit f443675affe3f16dd428e46f0f7fd3f4d703eeab
intel_agp: fix stolen mem range on G33
G33 GTT stolen memory is below graphics data stolen memory and be
seperate,
so don't subtract it in stolen mem counting.
Found it, without this corresponding change to xf86-video-intel, this
breaks utterly:
commit 2a8592f2ebcba86b1127aa889155d58a3dc186ca
Author: Zhenyu Wang [EMAIL PROTECTED]
Date: Wed Sep 5 14:52:56 2007 +0800
Fix G33 GTT stolen mem range
G33 GTT table lives in seperate stolen mem with
graphics data stolen mem.
I think this should be reverted for 2.6.23, it certainly doesn't seem to have
been appropriate for 2.6.23-rc6.
Cheers,
Kyle M.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
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
