On Fri, May 24, 2013 at 11:26:42AM -0700, Ben Widawsky wrote:
> On Mon, May 13, 2013 at 04:32:11PM +0300, Mika Kuoppala wrote:
> > In preparation to track per ring progress in hangcheck,
> > add i915_hangcheck_ring_hung.
> >
> > v2: omit dev parameter (Ben Widawsky)
> >
> > Signed-off-by: Mika Ku
On Fri, May 24, 2013 at 6:20 PM, Ville Syrjälä
wrote:
> On Fri, May 24, 2013 at 06:13:15PM +0200, Daniel Vetter wrote:
>> On Fri, May 24, 2013 at 6:07 PM, Daniel Vetter wrote:
>> > pfit_size stores the request mode, which matches crtc->config.requested
>> > mode. Instead of jumping through hoops
Since I'll need to modify i915_gem_object_bind_to_gtt(), fix the errors
now to get checkpatch to not complain.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/
Hello.
I'm continuing to develop full PPGTT support for the i915 driver. This
series is a follow-up to the previously posted RFC [1]. This series
contains reworked versions of the unmerged patches (fingers crossed that
I didn't miss review comments). I've rebased this series to hell and
back, so I
Add some debug messages to help figure out what goes wrong on context
initialization.
Later in the PPGTT series, I ended up having a lot of failures after
reset. In many cases it was extra difficult to debug because I hadn't
even realized that contexts failed to reinitialize after reset (again an
If contexts were actually initialized, and we fail somewhere later during
init this would possibly leak memory, and lead to some error messages
about unclean takedown. As the odds of this occurring, and someone
actually caring/noticing are pretty slim, the patch isn't terribly
important.
Found by
The GTT start is either 0 in the KMS case, or some value which is set
only after the init IOCTL in the UMS case. In both cases, we don't have
this information until after we've tried to kick out the firmware fb.
This patch should have no functional change since we kzalloc the GTT
struct anyway. It
Nothing outside of i915_gem_gtt.c and more specifically, the relevant
gen specific init function should need to know about number of PDEs, or
PTEs per PD. Exposing this will only lead to circumventing using the
upcoming VM abstraction.
To accomplish this, move the defines into the .c file, rename
I noticed this while doing the VMA abstraction. AFAICT, it won't
actually fix anything, but it is the correct thing to do.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/
From: Chris Wilson
Clients like i915 needs to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and also optimize allocation o
Scary alert.
AFAICT, we simply do not need the guard page if we have the PDEs at the
top since all prefetching is CS related, and it should always be safe to
prefetch into a PDE (provided the PDE is valid). The PDE fetching itself
should not be subject to the prefetching problem, though without fu
With the introduction of context refcounting we never explicitly
ref/unref the backing object. As such, the previous fix was a bit wonky.
Aside from fixing the above, this patch also puts us in good shape for
an upcoming patch which allows a failure to occur in between
context_init and the first d
When PPGTT support was originally enabled, it was only designed to
support 1 PPGTT. It therefore made sense to simply hide the GGTT space
required to enable this from the drm_mm allocator.
Since we intend to support full PPGTT, which means more than 1, and they
can be created and destroyed ad hoc
It's convenient to just call i915_gem_init_hw at reset because we'll be
adding new things to that function, and having just one function to call
instead of reimplementing it in two places is nice.
In order to accommodate we cleanup ringbuffers in order to bring them
back up cleanly. Optionally, we
We **need** to do this for exactly 1 reason, because we want to embed a
PPGTT into the context, but we don't want to special case the default
context.
To achieve that, we must be able to initialize contexts after the GTT is
setup (so we can allocate and pin the default context's BO), but before
th
My long term vision is for contexts to have a 1:1 relationship with a
PPGTT. Sharing objects between address spaces would work similarly to
the flink/dmabuf model if needed.
The only current code to convert is the aliasing PPGTT. The aliasing
PPGTT is just the PPGTT for the default context.
The o
In continuing to make default context/aliasing PPGTT behave like any
other context/PPGTT pair this patch sets us up by moving the
context/PPGTT init to a common location.
The resulting code isn't a huge improvement, but that will change in the
next patch (at least a bit).
Signed-off-by: Ben Widaw
A previous patch had set up the ppgtt and ggtt to use the same scratch
page, but still kept around both pointers. Kill it, it's not needed and
gets in our way for upcoming cleanups.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 5
This is the second half to the previous patch in that now if PPGTT fails
to come up, contexts are disabled, and we don't even try to bring up
contexts when we don't have PPGTT support.
NB: PPGTT cleanup is now done in context unreference.
NB2: Chris finally gets to disable HW contexts via the PPGT
The original pte_encode function needed the dev argument so we could do
platform specific handling via IS_GENX, etc. With the merging of a pte
encoding function there should never been a need to quirk away gen
specific details.
The patch doesn't do much but makes the upcoming reworks in gtt/ppgtt/
There isn't any special reason to do this other than it makes it obvious
that the two members are connected.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 6 --
drivers/gpu/drm/i915/i915_gem_gtt.c | 17 -
2 files changed, 12 insertions(+), 11 deletion
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 48 +++--
drivers/gpu/drm/i915/i915_gem_stolen.c | 20 +++---
drivers/gpu/drm/i915/intel_display.c | 6 ++---
drivers/gpu/drm/i915/intel_
for file in `ls drivers/gpu/drm/i915/*.c` ; do
sed -i "s/mm.gtt_mtrr/gtt.mtrr/" $file;
done
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 18 +-
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a
Just for compactness.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 36 +++-
1 file changed, 15 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 391cec9..6954e95 1
It doesn't apply to generic VMA, so it belongs with the gtt.
for file in `ls drivers/gpu/drm/i915/*.c` ; do
sed -i "s/mm.stolen_base/gtt.stolen_base/" $file;
done
for file in `ls drivers/gpu/drm/i915/*.c` ; do
sed -i "s/mm.stolen/gtt.stolen/" $file;
done
Signed-off-by: Ben Widaws
The GTT and PPGTT can be thought of more generally as GPU address
spaces. Many of their actions (insert entries), state (LRU lists) and
many of their characteristics (size), can be shared. Do that.
Created a i915_gtt_vm helper macro since for now we always want the
regular GTT address space. Event
for file in `ls drivers/gpu/drm/i915/*.c` ; do
sed -i "s/mm.aliasing/gtt.aliasing/" $file;
done
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
drivers/gpu/drm/i915/i915_dma.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 6 +++---
After we plumb our code to support multiple address spaces (VMs), there
are a few situations where we want to be able to traverse the list of
all address spaces in the system. Cases like eviction, or error state
collection are obvious example.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915
It's easy enough to test and make sure our list is accurate because we
already have a member in place to access our global GTT. By porting that
to use our list (which assumes the GGTT is always the first entry) we
can verify a decent amount of the code is working correct.
NOTE: to do this, we must
Every address space should support object allocation. It therefore makes
sense to have the allocator be part of the "superclass" which GGTT and
PPGTT will derive.
Since our maximum address space size is only 2GB we're not yet able to
avoid doing allocation/eviction; but we'd hope one day this beco
for file in `ls drivers/gpu/drm/i915/*.c` ; do sed -i
"s/dev_priv->mm.bound_list/i915_gtt_mm-\>bound_list/" $file; done
for file in `ls drivers/gpu/drm/i915/*.c` ; do sed -i
"s/dev_priv->mm.inactive_list/i915_gtt_mm-\>inactive_list/" $file; done
for file in `ls drivers/gpu/drm/i915/*.c` ; do sed
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj->gtt_space. Doing this
will break a bunch of code, but amongst them are 2 callers of
drm_mm_create_block(),
gtt_offset has always been == gtt_space->start. This makes an upcoming
change much easier to swallow.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c| 9 ---
drivers/gpu/drm/i915/i915_drv.h| 7 -
drivers/gpu/drm/i915/i915_gem.c| 43 ++
Remove the obj->gtt_space. See if it still works. This validates that
what we did in part 1 was correct.
BISECT WARNING: This patch was not meant for bisect. If it does end up
upstream, it should be included in the 3 part series for creating the
VMA.
Signed-off-by: Ben Widawsky
---
drivers/gpu/
This will be handy when we add VMs. It's not strictly, necessary, but it
will make the code much cleaner.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c| 24 +--
drivers/gpu/drm/i915/i915_drv.h| 21 +
drivers/gpu/drm/i915/i915_gem.c
Creates the VMA, but leaves the old obj->gtt_space in place. This
primarily just puts the basic infrastructure in place, and helps check
for leaks.
BISECT WARNING: This patch was not meant for bisect. If it does end up
upstream, it should be included in the 3 part series for creating the
VMA.
Sig
On 05/25/2013 12:26 PM, Ben Widawsky wrote:
The original pte_encode function needed the dev argument so we could do
platform specific handling via IS_GENX, etc. With the merging of a pte
encoding function there should never been a need to quirk away gen
specific details.
The patch doesn't do muc
Found with kmemleak.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6efe3b0..4df2b3f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i
On Sat, May 25, 2013 at 02:42:54PM -0700, Ben Widawsky wrote:
> Found with kmemleak.
>
> Signed-off-by: Ben Widawsky
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_irq.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
We **need** to do this for exactly 1 reason, because we want to embed a
PPGTT into the context, but we don't want to special case the default
context.
To achieve that, we must be able to initialize contexts after the GTT is
setup (so we can allocate and pin the default context's BO), but before
th
40 matches
Mail list logo
