On Tue, Oct 06, 2015 at 10:43:48AM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 10:38:22AM +0200, Daniel Vetter wrote:
> > On Mon, Oct 05, 2015 at 05:59:50PM +0100, Michel Thierry wrote:
> > > On 10/5/2015 5:36 PM, Dave Gordon wrote:
> > > >On 02/10/15 14:16, Michel Thierry wrote:
> > > >>W
On Tue, Jun 16, 2015 at 04:07:40PM +0300, Jani Nikula wrote:
> On Tue, 16 Jun 2015, Jani Nikula wrote:
> > On Wed, 03 Jun 2015, Mika Kahola wrote:
> >> From: Ville Syrjälä
> >>
> >> Add support for changing cdclk frequency during runtime on BDW. The
> >> procedure is quite a bit different on BDW
Another regression for Jairo to track. Also this one is bisected too
(although not 100% confirmed).
-Daniel
On Fri, Oct 2, 2015 at 8:43 PM, Zanoni, Paulo R
wrote:
> Em Qui, 2015-10-01 às 16:03 -0700, Matt Roper escreveu:
>> Cc: Paulo Zanoni
>> Signed-off-by: Matt Roper
>> ---
>> Paulo, I'm not
On Tue, Oct 06, 2015 at 12:09:51PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 10:43:48AM +0100, Chris Wilson wrote:
> > On Tue, Oct 06, 2015 at 10:38:22AM +0200, Daniel Vetter wrote:
> > > On Mon, Oct 05, 2015 at 05:59:50PM +0100, Michel Thierry wrote:
> > > > On 10/5/2015 5:36 PM, Dave
Passing cliprects into the kernel for it to re-execute the batch buffer
with different CMD_DRAWRECT died out long ago. As DRI1 support has been
removed from the kernel, we can now simply reject any execbuf trying to
use this "feature".
To keep Daniel happy with the prospect of being able to reuse
Since the remove of the pin-ioctl, we only care about not changing the
cache level on buffers pinned to the hardware as indicated by
obj->pin_display. So we can safely replace i915_gem_object_is_pinned()
here with a plain obj->pin_display check. During rebinding, we will check
sanity checks in case
It makes it slightly easier to read.
v2: Add missing word in patch title. (Ander)
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_dp_link_training.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_link_tr
On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
> On 10/05/2015 09:05 PM, Imre Deak wrote:
> > On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
> >> Mostly reuse what is programmed by pre-os, but in case there is no
> >> pre-os initialization, init the cdclk with the default value.
>
In addition to the last-in/first-out stack for accessing drm_mm nodes,
we occasionally and in the future often want to find a drm_mm_node by an
address. To do so efficiently we need to track the nodes in an interval
tree - lookups for a particular address will then be O(lg(N)), where N
is the numbe
Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make
With full-ppgtt, we want the user to have full control over their memory
layout, with a separate instance per context. Forcing them to use a
shared memory layout for !RCS not only duplicates the amount of work we
have to do, but also defeats the memory segregation on offer.
Signed-off-by: Chris Wi
On 10/06/2015 04:11 PM, Imre Deak wrote:
On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
On 10/05/2015 09:05 PM, Imre Deak wrote:
On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
Mostly reuse what is programmed by pre-os, but in case there is no
pre-os initialization, init the cd
On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> In addition to the last-in/first-out stack for accessing drm_mm nodes,
> we occasionally and in the future often want to find a drm_mm_node by an
> address. To do so efficiently we need to track the nodes in an interval
> tree - lookup
On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, Shobhit wrote:
> On 10/06/2015 04:11 PM, Imre Deak wrote:
> >On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
> >>On 10/05/2015 09:05 PM, Imre Deak wrote:
> >>>On ma, 2015-10-05 at 20:52 +0530, Shobhit Kumar wrote:
> Mostly reuse what is p
On Tue, Oct 06, 2015 at 11:39:55AM +0100, Chris Wilson wrote:
> Passing cliprects into the kernel for it to re-execute the batch buffer
> with different CMD_DRAWRECT died out long ago. As DRI1 support has been
> removed from the kernel, we can now simply reject any execbuf trying to
> use this "fea
On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> > In addition to the last-in/first-out stack for accessing drm_mm nodes,
> > we occasionally and in the future often want to find a drm_mm_node by an
> > address. To do s
On 06/10/15 09:38, Daniel Vetter wrote:
On Mon, Oct 05, 2015 at 05:59:50PM +0100, Michel Thierry wrote:
On 10/5/2015 5:36 PM, Dave Gordon wrote:
On 02/10/15 14:16, Michel Thierry wrote:
We tried to fix this in commit fdc454c1484a ("drm/i915: Prevent out of
range pt in gen6_for_each_pde").
But
On Tue, Oct 06, 2015 at 11:39:56AM +0100, Chris Wilson wrote:
> Since the remove of the pin-ioctl, we only care about not changing the
> cache level on buffers pinned to the hardware as indicated by
> obj->pin_display. So we can safely replace i915_gem_object_is_pinned()
> here with a plain obj->pi
Revision checks are almost always accompanied by a platform check. (The
exceptions are platform specific code.) Add helpers to check for a
platform and a revision range: IS_SKL_REVID() and IS_BXT_REVID(). In
most places this simplifies and clarifies the code. It will be obvious
that revid macros ar
Prefer inclusive ranges for revision checks rather than "below B0". Per
specs A2 is not used, so revid <= A1 matches revid < B0.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/i915_guc_submi
Totally unnecessary.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 51eea2951c0f..a3b137715604 100644
--- a/drivers/g
On Tue, Oct 06, 2015 at 01:28:07PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 11:39:56AM +0100, Chris Wilson wrote:
> > Since the remove of the pin-ioctl, we only care about not changing the
> > cache level on buffers pinned to the hardware as indicated by
> > obj->pin_display. So we can
On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, Shobhit wrote:
> > On 10/06/2015 04:11 PM, Imre Deak wrote:
> > >On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit wrote:
> > >>On 10/05/2015 09:05 PM, Imre Deak wrote:
> > >>>On ma, 201
On Tue, Oct 06, 2015 at 12:21:05PM +0100, Dave Gordon wrote:
> ... although I still think my version is (slightly) easier to read.
> Or it could be improved even more by moving the increment of 'iter'
> to the end, making it one line shorter and perhaps helping the
> compiler a little :)
>
> #defi
On Tue, Oct 06, 2015 at 12:19:43PM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> > > In addition to the last-in/first-out stack for accessing drm_mm nodes,
> > > we occasionally and in
As paranoia, we want to ensure that the CPU's PTEs have been revoked for
the object before we return from i915_gem_release_mmap(). This allows us
to rely on there being no outstanding memory accesses and guarantees
serialisation of the code against concurrent access just by calling
i915_gem_release
On Thu, Oct 01, 2015 at 12:34:47PM +0100, Chris Wilson wrote:
> Whilst discussing possible ways to trigger an invalidate_range on a
> userptr with an aliased GGTT mmapping (and so cause a struct_mutex
> deadlock), the conclusion is that we can, and we must, prevent any
> possible deadlock by avoidi
Since
commit 43566dedde54f9729113f5f9fde77d53e75e61e9
Author: Chris Wilson
Date: Fri Jan 2 16:29:29 2015 +0530
drm/i915: Broaden application of set-domain(GTT)
we allowed objects to be in the GTT domain, but unbound. Therefore
removing the GTT cache domain when removing the GGTT vma is no
On Thu, Oct 01, 2015 at 12:36:05PM +0100, Chris Wilson wrote:
> Once userptr becomes part of client API, it is almost a certainty that
> eventually someone will try to create a new object from a mapping of
> another client object, e.g.
>
> new = vaImport(vaMap(old, &size), size);
>
> (using a hyp
On Tue, Oct 06, 2015 at 10:48:28AM +0100, Tvrtko Ursulin wrote:
>
>
> On 06/10/15 10:34, Chris Wilson wrote:
> >On Tue, Oct 06, 2015 at 11:28:49AM +0200, Daniel Vetter wrote:
> >>On Tue, Oct 06, 2015 at 10:04:31AM +0100, Chris Wilson wrote:
> >>>On Tue, Oct 06, 2015 at 10:58:01AM +0200, Daniel Ve
On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, Shobhit wrote:
> > > On 10/06/2015 04:11 PM, Imre Deak wrote:
> > > >On ti, 2015-10-06 at 15:26 +0530, Kumar, Shobhit
On Tue, Oct 06, 2015 at 02:12:31PM +0200, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 12:36:05PM +0100, Chris Wilson wrote:
> > Once userptr becomes part of client API, it is almost a certainty that
> > eventually someone will try to create a new object from a mapping of
> > another client objec
On Tue, Oct 06, 2015 at 02:04:19PM +0200, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 12:34:47PM +0100, Chris Wilson wrote:
> > Whilst discussing possible ways to trigger an invalidate_range on a
> > userptr with an aliased GGTT mmapping (and so cause a struct_mutex
> > deadlock), the conclusion
On Tue, Oct 06, 2015 at 02:41:15PM +0300, Jani Nikula wrote:
> Prefer inclusive ranges for revision checks rather than "below B0". Per
> specs A2 is not used, so revid <= A1 matches revid < B0.
The w/a db would say UNTIL_B0 etc., so might be easier to check against
it if we keep to the same conven
On Tue, Oct 06, 2015 at 01:02:22PM +0100, Chris Wilson wrote:
> Since
>
> commit 43566dedde54f9729113f5f9fde77d53e75e61e9
> Author: Chris Wilson
> Date: Fri Jan 2 16:29:29 2015 +0530
>
> drm/i915: Broaden application of set-domain(GTT)
>
> we allowed objects to be in the GTT domain, but u
On Thu, Oct 01, 2015 at 12:57:10PM +0100, Chris Wilson wrote:
> With a little complexity to handle cmds straddling page boundaries, we
> can completely avoiding having to vmap the batch and the shadow batch
> objects whilst running the command parser.
>
> On ivb i7-3720MQ:
>
> x11perf -dot before
On 10/06/2015 05:49 PM, Daniel Vetter wrote:
On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:
On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:
On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, Shobhit wrote:
On 10/06/2015 04:11 PM, Imre Deak wrote:
On ti, 2015-10-06
On Tue, Oct 06, 2015 at 01:21:25PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 11:39:55AM +0100, Chris Wilson wrote:
> > Passing cliprects into the kernel for it to re-execute the batch buffer
> > with different CMD_DRAWRECT died out long ago. As DRI1 support has been
> > removed from the
On Tue, Oct 06, 2015 at 02:40:26PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 01:02:22PM +0100, Chris Wilson wrote:
> > Since
> >
> > commit 43566dedde54f9729113f5f9fde77d53e75e61e9
> > Author: Chris Wilson
> > Date: Fri Jan 2 16:29:29 2015 +0530
> >
> > drm/i915: Broaden applic
On Thu, Oct 01, 2015 at 12:18:25PM +0100, Chris Wilson wrote:
> As the shrinker_control now passes us unsigned long targets, update our
> shrinker functions to match.
>
> Signed-off-by: Chris Wilson
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h
I've botched this, so let's fix it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index f6ecbda2c604..674341708033
On Thu, Oct 01, 2015 at 12:18:26PM +0100, Chris Wilson wrote:
> Often it is very useful to know why we suddenly purge vast tracts of
> memory and surprisingly up until now we didn't even have a tracepoint
> for when we shrink our memory.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i9
On Thu, Oct 01, 2015 at 12:18:27PM +0100, Chris Wilson wrote:
> We can forgo an evict-everything here as the shrinker operation itself
> will unbind any vma as required. If we explicitly idle the GPU through a
> switch to the default context, we not only create a request in an
> illegal context (e.
On Thu, Oct 01, 2015 at 12:18:29PM +0100, Chris Wilson wrote:
> Exclude active GPU pages from the purview of the background shrinker
> (kswapd), as these cause uncontrollable GPU stalls. Given that the
> shrinker is rerun until the freelists are satisfied, we should have
> opportunity in subsequent
On Tue, Oct 06, 2015 at 02:44:22PM +0200, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 12:57:10PM +0100, Chris Wilson wrote:
> > With a little complexity to handle cmds straddling page boundaries, we
> > can completely avoiding having to vmap the batch and the shadow batch
> > objects whilst runn
On Tue, Oct 06, 2015 at 06:13:52PM +0530, Kumar, Shobhit wrote:
> On 10/06/2015 05:49 PM, Daniel Vetter wrote:
> >On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:
> >>On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:
> >>>On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar, S
On Tue, Oct 06, 2015 at 01:46:25PM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 02:40:26PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 06, 2015 at 01:02:22PM +0100, Chris Wilson wrote:
> > > Since
> > >
> > > commit 43566dedde54f9729113f5f9fde77d53e75e61e9
> > > Author: Chris Wilson
> > >
On Tue, Oct 06, 2015 at 03:00:49PM +0200, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 12:18:27PM +0100, Chris Wilson wrote:
> > We can forgo an evict-everything here as the shrinker operation itself
> > will unbind any vma as required. If we explicitly idle the GPU through a
> > switch to the de
On Tue, Oct 06, 2015 at 02:54:25PM +0200, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 12:18:26PM +0100, Chris Wilson wrote:
> > Often it is very useful to know why we suddenly purge vast tracts of
> > memory and surprisingly up until now we didn't even have a tracepoint
> > for when we shrink ou
On Tue, Oct 06, 2015 at 03:01:45PM +0200, Daniel Vetter wrote:
> On Thu, Oct 01, 2015 at 12:18:29PM +0100, Chris Wilson wrote:
> > Exclude active GPU pages from the purview of the background shrinker
> > (kswapd), as these cause uncontrollable GPU stalls. Given that the
> > shrinker is rerun until
From: Tvrtko Ursulin
Do some page flipping on the rotated plane just to excercise
that code path.
Signed-off-by: Tvrtko Ursulin
Cc: Sonika Jindal
Cc: Arun R Murthy
---
There are some, still unofficial, reports that page flipping with
90 degree rotation may be causing a vma->pin_count leak.
B
On Tue, Oct 06, 2015 at 06:13:52PM +0530, Kumar, Shobhit wrote:
> On 10/06/2015 05:49 PM, Daniel Vetter wrote:
> > On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:
> >> On Tue, Oct 06, 2015 at 01:19:52PM +0200, Daniel Vetter wrote:
> >>> On Tue, Oct 06, 2015 at 04:33:43PM +0530, Kumar
On Tue, Oct 06, 2015 at 03:04:28PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 06:13:52PM +0530, Kumar, Shobhit wrote:
> > On 10/06/2015 05:49 PM, Daniel Vetter wrote:
> > >On Tue, Oct 06, 2015 at 02:41:44PM +0300, Ville Syrjälä wrote:
> > >>On Tue, Oct 06, 2015 at 01:19:52PM +0200, Danie
On 10/04/15 10:07, Sonika Jindal wrote:
Signed-off-by: Sonika Jindal
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
ind
On Tue, 06 Oct 2015, Daniel Vetter wrote:
> I've botched this, so let's fix it.
Ahah, where's the reference to regressing commit, huh?! HUH?! ;)
Botched in
commit eb0b44adc08c0be01a027eb009e9cdadc31e65a2
Author: Daniel Vetter
Date: Wed Mar 18 14:47:59 2015 +0100
drm/i915: kerneldoc for
On Tue, 06 Oct 2015, Ville Syrjälä wrote:
> On Tue, Oct 06, 2015 at 02:41:15PM +0300, Jani Nikula wrote:
>> Prefer inclusive ranges for revision checks rather than "below B0". Per
>> specs A2 is not used, so revid <= A1 matches revid < B0.
>
> The w/a db would say UNTIL_B0 etc., so might be easier
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Chris Wilson
> Sent: Tuesday, October 6, 2015 11:53 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Allow the user to pass a context to
> any ring
>
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, October 6, 2015 11:53 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson; Daniel, Thomas
> Subject: [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer
>
> Userspace can pass in an o
On 06/10/15 11:39, Chris Wilson wrote:
Passing cliprects into the kernel for it to re-execute the batch buffer
with different CMD_DRAWRECT died out long ago. As DRI1 support has been
removed from the kernel, we can now simply reject any execbuf trying to
use this "feature".
To keep Daniel happy
The plan is to allow workaround list usage outside of
intel_ringbuffer.c, mainly in intel_pm.c where we setup assortment
of workaround registers as part of intel_init_clock_gating().
Move macros to i915_drv.h and export intel_wa_add().
Remove WA_WRITE macro as there are no users of it as of now.
For workarounds written in haswells's init clock gating path,
use mmio workaround list.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 35 +++
1 file changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/dri
Some registers are, naturally, lost in gpu reset/suspend cycle.
And some registers, for example in display domain and are not subject
to gpu reset so they retain their contents.
As hang recovery triggers a reset, recoverable gpu hang can currently
flush out essential workarounds and cause havoc la
We always write the ROW_CHICKEN2. Make this more clear
by writing it unconditionally.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_pm.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm
In preparation to have separate workaround lists
for both LRI and MMIO written workarounds, parametrize the
register addition and printing of wa lists.
Cc: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 39 +
drivers/gpu/
Use workarounds written in ivybridge's init clock gating path,
use mmio workaround list to ensure proper setup after
reset/resume.
This way we don't lose _3DCHICKEN and GEN7_FF_THREAD_MODE register
contents on reset/suspend.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 2
From: Mika Kuoppala
Rewrite everything in mmio workaround list right after
gpu reset. This ensures that we start the reinitialization
with proper mmio workarounds in place, before we
start the rings.
This commit just adds the mechanism, the list itself
is still empty. Following commits will add
For workarounds written in broadwell's init clock gating path,
use mmio workaround list.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 59 -
2 files changed, 38 insertions(+), 24 deletions(-)
It is considered a very bad practice to return inside
a macro. Instead of returning, emit a warning.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/g
As we move towards of adding mmio register setup to
use workaround list, raise the maximum amount of available
registers in list.
Signed-off-by: Mika Kuoppala
---
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
Hi,
This series was inspired by founding out:
https://bugs.freedesktop.org/show_bug.cgi?id=92315
and that we still lose some of the workarounds after
reset/suspend cycle. We did build a list for LRI emitted
workarounds in past to combat this same issue and checked that
contexts retain wa registers
On 06/10/15 11:39, Chris Wilson wrote:
Passing cliprects into the kernel for it to re-execute the batch buffer
with different CMD_DRAWRECT died out long ago. As DRI1 support has been
removed from the kernel, we can now simply reject any execbuf trying to
use this "feature".
To keep Daniel happy
On Tue, Oct 06, 2015 at 02:32:47PM +0100, Tvrtko Ursulin wrote:
>
> On 10/04/15 10:07, Sonika Jindal wrote:
> >Signed-off-by: Sonika Jindal
> >Reviewed-by: Matt Roper
> >---
> > drivers/gpu/drm/i915/intel_display.c |7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> >diff -
On Thu, 01 Oct 2015, Matt Roper wrote:
> When watermark calculation was moved up to the atomic check phase, the
> code was updated to calculate based on in-flight atomic state rather
> than already-committed state. However the hsw_compute_linetime_wm()
> didn't get updated and continued to pull v
Hi,
On 06/10/15 12:58, Chris Wilson wrote:
As paranoia, we want to ensure that the CPU's PTEs have been revoked for
the object before we return from i915_gem_release_mmap(). This allows us
to rely on there being no outstanding memory accesses and guarantees
serialisation of the code against con
On Tue, Oct 06, 2015 at 07:29:54AM -0700, Matt Roper wrote:
> On Tue, Oct 06, 2015 at 02:32:47PM +0100, Tvrtko Ursulin wrote:
> >
> > On 10/04/15 10:07, Sonika Jindal wrote:
> > >Signed-off-by: Sonika Jindal
> > >Reviewed-by: Matt Roper
> > >---
> > > drivers/gpu/drm/i915/intel_display.c |7
Introduce another workaround list for mmio write type of
workarounds. No users yet.
Cc: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 +-
drivers/gpu/drm/i915/i915_drv.h | 14 ++
2 files changed, 19 insertions(+), 9 deletions
In order to prepare for different types of workaround lists,
parametrize the list we are adding the workaround register.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 20 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 65 +
2 fil
These changes are a result of the requests made in VIZ-4277.
Make the lrc path more like the legacy submission path.
Attach the CPU mappings to vma (un)bind, so that the shrinker
also cleans those up.
Pin the CPU mappings while context is busy (pending bbs), so
that the mappings aren't released/mad
Shovel all context related objects through the active queue and obj
management.
- Added callback in vma_(un)bind to add CPU (un)mapping at same time
if desired
- Inserted LRC hw context & ringbuf to vma active list
Issue: VIZ-4277
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_drv.h
Pin the hw ctx mapping so that it is not mapped/unmapped per bb
when doing GuC submission.
Issue: VIZ-4277
Cc: David Gordon
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 --
drivers/gpu/drm/i915/i915_drv.h | 4 ++-
drivers/gpu/drm/i915/intel_lrc.c| 56 +
We now only need to update the address of the ringbuf object in the
hw context when it is pinned, and the hw context is first CPU mapped
Issue: VIZ-4277
Cc: David Gordon
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_lrc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
There is a desire to simplify the i915 driver by reducing the number of
different code paths introduced by the LRC / execlists support. As the
execlists request is now part of the gem request it is possible and
desirable to unify the request life-cycles for execlist and legacy
requests.
Added a c
On Tue, Oct 06, 2015 at 05:42:42PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 06, 2015 at 07:29:54AM -0700, Matt Roper wrote:
> > On Tue, Oct 06, 2015 at 02:32:47PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 10/04/15 10:07, Sonika Jindal wrote:
> > > >Signed-off-by: Sonika Jindal
> > > >Reviewed-
On Tue, Oct 06, 2015 at 03:29:20PM +0100, Dave Gordon wrote:
> On 06/10/15 11:39, Chris Wilson wrote:
> >Passing cliprects into the kernel for it to re-execute the batch buffer
> >with different CMD_DRAWRECT died out long ago. As DRI1 support has been
> >removed from the kernel, we can now simply r
On Tue, Oct 06, 2015 at 03:19:36PM +0100, Tvrtko Ursulin wrote:
>
> On 06/10/15 11:39, Chris Wilson wrote:
> >Passing cliprects into the kernel for it to re-execute the batch buffer
> >with different CMD_DRAWRECT died out long ago. As DRI1 support has been
> >removed from the kernel, we can now si
intel_mode_from_pipe_config() fills in a mode structure from the CRTC
state that was read out of the hardware, but does not set the
.crtc_clock field (it only sets the .clock). This causes the subsequent
call to drm_calc_timestamping_constants() to complain with messages like
"*ERROR* crtc 21: Can
On Tue, Oct 06, 2015 at 08:16:19AM -0700, Matt Roper wrote:
> On Tue, Oct 06, 2015 at 05:42:42PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 06, 2015 at 07:29:54AM -0700, Matt Roper wrote:
> > > On Tue, Oct 06, 2015 at 02:32:47PM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 10/04/15 10:07, Soni
On Tue, Oct 06, 2015 at 09:26:31AM -0700, Matt Roper wrote:
> intel_mode_from_pipe_config() fills in a mode structure from the CRTC
> state that was read out of the hardware, but does not set the
> .crtc_clock field (it only sets the .clock). This causes the subsequent
> call to drm_calc_timestamp
On Tue, 2015-10-06 at 12:09 +0300, Jani Nikula wrote:
> On Tue, 06 Oct 2015, Rodrigo Vivi wrote:
> > From: Deepak S
> >
> > v2: separate out device info into different GT (Damien)
> > v3: Add is_kabylake to the KBL gt3 structuer (Damien)
> > Sort the platforms in older -> newer order (Damien
On Tue, 2015-10-06 at 12:24 +0300, Jani Nikula wrote:
> On Tue, 06 Oct 2015, Rodrigo Vivi wrote:
> > Kabylake is gen 9.5 derivated from Skylake H0 stepping.
> >
> > So we don't need pre-production Skylake workaround and also
> > firmware loading will use SKL H0 offsets.
> >
> > Signed-off-by: Ro
On Tue, 2015-10-06 at 16:43 +0300, Jani Nikula wrote:
> On Tue, 06 Oct 2015, Ville Syrjälä
> wrote:
> > On Tue, Oct 06, 2015 at 02:41:15PM +0300, Jani Nikula wrote:
> > > Prefer inclusive ranges for revision checks rather than "below
> > > B0". Per
> > > specs A2 is not used, so revid <= A1 matc
On pe, 2015-09-18 at 23:39 +0530, Sagar Arun Kamble wrote:
> From: Akash Goel
>
> Signed-off-by: Ankitprasad Sharma
> Signed-off-by: Akash Goel
> Signed-off-by: Sagar Arun Kamble
The comment about units in gen6_set_rps_thresholds() is outdated, so you
could update that while at it. In any cas
On Tue, Oct 06, 2015 at 04:43:11PM +0300, Jani Nikula wrote:
> On Tue, 06 Oct 2015, Ville Syrjälä wrote:
> > On Tue, Oct 06, 2015 at 02:41:15PM +0300, Jani Nikula wrote:
> >> Prefer inclusive ranges for revision checks rather than "below B0". Per
> >> specs A2 is not used, so revid <= A1 matches r
On 30/09/15 07:28, Imre Deak wrote:
On ke, 2015-08-26 at 16:58 +0530, Animesh Manna wrote:
-void i915_firmware_load_error_print(const char *fw_path, int err)
-{
- DRM_ERROR("failed to load firmware %s (%d)\n", fw_path, err);
-
- /*
-* If the reason is not known assume -ENOEN
On Tue, Oct 06, 2015 at 12:09:17PM +0300, Jani Nikula wrote:
> On Tue, 06 Oct 2015, Rodrigo Vivi wrote:
> > From: Deepak S
> >
> > v2: separate out device info into different GT (Damien)
> > v3: Add is_kabylake to the KBL gt3 structuer (Damien)
> > Sort the platforms in older -> newer order (
cc'ing Ben to get his opinion...
On Tue, Oct 6, 2015 at 10:43 AM Vivi, Rodrigo
wrote:
> On Tue, 2015-10-06 at 12:24 +0300, Jani Nikula wrote:
> > On Tue, 06 Oct 2015, Rodrigo Vivi wrote:
> > > Kabylake is gen 9.5 derivated from Skylake H0 stepping.
> > >
> > > So we don't need pre-production Sk
On Tue, Oct 06, 2015 at 08:51:13PM +, Rodrigo Vivi wrote:
> cc'ing Ben to get his opinion...
>
Of course anything is possible wrt the delta of KBL features vs SKL. With the
knowledge we have, we can make a pretty educated guess that there will be no
changes, and with an equally high level of
The legacy pageflip ioctl calls drm_crtc_check_viewport() to determine
whether the framebuffer being flipped is big enough to fill the display
it is being flipped to. However some drivers support "windowing" of
their primary planes (i.e., a primary plane that does not cover the
entire CRTC dimensi
Gen9 adds some new capabilities not present on previous platforms
(primary plane windowing, 90/270 rotation, etc.). Add a new subtest to
check how these new features interact with the use of the universal
plane API.
For now we just check whether pageflips work as expected in a windowed
setting.
This new subtest will validate a Y-tiled object's tiling mode against
its associated fb modifier.
Cc: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
tests/kms_addfb_basic.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
index d4
1 - 100 of 132 matches
Mail list logo
