On Fri, 13 Feb 2015, Bob Paauwe wrote:
> Background:
>
> This capability is targeted at deeply embedded appliance like devices
> that make use of Intel integrated graphics. There are a few use cases
> that are not currently supported by the i915 driver. For example,
> they may not be running use
On Fri, 13 Feb 2015, Bob Paauwe wrote:
> Human readable name for each output type to correspond with names
> used in the ACPI property tables.
Could you not use drm_connector and drm_encoder type and name fields?
BR,
Jani.
>
> Signed-off-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_displ
On Fri, 13 Feb 2015, Bob Paauwe wrote:
> We'll reduce some duplicate code if we move the list node allocation
> to its own function when we start processing future config items like
> workaround or vbt information.
Should probably just be part of patch 1.
BR,
Jani.
>
> Signed-off-by: Bob Paauwe
On Fri, 13 Feb 2015, Bob Paauwe wrote:
> This adds an init-time configuration framework that parses configuration
> data from an ACPI property table. The table is assumed to have well
> defined sub-device property tables that correspond to the various
> driver components. Initially the following
On Thu, Feb 12, 2015 at 05:17:04PM -0800, Rodrigo Vivi wrote:
> No, we had solved old frontbuffer false positives... some missing
> flush somewhere at that time...
>
> So, I added a bunch of printk and I insist that it is conceptually
> wrong to set intel_crtc_atomic_commit on check times when you
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5765
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 282/282
On Thu, Feb 12, 2015 at 01:36:29PM +, Nick Hoath wrote:
> On 11/02/2015 18:21, Lespiau, Damien wrote:
> >I have no idea how that crept in, but we need to do the write from the
> >ring and this is a masked register. Two fixes in 1!
> >
> >Cc: Nick Hoath
> >Signed-off-by: Damien Lespiau
>
> Re
On Fri, Feb 06, 2015 at 09:32:29AM +0100, Daniel Vetter wrote:
> On Thu, Feb 05, 2015 at 04:11:00PM -0800, Jesse Barnes wrote:
> > On Wed, 14 Jan 2015 11:20:55 +
> > Chris Wilson wrote:
> >
> > > diff --git a/drivers/char/agp/intel-gtt.c
> > > b/drivers/char/agp/intel-gtt.c index 92aa43fa8d70
On Thu, Feb 12, 2015 at 09:48:23AM +, Chris Wilson wrote:
> On Thu, Feb 12, 2015 at 10:43:44AM +0100, Daniel Vetter wrote:
> > On Thu, Feb 12, 2015 at 07:53:18AM +, Chris Wilson wrote:
> > > When we walk the list of vma, or even for protecting against concurrent
> > > framebuffer creation,
On Fri, Feb 13, 2015 at 10:03:49AM +0100, Daniel Vetter wrote:
> On Thu, Feb 12, 2015 at 09:48:23AM +, Chris Wilson wrote:
> > On Thu, Feb 12, 2015 at 10:43:44AM +0100, Daniel Vetter wrote:
> > > On Thu, Feb 12, 2015 at 07:53:18AM +, Chris Wilson wrote:
> We still need to grab dev->struct_m
On Fri, Feb 13, 2015 at 10:59:42AM +0200, Ville Syrjälä wrote:
> Hmm, except we don't do it for clear_range(), but I guess that's not a
> huge issue, just means someone could clobber some other memory besides
> the scratch page if accidentally writing to a cleared area of the ggtt.
It's a very sma
On Thu, Feb 12, 2015 at 12:29:21PM +, Nick Hoath wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652
>
> Signed-off-by: Nick Hoath
Commit message is missing the absolutely crucial detail about which patch
introduced this regression:
commit 6d3d8274bc45de4babb62d64562d92af9
On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote:
> From: Rafael Barbalho
>
> With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be
> cleaned up so that the PPGTT PDE & PTE allocations can be freed.
>
> This problem only shows up with full PPGTT becau
On Thu, Feb 12, 2015 at 09:03:06PM +, Chris Wilson wrote:
> On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote:
> > From: Rafael Barbalho
> >
> > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be
> > cleaned up so that the PPGTT PDE & PTE allocat
On 13/02/2015 09:32, Daniel Vetter wrote:
On Thu, Feb 12, 2015 at 12:29:21PM +, Nick Hoath wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652
Signed-off-by: Nick Hoath
Commit message is missing the absolutely crucial detail about which patch
introduced this regression:
Hi,
My name is Stéphane ANCELOT, I am working at Numalliance R&D Team in
France (http://www.numalliance.com).
We are making our own wire bending CNC platform, linux based using INTEL
PC platforms (automation and GUI in the same PC).
That may be the wrong place, but I think it is important to re
On Fri, Feb 13, 2015 at 10:51:36AM +0100, Daniel Vetter wrote:
> On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote:
> > From: Rafael Barbalho
> >
> > With full PPGTT enabled an object's VMA entry into a PPGTT VM needs to be
> > cleaned up so that the PPGTT PDE & PTE alloca
This series includes a preparation patch for drrs support across differnt
platforms in intel_dp_set_m_n along with last 5 pending patches of V3 eDP
DRRS patch series.
New series is submitted to make the review more comfortable and
to display the dependancy of the patches explicitly.
Durgadoss R (
Till Gen 7 we have two sets of M_N registers, but Gen 8 onwards
we have only one M_N register set. To support DRRS on both scenarios
a input parameter to intel_dp_set_m_n is added.
In case of DRRS, When platform provides two set of M_N registers for dp,
we can program them with two different divid
From: Vandana Kannan
Definition of VLV RR switch bit and corresponding toggling in
set_drrs function.
Signed-off-by: Vandana Kannan
Signed-off-by: Uma Shankar
Reviewed-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c |
From: Durgadoss R
This patch enables eDP DRRS for CHV by adding the
required IS_CHERRYVIEW() checks.
CHV uses the same register bit as VLV.
[Vandana]: Since CHV has 2 sets of M_N registers, it will follow the same code
path as gen < 8. Added CHV check in dp_set_m_n()
[Ram]: Rebased on top of pr
From: Vandana Kannan
Adding a debugfs entry to determine if DRRS is supported or not
V2: [By Ram]: Following details about the active crtc will be filled
in seq-file of the debugfs
1. Encoder output type
2. DRRS Support on this CRTC
3. DRRS current state
4
From: Vandana Kannan
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will b
From: Vandana Kannan
Adding an overview of DRRS in general and the implementation for eDP DRRS.
Also, describing the functions related to eDP DRRS.
Signed-off-by: Vandana Kannan
Reviewed-by: Rodrigo Vivi
---
Documentation/DocBook/drm.tmpl | 11 +
drivers/gpu/drm/i915/intel_dp.c | 95
On Fri, Feb 13, 2015 at 10:55:46AM +0100, Daniel Vetter wrote:
> On Thu, Feb 12, 2015 at 09:03:06PM +, Chris Wilson wrote:
> > On Thu, Feb 12, 2015 at 08:05:02PM +, rafael.barba...@intel.com wrote:
> > > From: Rafael Barbalho
> > >
> > > With full PPGTT enabled an object's VMA entry into
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5766
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 282/282
On pe, 2015-02-13 at 08:44 +0100, Daniel Vetter wrote:
> On Thu, Feb 12, 2015 at 11:56:50PM +0200, Imre Deak wrote:
> > On Tue, 2015-02-03 at 11:30 +0100, Daniel Vetter wrote:
> > > At driver load we need to tell the vblank code about the state of the
> > > pipes, so that the logic around reject vb
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
is done. Thus guaranteeing that all that work is tagged by a known request. At
present, nothing further is done with the
From: John Harrison
Added explicit request creation and submission to the GPU idle code path.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
From: John Harrison
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
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c |2 +-
2 files
From: John Harrison
In execlist mode, the ringbuf is a function of the ring and context whereas in
legacy mode, it is derived from the ring alone. Thus the calculation required to
determine the ringbuf pointer from the ring (and context) also needs to test
execlist mode or not. This is messy.
Fu
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.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h|2 +-
drive
From: John Harrison
Updated the ring->sync_to() implementations to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c |6 --
drivers/gpu/drm/i915/intel_ringbuffer.h
From: John Harrison
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 batch buffer submission proce
From: John Harrison
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
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
drivers
From: John Harrison
Updated the switch_mm() code paths to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_context.c |2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 20
drivers/gpu/drm/i915/i915_gem_gtt.h
From: John Harrison
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 the ring, assign the
know
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.
Further, it is due to grow massively with the arrival of the GPU scheduler.
This patch simplies the prototype by passing a p
From: John Harrison
For some reason, the i915_add_request() call in
i915_gem_execbuffer_retire_commands() was explicitly having its return code
ignored. The _retire_commands() function itself was 'void'. Given that
_add_request() can fail without dispatching the batch buffer, this seems odd.
Als
From: John Harrison
Added explicit creation creation and submission of the request structure to the
display object pinning code. This removes any reliance on the OLR keeping track
of the request and the unknown randomness that can ensue with other work
becoming part of the same request.
For: VIZ
From: John Harrison
There is a trace point in the legacy execbuffer execution path that is missing
from the execlist path. Trace points are extremely useful for debugging and are
used by various automated validation tests. Hence, this patch adds the missing
trace point back in.
For: VIZ-5115
Sig
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 move_to_gpu() code paths.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +-
drive
From: John Harrison
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 match the execlist version. Th
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 request (ring->outstanding_la
From: John Harrison
Updated intel_emit_post_sync_nonzero_flush(), gen7_render_ring_cs_stall_wa(),
gen7_ring_fbc_flush() and gen8_emit_pipe_control() to take requests instead of
rings.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 29
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 dispatch
buffer call. It is simply called 'flags'. Unfortuantely, there are many other
flags words floating around in the same
From: John Harrison
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
---
drivers/gpu/drm/i915/i915_gem_context.c |4 ++--
drivers/gpu/dr
From: John Harrison
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
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 +++-
driv
From: John Harrison
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
---
drivers/gpu/drm/i915/intel_overlay.c | 64 +-
1 file changed, 4
From: John Harrison
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 in that ring's OLR until
From: John Harrison
Updated the two render_state_init() functions to take a request pointer instead
of a ring. This removes their reliance on the OLR.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_render_state.c | 18 +-
drivers/gpu/drm/i915/i91
From: John Harrison
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 it actually owns.
For: V
From: John Harrison
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 level
caller i915_gem_init
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
execbuffer_move_to_active() code path.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h|2 +-
From: John Harrison
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
---
drivers/gpu/drm/i915/i915_drv.h
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
mode and many are never actually used. Previously, the initialisation commands
were written to the ring and tagged with s
From: John Harrison
Converted i915_gem_l3_remap() to take a request structure instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c |5 +++--
drivers/gpu/drm/i915/i915_gem_context.c |
From: John Harrison
Updated the *_ring_workarounds_emit() functions to take requests instead of
ring/context pairs.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_lrc.c| 14 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c |6 +++---
2 files chang
From: John Harrison
In order to explicitly manage requests from creation to submission, it is
necessary to be able to explicitly create them in the first place. This patch
adds an indirection wrapper to the request creation function so that it can be
called from generic code without having to wor
From: John Harrison
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
---
drivers/gpu/drm/i915/i915_gem
From: John Harrison
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
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
drivers/gpu/drm/i915/intel_lrc.c| 11 +--
driver
From: John Harrison
The final step in removing the OLR from i915_gem_init_hw() is to pass the newly
allocated request structure in to each step rather than passing a ring
structure. This patch updates both i915_ppgtt_init_ring() and
i915_gem_context_enable() to take request pointers.
For: VIZ-51
From: John Harrison
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
---
drivers/gpu/drm/i915/intel_lrc.c| 17 -
drivers/gpu/drm/i915/intel_ringbuffer.h |3 +--
2
From: John Harrison
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 request's context must match
From: John Harrison
Updated the various ring->dispatch_execbuffer() implementations to take a
request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
drivers/gpu/drm/i915/i915_gem_render_state.c |3 +--
drivers/gpu
From: John Harrison
Updated do_switch() to take a request pointer instead of a ring/context pair.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_context.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/
From: John Harrison
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
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
dr
From: John Harrison
Updated mi_set_context() to take a request structure instead of a ring and
context pair.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_context.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i9
From: John Harrison
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 *_render_state_init() and
From: John Harrison
Udpated the various ring->flush() functions to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_context.c |2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c |6 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c
From: John Harrison
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
---
drivers/gpu/drm/i915/intel_lrc.c| 12 +---
drivers/gpu/drm/i915/intel_ringbuffer.h |3 +--
2 files chan
From: John Harrison
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 execbuff code is no longe
From: John Harrison
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
---
drivers/gpu/drm/i915/intel_ringbuffer.
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. This also means that it no longer needs to lazily allocate
a request if no-one happens to have done it earlier.
Note th
From: John Harrison
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 Harrison
---
drivers/gpu/
From: John Harrison
Updated ironlake_enable_rc6() to do explicit request creation and submission.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_pm.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/d
From: John Harrison
Updated intel_ring_cacheline_align() to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_display.c|2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c |3 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h |2 +-
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 no
longer needs to lazily allocate a request if no-one happens to have done it
earlier.
For: VIZ-5115
Signed-off-by: Jo
From: John Harrison
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 behind the scenes is now explicitly
creating/passing/submitting it's own private reque
On Fri, Feb 13, 2015 at 10:58 AM, Nick Hoath wrote:
> On 13/02/2015 09:32, Daniel Vetter wrote:
>>
>> On Thu, Feb 12, 2015 at 12:29:21PM +, Nick Hoath wrote:
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652
>>>
>>> Signed-off-by: Nick Hoath
>>
>>
>> Commit message is missi
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
> mode and many are never actually
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. This also means that it no longer n
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 don't even need to touch the ring here.
-Ch
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 no
> longer needs to lazily alloca
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, it must be pulled from ring->outstanding_lazy_request. This
> patch fixes this so that code can create
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5767
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 282/282
Long ago I found that I was getting sporadic errors when booting SNB,
with the symptom being that the first batch died with IPEHR != *ACTHD,
typically caused by the TLB being invalid. These magically disappeared
if I held the forcewake during the entire ring initialisation sequence.
(It can probabl
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 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,
> > is_master);
> >-if (ret)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652
When converting from implicitly tracked execlist queue items to ref counted
requests, not all free's of requests were replaced with unrefs, and extraneous
refs/unrefs of contexts were added.
Correct the unbalanced refcount & replace the
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 Fri, Feb 13, 2015 at 12:59:45PM +, Chris Wilson wrote:
> Long ago I found that I was getting sporadic errors when booting SNB,
> with the symptom being that the first batch died with IPEHR != *ACTHD,
> typically caused by the TLB being invalid. These magically disappeared
> if I held the for
On Fri, Feb 13, 2015 at 01:30:35PM +, Nick Hoath wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652
>
> When converting from implicitly tracked execlist queue items to ref counted
> requests, not all free's of requests were replaced with unrefs, and extraneous
> refs/unrefs
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 Fri, Feb 13, 2015 at 02:43:40PM +0100, Daniel Vetter wrote:
> On Fri, Feb 13, 2015 at 12:59:45PM +, Chris Wilson wrote:
> > Long ago I found that I was getting sporadic errors when booting SNB,
> > with the symptom being that the first batch died with IPEHR != *ACTHD,
> > typically caused by
On Fri, Feb 13, 2015 at 01:35:26PM +, John Harrison wrote:
> 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
Long ago I found that I was getting sporadic errors when booting SNB,
with the symptom being that the first batch died with IPEHR != *ACTHD,
typically caused by the TLB being invalid. These magically disappeared
if I held the forcewake during the entire ring initialisation sequence.
(It can probabl
On Fri, Feb 06, 2015 at 12:48:57PM +0200, Jani Nikula wrote:
> On Fri, 06 Feb 2015, Andreas Ruprecht wrote:
> > Commit 03dae59c72d8 ("drm/i915: Ditch UMS config option") removed
> > CONFIG_DRM_I915_UMS from the Kconfig file, but i915_drv.c still
> > references this option in two #ifndef statem
On Fri, Feb 13, 2015 at 02:00:50PM +, John Harrison wrote:
> >+list_move_tail(&obj->batch_pool_list, &pool->cache_list);
> Why is it now safe to do a move_tail instead of add_tail if the node
> has just been allocated? Was the original add_tail() wrong or am I
> not spotting some critical d
1 - 100 of 138 matches
Mail list logo