On Thu, Mar 19, 2015 at 06:37:28PM +0100, Daniel Vetter wrote:
On Wed, Mar 18, 2015 at 06:19:22PM +, Chris Wilson wrote:
WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279
i915_gem_evict_vm+0x10c/0x140()
WARN_ON(!list_empty(vm-active_list))
How does this
-Original Message-
From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
Sent: Thursday, March 19, 2015 12:52 AM
To: Konduru, Chandra
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 04/19] drm/i915: Allocate a crtc_state also when the crtc
is
being disabled
On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote:
Oh right, I got it, but not sure I like it that much. I don't think
batch pool implementation is well enough decoupled from the users.
batch pool Splitting it this way actually improves decoupling.
Well in a way at least where
Currently, we only track the last request globally across all engines.
This prevents us from issuing concurrent read requests on e.g. the RCS
and BCS engines (or more likely the render and media engines). Without
semaphores, we incur costly stalls as we synchronise between rings -
greatly
Michel Thierry michel.thie...@intel.com writes:
From: Ben Widawsky benjamin.widaw...@intel.com
This patch was formerly known as, Force pd restore when PDEs change,
gen6-7. I had to change the name because it is needed for GEN8 too.
The real issue this is trying to solve is when a new object
From: Ville Syrjälä ville.syrj...@linux.intel.com
AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2
From: Ville Syrjälä ville.syrj...@linux.intel.com
AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
When doing a native or i2c aux write the sink will indicate the number
of bytes written even if it the nacks the transfer. When we receive a
nack we just return an error upwards, but it might still be interesting
to see how many bytes made it
From: Deepak S deepa...@linux.intel.com
Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
Signed-off-by: Deepak S deepa...@linux.intel.com
---
Hi Dave -
Backporting a couple of plane related fixes from drm-next to v4.0.
BR,
Jani.
The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda:
Linux 4.0-rc4 (2015-03-15 17:38:20 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5995
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 272/272
On Thu, 2015-03-19 at 00:38 +, Konduru, Chandra wrote:
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Friday, March 13, 2015 2:49 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH 07/19] drm/i915: Copy
On Thu, 2015-03-19 at 00:44 +, Konduru, Chandra wrote:
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Friday, March 13, 2015 2:49 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH 08/19] drm/i915: Don't
On Thu, 2015-03-19 at 00:12 +, Konduru, Chandra wrote:
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Friday, March 13, 2015 2:49 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH 04/19] drm/i915:
On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
AUX addresses are 20 bits long. Send out the entire address instead of
just the low 16 bits.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Jani Nikula
On Wed, 2015-03-18 at 23:57 +, Konduru, Chandra wrote:
-Original Message-
From: Conselvan De Oliveira, Ander
Sent: Wednesday, March 18, 2015 12:57 AM
To: intel-gfx@lists.freedesktop.org
Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
Subject: [PATCH v4] drm/i915:
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5989
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On 03/18/2015 05:33 PM, Tvrtko Ursulin wrote:
On 03/18/2015 05:27 PM, Chris Wilson wrote:
On Wed, Mar 18, 2015 at 04:51:58PM +, Tvrtko Ursulin wrote:
On 03/09/2015 09:55 AM, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When doing a native or i2c aux write the sink will indicate the number
of bytes written even if it the nacks the transfer. When we receive a
nack we just return an error upwards, but it
On Tue, Mar 17, 2015 at 05:22:08PM +0200, Jani Nikula wrote:
On Fri, 13 Mar 2015, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
supposed to switch the request from I2C_WRITE to
On Thu, Mar 19, 2015 at 03:22:42AM +, Song, Ruiling wrote:
Yeah, MAP_FIXED sounds a bit more ambitious and though I think it would
work for OCL 2.0 pointer sharing, it's a little different than we were
planning.
To summarize, we have three possible approaches, each with its own
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 region, we are better off just trying to fit it
anywhere and
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.
Is there any way to identify either what
On 03/19/2015 10:06 AM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote:
Oh right, I got it, but not sure I like it that much. I don't think
batch pool implementation is well enough decoupled from the users.
batch pool Splitting it this way actually improves
From: Ville Syrjälä ville.syrj...@linux.intel.com
When doing a native or i2c aux write the sink will indicate the number
of bytes written even if it the nacks the transfer. When we receive a
nack we just return an error upwards, but it might still be interesting
to see how many bytes made it
On Thu, Mar 19, 2015 at 11:39:16AM +, Tvrtko Ursulin wrote:
On 03/19/2015 10:06 AM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote:
Well in a way at least where when we talk about LRU ordering, it
depends on retiring working properly and that is not
On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
When doing a native or i2c aux write the sink will indicate the number
of bytes written even if it the nacks the transfer. When we receive a
nack we just return an error upwards, but it
From: John Harrison john.c.harri...@intel.com
Much of the driver has now been converted to passing requests around instead of
rings/ringbufs/contexts. Thus the function for retreiving the request from a
ring (i.e. the OLR) is no longer used and can be removed.
For: VIZ-5115
Signed-off-by: John
From: John Harrison john.c.harri...@intel.com
Updated the *_ring_flush_all_caches() functions to take requests instead of
rings or ringbuf/context pairs.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
From: John Harrison john.c.harri...@intel.com
Updated do_switch() to take a request pointer instead of a ring/context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
v2: Removed some overzealous req- dereferencing.
---
drivers/gpu/drm/i915/i915_gem_context.c |7
From: John Harrison john.c.harri...@intel.com
Updated the various ring-dispatch_execbuffer() implementations to take a
request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
From: John Harrison john.c.harri...@intel.com
The overlay update code path to do explicit request creation and submission
rather than relying on the OLR to do the right thing.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/intel_overlay.c | 56
From: John Harrison john.c.harri...@intel.com
Udpated the various ring-flush() functions to take a request instead of a ring.
Also updated the tracer to include the request id.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c |
From: John Harrison john.c.harri...@intel.com
Now that all callers of i915_add_request() have a request pointer to hand, it is
possible to update the add request function to take a request pointer rather
than pulling it out of the OLR.
For: VIZ-5115
Signed-off-by: John Harrison
From: John Harrison john.c.harri...@intel.com
Updated intel_ring_cacheline_align() to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_display.c|2 +-
From: John Harrison john.c.harri...@intel.com
The outstanding_lazy_request is no longer used anywhere in the driver.
Everything that was looking at it now has a request explicitly passed in from on
high. Everything that was relying upon it behind the scenes is now explicitly
From: John Harrison john.c.harri...@intel.com
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()
From: John Harrison john.c.harri...@intel.com
Updated the various ring-emit_flush() implementations to take a request instead
of a ringbuf/context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
From: John Harrison john.c.harri...@intel.com
As there is no OLR to check, the check_olr() function is now a no-op and can be
removed.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 28
From: John Harrison john.c.harri...@intel.com
The start of day context initialisation code in i915_gem_context_enable() loops
over each ring and calls the legacy switch context or the execlist init context
code as appropriate.
This patch moves the ring looping out of that function in to the top
From: John Harrison john.c.harri...@intel.com
In _i915_add_request(), the request is associated with a userland client.
Specifically it is linked to the 'file' structure and the current user process
is recorded. One problem here is that the current user process is not
necessarily the same as when
From: John Harrison john.c.harri...@intel.com
When the ring buffer is full, the driver finds an outstanding request that will
free up sufficient space for the current operation and waits for it to complete.
If no such request can be found, there is a fall back path of just polling until
From: John Harrison john.c.harri...@intel.com
Converted i915_gem_l3_remap() to take a request structure instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
From: John Harrison john.c.harri...@intel.com
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
mode and many are never actually used. Previously, the initialisation commands
were written to
From: John Harrison john.c.harri...@intel.com
Updated the display page flip code to do explicit request creation and
submission rather than relying on the OLR and just hoping that the request
actually gets submitted at some random point.
The sequence is now to create a request, queue the work to
From: John Harrison john.c.harri...@intel.com
Updated the various ring-signal() implementations to take a request instead of
a ring. This removes their reliance on the OLR to obtain the seqno value that
should be used for the signal.
For: VIZ-5115
Signed-off-by: John Harrison
From: John Harrison john.c.harri...@intel.com
Updated the ring-emit_request() implementation to take a request instead of a
ringbuf/request pair. Also removed it's use of the OLR for obtaining the
request's seqno.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by:
From: John Harrison john.c.harri...@intel.com
Updated the ring-sync_to() implementations to take a request instead of a ring.
Also updated the tracer to include the request id.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c |
From: John Harrison john.c.harri...@intel.com
In order to explcitly track all GPU work (and completely remove the outstanding
lazy request), it is necessary to add extra i915_add_request() calls to various
places. Some of these do not need the implicit cache flush done as part of the
standard
From: John Harrison john.c.harri...@intel.com
The i915_gem_init_hw() function calls a bunch of smaller initialisation
functions. Multiple of which have generic sections and per ring sections. This
means multiple passes are done over the rings. Each pass writes data to the ring
which floats around
From: John Harrison john.c.harri...@intel.com
The render state initialisation code does an explicit i915_add_request() call to
commit the init commands. It was passing in the initialisation batch buffer to
add_request() as the batch object parameter. However, the batch object entry in
the request
From: John Harrison john.c.harri...@intel.com
Now that everything above has been converted to use request structures, it is
possible to update the lower level move_to_active() functions to be request
based as well.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by:
From: John Harrison john.c.harri...@intel.com
The LRC submission code requires a request for tracking purposes. It does not
actually require that request to 'complete' it simply uses it for keeping hold
of reference counts on contexts and such like.
Previously, the fall back path of polling for
From: John Harrison john.c.harri...@intel.com
Updated *_ring_invalidate_all_caches(), i915_reset_gen7_sol_offsets() and
i915_emit_box() to take request structures instead of ring or ringbuf/context
pairs.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf
From: John Harrison john.c.harri...@intel.com
Updated the two render_state_init() functions to take a request pointer instead
of a ring. This removes their reliance on the OLR.
v2: Rebased to newer tree.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf
From: John Harrison john.c.harri...@intel.com
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 more complex patch to share a single request between the sync and the
From: John Harrison john.c.harri...@intel.com
Updated the *_ring_workarounds_emit() functions to take requests instead of
ring/context pairs.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c
From: John Harrison john.c.harri...@intel.com
The i915_gem_object_flush_active() call used to do lots. Over time it has done
less and less. Now all it does call i915_gem_retire_requests_ring(). Hence it is
pretty much redundant as the two callers could just call retire directly. This
patch makes
From: John Harrison john.c.harri...@intel.com
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. This also means that it no longer needs to lazily allocate
a request if no-one happens to have
From: John Harrison john.c.harri...@intel.com
Updated the switch_mm() code paths to take a request instead of a ring. This
includes the myriad *_mm_switch functions themselves and a bunch of PDP related
helper functions.
v2: Rebased to newer tree.
For: VIZ-5115
Signed-off-by: John Harrison
From: John Harrison john.c.harri...@intel.com
In execlist mode, the context object pointer is written in to the request
structure (and reference counted) at the point of request creation. In legacy
mode, this only happens inside i915_add_request().
This patch updates the legacy code path to
From: John Harrison john.c.harri...@intel.com
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
is done. Thus guaranteeing that all that work is tagged by a known request. At
present,
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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.
Further, it is due to grow massively with the arrival of the GPU scheduler.
This patch simplifies
From: John Harrison john.c.harri...@intel.com
The only usage of intel_logical_ring_begin() is within intel_lrc.c so it can be
made static. To avoid a forward declaration at the top of the file, it and bunch
of other functions have been shuffled upwards.
For: VIZ-5115
Signed-off-by: John Harrison
From: John Harrison john.c.harri...@intel.com
The legacy and LRC code paths have an almost identical procedure for waiting for
space in the ring buffer. They both search for a request in the free list that
will advance the tail to a point where sufficient space is available. They then
wait for
From: John Harrison john.c.harri...@intel.com
The submission portion of the execbuffer code path was abstracted into a
function pointer indirection as part of the legacy vs execlist work. The two
implementation functions are called 'i915_gem_ringbuffer_submission' and
'intel_execlists_submission'
From: John Harrison john.c.harri...@intel.com
Shrunk the parameter list of i915_gem_execbuffer_retire_commands() to a single
structure as everything it requires is available in the execbuff_params object.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf
From: John Harrison john.c.harri...@intel.com
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the move_to_gpu() code paths.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas
From: John Harrison john.c.harri...@intel.com
Rather than just having a local request variable in the execbuff code, the
request pointer is now stored in the execbuff params structure. Also added
explicit cleanup of the request (plus wiping the OLR to match) in the error
case. This means that the
From: John Harrison john.c.harri...@intel.com
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the
execbuffer_move_to_active() code path.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
From: John Harrison john.c.harri...@intel.com
Now that a single per ring loop is being done for all the different
intialisation steps in i915_gem_init_hw(), it is possible to add proper request
management as well. The last remaining issue is that the context enable call
eventually ends up within
From: John Harrison john.c.harri...@intel.com
Updated a couple of trace points to use the now cached request pointer rather
than extracting it from the ring.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
From: John Harrison john.c.harri...@intel.com
The alloc_request() function does not actually return the newly allocated
request. Instead, it must be pulled from ring-outstanding_lazy_request. This
patch fixes this so that code can create a request and start using it knowing
exactly which request
From: John Harrison john.c.harri...@intel.com
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), moves the request structure onto the right list and other
such house
From: John Harrison john.c.harri...@intel.com
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 or
management of that work.
The only way the add request call can fail is if it can't write
From: John Harrison john.c.harri...@intel.com
Added explicit request creation and submission to the GPU idle code path.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 14 +-
1
From: John Harrison john.c.harri...@intel.com
Updated mi_set_context() to take a request structure instead of a ring and
context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c |
From: John Harrison john.c.harri...@intel.com
Now that everything above has been converted to use requests, it is possible to
update init_context() to take a request pointer instead of a ring/context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas
On Thu, 19 Mar 2015, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
On Thu, Mar 19, 2015 at 04:23:32PM +0530, Deepak S wrote:
Hi Chris,
if we map the object into unmappable region. I think we should skip fence
create ?
We should just ignore the failure. Whether or not we want the fence
pinned is a matter for the FBC code, which is a different level.
But
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5999
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On 03/19/2015 11:46 AM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 11:39:16AM +, Tvrtko Ursulin wrote:
On 03/19/2015 10:06 AM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 09:36:14AM +, Tvrtko Ursulin wrote:
Well in a way at least where when we talk about LRU ordering, it
depends on
On Thu, Mar 19, 2015 at 11:58:17AM +, Tvrtko Ursulin wrote:
How about retire all rings and then the inactive batch search with a
global pool becomes only O(num_rings) at worst? Might be worth
saving memory resource (multiple pools) vs. trivial traversal like
that?
There isn't a memory
From: John Harrison john.c.harri...@intel.com
The request allocation code is largely duplicated between legacy mode and
execlist mode. The actual difference between the two versions of the code is
pretty minimal.
This patch moves the common code out into a separate function. This is then
called
On Thursday 19 March 2015 03:38 AM, 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
From: Ben Widawsky benjamin.widaw...@intel.com
This patch was formerly known as, Force pd restore when PDEs change,
gen6-7. I had to change the name because it is needed for GEN8 too.
The real issue this is trying to solve is when a new object is mapped
into the current address space. The GPU
On 3/19/2015 9:01 AM, Mika Kuoppala wrote:
Michel Thierry michel.thie...@intel.com writes:
From: Ben Widawsky benjamin.widaw...@intel.com
This patch was formerly known as, Force pd restore when PDEs change,
gen6-7. I had to change the name because it is needed for GEN8 too.
The real issue
From: John Harrison john.c.harri...@intel.com
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 no
longer needs to lazily allocate a request if no-one happens to have done it
earlier.
For:
From: John Harrison john.c.harri...@intel.com
Updated intel_emit_post_sync_nonzero_flush(), gen7_render_ring_cs_stall_wa() and
gen8_emit_pipe_control() to take requests instead of rings.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf
From: John Harrison john.c.harri...@intel.com
A bunch of the low level LRC functions were passing around ringbuf and ctx
pairs. In a few cases, they took the r/c pair and a request as well. This is all
quite messy and unnecesary. The context_queue() call is especially bad since the
fake request
From: John Harrison john.c.harri...@intel.com
Updated the ring-emit_bb_start() implementation to take a request instead of a
ringbuf/context pair.
For: VIZ-5115
Signed-off-by: John Harrison john.c.harri...@intel.com
Reviewed-by: Tomas Elf tomas@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c
From: John Harrison john.c.harri...@intel.com
Now that the request is guaranteed to specify the context, it is possible to
update the context switch code to use requests rather than ring and context
pairs. This patch updates i915_switch_context() accordingly.
Also removed the warning that the
From: John Harrison john.c.harri...@intel.com
Updated the various ring-add_request() implementations to take a request
instead of a ring. This removes their reliance on the OLR to obtain the seqno
value that the request should be tagged with.
For: VIZ-5115
Signed-off-by: John Harrison
This patch adds fast link training support if BDB version
is equal or higher than 182 and the feature is supported
in VBT.
Signed-off-by: Mika Kahola mika.kah...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 4
drivers/gpu/drm/i915/intel_bios.h
On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5996
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.
Do we want to throw out the actual code as well
On Thursday 19 March 2015 04:48 PM, Ville Syrjälä wrote:
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy
Yeah my big concern was with not making this opt-in like the old patch or
adding an interface which does a lot more than what we need right now
(Chris' patch). Just a bitflag to ask for this seems best and is fine with me.
And for the implementation I think we should reuse the PIN_BIAS
1 - 100 of 219 matches
Mail list logo
