Hi,
please add some updates ;)
On Thu, 2013-11-21 at 13:29 +0800, Aaron Lu wrote:
> On 11/21/2013 04:56 AM, Igor Gnatenko wrote:
> > Any news here? If no - I think we need re-send patch as new..
>
> Since the v2 patch can't apply cleanly on top of pm's -next tree, I
> think it's worth a re-send,
Hi,
add some updates to the patch ;)
On Thu, 2013-11-21 at 13:29 +0800, Aaron Lu wrote:
> On 11/21/2013 04:56 AM, Igor Gnatenko wrote:
> > Any news here? If no - I think we need re-send patch as new..
>
> Since the v2 patch can't apply cleanly on top of pm's -next tree, I
> think it's worth a re
- Forwarded message from Tetsuo Handa
-
Date: Tue, 24 Dec 2013 20:50:23 +0900
From: Tetsuo Handa
To: ch...@chris-wilson.co.uk, b...@bwidawsk.net, daniel.vet...@ffwll.ch
Cc: linux-ker...@vger.kernel.org
Subject: [PATCH] drm/i915: Fix refcount leak and possible NULL pointer
dereference.
I keep meaning to do this... by now almost the entire file has been
written by an Intel employee (including Daniel post-2010).
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gp
The following patches rework a lot of the PPGTT cleanup and
initialization code. In the short term, this should allow us to use all
4GB address space as well as get the code ready for adding full PPGTT
support to BDW.
Aside from making the code clearer, the more discrete functions make
finer grain
This will make the code more readable, and extensible which is needed
for upcoming feature work. Eventually, we'll do the same for init.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 58 +++--
1 file changed, 37 insertions(+), 21 deletions(
The previous allocation mechanism would get 2 contiguous allocations,
one for the page directories, and one for the page tables. As each page
table is 1 page, and there are 512 of these per page directory, this
goes to 1MB. An unfriendly request at best. Worse still, our HW now
supports 4 page dire
Create 3 clear stages in PPGTT init. This will help with upcoming
changes be more readable. The 3 stages are, allocation, dma mapping, and
writing the P[DT]Es
One nice benefit to the patches is that it makes 2 very clear error
points, allocation, and mapping, and avoids having to do any handling
a
Like cleanup in an earlier patch, the code becomes much more readable,
and easier to extend if we extract out helper functions for the various
stages of init.
Note that with this patch it becomes really simple, and tempting to begin
using the 'goto out' idiom with explicit free/fini semantics. I'v
This reverts commit 3a2ffb65eec6dbda2fd8151894f51c18b42c8d41.
Now that the code is fixed to use smaller allocations, it should be safe
to let the full GGTT be used on DW.
The testcase for this is anything which uses more than half of the GTT,
thus eclipsing the old limit.
Signed-off-by: Ben Wida
This patch converts insert_entries and clear_range, both functions which
are specific to the VM. These functions tend to encapsulate the gen
specific PTE writes. Passing absolute addresses to the insert_entries,
and clear_range will help make the logic clearer within the functions as
to what's goin
gem_gtt_cpu_tlb seems to indicate that it is needed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72869
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/
This was an accidental "ABI" change introduced during PPGTT:
commit 0eea67eb26000657079b7fc41079097942339452
Author: Ben Widawsky
Date: Fri Dec 6 14:11:19 2013 -0800
drm/i915: Create a per file_priv default context
The failure test application actually tests the return type. The other
opt
Create 3 clear stages in PPGTT init. This will help with upcoming
changes be more readable. The 3 stages are, allocation, dma mapping, and
writing the P[DT]Es
One nice benefit to the patches is that it makes 2 very clear error
points, allocation, and mapping, and avoids having to do any handling
a
Like cleanup in an earlier patch, the code becomes much more readable,
and easier to extend if we extract out helper functions for the various
stages of init.
Note that with this patch it becomes really simple, and tempting to begin
using the 'goto out' idiom with explicit free/fini semantics. I'v
15 matches
Mail list logo
