On Thu, Apr 28, 2016 at 01:48:27PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 28, 2016 at 10:13:37AM +0200, Daniel Vetter wrote:
> > On Tue, Apr 26, 2016 at 08:57:51PM +0300, Ville Syrjälä wrote:
> > > On Tue, Apr 26, 2016 at 04:30:05PM +0200, Daniel Vetter wrote:
> > > > On Tue, Apr 26, 2016 at 05:
On 28/04/16 09:56, Chris Wilson wrote:
In the next patches, we want to move the work out of freeing the request
and into its retirement (so that we can free the request without
requiring the struct_mutex). This means that we cannot rely on
unreferencing the request to completely teardown the requ
On Thu, Apr 28, 2016 at 03:31:00PM +0100, Chris Wilson wrote:
> On Thu, Apr 28, 2016 at 03:02:18PM +0100, Dave Gordon wrote:
> > On 28/04/16 09:56, Chris Wilson wrote:
> > >Now that we share intel_ring_begin(), reserving space for the tail of
> > >the request is identical between legacy/execlists a
On Thu, Apr 28, 2016 at 03:43:52PM +0100, Dave Gordon wrote:
> On 28/04/16 09:56, Chris Wilson wrote:
> >In the next patches, we want to move the work out of freeing the request
> >and into its retirement (so that we can free the request without
> >requiring the struct_mutex). This means that we ca
On 28/04/16 09:56, Chris Wilson wrote:
The hardware tracks contexts and expects all live contexts (those active
on the hardware) to have a unique identifier. This is used by the
hardware to assign pagefaults and the like to a particular context.
v2: Reorder to make sure ctx->link is not left dan
On Thu, Apr 28, 2016 at 11:38:55AM +0300, Imre Deak wrote:
> On to, 2016-04-28 at 10:17 +0200, Daniel Vetter wrote:
> > On Tue, Apr 26, 2016 at 07:01:06PM +0300, Imre Deak wrote:
> > > On ti, 2016-04-26 at 15:42 +0100, Chris Wilson wrote:
> > > > On Tue, Apr 26, 2016 at 05:26:43PM +0300, Eero Tammi
On 28/04/16 14:47, Chris Wilson wrote:
Move all of the constant assignments up front and into a common
function. This is primarily to ensure the backpointers are set as early
as possible for later use during initialisation.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
I'm not too happy
On 28/04/16 09:56, Chris Wilson wrote:
Rather than reuse the current location of the context in the global GTT
for its hardware identifier, use the context's unique ID assigned to it
for its whole lifetime.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915
On Thu, Apr 28, 2016 at 04:10:54PM +0100, Tvrtko Ursulin wrote:
> >-/* Intentionally left blank. */
> >-engine->buffer = NULL;
> >
> > engine->dev = dev;
>
> Setting engine->dev was last in sequence before and now it is ahead
> of lot of other things. I am not sure how important that w
On Thu, Apr 28, 2016 at 03:55:44PM +0100, Dave Gordon wrote:
> On 28/04/16 09:56, Chris Wilson wrote:
> >The hardware tracks contexts and expects all live contexts (those active
> >on the hardware) to have a unique identifier. This is used by the
> >hardware to assign pagefaults and the like to a p
On 04/28/2016 10:41 AM, Daniel Vetter wrote:
On Thu, Apr 28, 2016 at 10:07:41AM -0400, Robert Foss wrote:
On 04/28/2016 04:02 AM, Daniel Vetter wrote:
On Tue, Apr 26, 2016 at 01:08:35PM -0400, Robert Foss wrote:
On 04/26/2016 01:00 PM, Ville Syrjälä wrote:
On Tue, Apr 26, 2016 at 12:55:
On 28/04/16 14:47, Chris Wilson wrote:
Move all of the constant assignments up front and into a common
function. This is primarily to ensure the backpointers are set as early
as possible for later use during initialisation.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
I'm not too happy
For legacy ringbuffer mode, we need the new ordered breadcrumb emission
tried and tested on execlists.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i9
We have sufficient evidence from igt to support that semaphores are in
a working state. Enabling semaphores now for legacy provides a better
comparison of execlists against legacy ring submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 4
1 file changed, 4 deletio
With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a semaphore. Note that these values can be merged with engine->guc_id.
Fixes: de1add360522c876c25ef2ab1c94bdb509ab
Signed-off-by: Chris Wilson
C
At the start of request emission, we flush some space for the request,
estimating the typical size for the request body. The tail is now much
larger than the typical body, so we can shrink the flush slightly.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +++--
With 5 rings and a flush, we need 192 bytes of space to emit the
breadcrumb and semaphores. However, we need some spare room the size of
the single largest packet (36 dwords, 144 bytes) to accommodate
wraparound giving a grand total of 336 bytes
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i9
The i915.enable_ppgtt option depends upon the state of
i915.enable_execlists option - so we need to sanitize execlists first.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c | 13 +
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c |
At the start of request emission, we flush some space for the request,
estimating the typical size for the request body. The common tail is now
much larger than the typical body, so we can shrink the flush
substantially.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 7 +-
---
drivers/gpu/drm/i915/intel_lrc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4735460be1a0..8d9849b9b6ed 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -260,10 +260,6 @@
When the engine idles waiting upon a semaphore, it loses its
pagetables and we must reload them before executing the batch.
v2: Restrict w/a to non-RCS rings (RCS works correctly apparently).
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/int
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the
pipecontrol writing the signal value is complete, we have to pause the
CS inside the PIPE_CONTROL with the CS_STALL bit.
Signed-off-by: Chris Wilson
Reviewed-by: Ville Syrjälä
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_
intel_pin_and_map_ringbuffer_obj() should have been setting the dirty
flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also
updated to use the new function.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c| 10 +-
drivers/gpu/drm/i915/intel_ringbu
This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely.
Existing code that sets obj->dirty is then changed to use the function
instead.
Inspired-by: http://www.spinics.net/lists/intel-gfx/msg92390.html
Cc: Chris Wilson
Sig
On Thu, Apr 28, 2016 at 05:26:20PM +0100, Dave Gordon wrote:
> This just hides the existing obj->dirty flag inside a trivial inline
> setter, to discourage non-GEM code from looking too closely.
>
> Existing code that sets obj->dirty is then changed to use the function
> instead.
I prefer set_dir
On Thu, Apr 28, 2016 at 05:26:21PM +0100, Dave Gordon wrote:
> intel_pin_and_map_ringbuffer_obj() should have been setting the dirty
> flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also
> updated to use the new function.
Technically it doesn't need to. Whilst there is any vali
== Series Details ==
Series: series starting with [01/10] drm/i915: Apply strongly ordered RCS
breadcrumb to gen8/legacy
URL : https://patchwork.freedesktop.org/series/6490/
State : failure
== Summary ==
Series 6490v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series
On Thu, Apr 28, 2016 at 05:12:28PM +0100, Dave Gordon wrote:
> On 28/04/16 14:47, Chris Wilson wrote:
> >-/* Intentionally left blank. */
> >-engine->buffer = NULL;
> >
> > engine->dev = dev;
>
> Eeep! Isn't this the "engine initialised and ready for use" flag?
The same that we set to
On to, 2016-04-28 at 16:48 +0200, Daniel Vetter wrote:
> On Thu, Apr 28, 2016 at 11:38:55AM +0300, Imre Deak wrote:
> > On to, 2016-04-28 at 10:17 +0200, Daniel Vetter wrote:
> > > On Tue, Apr 26, 2016 at 07:01:06PM +0300, Imre Deak wrote:
> > > > On ti, 2016-04-26 at 15:42 +0100, Chris Wilson wrot
On 28/04/16 17:36, Chris Wilson wrote:
On Thu, Apr 28, 2016 at 05:26:21PM +0100, Dave Gordon wrote:
intel_pin_and_map_ringbuffer_obj() should have been setting the dirty
flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also
updated to use the new function.
Technically it does
On Thu, Apr 28, 2016 at 04:44:00PM +0200, Daniel Vetter wrote:
> On Thu, Apr 28, 2016 at 01:48:27PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 28, 2016 at 10:13:37AM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 26, 2016 at 08:57:51PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Apr 26, 2016 at 04:
On Thu, Apr 28, 2016 at 04:48:37PM +0200, Daniel Vetter wrote:
> On Thu, Apr 28, 2016 at 11:38:55AM +0300, Imre Deak wrote:
> > On to, 2016-04-28 at 10:17 +0200, Daniel Vetter wrote:
> > > On Tue, Apr 26, 2016 at 07:01:06PM +0300, Imre Deak wrote:
> > > > On ti, 2016-04-26 at 15:42 +0100, Chris Wil
On Thu, Apr 28, 2016 at 06:20:30PM +0100, Dave Gordon wrote:
> On 28/04/16 17:36, Chris Wilson wrote:
> >On Thu, Apr 28, 2016 at 05:26:21PM +0100, Dave Gordon wrote:
> >>intel_pin_and_map_ringbuffer_obj() should have been setting the dirty
> >>flag, but wasn't; and the LRC code in intel_lr_context_
On 28/04/16 17:34, Chris Wilson wrote:
On Thu, Apr 28, 2016 at 05:26:20PM +0100, Dave Gordon wrote:
This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely.
Existing code that sets obj->dirty is then changed to use the fun
Move all of the constant assignments up front and into a common
function. This is primarily to ensure the backpointers are set as early
as possible for later use during initialisation.
v2: Use a constant struct so that all the similar values are set
together.
Signed-off-by: Chris Wilson
Cc: Tvrt
== Series Details ==
Series: series starting with [1/2] drm/i915: introduce & use
i915_gem_object_mark_dirty()
URL : https://patchwork.freedesktop.org/series/6491/
State : warning
== Summary ==
Series 6491v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/6491/revi
On 28/04/16 16:32, Chris Wilson wrote:
On Thu, Apr 28, 2016 at 03:55:44PM +0100, Dave Gordon wrote:
On 28/04/16 09:56, Chris Wilson wrote:
The hardware tracks contexts and expects all live contexts (those active
on the hardware) to have a unique identifier. This is used by the
hardware to assig
On Mon, Apr 25, 2016 at 05:08:18PM +0100, Emil Velikov wrote:
> On 21 April 2016 at 11:24, Eric Engestrom wrote:
> > Commit 3d0fac7aca237bbe8ed8e2a362d3b42d0ef8c46c changed all the
> > VK_PROTOTYPES to VK_NO_PROTOTYPES
> > This brings the Intel header in line with the rest of the Vulkan code.
> >
On 28/04/16 09:56, Chris Wilson wrote:
As the contexts are accessed by the hardware until the switch is completed
to a new context, the hardware may still be writing to the context object
after the breadcrumb is visible. We must not unpin/unbind/prune that
object whilst still active and so we kee
On Thu, Apr 28, 2016 at 07:15:23PM +0100, Dave Gordon wrote:
> On 28/04/16 09:56, Chris Wilson wrote:
> >As the contexts are accessed by the hardware until the switch is completed
> >to a new context, the hardware may still be writing to the context object
> >after the breadcrumb is visible. We mus
On Thu, Apr 28, 2016 at 07:08:18PM +0100, Dave Gordon wrote:
> On 28/04/16 16:32, Chris Wilson wrote:
> >On Thu, Apr 28, 2016 at 03:55:44PM +0100, Dave Gordon wrote:
> >>On 28/04/16 09:56, Chris Wilson wrote:
> >>>The hardware tracks contexts and expects all live contexts (those active
> >>>on the
On 28/04/16 18:48, Patchwork wrote:
== Series Details ==
Series: series starting with [1/2] drm/i915: introduce & use
i915_gem_object_mark_dirty()
URL : https://patchwork.freedesktop.org/series/6491/
State : warning
== Summary ==
Series 6491v1 Series without cover letter
http://patchwork.fr
On Wed, Apr 27, 2016 at 04:56:42PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 27, 2016 at 04:30:14PM +0300, Mika Kahola wrote:
> > s/Programmng/Programming
>
> It's straight from the spec, hence the [sic]
Didn't get any further objections, so pushed the series to dinq, with the typoes
and [sic]s i
On 28/04/16 17:24, Chris Wilson wrote:
The i915.enable_ppgtt option depends upon the state of
i915.enable_execlists option - so we need to sanitize execlists first.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c | 13 +
drivers/gpu/drm/i915/i915_drv.h |
On Wed, Apr 27, 2016 at 06:10:44PM -0700, tom.orou...@intel.com wrote:
> From: Tom O'Rourke
>
> SLPC (Single Loop Power Controller) is a replacement for
> some host-based power management features. The SLPC
> implemenation runs in firmware on GuC.
>
> This series has been tested with SKL guc fi
+Juan
Hi Yu,
Do you have any update on your patches? We need a solution to fix the
SandyBridge hang asap, then Daniel and Jani can help to cherry-pick the tsc
patches to drm-intel repo.
BR,
Han Lu
> -Original Message-
> From: Lu, Han
> Sent: Wednesday, April 27, 2016 1:18 PM
> To: Vil
Please ignore my previous patch(it is incorrect), you can cherry pick Len's
8 patches except this one:
540cc882de7d1da2e71591e215f0e04cb89883fa
x86 tsc_msr: Extend to include Intel Core Architecture
thanks,
Yu
> -Original Message-
> From: Lu, Han
> Sent: Friday, April 29, 2016 9:38 AM
>
Does this mean that Len's patches will be merged into upstream except this one?
Regards,
Libin
> -Original Message-
> From: Chen, Yu C
> Sent: Friday, April 29, 2016 9:43 AM
> To: Lu, Han; 'Ville Syrjälä'; Brown, Len
> Cc: 'Daniel Vetter'; Nikula, Jani; Lin, Mengdong; Yang, Libin; Li, Jo
Hi,
> The Bugzilla at https://bugs.freedesktop.org is our tool of choice for
> tracking bugs in drm/i915. It's your choice to not create an account
> there, but please, don't expect us to work as a proxy between you and
> bugzilla either. It's a much bigger and unscalable inconvenience for us
> th
From: Akash Goel
Update made to the Gen9 forcewake range to cover the OA registers.
MMIO locations 0x2700-0x2FFF belong to the same power domain
as 0x2000-0x26FF.
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/intel_uncore.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --g
Reviewed-by: Sagar Arun Kamble
On 4/29/2016 9:54 AM, akash.g...@intel.com wrote:
From: Akash Goel
Update made to the Gen9 forcewake range to cover the OA registers.
MMIO locations 0x2700-0x2FFF belong to the same power domain
as 0x2000-0x26FF.
Signed-off-by: Akash Goel
---
drivers/gpu/drm
Hi Len, Daniel, Jani,
Keqiao has validated the 8 patches can fix the pulseaudio issues on APL.
As soon as the 9 patches have been in Ingo's repo, it may difficult to revert
540cc882de7d1da2e71591e215f0e04cb89883fa.
So can we follow the process below:
1. Daniel and Jani help to cherry-pick other 8
101 - 152 of 152 matches
Mail list logo
