>
> Results at /archive/results/CI_IGT_test/Patchwork_2062/
>
> f814551aa7232ed36d71244dd148b48660b53a78 drm-intel-nightly:
> 2016y-04m-25d-11h-36m-27s UTC integration manifest
> c3f40d8 drm/i915: Propagate error from drm_gem_object_init()
>
> ___
On ti, 2016-04-26 at 11:04 +0100, Dave Gordon wrote:
> On 26/04/16 10:21, Matthew Auld wrote:
> >
> > The teardown path in render_state_init leaves so->obj != NULL.
> >
> > Suggested-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> > Signed-of
tch
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On ke, 2016-04-27 at 15:30 +0300, Mika Kuoppala wrote:
> Matthew Auld <matthew.a...@intel.com> writes:
>
> >
> > [ text/plain ]
> > Prefer a goto teardown path to do all the required cleanup.
> >
> > v2:
> > (Joonas Lahtinen)
> >
85ad98d0ec0369a3b18d4a09938f3f5537d drm-intel-nightly:
> 2016y-04m-22d-17h-32m-25s UTC integration manifest
> f9b4352 drm/i915: Function per early graphics quirk
> 135a1d0 drm/i915: Canonicalize stolen memory calculations
>
--
Joonas Lahtinen
Open Source Technology Center
On ma, 2016-04-25 at 10:23 +0100, Tvrtko Ursulin wrote:
> Acked-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Merged, thanks for the R-b and A-b!
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gf
@@ -2776,7 +2776,7 @@ int intel_init_render_ring_buffer(struct drm_device
> *dev)
>
> if (INTEL_INFO(dev)->gen >= 8) {
> if (i915_semaphore_is_enabled(dev)) {
> - obj = i915_gem_alloc_object(dev, 4096);
> + obj = i
(Correcting the bad CC's.)
What do others think?
This failed in the CI due to i915 driver not being able to claim
RESERVED_GFX memory as it's handled like RESERVED_KERN in all places.
So that'll need some tweaking, still.
Regards, Joonas
On pe, 2016-04-22 at 16:29 +0300, Joonas Lahtinen wrote
pre-eanbled state" is enabled in i915. If yes, then it will use the
> snapshot in i915 and continue to load. If no, then bail out.
>
> Thanks,
> Zhi.--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
k);
> hash_init(dev_priv->mm_structs);
> return 0;
You should remove the "return 0;" if you make the function void, and
maybe also make a not int he commit message.
With that,
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Regards, Joonas
--
Joona
EN_FOREVER.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> (v3)
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Jani Nikula &
-wilson.co.uk>
> Cc: Imre Deak <imre.d...@intel.com>
> Cc: David Weinehall <david.weineh...@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
> 1 file changed, 2 insertions(+), 6
filtered out
> with EINVAL on full-ppgtt.)
>
> The most dramatic effect this will have will be during resume, as with
> full-ppgtt the GGTT is only used sparingly.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: David Weinehall <david.weineh.
form the domain tracking inside freeze, before the image is
> written, rather than upon restoration.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Imre Deak <imre.d...@intel.com>
> Cc: David Weinehall <david.weineh...@intel.com>
Reviewed-by:
handling GEM objects.
>
> v2: There are more! Don't forget the freeze phases.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Imre Deak <imre.d...@intel.com>
> Cc: David Weinehall <david.weineh...@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.
ggtt->base.clear_range = gen8_ggtt_clear_range;
> +
> + ggtt->base.insert_entries = gen8_ggtt_insert_entries;
> + if (IS_CHERRYVIEW(dev_priv))
> + ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
> +
> return ret;
> }
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
hris.
Merged, thanks for the patch and opening the bug.
Regards, Joonas
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Joonas Lahtinen
Open Source Technology Center
Intel Corpora
second guess when it will be active (a mixture of module
> parameters and generational support, which may change over time).
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Assuming zero was previously unused.
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.
yrj...@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Cc: Thomas Gleixner <t...@linutronix.de>
> Cc: Ingo Molnar <mi...@redhat.com>
> Cc: "H. Peter Anvin" <h...@z
<daniel.vet...@ffwll.ch>
Cc: Jani Nikula <jani.nik...@intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
dim | 11 +++
1 file changed, 11 insertions(+)
diff --git a/dim b/dim
index d9c1be5..cbdae85 100755
--- a/dim
+++ b/dim
@@ -691,6 +
Nikula <jani.nik...@intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
dim | 11 +++
1 file changed, 11 insertions(+)
diff --git a/dim b/dim
index d9c1be5..cbdae85 100755
--- a/dim
+++ b/dim
@@ -691,6 +691,17 @@ function checkpatch_commit
i
Disregard this v3.
On ti, 2016-05-10 at 11:50 +0300, Joonas Lahtinen wrote:
> If committing to drm-intel-next-queued branch, require the committer
> to be aware that they are committing outside of drm/i915 maintenance
> scope.
>
> v2:
> - Do not use warn_or_fail (Jani)
>
<daniel.vet...@ffwll.ch>
Cc: Jani Nikula <jani.nik...@intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
dim | 11 +++
1 file changed, 11 insertions(+)
diff --git a/dim b/dim
index d9c1be5..fa307d5 100755
--- a/dim
+++ b/dim
@@ -691,6 +
On ti, 2016-05-10 at 12:22 +0300, Jani Nikula wrote:
> Acked-by: Jani Nikula <jani.nik...@intel.com>
Pushed to maintainer-tools.
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
p identify the register (Chris)
v3:
- Refer to register value as *_val instead of *_reg (Chris)
Cc: Jani Nikula <jani.nik...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Reviewed-by: Chris Wilson <ch...@chris-wils
>
> 83dde235b9d8bbe1cabf7ad002a6c48ff5a699fc drm-intel-nightly:
> 2016y-04m-19d-11h-58m-43s UTC integration manifest
> 6711989 drm/i915: Clean up PCI config register handling
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
On ti, 2016-04-12 at 16:57 +0100, Matthew Auld wrote:
> Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.
>
> v2: use dev_priv directly for QUESTION_MACROS (Joonas Lahtinen)
>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Reviewed-by: Joonas L
on <ch...@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Signed-off-by: Matthew Auld <matthew.a...@intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers
On ma, 2016-04-18 at 14:11 +0100, Chris Wilson wrote:
> On Mon, Apr 18, 2016 at 03:51:20PM +0300, Joonas Lahtinen wrote:
> >
> > On ti, 2016-04-12 at 16:57 +0100, Matthew Auld wrote:
> > >
> > > Remove dev local and use to_i915() in gen8_ppgtt_notify_vgt.
>
hris Wilson <ch...@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Comment below.
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i9
rflow in our checks.
>
Not sure this is the right thing to do. I think I do prefer erroring
out on invalid arguments as we're talking of internal programmer
interface.
Regards, Joonas
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel
formation + CC'ing the author (Mika
here):
Fixes: d1c54acd67dc ("drm/i915/gtt: Introduce kmap|kunmap for dma page")
With that added,
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Mika to comment on too, looks like fairly straightforward error when
doing a mass replac
p identify the register (Chris)
Cc: Jani Nikula <jani.nik...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
drivers/gpu/drm/i915/i915_dma.c|
hose
> objects used for display and hardware access.
>
> Reported-by: Akash Goel <akash.g...@intel.com>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Cc: Akash Goel <akash.g...@intel.com>
>
shrinker, so this just makes the logic for can_release_pages()
> clearer (and safer in future so that we don't over estimate our ability
> to free up pages from future non-swappable objects).
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Joonas Lahtinen
unit, too.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --
le Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
drivers/gpu/drm/i915/i915_dma.c| 15 --
drivers/gpu/drm/i915/i915_gem_stolen.c | 9
drivers/gpu/drm/i915/i915_reg.h| 38 ++
GPU engines are initialised. For example, this means that power
> contexts for rc6 (Ironlake) need to explicitly loaded, as they are.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuopp...@intel.com>
Some comments below.
Reviewed-by: Joonas
return PTR_ERR(obj);
>
> /* mark ring buffers as read-only from GPU side by default */
> obj->gt_ro = 1;
> @@ -2780,7 +2781,7 @@ int intel_init_render_ring_buffer(struct drm_device
> *dev)
> if (INTEL_INFO(dev)->gen >= 8) {
> if (i915_semaphore_i
truct i915_vma *vma)
> {
> struct i915_ggtt *ggtt;
> void *ptr;
>
> if (vma->iomap)
> return vma->iomap;
>
> if (WARN_ON(!vma->obj->map_and_fenceable))
> return ERR_PTR(-ENODEV);
>
>
.com>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +---
> 1 file ch
On to, 2016-04-21 at 08:08 +0100, Chris Wilson wrote:
> On Thu, Apr 21, 2016 at 09:57:03AM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > >
> > > + if (!request->ctx->engine[engine->id].initialised) {
On to, 2016-04-21 at 08:01 +0100, Chris Wilson wrote:
> On Thu, Apr 21, 2016 at 09:48:36AM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > >
> > > The code to switch_mm() is already handled by i915_switch_con
obj->pages->nents, 0)
> - pages[n++] = sg_page_iter_page(_iter);
> -
> - obj->mapping = vmap(pages, n, 0, PAGE_KERNEL);
> - drm_free_large(pages);
> - }
> + obj->mapping = i915_gem_object_map(obj);
> if (obj->mapping == NULL) {
> i915_gem_object_unpin_pages(obj);
> return ERR_PTR(-ENOMEM);
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
legacy/execlist contexts.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Nitpick below.
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_lrc.c | 39 ++
ble pin as that exposes a race inside the lrc
> irq handler as it tries to access the context after it may be retired.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
Below comments addressed,
Reviewe
On to, 2016-04-21 at 08:22 +0100, Chris Wilson wrote:
> On Thu, Apr 21, 2016 at 10:07:50AM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-04-20 at 19:42 +0100, Chris Wilson wrote:
> > >
> > > As the contexts are accessed by the hardware until the switch is
On to, 2016-04-21 at 08:56 +0100, Chris Wilson wrote:
> On Thu, Apr 21, 2016 at 10:47:30AM +0300, Joonas Lahtinen wrote:
> >
> > On to, 2016-04-21 at 08:08 +0100, Chris Wilson wrote:
> > >
> > > On Thu, Apr 21, 2016 at 09:57:03AM +0300, Joonas Lahtinen wrote
;
> > Cc: Mika Kuoppala <mika.kuopp...@intel.com>
> > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> > Cc: Thomas Gleixner <t...@li
the s/dev_priv/i915/. Do you have a
patch for the preceding s/i915/i915_module/ patch, or should I go and
write it?
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Regards, Joonas
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> ---
> drivers/gp
gpu_idle(struct drm_device *dev)
>
> /* Flush everything onto the inactive list. */
> for_each_engine(engine, dev_priv) {
> + if (engine->last_context == NULL)
> + continue;
> +
> if (!i915.enable_execlists) {
On ma, 2016-05-23 at 12:34 +0100, Chris Wilson wrote:
> Pack the integers and related types together inside the struct.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> Cc: Joonas Lahtinen <j
On ma, 2016-05-23 at 12:34 +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Some commit message would be nice.
> ---
> dr
_priv as closed.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 17 +++--
> drivers/gpu/d
ure to allocate the ppgtt.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 53
> +
> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 38
> -
> 1 file changed, 37 insertions(+), 1 deletion(-)
>
> diff
ists and non-default legacy contexts) will retain their
> state across the reset.
>
Should not hurt at least.
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_ge
stored/
> + for_each_engine(engine, dev_priv) {
> + struct intel_context *ce =
> + _priv->kernel_context->engine[engine->id];
> +
> + ce->initialised =
> + !i915.enable_execlists || engine->init_context == NULL;
> + }
here?
> dev_priv->kernel_context->remap_slice = ALL_L3_SLICES(dev_priv);
> }
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
locate requests as side-effect of calling certain functions.
>
I already added in previous series; CC'ing Dave again.
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Link:
> http://patchwork.freedesk
i915_ring_error_state(m, dev, error, i);
>
This captures the engine related ring state, I think it's even worth a
comment when there is engine vs. error disparity.
And how about the messages? Should we update them more agressively
where necessary.
Regards, Joonas
--
Joonas Laht
->global += vma->node.size;
> + } else {
> + struct i915_hw_ppgtt *ppgtt
> + = container_of(vma->vm,
> + struct i915_hw_ppgtt,
> + base);
Use i91
h for Tvrtko, not remembering he's traveling.
assert_spin_locked() should make this enough robust that it'll still do
what it did perviously.
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Regards, Joonas
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
&g
dev)
>
> ret = i915_gem_init_hw(dev);
> if (ret == -EIO) {
> - /* Allow ring initialisation to fail by marking the GPU as
> + /* Allow engine initialisation to fail by marking the GPU as
> * wedged. But we only want to do this where the GPU is angry,
> * for all other failure, such as an allocation failure, bail.
> */
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
it on the legacy of gpu_caches_dirty
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Link:
> http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-18-git-send-email-ch...@chris-wilson.co
copying here;
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Link:
> http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-2-git-send-email-ch...@chris-wilson.co.uk
> Cc: Tvrtko Ursulin <tvr
request = i915_gem_active_peek(>last_read[i],
> -
> >base.dev->struct_mutex);
> - if (!request)
> - continue;
> + active_mask = 1;
Wouldn't we have RENDER_RING
eak;
> -
> - ret = i915_gem_object_put_pages(obj);
> + ret = i915_gem_object_unbind(obj);
> + if (ret == 0)
(!ret)
Other than that, looks good.
The list_for_each loops are fancy to review because we have so many
levels of functions and you never know where the corresponding li
pu/drm/i915/intel_display.c
> @@ -11378,7 +11378,7 @@ static bool use_mmio_flip(struct intel_engine_cs
> *engine,
> if (resv && !reservation_object_test_signaled_rcu(resv, false))
> return true;
>
> - return engine != i915_gem_request_get_en
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
This series will need plenty of CI regression and benchmark testing...
Regards, Joonas
> ---
> drivers/gpu/drm/i915/i915_gem.c | 59
> +++
et)
> - goto out_gtt_cleanup;
> + ggtt->mappable =
> + io_mapping_create_wc(ggtt->mappable_base, ggtt->mappable_end);
Splitting between arguments might look leaner.
Otherwise looks OK, plenty of code motion so not super easy to track.
On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote:
> We use "list" to denote the list and "link" to denote an element on that
> list. Rename request->list to match this idiom.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
R
ive)
> +{
> + return i915_gem_request_get_seqno(i915_gem_active_peek(active));
Nuke the i915_gem_request_get_seqno wrapper, it's insanity. Now or an
another patch.
> +}
> +
> +static inline struct intel_engine_cs *
> +i915_gem_active_g
i915_gem_active_get_seqno(>last_read[id]));
> + i915_gem_active_get_seqno(>last_read[id],
> +
> >base.dev->struct_mutex));
In functions where you use plenty of this, maybe make struct_mutex
alias. But before that, what's wrong with passing dev_priv?
Regar
t;
> - }
> + } else
> + intel_overlay_release_old_vid_tail(>last_flip, NULL);
Why you added else?
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On ti, 2016-07-26 at 09:12 +0100, Chris Wilson wrote:
> On Tue, Jul 26, 2016 at 08:02:25AM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-07-25 at 18:31 +0100, Chris Wilson wrote:
> > >
> > > A few places we use ring when referring to the struct intel_e
)
> static inline struct drm_i915_gem_request *
> i915_gem_active_get(const struct i915_gem_active *active, struct mutex
> *mutex)
> {
> - struct drm_i915_gem_request *request;
> -
> - request = i915_gem_active_peek(active, mutex);
> - if (!request || i915_gem_request_completed(request))
> - return NULL;
> -
> - return i915_gem_request_get(request);
> + return i915_gem_request_get(i915_gem_active_peek(active, mutex));
On average looks better with a variable in between and not all
functions chained.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ruct i915_vma *vma,
> + unsigned int engine)
> +{
> + return vma->active & BIT(engine);
> +}
> +
Are these going to grow more complex? Otherwise looks fine,
Reviewed-by: Joonas Lahtinen <joonas.
On ke, 2016-07-27 at 08:04 +0100, Chris Wilson wrote:
> On Wed, Jul 27, 2016 at 09:04:03AM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote:
> > >
> > > Tidy up the for loops that handle waiting for rea
>obj_link);
> + if (!i915_vma_is_active(vma) && !vma->pin_count)
> + WARN_ON(__i915_vma_unbind_no_wait(vma));
Same here, an optimization?
Somebody from the original CC list probably should give it a look too.
Regards, Joonas
--
Joonas Lahtinen
llow, there also seems to
be a hint of paranoia, but it's with GEM_BUG_ON() so should not hurt.
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
active_mask = 1;
> >
> > Wouldn't we have RENDER_RING define for this and other instances?
>
> ?
Defining a mask with first bit set is not very informative, is it?
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
On ti, 2016-07-26 at 08:42 +0100, Chris Wilson wrote:
> On Tue, Jul 26, 2016 at 10:08:32AM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote:
> > >
> > > -/**
> > > - * i915_gem_init_ggtt - Initialize GEM
lson <ch...@chris-wilson.co.uk>
With the improvements in tracking, makes sense.
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 -
> drivers/gpu/drm/i915/i915_gem.c | 14 ++-
On ke, 2016-07-27 at 08:57 +0100, Chris Wilson wrote:
> On Wed, Jul 27, 2016 at 10:40:14AM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote:
> > >
> > > @@ -172,6 +176,24 @@ static void i915_gem_request_retire(struct
&g
t;)
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: David Weinehall <david.weineh...@intel.com>
> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i91
>
> > Subgroup basic-batch-kernel-default-wb:
> > pass -> DMESG-FAIL (ro-bdw-i7-5557U)
> Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=96927
>
> >
> > Test kms_pipe_crc_basic:
> > Subgroup suspend-rea
_flush(request,
> + 0, I915_GEM_GPU_DOMAINS);
> +
> /* Not allowed to fail! */
> WARN(ret, "*_ring_flush_all_caches failed: %d!\n", ret);
Fix this message too.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology C
s Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem_request.c| 8 +++-
> drivers/gpu/drm/i915/i915_guc_submission.c | 9 ++---
> drivers/gpu/drm/i915/intel_guc.h
. This makes the interface simpler for the reader, and will
> simplify for patches.
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 51
> ++
/CI_IGT_test/RO_Patchwork_1594/
>
> 5c9e3d9 drm-intel-nightly: 2016y-07m-25d-06h-32m-37s UTC integration manifest
> 7e91383 drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
n.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_drv.h| 4 ++--
> drivers/gpu/drm/i915/i915_gem.c| 2 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 ---
> 3 fil
hw(dev);
> if (ret == -EIO) {
> - /* Allow ring initialisation to fail by marking the GPU as
> + /* Allow engine initialisation to fail by marking the GPU as
> * wedged. But we only want to do this where the GPU is angry,
> * for all other failure, such as an allocation failure, bail.
> */
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
wn a bit too.
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_irq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/
On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote:
> Joonas doesn't like the tiny function, especially if I go around making
> it more complicated and using it elsewhere. To remove that temptation,
> remove the function!
>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@
ringbuf->space = __intel_ring_space(ringbuf->head & HEAD_ADDR,
> - ringbuf->tail, ringbuf->size);
> + ring->space = __intel_ring_space(ring->head & HEAD_ADDR,
> + ring->tail, ring-
selection compact.
With this change,
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lis
nd content, so
you could mentione renaming the function (which is all this patch
does).
For code,
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
On ma, 2016-07-25 at 09:44 +0100, Chris Wilson wrote:
> On Mon, Jul 25, 2016 at 11:38:07AM +0300, Joonas Lahtinen wrote:
> >
> > On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote:
> > >
> > > The obj->batch_pool_link is only inspected when traversin
h_pool_link)
> i915_gem_object_put(obj);
> - }
> +
> + INIT_LIST_HEAD(>cache_list[n]);
> }
> }
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
mand length in the header).
> + * If not, it calls this function to determine the per-engine length
> + * field encoding for the command (i.e. different opcode ranges use
> + * certain bits to encode the command length in the header).
> */
> u32 (*get_cmd_length_mask)(u32 cmd_header);
> };
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
401 - 500 of 2892 matches
Mail list logo
