On Fri, Aug 8, 2014 at 7:19 PM, Rodrigo Vivi wrote:
> From: Rodrigo Vivi
>
> 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.
>
> v2: Adding some comments and better c
On Sat, Aug 9, 2014 at 12:07 AM, Linus Torvalds
wrote:
> On Fri, Aug 8, 2014 at 1:52 PM, Linus Torvalds
> 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 series. If
you still see this on your tip, please scr
On Sat, Aug 9, 2014 at 3:21 AM, Alan Stern 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 trying to
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 c
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
---
driv
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 pp
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
---
drivers/gpu/drm/i915/i915_drv.h| 7 --
drivers/gpu/drm/i915/i915_gem.c| 17 ---
dr
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 achie
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
---
drivers/gpu/drm/i915/i915_dma.c | 5 +++--
drivers/gpu/drm/i915/i915_drv.h | 50 +
2 files changed, 29
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 decid
See the following for many more details.
commit acc240d41ea1ab9c488a79219fb313b5b46265ae
Author: Daniel Vetter
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
ppgtt_release
i9
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
---
drivers/gpu/drm/i915/i915_gem_exec
Found with sparse.
Signed-off-by: Damien Lespiau
---
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
--- a/drivers/gpu/drm/i915/inte
Running smatch adds quite a few checks to what sparse is doing. This is
one of them.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4b8944
Signed-off-by: Damien Lespiau
---
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
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -37
On Saturday, August 09, 2014 10:53:03 AM Daniel Vetter wrote:
> On Sat, Aug 9, 2014 at 3:21 AM, Alan Stern 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 partic
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 Wilso
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
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 36 +-
1 file changed, 15 insertions(+), 21 deletions(-)
diff --
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 Wi
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
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 23 ++-
1 file changed, 10 insertions(+), 13
On Sat, Aug 09, 2014 at 12:29:17PM -0700, Ben Widawsky wrote:
> 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 wh
21 matches
Mail list logo
