On Thu, 23 Oct 2008 13:22:12 -0700
Keith Packard [EMAIL PROTECTED] wrote:
We just ran some numbers on a box with PAT enabled and broken MTRRs.
Finally we have a test platform for the difference between kmap_atomic
and kmap_atomic_prot. Using regular kmap_atomic on this platform, we get
UC
On Thu, 2008-10-23 at 19:48 -0700, Linus Torvalds wrote:
So I would suspect that if you guys actually write a patch, and make sure
that it works on x86-32 even _without_ CONFIG_HIGHMEM, and send it to
Ingo, good things will happen.
Something like the following (yes, I know, this is missing
On Fri, 2008-10-24 at 04:34 +0200, Esben Stien wrote:
I've pulled GIT xf86-video-ati for some months now and I always have
to apply this patch:
diff --git a/src/radeon_video.c b/src/radeon_video.c
index ac60166..c400468 100644
--- a/src/radeon_video.c
+++ b/src/radeon_video.c
@@ -1597,5
Keith,
What you actually are doing here is claiming copyright on code that
other people have written, and tighten the export restrictions.
kmap_atomic_prot_pfn() appeared long ago in drm git with identical code
and purpose, but with different authors, and iounmap_atomic is identical
to
* Thomas Hellström [EMAIL PROTECTED] wrote:
Keith,
What you actually are doing here is claiming copyright on code that
other people have written, and tighten the export restrictions.
kmap_atomic_prot_pfn() appeared long ago in drm git with identical
code and purpose, but with different
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 23 Oct 2008, Keith Packard wrote:
So I'd much rather create a new linux/kmap.h or something. Or just
expose this from to asm/fixmap.h or something. Let's not confuse this
with highmem, even if the implementation _historically_ was
Ingo Molnar wrote:
* Thomas Hellström [EMAIL PROTECTED] wrote:
Keith,
What you actually are doing here is claiming copyright on code that
other people have written, and tighten the export restrictions.
kmap_atomic_prot_pfn() appeared long ago in drm git with identical
code and
* Thomas Hellström [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Thomas Hellström [EMAIL PROTECTED] wrote:
Keith,
What you actually are doing here is claiming copyright on code that
other people have written, and tighten the export restrictions.
kmap_atomic_prot_pfn() appeared
On 24.10.2008 04:34, Esben Stien wrote:
I've pulled GIT xf86-video-ati for some months now and I always have
to apply this patch:
diff --git a/src/radeon_video.c b/src/radeon_video.c
index ac60166..c400468 100644
--- a/src/radeon_video.c
+++ b/src/radeon_video.c
@@ -1597,5 +1597,8 @@
On Thu, 23 Oct 2008, Keith Packard wrote:
I'm fine with sticking the mapping in a separate structure; it's just
the return from ioremap_wc on 64-bit systems, and nothing at all on
32-bit systems.
Actually, on 32-bit, the 'prot' should be there, as should the starting
physical page.
On Thursday, October 23, 2008 5:20 pm Jesse Barnes wrote:
Ugg, get_fence was pretty broken in the !reg case... fixing that makes
things a bit more stable...
And here's one that's actually pretty solid. It doesn't try to unbind from
get_fence (should be safe, but we don't want to do it anyway,
On Fri, 2008-10-24 at 09:33 +0200, Thomas Hellström wrote:
Keith,
What you actually are doing here is claiming copyright on code that
other people have written, and tighten the export restrictions.
kmap_atomic_prot_pfn() appeared long ago in drm git with identical code
and purpose, but
On Fri, 2008-10-24 at 07:53 -0700, Linus Torvalds wrote:
Actually, on 32-bit, the 'prot' should be there, as should the starting
physical page. Otherwise the two interfaces would be very odd, and you'd
have to repeat those arguments in all callers (ie both in prepare and
in the actual
http://bugs.freedesktop.org/show_bug.cgi?id=18212
Summary: Crash inside r300MapTexture()
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Keith Packard wrote:
On Fri, 2008-10-24 at 09:33 +0200, Thomas Hellström wrote:
Keith,
What you actually are doing here is claiming copyright on code that
other people have written, and tighten the export restrictions.
kmap_atomic_prot_pfn() appeared long ago in drm git with identical
Ok this one doesn't crash and doesn't leave the flushing list full at leavevt
time, so I think it's ready for some actual review.
I'm using the patch I posted to intel-gfx@ to do tiled EXA pixmaps, but I
think my approach of faulting in fence registers may not be the best one
(though I haven't
http://bugs.freedesktop.org/show_bug.cgi?id=18214
Summary: Prey rendering is broken
Product: Mesa
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
http://bugzilla.kernel.org/show_bug.cgi?id=11798
--- Comment #5 from [EMAIL PROTECTED] 2008-10-24 20:34 ---
This problem can be fixed by simply revert:
commit edc6f389f6ae9cb7621270a8ddbb1892bd8df125
radeon: fix PCI bus mastering support enables.
As Alex is the author of the
18 matches
Mail list logo
