Jerome Glisse wrote:
On Tue, Jan 12, 2010 at 01:03:02AM +0800, Donnie Fang wrote:
I want to dig much more into this asynchronous memory manager mechanism.
Now I have several questions:
1.According to Thamos's suggestion, each memory manager will has a fence
object with it, which is
Arnd Bergmann wrote:
On Friday 18 December 2009, Dave Airlie wrote:
This looks good, I've taken this and I've squashed
the generic pieces of your RFC into this (i.e.
I haven't modified the drivers, but just added the
flag to allow the ioctls to be unlocked if the driver
selects them).
Donnie Fang wrote:
Hi Thomas,
I have several doubts. please check them as below.
2009/12/15 Thomas Hellstrom tho...@shipmail.org
mailto:tho...@shipmail.org
Jerome Glisse wrote:
Hi Thomas,
Dave find out the root of a strange oops we did encouter.
I spend
Jerome Glisse wrote:
On Sat, Dec 05, 2009 at 11:30:38PM +0100, Thomas Hellström wrote:
Jerome Glisse wrote:
On Sat, Dec 05, 2009 at 01:14:29PM +0100, Thomas Hellström wrote:
Jerome,
I'm just reviewing the API change here. I'll do a more thorough
code review when the API
Hi, Jerome,
While moving the ttm core code over to return -ERESTARTSYS in the event
of it getting interrupted by a signal,
I took a look at the use of the old -ERESTART usage in Radeon.
It turns out that in radeon_object.c, -ERESTART return values are caught
and the ttm call is reissued. That
Jerome Glisse wrote:
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/drm_mm.c | 88
++
include/drm/drm_mm.h | 34 ++
2 files changed, 122 insertions(+), 0 deletions(-)
diff --git
Jerome Glisse wrote:
This change allow driver to pass memory space preference
on buffer object placement. Up to 15 differents places
which should be enought. The placement order is given
by the memory type encoded on 4bits in 64bits dword.
First 4bits is the number of memory placement. Next
Jerome Glisse wrote:
On Sat, Dec 05, 2009 at 01:14:29PM +0100, Thomas Hellström wrote:
Jerome,
I'm just reviewing the API change here. I'll do a more thorough code
review when the API is agreed upon.
+
+/**
+ * struct ttm_placement
+ *
+ * @fpfn: first valid page
Jerome Glisse wrote:
On Thu, 2009-11-19 at 16:29 +0800, Donnie Fang wrote:
Hi all,
after reviewed the radeon fence scheme, there are lots of chances
that it needs create a new fence object, and also there are lots of
chances need to destroy these fence objects.
In my opinion, is
Jerome,
Please see comments inline.
Jerome Glisse wrote:
Add a function to validate buffer in a given range of
memory. This is needed by some hw for some of their
buffer (scanout buffer, cursor ...).
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c|
Jakob Bornecrantz wrote:
From: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
drivers/gpu/drm/drm_fops.c | 14 ++
drivers/gpu/drm/drm_stub.c | 11 +++
Dan Carpenter wrote:
I moved the allocation until after the check for (si-totalhigh == 0).
regards,
dan carpenter
Signed-off-by: Dan Carpenter erro...@gmail.com
--- orig/drivers/gpu/drm/ttm/ttm_memory.c 2009-11-28 07:05:54.0
+0200
+++ devel/drivers/gpu/drm/ttm/ttm_memory.c
brucech...@via.com.tw wrote:
Hello Sirs:
This patch is to solve the video hang issue caused by verification
function. These 3 patches has been verified in (1) CX700M platform (2) CLE266
platform (3) K8M800 platform (4) CN400 platform with UniChrome/OpenChrome
driver except few of these
brucech...@via.com.tw wrote:
Hello Sirs:
This patch is to add the support of ACPI suspend/resume. Some information
locating in video memory
need to be saved for 3D function. The mesa driver source has been release on
VIA Linux portal
Dave Airlie wrote:
On Wed, Nov 18, 2009 at 8:41 AM, a...@linux-foundation.org wrote:
From: Thomas Schlichter thomas.schlich...@web.de
The VIA DRM module is able to accelerate 2D video on the VX800 chipset,
thus add the corresponding PCI ID. Accelerated 3D video is not
implemented.
brucech...@via.com.tw wrote:
Hello Sirs:
This patch is to add the interface to communicate with V4L and DDMPEG.
Signed-off-by Bruce C. Chang brucech...@via.com.tw
diff -ruN old/drivers/gpu/drm/via/via_dma.c new/drivers/gpu/drm/via/via_dma.c
--- old/drivers/gpu/drm/via/via_dma.c
Jerome Glisse wrote:
Hi,
I would like to do some modification for 2.6.33, so i figure it's good
time to talk about them. I have 2 aims :
1) add flexibility to bo placement
2) simplify bo move code
3) avoid sub optimal move scenario
4) Allow support of GPU with unmappable memory
1) i
Donnie Fang wrote:
Sorry for omitting thomas.
-- Forwarded message --
From: *Donnie Fang* donnie.f...@gmail.com mailto:donnie.f...@gmail.com
Date: 2009/11/2
Subject: how to make sure cache synchronization between GPU and CPU
To: dri-devel@lists.sourceforge.net
Daniel Vetter skrev:
On Mon, Aug 31, 2009 at 02:58:15PM +0200, Thomas Hellström wrote:
...
Is this some new (embedded) hw support your working on (that supports
gallium), Thomas? Or why do you think gallium needs overlay support?
I must stress this is not Gallium
Alex Deucher skrev:
This commit seems to break redbook texbind and texsub on r600:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=956e6c3978abe918348377cf05e5c92971e50d3f
Has anyone else had any problems with these apps on other hardware?
Thanks,
Alex
Alex,
I think mesa3d-dev is the
Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel is that of the various hw
constrains on the buffer layout. IMHO this has two solutions:
a) complicated to communicate the constrains to userspace. This is either
to generic
Stephane Marchesin skrev:
2009/9/1 Keith Whitwell kei...@vmware.com:
On Tue, 2009-09-01 at 02:20 -0700, Thomas Hellström wrote:
Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
The problem I see with Xv-API-in-kernel
Jerome and other Radeon developers.
You're probably aware of this, but I'd thought I'd mention it before the
Radeon user-space interface is set in stone.
There is a slight problem with the radeon bo wait idle ioctl if there
are multiple threads or processes rendering to the same buffer without
Daniel Vetter wrote:
Open issues:
- Flickering. But when the frame is not changed, this stabilizes
after a few seconds (at most). This is in a 855GM and a 865G, other
chipset variants are untested.
- Runs in sync with the gpu, i.e. unnecessary waiting. Unfortunately
changes in this
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel side is certainly possible, if
someone implements overlay support for another chipset. But I don't really
count on that, because at least radeon has textured
Daniel Vetter wrote:
On Mon, Aug 31, 2009 at 02:15:15PM +0200, Stephane Marchesin wrote:
2009/8/31 Thomas Hellström tho...@shipmail.org:
Daniel Vetter wrote:
...
In conclusion I don't think a common ioctl is worth it. But sharing some
code and infrastructure on the kernel
Jerome Glisse wrote:
On Mon, 2009-08-31 at 10:40 +0200, Thomas Hellström wrote:
Jerome and other Radeon developers.
You're probably aware of this, but I'd thought I'd mention it before the
Radeon user-space interface is set in stone.
There is a slight problem with the radeon bo wait
.
/Thomas
cheers,
Kristiain
2009/8/30 Thomas Hellström tho...@shipmail.org:
Thomas Hellström skrev:
I described this in more detail and hopefully more coherently in my
email to Michel. If that's still not clear, follow up there.
I've read the mail and understand
Thomas Hellström skrev:
I described this in more detail and hopefully more coherently in my
email to Michel. If that's still not clear, follow up there.
I've read the mail and understand the proposal, thanks.
/Thomas
So, I've been doing some thinking over the weekend
Kristian Høgsberg skrev:
2009/8/27 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg skrev:
---
Okay, here's the patch again with the locking fixed. Everything else is
the same. As for the potential problem with polling on the drm fd with
both dri1 and dri2 enabled, I
Thomas Hellström skrev:
What's protecting file_priv-event_list here?
You can test for list emptiness without taking the lock.
Are you suggesting accessing a member of a mutex protected struct
without taking the mutex?
Do you have a pointer to where
Michel Dänzer skrev:
On Thu, 2009-08-27 at 17:33 -0400, Kristian Høgsberg wrote:
2009/8/27 Thomas Hellström tho...@shipmail.org:
b) It requires the master to act as a scheduler, and circumvents the DRM
command submission mechanism through the delayed unpin callback
Kristian Høgsberg skrev:
This mail is getting out of control... too many sub-threads going
on... maybe we shold break it out and talk about events vs kernel
scheduling and wait with the patch review until we've figured
something out.
Sure.
b) It requires the master to act as a
Kristian Høgsberg skrev:
---
Okay, here's the patch again with the locking fixed. Everything else is
the same. As for the potential problem with polling on the drm fd with
both dri1 and dri2 enabled, I suggest that we just disable the dri1
sigio handler in the xserver. We'll do this in a
Hi!
I wonder why you went so quiet on IRC, just to discover my bridge
computer had given in completely. Need to resort to the lappy.
Anyway to avoid any misunderstandings: Here is my view on how this ought
to be implemented:
1) X server schedules a pageflip.
2) When a client tries to render
Michel Dänzer wrote:
On Thu, 2009-08-20 at 13:17 +0200, Thomas Hellstrom wrote:
1) On some systems, X roundtrips are very costly. For example on via
processors when running gears, X ends up at around 10% for just the
reportdamage call of dri1.
Does this affect real apps with
Dave Airlie wrote:
On Thu, Aug 20, 2009 at 5:52 PM, Thomas Hellstromthellst...@vmware.com
wrote:
The drm sysfs class suspend / resume methods could not distinguish
between different device types wich could lead to illegal type casts.
Use struct device_type and make sure the class
Dave Airlie wrote:
From: Dave Airlie airl...@linux.ie
This adds code to the drm_mm to talk to debugfs, and adds
support to radeon to add the VRAM and GTT mm lists to debugfs.
changes since v1:
don't bother with free list just add used/free to main list
add totals in pages
Signed-off-by:
Dave Airlie wrote:
2009/8/21 Thomas Hellström tho...@shipmail.org:
Dave Airlie wrote:
From: Dave Airlie airl...@linux.ie
This adds code to the drm_mm to talk to debugfs, and adds
support to radeon to add the VRAM and GTT mm lists to debugfs.
changes since v1:
don't bother
Dave Airlie wrote:
On Wed, Aug 19, 2009 at 12:51 AM, Thomas Hellstromthellst...@vmware.com
wrote:
Common resources, like memory accounting and swap lists should be
global and not per device. Introduce a struct ttm_bo_global to
accomodate this, and register it with sysfs. Add a small
Dave,
The patch titled [PATCH] drm: Fix sysfs device confusion seems to have
been lost somewhere.
It's not drm-next and is a prerequisite for the ttm sysfs patches.
Funny, Jbarnes have replied by a Reviewed-by, but I can't find it in my
dri-devel folder.
I've resent it to dri-devel.
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 6:12 PM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlieairl...@gmail.com wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
Kristian Høgsberg wrote:
2009/8/17 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming
Jesse Barnes wrote:
On Mon, 17 Aug 2009 22:22:34 +0200
Thomas Hellström tho...@shipmail.org wrote:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the
modesetting family of ioctls. The ioctl takes a crtc and an fb and
schedules a pageflip to the new
Kristian Høgsberg wrote:
2009/8/17 Thomas Hellström tho...@shipmail.org:
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 3:52 AM, Thomas Hellströmtho...@shipmail.org wrote:
Kristian Høgsberg wrote:
By sending an event back on the file descriptor we allow users of the
API to wait on the flip to finish in a standard poll or select
mainloop, where it can
outstanding rendering
before flipping).
I guess GEM's buffer object busy lists be used to accomodate something
similar?
/Thomas
Keith
From: Kristian Høgsberg [...@bitplanet.net]
Sent: Tuesday, August 18, 2009 11:46 AM
To: Thomas Hellström
Cc
Thomas Hellström wrote:
Keith Whitwell wrote:
This seems wrong to me -- the client doesn't need to sleep - all it's
going to do is build a command buffer targeting the new backbuffer.
There's no problem with that, it should be the preserve of the GPU
scheduler (TTM or GEM) to ensure those
Kristian Høgsberg wrote:
On Tue, Aug 18, 2009 at 5:03 PM, Dave Airlieairl...@gmail.com wrote:
On Wed, Aug 19, 2009 at 2:12 AM, Keith Whitwellkei...@vmware.com wrote:
I think the bug in question was because somebody (Jon Smirl??) removed the
empty apparently unused poll
Jesse Barnes wrote:
Anyway, to me this discussion is more of a future directions one than
a blocker for this particular patchset. AFAICT the only thing that
needs fixing with this patch is my lock confusion (struct_mutex vs
mode_config). Or would you like something substantial changed with
Jesse Barnes wrote:
On Fri, 14 Aug 2009 10:42:57 +0200
Thomas Hellstrom thellst...@vmware.com wrote:
The drm sysfs class suspend / resume methods could not distinguish
between different device types wich could lead to illegal type casts.
Use struct device_type and make sure the class
Kristian Høgsberg wrote:
On Mon, Aug 17, 2009 at 10:28 AM, Thomas Hellstromthellst...@vmware.com
wrote:
The device directory will be the base directory of the
sysfs representation of other ttm subsystems.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
Kristian Høgsberg wrote:
This patch adds a vblank synced pageflip ioctl for to the modesetting
family of ioctls. The ioctl takes a crtc and an fb and schedules a
pageflip to the new fb at the next coming vertical blank event. This
feature lets userspace implement tear-free updating of the
I'm revoking this patch. A replacement will be posted.
Thomas Hellstrom wrote:
This code wraps the struct device so that the drm class callbacks can
differentiate between different types of drm sysfs devices. It fixes a
case where a struct drm_connecor is cast to a struct drm_minor in the
Kristian Høgsberg wrote:
2009/8/11 Thomas Hellström tho...@shipmail.org:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org wrote:
Hi!
I'm wondering why we are using a struct device as a sysfs
representation for connectors
Greg KH wrote:
On Wed, Aug 12, 2009 at 04:48:33PM -0700, Jesse Barnes wrote:
On Wed, 12 Aug 2009 16:24:58 -0700
Greg KH g...@kroah.com wrote:
On Wed, Aug 12, 2009 at 08:59:17AM -0700, Jesse Barnes wrote:
On Wed, 12 Aug 2009 08:21:24 +0200
Thomas Hellström tho
Jesse Barnes wrote:
On Tue, 11 Aug 2009 20:29:39 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org wrote:
Hi!
I'm wondering why we are using a struct device as a sysfs
Michel Dänzer wrote:
On Wed, 2009-08-05 at 12:06 +0200, Thomas Hellström wrote:
Michel Dänzer wrote:
On Wed, 2009-08-05 at 11:18 +0200, Thomas Hellström wrote:
Aargh. Wait. I remember now.
The fbcon bo is exported through the fbdev address space at offset 0
Michel Dänzer wrote:
On Tue, 2009-08-11 at 10:48 +0200, Thomas Hellström wrote:
Michel Dänzer wrote:
On Wed, 2009-08-05 at 12:06 +0200, Thomas Hellström wrote:
Michel Dänzer wrote:
On Wed, 2009-08-05 at 11:18 +0200, Thomas Hellström wrote
Hi!
I'm wondering why we are using a struct device as a sysfs representation
for connectors instead of a struct kobject?
In particular, what stops the drm_sysfs_[suspend|resume] functions to
get called for the connectors, having them cast to a struct drm_minor
and sending the cpu to the
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org wrote:
Hi!
I'm wondering why we are using a struct device as a sysfs
representation for connectors instead of a struct kobject?
In particular, what stops the drm_sysfs_[suspend|resume
Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
Make sure bo-vm_node is valid, to prevent crashes in the fault handler, and
adjust vma-vm_pgoff according to it, so userspace attempts to access /dev/fb*
mappings don't always result in SIGBUS.
Signed-off-by: Michel Dänzer
Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
Use the fb_mmap hook for userspace and re-create the kernel mapping whenever
the
fbcon BO moves back into VRAM. KMS will pin it when necessary. This way we
aren't wasting precious VRAM when we're e.g. in X.
fbcon shouldn't (and
Michel Dänzer wrote:
On Wed, 2009-08-05 at 10:50 +0200, Thomas Hellström wrote:
Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
Make sure bo-vm_node is valid, to prevent crashes in the fault handler, and
adjust vma-vm_pgoff according to it, so userspace attempts
Michel Dänzer wrote:
On Wed, 2009-08-05 at 11:01 +0200, Thomas Hellström wrote:
Michel Dänzer wrote:
On Wed, 2009-08-05 at 10:50 +0200, Thomas Hellström wrote:
Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
Make sure bo-vm_node is valid
Michel Dänzer wrote:
On Wed, 2009-08-05 at 11:18 +0200, Thomas Hellström wrote:
Michel Dänzer wrote:
On Wed, 2009-08-05 at 11:01 +0200, Thomas Hellström wrote:
Michel Dänzer wrote:
On Wed, 2009-08-05 at 10:50 +0200, Thomas Hellström wrote
Maarten Maathuis wrote:
- This appears to fix some of the graphical corruption issues i've been
having.
---
drivers/gpu/drm/ttm/ttm_bo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index
Maarten Maathuis wrote:
Let me rephrase that, could you pinpoint the place where the
translation from vm to real memory happens?
Maarten.
Hi!
When a bo is created, a slot is allocated in the device file address
space. This slot size corresponds to the size of the bo. The offset in
the
Suresh Siddha skrev:
Also, now that we have set_pages_array interface, do we still need the
set_memory_array_uc interface? Removing that should clean up the cpa
code a bit.
thanks,
suresh
This might be a good time to discuss how graphics drivers will use this
interface in the not too
Jerome Glisse wrote:
Corollary the TTM priority stuff is i believe a wrong idea
for radeon (could be usefull for others GPU but i don't have
such feeling). So i would like to be able to disable it and
move the knowledge in radeon kernel driver, here is my thinking
on that :
The TTM
Pekka Paalanen skrev:
From 5e2851952729b287a82efa002b28a2095404d44d Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom thellst...@vmware.com
Date: Fri, 31 Jul 2009 10:47:51 +0200
Subject: [PATCH] ttm: Fix a potential comparison of structs.
On some architectures the comparison may cause a
Pekka Paalanen wrote:
Hi,
since I see this patch in Linus' tree, and I likely have to patch
TTM in Nouveau's compat-branch to compile with older kernels,
I have a question below.
(The Nouveau kernel tree's compat branch offers drm.ko, ttm.ko and
nouveau.ko to be built against kernels
Jerome Glisse wrote:
On Tue, 2009-07-28 at 20:55 +0200, Thomas Hellström wrote:
Jerome Glisse skrev:
On Wed, 2009-07-22 at 10:37 +0200, Thomas Hellström wrote:
TTM has a device struct per device and an optional global struct that is
common for all devices and intended
Jerome Glisse skrev:
Hi Thomas,
I think ttm is doing somethings wrong when we validate a bo for the
same mem type but with different cache flags. Here is my understanding :
(Use case i am refering too is object validate with
current state GTT | CACHED validate to GTT | WC)
if
Michel Dänzer wrote:
Patches 1 and 2 are fixes for rather serious bugs, which made KMS pretty much
unusable for me with AGP, and should probably go into 2.6.31 if possible. The
others can use more testing and wait for 2.6.32.
[PATCH 1/4] drm/radeon: Don't unreserve twice on failure to
Jerome Glisse wrote:
On Wed, 2009-07-22 at 10:27 +0200, Thomas Hellström wrote:
Jerome Glisse wrote:
On Thu, 2009-06-25 at 17:53 +0200, Thomas Hellström wrote:
Jerome Glisse skrev:
Hi,
Thomas i attach a reworked page pool allocator based on Dave works
at 17:53 +0200, Thomas Hellström wrote:
4) We could now skip the ttm_tt_populate() in ttm_tt_set_caching, since
it will always allocate cached pages and then transition them.
Okay 4) is bad, what happens (my brain is a bit meltdown so i might be
wrong) :
1 - bo get
Christoph Hellwig wrote:
I think you're just trying to push your agenda.
I think you're just trying to defend your business writing closed source
drivers. Drivers that aren't usable without binary blobs don't have
a business in the kernel tree, and your whining doesn't help it. You'd
Peter Zijlstra wrote:
On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote:
Politics:
It's true that sometimes some people don't like the code or what it
does. But when this is the underlying cause of NAK-ing a driver I think
it's very important that this is clearly stated, instead
Stephane Marchesin wrote:
You obviously got all this completely wrong.
I avoid writing closed source drivers whenever I can, I'm not whining and
I'm not trying to push any of them. The code VIA is trying to submit has not
been written by me nor anybody I know. All VIA code I and the companies
Jerome Glisse skrev:
On Fri, 2009-06-26 at 10:00 +1000, Dave Airlie wrote:
On Thu, Jun 25, 2009 at 10:01 PM, Jerome Glissegli...@freedesktop.org
wrote:
Hi,
Thomas i attach a reworked page pool allocator based on Dave works,
this one should be ok with ttm cache status tracking. It
Michel Dänzer skrev:
On Wed, 2009-06-24 at 19:26 +0200, Thomas Hellström wrote:
Just prior to the commit I sent out a message explaining what I was
going to do and why, but apparently it didn't make it to the list
(which seems to be the case of quite a few mails these days).
What
Pekka Enberg skrev:
Hi Jerome,
On Tue, 2009-06-23 at 22:52 +0300, Pekka Enberg wrote:
On Tue, Jun 23, 2009 at 10:46 PM, Jerome Glissejgli...@redhat.com wrote:
Command stream parsing is the most common operation and can
happen hundred of times per second, we don't want to
Dave Airlie skrev:
From: Dave Airlie airl...@redhat.com
This adds color tiling support for buffers in VRAM, it enables
a color tiled fbcon and a color tiled X frontbuffer.
It changes the API:
adds two new parameters to the object creation API (is this better than
a set/get tiling?) we
Hi, Pekka!
I'm sorry for this breakage. I thought drm master was currently used
only for libdrm development, but
I see now that I didn't pay enough attention. Just prior to the commit I
sent out a message explaining what I was going to do and why, but
apparently it didn't make it to the list
Jerome Glisse skrev:
On Wed, 2009-06-24 at 02:34 -0700, Thomas Hellstrom wrote:
Dave,
sorry for top-posting. It's this stupid email client.
First, I think we need to make sure we agree on the purpose of this patch. I
see it as a huge benefit for
short-lived buffer-objects that are
Dave Airlie skrev:
On Tue, Jun 23, 2009 at 9:35 PM, Peter Zijlstrapet...@infradead.org wrote:
On Mon, 2009-06-22 at 19:26 +0200, Jerome Glisse wrote:
We don't need to allocated contiguous pages in cs codepath
so use vmalloc instead.
Best would be to not require PAGE_SIZE
Jerome Glisse wrote:
On Mon, 2009-04-20 at 12:13 +0200, Thomas Hellstrom wrote:
Jerome Glisse wrote:
On Sun, 2009-04-19 at 18:21 +0200, Thomas Hellström wrote:
Jerome Glisse wrote:
On Sat, 2009-04-18 at 21:06 +0200, Thomas Hellström wrote
Jerome Glisse wrote:
On Mon, 2009-04-20 at 14:02 +0200, Jerome Glisse wrote:
On Mon, 2009-04-20 at 12:13 +0200, Thomas Hellstrom wrote:
If there was an erratum causing PAT not to be enabled on your processor,
then definitely that
may have cause strange inconsistencies.
Thanks,
Jerome Glisse wrote:
On Mon, 2009-04-20 at 14:50 +0200, Thomas Hellström wrote:
Jerome Glisse wrote:
On Mon, 2009-04-20 at 14:02 +0200, Jerome Glisse wrote:
On Mon, 2009-04-20 at 12:13 +0200, Thomas Hellstrom wrote:
If there was an erratum causing PAT
Jerome Glisse wrote:
On Sat, 2009-04-18 at 21:06 +0200, Thomas Hellström wrote:
Jerome Glisse wrote:
Hi Thomas
I am getting massive error on x86_64, things like :
BUG: Bad page map in process gnome-session pte:1f1d1d1d0100
pmd:321a6067
keep filling the log until very bad
Jerome Glisse wrote:
Hi Thomas
I am getting massive error on x86_64, things like :
BUG: Bad page map in process gnome-session pte:1f1d1d1d0100
pmd:321a6067
keep filling the log until very bad things happen.
Do you have any idea what might cause that in ttm ?
My assumption is that ttm
Jerome Glisse wrote:
On Fri, 2009-04-10 at 10:14 +0200, Thomas Hellström wrote:
Jerome Glisse wrote:
On Wed, 2009-04-08 at 16:47 +0200, Thomas Hellstrom wrote:
Jerome Glisse wrote:
Hi Thomas,
I think we should not ttm_bo_unreserve the bo
Jerome Glisse wrote:
On Wed, 2009-04-08 at 16:47 +0200, Thomas Hellstrom wrote:
Jerome Glisse wrote:
Hi Thomas,
I think we should not ttm_bo_unreserve the bo in
ttm_bo_move_accel_cleanup i am seeing double unreserve
which likely lead to kernel list corruption and i
think it's due
Jerome Glisse wrote:
Thomas there is 2 more bugs:
In ttm_bo_mmap if the bo = NULL after ttm_bo_vm_lookup_rb
then
if (unlikely(bo == NULL)) {
printk(KERN_ERR Could not find buffer object to map.\n);
goto out_unref;
}
Should be
if
Jerome Glisse wrote:
In ttm_mem_reg_is_pci i think it should return false if
flags TTM_MEMTYPE_FLAG_NEEDS_IOREMAP is not set otherwise
kmap on a gart (unmappable to cpu) will think it needs
to use ioremap which fails.
Jerome, in this case, how is the memory type backing the gart set up?
Greg KH wrote:
On Fri, Mar 20, 2009 at 03:00:32PM +, Alan Cox wrote:
By the same logic, would you support including the proprietary NVIDIA
driver while we wait for Nouveau to catch up?
The license of the NVIDIA driver does not allow that to even be a
possibility.
Dave and Greg,
Some quick comments below.
Dave Airlie wrote:
On Thu, Mar 19, 2009 at 2:08 PM, Greg KH g...@kroah.com wrote:
Hi,
Here's 5 patches that add the Intel Poulsbo/Morrestown DRM driver to the
kernel tree.
There are 4 patches that make changes to the DRM core, and one patch
Greg / Richard:
Comments to the non-staging patches:
patch 1/5] drm: Split out the mm declarations in a separateheader.
Add atomic operations:
The range manager operations are usually quite fast, and the range
manager really only needs
to be protected by a spinlock. Add atomic operations
Greg KH wrote:
On Thu, Mar 19, 2009 at 11:14:35AM +0100, Thomas Hellström wrote:
First off, the non-staging patches need more complete changelog entries,
a bit of meaning goes a long way. I'll ack them if they are documented and
make sense. The unlocked ioctl hook makes sense to me
1 - 100 of 514 matches
Mail list logo
