On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> @@ -2843,8 +2843,7 @@ int i915_vma_unbind(struct i915_vma *vma)
> GEM_BUG_ON(obj->bind_count == 0);
> GEM_BUG_ON(!obj->pages);
>
> - if (i915_vma_is_ggtt(vma) &&
> - vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
Ma
On Mon, Aug 15, 2016 at 11:03:32AM +0300, Joonas Lahtinen wrote:
> On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> Not sure if there should be a comment that for 1:1 mappings vma->pages
> is just obj->pages so it should not be freed. Or maybe you could even
> make the test if vma->pages !=
On Sun, Aug 14, 2016 at 02:28:56PM +0100, Chris Wilson wrote:
> For convenience when debugging user issues show the autotuning
> RPS parameters in debugfs/i915_rps_boost_info.
>
> v2: Refine the presentation
>
> Signed-off-by: Chris Wilson
> Cc: frit...@kodi.tv
Looks good to me (well, it doesn'
For convenience when debugging user issues show the autotuning
RPS parameters in debugfs/i915_rps_boost_info.
v2: Refine the presentation
v3: Style
Signed-off-by: Chris Wilson
Cc: frit...@kodi.tv
Link:
http://patchwork.freedesktop.org/patch/msgid/1471181336-27523-1-git-send-email-ch...@chris-wi
drm/i915: debugfs spring cleaning
Just like with sysfs, we do some major overhaul.
Pass dev_priv instead of dev to all feature macros (IS_, HAS_,
INTEL_, etc.). This has the side effect that a bunch of functions
now get dev_priv passed instead of dev.
All calls to INTEL_INFO()->gen have been rep
On Fri, Aug 12, 2016 at 01:43:52PM +0100, Dave Gordon wrote:
> Alternatively (noting that almost the only use we make of this drm_info_node
> is to indirect multiple times to get dev_priv), we could change what is
> stored in (struct seq_file).private to make it more convenient and/or
> efficient.
== Series Details ==
Series: drm/i915: Show RPS autotuning thresholds along with waitboost (rev3)
URL : https://patchwork.freedesktop.org/series/11063/
State : failure
== Summary ==
Series 11063v3 drm/i915: Show RPS autotuning thresholds along with waitboost
http://patchwork.freedesktop.org/ap
On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> @@ -455,15 +455,21 @@ struct intel_opregion {
> struct intel_overlay;
> struct intel_overlay_error_state;
>
> -#define I915_FENCE_REG_NONE -1
> -#define I915_MAX_NUM_FENCES 32
> -/* 32 fences + sign bit for FENCE_REG_NONE */
> -#define I91
On 12/08/16 17:31, Goel, Akash wrote:
On 8/12/2016 9:52 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
As per the current i915 Driver load sequence, debugfs registration is
done
at the end and so the relay channel debugfs file is also created after
On Mon, Aug 15, 2016 at 12:18:20PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> > + if (1) {
>
> Umm? At least ought to have TODO: / FIXME: or some explanation. And
You're not aware of the pipelined fencing?
-Chris
--
Chris Wilson, Intel Open Source
On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> @@ -1717,26 +1716,30 @@ int i915_gem_fault(struct vm_area_struct *area,
> struct vm_fault *vmf)
> }
>
> /* Use a partial view if the object is bigger than the aperture. */
Move this comment down to where partial view is actuall
On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> The existing ABI says that scanouts are pinned into the mappable region
> so that legacy clients (e.g. old Xorg or plymouthd) can write directly
> into the scanout through a GTT mapping. However if the surface does not
> fit into the mappable
On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> When using the aliasing ppgtt and pagefliping with the shrinker/eviction
s/fliping/flipping/
> active, we note that we often have to rebind the backbuffer before
> flipping onto the scanout because it has an invalid alignment. If we
> store
With execlists, we have context objects everywhere, not just RCS. So
store them for post-mortem debugging. This also has a secondary effect
of removing one more unsafe list iteration with using preserved state
from the hanging request. And now we can cross-reference the request's
context state with
Only those objects pinned to the display have semi-permanent pins of a
global nature (other pins are transient within their local vm). Simplify
i915_gem_pinned to only show the pertinent information about the pinned
objects within the GGTT.
v2: i915_gem_gtt_info is still shared with debugfs/i915_g
v2: Rename functions to suit their more active role
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_tiling.c | 51 --
1 file changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
It's an outright programming error, so explode if it is ever hit.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_request.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/driver
When capturing the error state, we do not need to know about every
address space - just those that are related to the error. We know which
context is active at the time, therefore we know which VM are implicated
in the error. We can then restrict the VM which we report to the
relevant subset.
v2:
Not only does it make for good documentation and debugging aide, but it is
also vital for when we want to unwind requests - such as when throwing away
an incomplete request.
Signed-off-by: Chris Wilson
Link:
http://patchwork.freedesktop.org/patch/msgid/1470414607-32453-2-git-send-email-arun.silu
Lookup the GGTT vma once for the object assigned to the fence, and then
derive everything from that vma.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_fence.c | 55 +--
1 file changed, 26 insertions(+), 29 deletions(-)
In many places, we wish to store the VMA in preference to the object
itself and so being able to create the persistent VMA is useful.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +++
drivers/gpu/drm/i915/i915_gem_gtt.h | 5 +
These two files (i915_gem_active, i915_gem_inactive) no longer give
pertinent information since active/inactive tracking is per-vm and so we
need the information per-vm. They are obsolete so remove them.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debu
No longer is knowing how much of the GTT (both mappable aperture and
beyond) relevant, and the output clutters the real information - that is
how many objects are allocated and bound (and by who) so that we can
quickly grasp if there is a leak.
v2: Relent, and rename pinned to indicate display onl
Previously, we would only set the vma->pages pointer for GGTT entries.
However, if we always set it, we can use it to prettify some code that
may want to access the backing store associated with the VMA (as
assigned to the VMA).
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drive
We know that the only access to the context object is via the GPU, and
the only time when it can be out of the GPU domain is when it is swapped
out and unbound. Therefore we only need to clflush the object when
binding, thus avoiding any potential stall on touching the domain on an
active context.
Since the intel_engine_init_seqno() is shared by all engine submission
backends, move it out of the legacy intel_ringbuffer.c and
into the new home for common routines, intel_engine_cs.c
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915
Access through the GTT requires the device to be awake. Ideally
i915_vma_pin_iomap() is short-lived and the pinning demarcates the
access through the iomap. This is not entirely true, we have a mixture
of long lived pins that exceed the wakelock (such as legacy ringbuffers)
and short lived pin that
It is useful when looking at captured error states to check the recorded
BBADDR register (the address of the last batchbuffer instruction loaded)
against the expected offset of the batch buffer, and so do a quick check
that (a) the capture is true or (b) HEAD hasn't wandered off into the
badlands.
Use the GGTT VMA as the primary cookie for handing ring objects as
the most common action upon the ring is mapping and unmapping which act
upon the VMA itself. By restructuring the code to work with the ring
VMA, we can shrink the code and remove a few cycles from context pinning.
v2: Move the flu
When working with contexts, we most frequently want the GGTT VMA for the
context state, first and foremost. Since the object is available via the
VMA, we need only then store the VMA.
v2: Formatting tweaks to debugfs output, restored some comments removed
in the next patch
Signed-off-by: Chris Wi
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 58 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +--
3 files changed, 35 insertions(+), 29 deletions(-)
diff
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_render_state.c | 40 +++-
drivers/gpu/drm/i915/i915_gem_render_state.h | 2 +-
2 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_render
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_overlay.c | 39
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index 90f3ab42
Since the scratch allocation and cleanup is shared by all engine
submission backends, move it out of the legacy intel_ringbuffer.c and
into the new home for common routines, intel_engine_cs.c
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm
The VMA are unreferenced, they belong to the object and live until they
are closed. However, if we want to use the VMA as a cookie and use it to
keep the object alive, we want to hold onto a reference to the object
for the lifetime of the VMA cookie. To facilitate this, add a couple of
simple wrapp
Treat the VMA as the primary struct responsible for tracking bindings
into the GPU's VM. That is we want to treat the VMA returned after we
pin an object into the VM as the cookie we hold and eventually release
when unpinning. Doing so eliminates the ambiguity in pinning the object
and then searchi
In a few places, we repeat a call to clear a pointer to a vma whilst
unpinning and releasing a reference to its owner. Refactor those into a
common function.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c| 12
drivers/gpu/dr
Just another useful register to inspect following a GPU hang.
v2: Remove partial decoding of RING_MODE to userspace, be consistent and
use GEN > 2 guards around RING_MODE everywhere.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
dri
This little helper only exists to safely discard the upper unused 32bits
of the general 64-bit VMA address - as we know that all Global GTT
currently are less than 4GiB in size and so that the upper bits must be
zero. In many places, we use a u32 for the global GTT offset and we want
to document wh
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 16 -
drivers/gpu/drm/i915/intel_engine_cs.c | 12 ---
drivers/gpu/drm/i915/intel
There is no other state pertaining to the completed requests in the
hang, other than gleamed through the ringbuffer, so including the
expired requests in the list of outstanding requests simply adds noise.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Matthew Auld
---
d
A simple little macro to clear a pointer and return the old value. This
is useful for writing
value = *ptr;
if (!value)
return;
*ptr = 0;
...
free(value);
in a slightly more concise form:
value = fetch_and_zero(ptr);
if (!v
Since contexts are not currently shared between userspace processes, we
have an exact correspondence between context creator and guilty batch
submitter. Therefore we can save some per-batch work by inspecting the
context->pid upon error instead. Note that we take the context's
creator's pid rather
Since the guc allocates and pins and object into the GGTT for its usage,
it is more natural to use that pinned VMA as our resource cookie.
v2: Embrace naming tautology
v3: Rewrite comments for guc_allocate_vma()
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/intel_display.c| 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 18 +--
drivers/gpu/drm/i915/intel_rin
On Mon, Aug 15, 2016 at 12:18:20PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> > @@ -1131,15 +1131,11 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private
> > *i915,
> > } else {
> > node.start = i915_ggtt_offset(vma);
> > node
On Mon, 15 Aug 2016, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
>
> I moved the main bits to be the first diffs, shouldn't affect anything
> when applying the patch, but I wanted to ask:
> I don't like the hard-coded `32` the appears in both kmalloc() and
> snprintf(), what do yo
> When we bump the MRU access tracking on set-to-gtt, we need to not only
> bump the primary GGTT VMA but all partials as well. Similarly we want to
> bump the MRU access for when unpinning an object from the scanout.
Refer to the list as LRU in the commit title and message to avoid confusion.
On
On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> Since commit 43566dedde54 ("drm/i915: Broaden application of
> set-domain(GTT)") we allowed objects to be in the GTT domain, but unbound.
> Therefore removing the GTT cache domain when removing the GGTT vma is no
> longer semantically correct.
This can happen when doing a modeset with only the cursor plane active.
Testcase: kms_atomic_transition
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
inde
On Mon, Aug 15, 2016 at 12:59:09PM +0300, Joonas Lahtinen wrote:
> > When we bump the MRU access tracking on set-to-gtt, we need to not only
> > bump the primary GGTT VMA but all partials as well. Similarly we want to
> > bump the MRU access for when unpinning an object from the scanout.
>
> Refer
== Series Details ==
Series: series starting with [CI,01/32] drm/i915: Record the position of the
start of the request
URL : https://patchwork.freedesktop.org/series/11093/
State : failure
== Summary ==
Series 11093v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series
On ma, 2016-08-15 at 10:25 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 12:18:20PM +0300, Joonas Lahtinen wrote:
> >
> > On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> > >
> > > + if (1) {
> > Umm? At least ought to have TODO: / FIXME: or some explanation. And
> You're not aware
On pe, 2016-08-12 at 12:13 +0100, Chris Wilson wrote:
> On Fri, Aug 12, 2016 at 01:50:56PM +0300, Joonas Lahtinen wrote:
> >
> > On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> > >
> > > @@ -1715,10 +1716,10 @@ int i915_gem_fault(struct vm_area_struct *area,
> > > struct vm_fault *vmf)
>
On 8/15/2016 2:50 PM, Tvrtko Ursulin wrote:
On 12/08/16 17:31, Goel, Akash wrote:
On 8/12/2016 9:52 PM, Tvrtko Ursulin wrote:
On 12/08/16 07:25, akash.g...@intel.com wrote:
From: Akash Goel
As per the current i915 Driver load sequence, debugfs registration is
done
at the end and so the re
== Series Details ==
Series: drm/i915/skl: Do not error out when total_data_rate is 0
URL : https://patchwork.freedesktop.org/series/11094/
State : failure
== Summary ==
Series 11094v1 drm/i915/skl: Do not error out when total_data_rate is 0
http://patchwork.freedesktop.org/api/1.0/series/1109
On 12 August 2016 at 16:07, Chris Wilson wrote:
> On the blitter (and in test code), we see long sequences of repeated
> commands, e.g. XY_PIXEL_BLT, XY_SCANLINE_BLT, or XY_SRC_COPY. For these,
> we can skip the hashtable lookup by remembering the previous command
> descriptor and doing a straight
On ma, 2016-08-15 at 11:12 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 12:59:09PM +0300, Joonas Lahtinen wrote:
> >
> > >
> > > When we bump the MRU access tracking on set-to-gtt, we need to not only
> > > bump the primary GGTT VMA but all partials as well. Similarly we want to
> > > bum
Stable team, please backport
commit 78c3d5fa7354774b7c8638033d46c042ebae41fb
Author: Daniel Vetter
Date: Fri Oct 23 11:00:06 2015 +0200
drm/i915: Don't complain about lack of ACPI video bios
to v4.4.
Tested-by: Rainer Fiebig # v4.4
BR,
Jani.
--
Jani Nikula, Intel Open Source Techn
On pe, 2016-08-12 at 11:28 +0100, Chris Wilson wrote:
> Keep any error reported by the gup_worker until we are notified that the
> arena has changed (via the mmu-notifier). This has the importance of
> making two consecutive calls to i915_gem_object_get_pages() reporting
> the same error, and curta
Hi list,
I have an Asus laptop, and these two patches solved my problem with
bright hot-keys not working[1].
I applied both patches on 4.8-rc1, and the only necessary fix was
changing priv_dev->dev to priv_dev->drm in all places of for_each_*
macros touched by these patches.
Is there any chance
The error state is purposefully racy as we expect it to be called at any
time and so have avoided any locking whilst capturing the crash dump.
However, with multi-engine GPUs and multiple CPUs, those races can
manifest into OOPSes as we attempt to chase dangling pointers freed on
other CPUs. Under
We currently capture the GPU state after we detect a hang. This is vital
for us to both triage and debug hangs in the wild (post-mortem
debugging). However, it comes at the cost of running some potentially
dangerous code (since it has to make very few assumption about the state
of the driver) that
After adjusting how we track the data to capture exactly what we use
via VMA, then adjusting the way we inspect the VMA we can finally
compress it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/li
Leave all the pretty printing to userspace and simplify the error
capture to only have a single common object printer. It makes the kernel
code more compact, and the refactoring allows us to apply more complex
transformations like compressing the output.
Signed-off-by: Chris Wilson
Reviewed-by: J
Since the GTT provides universal access to any GPU page, we can use it
to reduce our plethora of read methods to just one. It also has the
important characteristic of being exactly what the GPU sees - if there
are incoherency problems, seeing the batch as executed (rather than as
trapped inside the
Our error states are quickly growing, pinning kernel memory with them.
The majority of the space is taken up by the error objects. These
compress well using zlib and without decode are mostly meaningless, so
encoding them does not hinder quickly parsing the error state for
familiarity.
v2: Make th
From: Jesse Barnes
Use David's new IOMMU layer functions for supporting SVM in i915.
TODO:
error record collection for failing SVM contexts
callback handling for fatal faults
scheduling
v2: integrate David's core IOMMU support
make sure we don't clobber the PASID in the context reg st
Hi,
Now when fences got merged I reworked the series. It is now much
smaller in size. Some items are still missing like error state recording,
fault handling, documentation and in fences.
You can also find the most recent version in here:
https://cgit.freedesktop.org/~miku/drm-intel/log/?h=svm
-
From: Jesse Barnes
Add i915_gem_context_create2_ioctl for passing flags
(e.g. SVM) when creating a context.
v2: check the pad on create_context
v3: rebase
v4: i915_dma is no more. create_gvt needs flags
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Jesse Barnes (v1)
From: Jesse Barnes
Add possibility to query if svm is available.
v2: moved into i915_drv.c
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Jesse Barnes (v1)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
include/uapi/drm/i915_drm.h | 1
From: Jesse Barnes
We just need to pass in an address to execute and some flags, since we
don't have to worry about buffer relocation or any of the other usual
stuff. Returns a fence to be used for synchronization.
v2: add a request after batch submission (Jesse)
v3: add a flag for fence creati
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 21a2c58a9c122151080ecbdddc115257cd7c30d8
commit: 2bd160a131ac617fc2441bfb4a02964c964a5da6 [7/33] drm/i915: Reduce
i915_gem_objects to only show object information
config: x86_64-randconfig-s2-08151903 (attached as .confi
Very old numbers indicate this is a 66% improvement when remapping the
entire object for fence contention - due to the elimination of
track_pfn_insert and its strcmp).
Signed-off-by: Chris Wilson
Testcase: igt/gem_fence_upload/performance
Testcase: igt/gem_mmap_gtt
---
drivers/gpu/drm/Makefile
Currently, we only allocate a structure to hold metadata if we need to
allocate an ioremap for every access, such as on x86-32. However, it
would be useful to store basic information about the io-mapping, such as
its page protection, on all platforms.
Signed-off-by: Chris Wilson
Cc: linux...@kvac
On Mon, Aug 15, 2016 at 02:48:04PM +0300, Mika Kuoppala wrote:
> From: Jesse Barnes
>
> Add i915_gem_context_create2_ioctl for passing flags
> (e.g. SVM) when creating a context.
>
> v2: check the pad on create_context
> v3: rebase
> v4: i915_dma is no more. create_gvt needs flags
>
> Cc: Danie
On 12 August 2016 at 16:07, Chris Wilson wrote:
> If the developer adds a register in the wrong order, we BUG during boot.
> That makes development and testing very difficult. Let's be a bit more
> friendly and disable the command parser with a big warning if the tables
> are invalid.
>
> Signed-o
== Series Details ==
Series: series starting with [1/5] drm/i915: Allow disabling error capture
URL : https://patchwork.freedesktop.org/series/11096/
State : failure
== Summary ==
Series 11096v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/11096/revisions/1/mbox
On ma, 2016-08-15 at 14:48 +0300, Mika Kuoppala wrote:
> @@ -2566,6 +2566,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl,
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM,
> i915_gem_context_getp
On Mon, Aug 15, 2016 at 02:48:05PM +0300, Mika Kuoppala wrote:
> @@ -891,6 +894,8 @@ struct i915_gem_context {
> unsigned long flags;
> #define CONTEXT_NO_ZEROMAP BIT(0)
> #define CONTEXT_NO_ERROR_CAPTURE BIT(1)
> +#define CONTEXT_SVM BIT(2)
> +
> unsign
On Mon, 2016-08-15 at 14:48 +0300, Mika Kuoppala wrote:
>
>
> +static void i915_svm_fault_cb(struct device *dev, int pasid, u64 addr,
> + u32 private, int rwxp, int response)
> +{
> +}
> +
> +static struct svm_dev_ops i915_svm_ops = {
> + .fault_cb = i915_svm_fa
On Mon, Aug 15, 2016 at 02:48:06PM +0300, Mika Kuoppala wrote:
> From: Jesse Barnes
>
> We just need to pass in an address to execute and some flags, since we
> don't have to worry about buffer relocation or any of the other usual
> stuff. Returns a fence to be used for synchronization.
>
> v2:
On Mon, Aug 15, 2016 at 02:48:07PM +0300, Mika Kuoppala wrote:
> From: Jesse Barnes
>
> Add possibility to query if svm is available.
When we try to enable SVM on the context we get an error. We have to do
that first anywhere, that seems like a good spot for userspace to catch
all issues.
What
On Mon, 2016-08-15 at 13:05 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 02:48:05PM +0300, Mika Kuoppala wrote:
> >
> > + struct task_struct *task;
>
> We don't need the task, we need the mm.
>
> Holding the task is not sufficient.
From the pure DMA point of view, you don't need the M
Reported-by: 0day kbuild test robot
Fixes: 2bd160a131ac ("drm/i915: Reduce i915_gem_objects to only show...")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/g
Chris Wilson writes:
> On Mon, Aug 15, 2016 at 02:48:07PM +0300, Mika Kuoppala wrote:
>> From: Jesse Barnes
>>
>> Add possibility to query if svm is available.
>
> When we try to enable SVM on the context we get an error. We have to do
> that first anywhere, that seems like a good spot for user
On Mon, Aug 15, 2016 at 01:13:25PM +0100, David Woodhouse wrote:
> On Mon, 2016-08-15 at 13:05 +0100, Chris Wilson wrote:
> > On Mon, Aug 15, 2016 at 02:48:05PM +0300, Mika Kuoppala wrote:
> > >
> > > + struct task_struct *task;
> >
> > We don't need the task, we need the mm.
> >
> > Holding the
== Series Details ==
Series: svm support
URL : https://patchwork.freedesktop.org/series/11097/
State : failure
== Summary ==
Series 11097v1 svm support
http://patchwork.freedesktop.org/api/1.0/series/11097/revisions/1/mbox
Test drv_hangman:
Subgroup error-state-basic:
Chris Wilson writes:
> On Mon, Aug 15, 2016 at 02:48:04PM +0300, Mika Kuoppala wrote:
>> From: Jesse Barnes
>>
>> Add i915_gem_context_create2_ioctl for passing flags
>> (e.g. SVM) when creating a context.
>>
>> v2: check the pad on create_context
>> v3: rebase
>> v4: i915_dma is no more. crea
== Series Details ==
Series: series starting with [1/2] io-mapping: Always create a struct to hold
metadata about the io-mapping
URL : https://patchwork.freedesktop.org/series/11099/
State : failure
== Summary ==
Applying: io-mapping: Always create a struct to hold metadata about the
io-mapp
On Mon, 2016-08-15 at 13:23 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 01:13:25PM +0100, David Woodhouse wrote:
> > On Mon, 2016-08-15 at 13:05 +0100, Chris Wilson wrote:
> > > On Mon, Aug 15, 2016 at 02:48:05PM +0300, Mika Kuoppala wrote:
> > > >
> > > > + struct task_struct *task;
> >
Chris Wilson writes:
> On Mon, Aug 15, 2016 at 02:48:06PM +0300, Mika Kuoppala wrote:
>> From: Jesse Barnes
>>
>> We just need to pass in an address to execute and some flags, since we
>> don't have to worry about buffer relocation or any of the other usual
>> stuff. Returns a fence to be used
On pe, 2016-08-12 at 18:52 +0100, Chris Wilson wrote:
> Daniel Vetter proposed a new challenge to the serialisation inside the
> busy-ioctl that exposed a flaw that could result in us reporting the
> wrong engine as being busy. If the request is reallocated as we test
> its busyness and then reassi
Chris Wilson writes:
> Reported-by: 0day kbuild test robot
> Fixes: 2bd160a131ac ("drm/i915: Reduce i915_gem_objects to only show...")
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(
On Mon, Aug 15, 2016 at 01:30:11PM +0100, David Woodhouse wrote:
> On Mon, 2016-08-15 at 13:23 +0100, Chris Wilson wrote:
> > On Mon, Aug 15, 2016 at 01:13:25PM +0100, David Woodhouse wrote:
> > > On Mon, 2016-08-15 at 13:05 +0100, Chris Wilson wrote:
> > > > On Mon, Aug 15, 2016 at 02:48:05PM +030
On Mon, Aug 15, 2016 at 03:25:43PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Mon, Aug 15, 2016 at 02:48:04PM +0300, Mika Kuoppala wrote:
> >> From: Jesse Barnes
> >>
> >> Add i915_gem_context_create2_ioctl for passing flags
> >> (e.g. SVM) when creating a context.
> >>
> >> v
== Series Details ==
Series: drm/i915: Initialise mmaped_count for i915_gem_object_info
URL : https://patchwork.freedesktop.org/series/11100/
State : failure
== Summary ==
Series 11100v1 drm/i915: Initialise mmaped_count for i915_gem_object_info
http://patchwork.freedesktop.org/api/1.0/series/
On Mon, Aug 15, 2016 at 12:54:01PM +0300, Jani Nikula wrote:
> On Mon, 15 Aug 2016, Eric Engestrom wrote:
> > Signed-off-by: Eric Engestrom
> > ---
> >
> > I moved the main bits to be the first diffs, shouldn't affect anything
> > when applying the patch, but I wanted to ask:
> > I don't like the
On Mon, 2016-08-15 at 13:53 +0100, Chris Wilson wrote:
>
> So it is really just what happens to commands for this client when it
> dies/exits. The kneejerk reaction is to say the pages should be kept
> alive as they are now for !svm. We could be faced with a situation where
> the client copies on
Chris Wilson writes:
> Daniel Vetter proposed a new challenge to the serialisation inside the
> busy-ioctl that exposed a flaw that could result in us reporting the
> wrong engine as being busy. If the request is reallocated as we test
> its busyness and then reassigned to this object by another
1 - 100 of 219 matches
Mail list logo
