On 19/10/2014 15:15, Daniel Vetter wrote:
On Fri, Oct 10, 2014 at 12:41:12PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
For: VIZ-4377
Signed-off-by: john.c.harri...@intel.com
I think this should be squashed (well, split first) into the relevant
earlier patches. Generally I
time
being as the semaphores are hardware based and the hardware only understands
seqno values.
[Patches against drm-intel-nightly tree fetched 29/10/2014]
On 30/10/2014 18:40, john.c.harri...@intel.com wrote:
From: John Harrison
Work in progress for replacing seqno usage with requst str
This is an old version. I have a new and improved patch that also fixes
the legacy ring buffer case (which was equally broken). Will post shortly...
On 30/10/2014 15:30, Dave Gordon wrote:
From: John Harrison
Check whether each engine exists before trying to clean up the
corresponding
/i915: Add IRQ friendly request
deference facility
From: John Harrison
The next patches in the series convert some display related seqno usage to
request structure usage. However, the request dereference introduced
must be done from interrupt context. As the dereference potentially
involves freeing
/i915: Interrupt driven request
completion
From: John Harrison
Added a hook to the ring noftification code to process request completion.
This means that there is no longer a need to explicitly process request
completions every time a request object is tested. Instead, the test code
simply becomes
friendly
request deference facility
From: John Harrison
The next patches in the series convert some display related seqno
usage to request structure usage. However, the request dereference
introduced must be done from interrupt context. As the dereference
potentially involves freeing the request
Looks good to me.
Reviewed-by: John Harrison
On 25/11/2014 10:39, Thomas Daniel wrote:
Dynamic context pinning for LRCs introduced a leak in legacy mode.
Reinstate context unreference in i915_gem_free_request for legacy contexts.
Leak reported by i-g-t/drv_module_reload fixed by this patch
On 26/11/2014 09:23, Daniel Vetter wrote:
On Mon, Nov 24, 2014 at 06:49:34PM +, john.c.harri...@intel.com wrote:
From: John Harrison
Converted the mmio_flip 'seqno' value to be a request structure as part of the
on going seqno to request changes. This includes reference co
On 26/11/2014 09:19, Daniel Vetter wrote:
On Mon, Nov 24, 2014 at 06:49:33PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The next patches in the series convert some display related seqno usage to
request structure usage. However, the request dereference introduced must be
done
set with the order re-worked so that it still builds and runs at each
step along the way...
On 24/11/2014 18:49, john.c.harri...@intel.com wrote:
From: John Harrison
Added reference counting of the request structure around __wait_seqno() calls.
This is a precursor to updating the wait code i
On 26/11/2014 10:39, Chris Wilson wrote:
On Wed, Nov 26, 2014 at 10:28:13AM +0100, Daniel Vetter wrote:
With refcounting it looks like you can just drop that refcount, but
that's not really the case. So make sure no one forgets.
Motivated by the unlocked call in the mmio flip code.
I had an un
On 26/11/2014 13:24, Daniel Vetter wrote:
On Mon, Nov 24, 2014 at 06:49:39PM +, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the trace_irq code to use requests instead of seqnos. This includes
reference counting the request object to ensure it sticks around when required
On 26/11/2014 14:42, Daniel Vetter wrote:
On Wed, Nov 26, 2014 at 3:12 PM, John Harrison
wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 8bfdac6..831fae2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3130,4
On 26/11/2014 12:49, Daniel Vetter wrote:
On Wed, Nov 26, 2014 at 1:12 PM, John Harrison
wrote:
The unref_irq is needed for the flip_queued_req as that is still
dereferenced from interrupt time. Possibly this one could now be downgraded
to a mutex lock but before the recent rebase, the
On 26/11/2014 13:43, Daniel Vetter wrote:
On Mon, Nov 24, 2014 at 06:49:43PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The ring member of the object structure was always updated with the
last_read_seqno member. Thus with the conversion to last_read_req, obj->ring is
no
On 28/11/2014 18:06, Daniel Vetter wrote:
On Fri, Nov 28, 2014 at 05:49:26PM +, John Harrison wrote:
On 26/11/2014 13:43, Daniel Vetter wrote:
On Mon, Nov 24, 2014 at 06:49:43PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The ring member of the object structure was
rences: https://bugs.freedesktop.org/show_bug.cgi?id=86992
Cc: John Harrison
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
But yes, the reasoning why it crashes without the zero fill is correct.
Dodgy context pointers that used to be ignored now get processed. Doing
the zero fill keeps it all sane.
On 05/12/2014 17:54, John Harrison wrote:
This is already part of the seqno/request patch series and has been
right
Is anyone else having problems reading the PRTS logs?
It looks like I got a merge failure complaint, presumably because I need
to rebase to a newer nightly tree. However, the log file itself does not
say anything useful. There is a bit of pre-amble which finishes by
saying 'This file include 3
On 02/07/2014 19:20, Jesse Barnes wrote:
On Thu, 26 Jun 2014 18:24:04 +0100
john.c.harri...@intel.com wrote:
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver with
submission of batch buffers to the hardware. Thus it is possible for an
application to
On 02/07/2014 19:29, Jesse Barnes wrote:
On Thu, 26 Jun 2014 18:24:07 +0100
john.c.harri...@intel.com wrote:
From: John Harrison
The scheduler needs to explicitly allocate a seqno to track each submitted batch
buffer. This must happen a long time before any commands are actually written to
On 07/07/2014 20:14, Daniel Vetter wrote:
On Thu, Jun 26, 2014 at 06:24:06PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
The scheduler needs to do interrupt triggered work that is too complex to do in
the interrupt handler. Thus it requires a deferred work handler to process
On 07/07/2014 20:21, Daniel Vetter wrote:
On Wed, Jul 02, 2014 at 11:34:23AM -0700, Jesse Barnes wrote:
On Thu, 26 Jun 2014 18:24:08 +0100
john.c.harri...@intel.com wrote:
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver with their
submission to the
On 23/07/2014 19:50, Daniel Vetter wrote:
On Wed, Jul 23, 2014 at 5:37 PM, John Harrison
wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 0977653..fbafa68 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
On 17/06/2015 15:04, Daniel Vetter wrote:
On Thu, Jun 04, 2015 at 01:06:34PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking
On 17/06/2015 15:06, Daniel Vetter wrote:
On Fri, May 29, 2015 at 05:44:16PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_gem_object_flush_active() call used to do lots. Over time it has done
less and less. Now all it does check the various associated requests to see
On 17/06/2015 15:21, Chris Wilson wrote:
On Wed, Jun 17, 2015 at 04:06:05PM +0200, Daniel Vetter wrote:
On Fri, May 29, 2015 at 05:44:16PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_gem_object_flush_active() call used to do lots. Over time it has done
less and less
...@intel.com wrote:
From: John Harrison
Now that the *_ring_begin() functions no longer call the request allocation
code, it is finally safe for the request allocation code to call *_ring_begin().
This is important to guarantee that the space reserved for the subsequent
i915_add_request() call does
On 18/06/2015 12:10, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 12:03:12PM +0100, John Harrison wrote:
On 17/06/2015 15:21, Chris Wilson wrote:
On Wed, Jun 17, 2015 at 04:06:05PM +0200, Daniel Vetter wrote:
On Fri, May 29, 2015 at 05:44:16PM +0100, john.c.harri...@intel.com wrote:
From
On 18/06/2015 13:21, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 01:14:56PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync
On 18/06/2015 16:39, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 04:24:53PM +0200, Daniel Vetter wrote:
On Thu, Jun 18, 2015 at 01:59:13PM +0100, John Harrison wrote:
On 18/06/2015 13:21, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 01:14:56PM +0100, john.c.harri...@intel.com wrote:
From
On 18/06/2015 14:29, Daniel Vetter wrote:
On Thu, Jun 18, 2015 at 1:21 PM, John Harrison
wrote:
I'm still confused by what you are saying in the above referenced email.
Part of it is about the sanity checks failing to handle the wrapping case
correctly which has been fixed in the base re
On 23/06/2015 11:24, Chris Wilson wrote:
On Fri, May 29, 2015 at 05:44:07PM +0100, john.c.harri...@intel.com wrote:
-int intel_ring_begin(struct intel_engine_cs *ring,
+int intel_ring_begin(struct drm_i915_gem_request *req,
int num_dwords)
{
- struct drm_i915_gem_req
On 23/06/2015 11:23, Chris Wilson wrote:
On Fri, May 29, 2015 at 05:44:15PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
As there is no OLR to check, the check_olr() function is now a no-op and can be
removed.
You ignored a genuine, and trivially easy to hit, compiler warning
On 23/06/2015 11:16, Chris Wilson wrote:
On Fri, May 29, 2015 at 05:43:24PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_add_request() function is called to keep track of work that has been
written to the ring buffer. It adds epilogue commands to track progress (seqno
On 22/06/2015 21:12, Daniel Vetter wrote:
On Fri, Jun 19, 2015 at 05:34:12PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking
On 23/06/2015 14:25, Daniel Vetter wrote:
On Tue, Jun 23, 2015 at 11:37:53AM +0100, John Harrison wrote:
On 23/06/2015 11:24, Chris Wilson wrote:
On Fri, May 29, 2015 at 05:44:07PM +0100, john.c.harri...@intel.com wrote:
-int intel_ring_begin(struct intel_engine_cs *ring,
+int
On 23/06/2015 14:24, Daniel Vetter wrote:
On Tue, Jun 23, 2015 at 12:38:01PM +0100, John Harrison wrote:
On 22/06/2015 21:12, Daniel Vetter wrote:
On Fri, Jun 19, 2015 at 05:34:12PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
It is a bad idea for i915_add_request() to fail
On 23/06/2015 21:00, Daniel Vetter wrote:
On Tue, Jun 23, 2015 at 04:43:24PM +0100, John Harrison wrote:
On 23/06/2015 14:24, Daniel Vetter wrote:
On Tue, Jun 23, 2015 at 12:38:01PM +0100, John Harrison wrote:
On 22/06/2015 21:12, Daniel Vetter wrote:
On Fri, Jun 19, 2015 at 05:34:12PM +0100
On 24/06/2015 13:45, Daniel Vetter wrote:
On Wed, Jun 24, 2015 at 01:18:48PM +0100, John Harrison wrote:
On 23/06/2015 21:00, Daniel Vetter wrote:
On Tue, Jun 23, 2015 at 04:43:24PM +0100, John Harrison wrote:
On 23/06/2015 14:24, Daniel Vetter wrote:
On Tue, Jun 23, 2015 at 12:38:01PM +0100
On 26/06/2015 14:34, Chris Wilson wrote:
On Fri, Jun 26, 2015 at 01:58:11PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
The intended usage model for struct fence is that the signalled status should be
set on demand rather than polled. That is, there should not be a need for a
On 30/06/2015 15:43, Tomas Elf wrote:
On 30/06/2015 12:40, john.c.harri...@intel.com wrote:
From: John Harrison
An earlier patch was added to reserve space in the ring buffer for the
commands issued during 'add_request()'. The initial version was
pessimistic in the way it hand
ed correctly. Either way, the downgrade was
certainly not intentional.
Cc: John Harrison
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915
On 02/07/2015 12:54, Chris Wilson wrote:
On Thu, Jul 02, 2015 at 12:09:59PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
Various projects desire a mechanism for managing dependencies between
work items asynchronously. This can also include work items across
complete different
On 02/07/2015 14:22, Chris Wilson wrote:
On Thu, Jul 02, 2015 at 02:01:56PM +0100, John Harrison wrote:
On 02/07/2015 12:54, Chris Wilson wrote:
On Thu, Jul 02, 2015 at 12:09:59PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
Various projects desire a mechanism for managing
On 06/07/2015 10:29, Daniel Vetter wrote:
On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote:
On 07/02/2015 04:55 PM, Chris Wilson wrote:
It would be nice if we could reuse one seqno both for internal/external
fences. If you need to expose a fence ordering within a timeline that is
On 06/07/2015 14:59, Daniel Vetter wrote:
On Mon, Jul 06, 2015 at 01:58:25PM +0100, John Harrison wrote:
On 06/07/2015 10:29, Daniel Vetter wrote:
On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote:
On 07/02/2015 04:55 PM, Chris Wilson wrote:
It would be nice if we could reuse
ntel.com wrote:
From: John Harrison
The driver tracks GPU work using request structures. Unfortunately, this
tracking is not currently explicit but is done by means of a catch-all request
that floats around in the background hoovering up work until it gets submitted.
This background reque
On 02/06/2015 19:26, Tomas Elf wrote:
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
The plan is to pass requests around as the basic submission tracking
structure
rather than rings and contexts. This patch updates the
i915_gem_object_sync()
code path.
v2: Much
On 02/06/2015 19:16, Tomas Elf wrote:
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_add_request() function is called to keep track of work that
has been
written to the ring buffer. It adds epilogue commands to track
progress (seqno
updates and such
hn.c.harri...@intel.com wrote:
From: John Harrison
A previous patch (read-read optimisation) changed the early exit
condition in i915_gem_retire_requests_ring() from checking the request
list to checking the active list. This assumes that all requests have
objects associated with them which are pla
Doh! The subject was meant to be RFC not PATCH.
On 19/12/2014 14:41, john.c.harri...@intel.com wrote:
From: John Harrison
The outstanding lazy request mechanism does not really work well with
a GPU scheduler. The scheduler expects each work packet, i.e. request
structure, to be a complete
Hello,
Apparently, I've been volunteered to review these patches despite not
knowing too much about these areas of the driver...
On 14/01/2015 11:20, Chris Wilson wrote:
Currently, the command parser tries to create a secondary batch exactly
as large as the original, and vmap both. This is op
On 14/01/2015 11:20, Chris Wilson wrote:
The biggest user of i915_gem_object_get_page() is the relocation
processing during execbuffer. Typically userspace passes in a set of
relocations in sorted order. Sadly, we alternate between relocations
increasing from the start of the buffers, and relocat
Accidentally hit send too early, ignore the other reply!
On 14/01/2015 11:20, Chris Wilson wrote:
The biggest user of i915_gem_object_get_page() is the relocation
processing during execbuffer. Typically userspace passes in a set of
relocations in sorted order. Sadly, we alternate between relocat
On 14/01/2015 11:20, Chris Wilson wrote:
Move the madvise logic out of the execbuffer main path into the
relatively rare allocation path, making the execbuffer manipulation less
fragile.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 12 +++-
drivers/gp
On 11/02/2015 15:29, Chris Wilson wrote:
On Wed, Feb 11, 2015 at 04:50:14PM +0200, Mika Kuoppala wrote:
We use the pid of the process which opened our device when
we track which was the culprit of the gpu hang. But as that
file descriptor might get inherited, we might blame the
wrong process whe
On 13/02/2015 13:23, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 01:08:59PM +, John Harrison wrote:
@@ -1155,40 +1154,30 @@ i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
batch_start_offset,
batch_len
On 13/02/2015 12:19, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:56AM +, john.c.harri...@intel.com wrote:
From: John Harrison
Updated ironlake_enable_rc6() to do explicit request creation and submission.
If you merged the context here with the common context switching code,
we
On 13/02/2015 12:17, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:58AM +, john.c.harri...@intel.com wrote:
From: John Harrison
Now that everything above has been converted to use requests,
intel_logical_ring_begin() can be updated to take a request instead of a
ringbuf/context pair
On 13/02/2015 17:03, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote:
On 13/02/2015 12:19, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:56AM +, john.c.harri...@intel.com wrote:
From: John Harrison
Updated ironlake_enable_rc6() to do explicit
On 13/02/2015 12:15, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:33AM +, john.c.harri...@intel.com wrote:
From: John Harrison
In execlist mode, context initialisation is deferred until first use of the
given context. This is because execlist mode has many more contexts than legacy
On 13/02/2015 12:20, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:57AM +, john.c.harri...@intel.com wrote:
From: John Harrison
Now that everything above has been converted to use requests, intel_ring_begin()
can be updated to take a request instead of a ring. This also means that it
Please note that a lot of the issues with _i915_add_request are cleaned
up by my patch series to remove the outstanding_lazy_request. The add to
client in some random client context is fixed, the messy execlist vs
legacy ringbuf decisions are removed, the execlist vs legacy one-sided
context re
On 25/02/2015 21:34, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:10AM +, john.c.harri...@intel.com wrote:
From: John Harrison
There is a flags word that is passed through the execbuffer code path all the
way from initial decoding of the user parameters down to the very final
On 25/02/2015 21:52, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
From: John Harrison
The do_execbuf() function takes quite a few parameters. The actual set of
parameters is going to change with the conversion to passing requests around
On 25/02/2015 22:22, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:16AM +, john.c.harri...@intel.com wrote:
From: John Harrison
Start of explicit request management in the execbuffer code path. This patch
adds a call to allocate a request structure before all the actual hardware work
On 25/02/2015 21:08, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 12:21:29PM +, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:17AM +, john.c.harri...@intel.com wrote:
From: John Harrison
The alloc_request() function does not actually return the newly allocated
request. Instead
On 25/02/2015 21:15, Daniel Vetter wrote:
On Wed, Feb 18, 2015 at 03:27:38PM +, John Harrison wrote:
On 13/02/2015 12:15, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:33AM +, john.c.harri...@intel.com wrote:
From: John Harrison
In execlist mode, context initialisation is
On 25/02/2015 21:31, Daniel Vetter wrote:
On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote:
On 13/02/2015 17:03, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote:
On 13/02/2015 12:19, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:56AM +
On 27/02/2015 13:35, Daniel Vetter wrote:
On Fri, Feb 27, 2015 at 12:22:42PM +, John Harrison wrote:
On 25/02/2015 21:52, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
From: John Harrison
The do_execbuf() function takes quite a few
On 21/07/2015 08:05, Daniel Vetter wrote:
On Fri, Jul 17, 2015 at 03:31:17PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is intended
to keep track of work that is executed on hardware. I.e. it solves
On 22/07/2015 15:26, Tvrtko Ursulin wrote:
Hi,
On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that
is intended
to keep track of work that is executed on hardware. I.e. it solves
the bas
On 22/07/2015 15:45, Tvrtko Ursulin wrote:
On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that
is intended
to keep track of work that is executed on hardware. I.e. it solves
the basic
pr
On 29/07/2015 22:19, Jesse Barnes wrote:
On 07/07/2015 02:15 AM, Tvrtko Ursulin wrote:
On 07/06/2015 01:58 PM, John Harrison wrote:
On 06/07/2015 10:29, Daniel Vetter wrote:
On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote:
On 07/02/2015 04:55 PM, Chris Wilson wrote:
It would
Hello,
Is this patch going to be split up into more manageable pieces? I tried
to apply it to a tree fetched yesterday and got a very large number of
conflicts. I don't know whether that is because more execlist patches
have been merged or if it is other random changes that have broken it or
ut it
seems a bit inconsistent.
Thanks,
John.
On 11/09/2014 07:51, Chris Wilson wrote:
On Tue, Sep 09, 2014 at 03:14:29PM +0100, John Harrison wrote:
I pulled a fresh tree on Monday and applied this set of patches.
There were two conflicts. It looks like nightly does not have
'i915_gem_context
On 06/10/2014 15:45, Daniel Vetter wrote:
On Mon, Oct 06, 2014 at 03:15:05PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu
i915: Zero fill the request structure
24drm/i915: Defer seqno allocation until actual hardware
submission time
The whole set in its latest and greatest form has also been uploaded to
the drm-private git as 'topic/seqno-request'.
On 06/10/2014 15:15, john.c.harri...@intel.com wr
On 19/10/2014 15:21, Daniel Vetter wrote:
On Fri, Oct 10, 2014 at 01:03:17PM +0100, John Harrison wrote:
I have just posted an updated subset of the patch series. Note that one
patch has been inserted in the middle and the first one has been dropped.
The correct sequence is now:
01drm
On 10/10/2014 11:35, Steven Newbury wrote:
On Thu, 2014-06-26 at 18:23 +0100, john.c.harri...@intel.com wrote:
From: John Harrison harri...@intel.com>
Implemented a batch buffer submission scheduler for the i915 DRM
driver.
Hi John,
I was just wondering what's happening with th
On 19/10/2014 13:32, Daniel Vetter wrote:
On Mon, Oct 06, 2014 at 03:15:07PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
The new seqno alloction code pre-allocates a 'lazy' request structure and then
tries to allocate the 'lazy' seqno. The seqno allocatio
On 19/10/2014 13:35, Daniel Vetter wrote:
On Mon, Oct 06, 2014 at 03:15:09PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
I think a few words about how these helpers help the transitions (and
example maybe) would be great. Since without peeking ahead (which I
didn't
On 19/10/2014 13:40, Daniel Vetter wrote:
On Mon, Oct 06, 2014 at 03:15:10PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison
For: VIZ-4377
Signed-off-by: john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c|6 +--
drivers/gpu/drm/i915/i915_drv.h
On 9/18/2024 12:32, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* drm/i915/guc: Enable PXP GuC autoteardown flow (rev2)
*URL:* https://patchwork.freedesktop.org/series/138337/
*State:*failure
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13833
On 9/26/2024 18:54, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* drm/i915/guc: Enable PXP GuC autoteardown flow (rev3)
*URL:* https://patchwork.freedesktop.org/series/138337/
*State:*failure
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13833
On 10/12/2024 08:34, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* drm/i915/guc: Enable PXP GuC autoteardown flow (rev4)
*URL:* https://patchwork.freedesktop.org/series/138337/
*State:*failure
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1383
and ARL-U are supported from
102.1.15.1926. Therefore, the driver needs to check which specific ARL
subplatform its running on when verifying that the GSC FW is new enough
for it.
Fixes: 2955ae8186c8 ("drm/i915: ARL requires a newer GSC firmware")
Signed-off-by: Daniele Ceraolo Spurio
On 11/4/2024 15:09, Daniele Ceraolo Spurio wrote:
On 11/4/2024 3:02 PM, John Harrison wrote:
On 10/28/2024 16:31, Daniele Ceraolo Spurio wrote:
All MTL and ARL SKUs share the same GSC FW, but the newer platforms are
only supported in newer blobs. In particular, ARL-S is supported
starting from
Please ignore, sent to the wrong mailing list!
John.
s/12309
Cc: John Harrison
Cc: # v6.3+
Signed-off-by: Eugene Kobyak
---
v2:
- return drm_info to separate condition
v3:
- create separate condition which generate string if intel_context exist
v4:
- rollback and add check intel_context in log condition
drivers/gpu/drm/i915/i915_gpu_e
On 11/29/2024 04:12, Andi Shyti wrote:
On Thu, Nov 28, 2024 at 06:32:28PM -0800, John Harrison wrote:
On 11/28/2024 13:28, Eugene Kobyak wrote:
When the intel_context structure contains NULL,
it raises a NULL pointer dereference error in drm_info().
Fixes: e8a3319c31a1 ("drm/i915: Allow
hn)
Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to
pmu")
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/dri
On 12/24/2024 11:10, Daniele Ceraolo Spurio wrote:
On 12/24/2024 10:13 AM, John Harrison wrote:
On 12/23/2024 15:20, Daniele Ceraolo Spurio wrote:
On 12/20/2024 5:19 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Add debug info to help investigate a very rare bug:
https
, run igt@perf_pmu@busy-hang followed by
igt@perf_pmu@most-busy-idle-check-all for a couple iterations.
Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to
pmu")
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: John Harrison
---
.../gpu
m/i915/pmu: Connect engine busyness stats from GuC to
pmu")
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 -
2 files changed, 9 insertions(+), 1 de
On 11/18/2024 15:22, Umesh Nerlige Ramappa wrote:
On gt reset, if a context is running, then accumulate it's active time
into the busyness counter since there will be no chance for the context
to switch out and update it's run time.
Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness sta
On 11/21/2024 16:31, John Harrison wrote:
On 11/18/2024 15:22, Umesh Nerlige Ramappa wrote:
Active busyness of an engine is calculated using gt timestamp and the
context switch in time. While capturing the gt timestamp, it's possible
that the context switches out. This race could result
On 11/20/2024 07:03, Eugene Kobyak wrote:
When the intel_context structure contains NULL,
it raises a NULL pointer dereference error in drm_info().
This patch aims to resolve issue:
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12309
Signed-off-by: Eugene Kobyak
---
drivers/gpu/drm
On 12/23/2024 15:20, Daniele Ceraolo Spurio wrote:
On 12/20/2024 5:19 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Add debug info to help investigate a very rare bug:
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13385
Signed-off-by: John Harrison
---
drivers/gpu
901 - 1000 of 1003 matches
Mail list logo
