Re: [git pull] drm request 3

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® Parallel Studio Eval Try the new software tools for yourself. Speed c

[PATCH] vgaarb: fix "target=default" passing

From: Kyle McMartin 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

Re: [git pull] drm

e 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 Enter

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

[PATCH trivial] drm: i915: i915_modeset is signed

From: Kyle McMartin Signed-off-by: Kyle McMartin --- 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

Re: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE

l 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 & bra

[PATCH] drm: i915: ensure objects are allocated below 4GB on PAE

From: Kyle McMartin 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

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 McMart

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

[PATCH] drm: edid: don't fail to build on big endian

From: Kyle McMartin 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...) inste

[PATCH] drm: edid revision 0 is valid

From: Kyle McMartin 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#4767

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

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

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

Re: G33 graphics broken after 2.6.23-rc6

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

Re: [PATCH] DRM depends on ???

On May 29, 2005, at 15:58:10, Geert Uytterhoeven wrote: What Kyle said is the correct answer... we either keep this lovely construct (I'll add a comment for 2.6.13) or we go back to the old intermodule or module_get stuff... DRM built-in with modular AGP is always wrong... or at least

Re: [PATCH] DRM depends on ???

n AGP may be built- in, modular, or not built at all. The "depends on AGP || AGP=n" means that if DRM=y, then AGP=y or AGP=n, and if DRM=m or DRM=n, then AGP=y or AGP=m or AGP=n. Yes it's unclear and yes it should probably be documented in a comment somewhere. Cheers, Ky

[Dri-devel] Help with X/Mesa segfault bug

mmary to: http://sourceforge.net/tracker/index.php?func=detail&aid=912828&group_id=3&atid=13 This crash happens only when Xinerama is turned on and was not a problem under XFree86 4.2. I can do testing/debugging, but I'm lost and don't know where to look next. Can an