Showing who is the current master is useful for trying to decypher
errors when trying to acquire master (e.g. a race with X taking over
from plymouth). By including the process name as well as the pid
simplifies the task of grabbing enough information remotely at the point
of error.
On Fri, Aug 8, 2014 at 7:19 PM, Rodrigo Vivi rodrigo.v...@intel.com wrote:
From: Rodrigo Vivi rodrigo.v...@gmail.com
Some registers set during setup might not be persistent after suspend/resume.
This was causing bugs for some people that was unable to get PSR entry state
after resume cycle.
On Sat, Aug 9, 2014 at 12:07 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Aug 8, 2014 at 1:52 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Got this while bisecting. I'm not sure it's related
It's not.
Iirc it was an intermediate merge issue between two patch
On Sat, Aug 9, 2014 at 3:21 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 9 Aug 2014, Rafael J. Wysocki wrote:
Well it works currently. So where do you see the problem?
Sampling registers from an timer - in particular, we really do not want
to disable runtime pm whilst
I keep telling myself that those tables aren't great because their size
is the number of dwords we need to program and not the number of entries
(number of dwords = number of entries * 2).
And... I got it wrong when I refactored the code. Fortunately, it was
only wrong when the VBT table (or the
If an object is not bound into the global GTT, then it cannot be
accessed via the GTT. This restores the original code that was muddled
by ppGTT. In the process, we remove a WARN that had long outlived its
usefulness and was simply being coded around instead.
Signed-off-by: Chris Wilson
With ppgtt, it is no longer correct to mark an object as
map_and_fenceable if we simply unbind it from the global gtt. This has
consequences during execbuffer where we simply use
obj-map_and_fenceable in use_cpu_reloc() to decide which access method
to use for writing into the object. Now for a
This migrates the fence tracking onto the existing seqno
infrastructure so that the later conversion to tracking via requests is
simplified.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h| 7 --
drivers/gpu/drm/i915/i915_gem.c
Adapt the macro so that we can pass either the struct drm_device or the
struct drm_i915_private pointers and get the answer we want. Over time,
my plan is to convert all users over to using drm_i915_private and so
trimming down the pointer dance. Having spent a few hours chasing that
goal and
This is so that we can make the drm_i915_private-info always the
preferred source for chipset type and feature queries.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c | 5 +++--
drivers/gpu/drm/i915/i915_drv.h | 50
On Sat, Aug 09, 2014 at 05:37:23PM +0100, Chris Wilson wrote:
With ppgtt, it is no longer correct to mark an object as
map_and_fenceable if we simply unbind it from the global gtt. This has
consequences during execbuffer where we simply use
obj-map_and_fenceable in use_cpu_reloc() to decide
See the following for many more details.
commit acc240d41ea1ab9c488a79219fb313b5b46265ae
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Dec 5 15:42:34 2013 +0100
drm/i915: Fix use-after-free in do_switch
In this case, the issue is only for full PPGTT:
do_switch
context_unref
We have an implementation requirement that precludes the user from
requesting a ggtt entry when the device is operating in ppgtt mode. Move
the current check from inside the execbuffer object collation to the
prevalidation phase.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
Found with sparse.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a460bd3..4b89447 100644
---
Running smatch adds quite a few checks to what sparse is doing. This is
one of them.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 41de760..12f4e14 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++
On Saturday, August 09, 2014 10:53:03 AM Daniel Vetter wrote:
On Sat, Aug 9, 2014 at 3:21 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 9 Aug 2014, Rafael J. Wysocki wrote:
Well it works currently. So where do you see the problem?
Sampling registers from an timer - in
Part of the pre-validation for an execbuffer call is that there is at
least one object in the execlist. As we bail if we fail to lookup any
object, we can be sure that after the eb_lookup_vma() there is at least
one object in the vma list and so we do not need to assert.
Signed-off-by: Chris
This just allows the compiler to pessimise callers who try to abuse the
ioctl in the hope of making the correct users faster.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 36 +-
1 file changed, 15 insertions(+),
We have an implementation requirement that precludes the user from
requesting a ggtt entry when the device is operating in ppgtt mode. Move
the current check from inside the execbuffer object collation to the
prevalidation phase.
v2: Roll both invalid flags checks into one
Signed-off-by: Chris
Even though we should not try to use 4+GiB GTTs on 32-bit systems, by
using a local variable we can future proof the code whilst making it
easier to read.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 23 ++-
1 file
21 matches
Mail list logo
