On Mon, Jun 30, 2014 at 02:40:05PM -0700, Jesse Barnes wrote:
On Thu, 26 Jun 2014 18:23:55 +0100
john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
The i915_gem_record_rings() code was unconditionally querying and saving
state
for the batch_obj of a
For cleanliness, i915_error_object_create() was written to handle the
NULL pointer in a central location. The macro that wrapped it and passed
it a num_pages to use, was not safe. As we now never limit the num_pages
to use (we did so at one point to only capture the first page of the
context), we
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Rodrigo Vivi
Sent: Monday, June 30, 2014 5:51 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 1/3] drm/i915: Fix VCS2's ring name.
It just fix a
On Mon, 30 Jun 2014, Paul Bolle pebo...@tiscali.nl wrote:
Kernels v3.16-rc2 and v3.16-rc3 trigger a new (for me) warning. (I never
booted v3.16-rc1). Machine is a, rather outdated, ThinkPad X41 (ie,
single core i686).
WARNING: CPU: 0 PID: 221 at drivers/gpu/drm/i915/intel_display.c:1274
On 27 June 2014 15:15, tim.g...@intel.com wrote:
From: Tim Gore tim.g...@intel.com
Quite a few single tests do not use the igt_simple_main
macro because they want access to argc/argv. So change the
igt_simple_main macro to pass these arguments through to the
__real_mainxxx function, and
On Tue, 2014-07-01 at 09:18 +0530, Deepak S wrote:
On Friday 13 June 2014 05:24 PM, Imre Deak wrote:
This functionality will be also needed by an upcoming patch, so factor
it out. As a bonus this also makes things a bit more uniform across
platforms. Note that this also changes the register
Hi, I would like to inform that I use UEFI boot. I don't have a spare
machine/disk to test legacy unfortunately.
regards
Anton.
2014-06-27 7:20 GMT+04:00 Aaron Lu aaron...@intel.com:
On 06/25/2014 07:08 PM, Jani Nikula wrote:
On Tue, 24 Jun 2014, Aaron Lu aaron...@intel.com wrote:
Some
This functionality will be also needed by an upcoming patch, so factor
it out. As a bonus this also makes things a bit more uniform across
platforms. Note that this also changes the register read-modify-write
to a simple write during disabling. This is what we do during enabling
anyway and
Notifying the BIOS about CDCLK changes lets it program audio controller
EM4/EM5 divider values accordingly.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_opregion.c | 29 +
2 files
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_opregion.c | 10 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index
Hi Mengdong -
Here's the first drafts towards fixing [1], but unfortunately this is
still Broadwell specific. Currently patch 2 is not needed, but is
included in case we'll need that too (maybe for Haswell?). Please
review/test, I don't have access to either hsw or bdw right now.
BR,
Jani.
[1]
If the display power well has been disabled, the display audio
controller divider values EM4 MVALUE and EM5 NVALUE will have been
lost. Notify the BIOS about CDCLK change through opregion to make it
reprogram the values when the audio driver requests the power
well. Otherwise the audio playback
Hi Chris,
I had to rediff to get a patch that applies... I am not hanging with this
applied - it
does look like the i915 is starting is initialization later boot the new kernel.
[2.389796] [drm] Radeon Display Connectors
[2.389798] [drm] Connector 0:
[2.389799] [drm] DP-1
[
On Tue, 01 Jul 2014, Jani Nikula jani.nik...@intel.com wrote:
Notifying the BIOS about CDCLK changes lets it program audio controller
EM4/EM5 divider values accordingly.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
On Sat, 28 Jun 2014, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
It is possible that, by the time we run i915_drm_freeze(),
delayed_resume_work was already queued but did not run yet. If it
still didn't run after intel_runtime_pm_disable_interrupts(), by
This may do what's required on Haswell to achieve the same as the
previous patch does on Broadwell...
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74861
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 insertions(+)
diff
It seems the flexibility on rings is more wanted and needed than I imagined.
Please ignore this patch here...
I liked both execution flag or debugfs, but exec flag would cover this case of
different applications using different command streamers.
With flags Would it be something like:
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Monday, June 30, 2014 9:54 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915: Rename ctx-id to ctx-handle
On Thu, 26 Jun 2014 14:24:15 +0100
Jani, please ignore the 4th patch on this series and merge the 3 I've
reviewed and tested already.
They are essential to allow FBC work on BDW without changing bios
configuration and allow PC7 residency.
Thanks,
Rodrigo.
On Mon, Jun 30, 2014 at 10:41 AM, Rodrigo Vivi rodrigo.v...@intel.com
On Tue, 1 Jul 2014 15:46:51 +
Mateo Lozano, Oscar oscar.ma...@intel.com wrote:
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Monday, June 30, 2014 9:54 PM
To: Mateo Lozano, Oscar
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx]
From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com
The context used to execute a batchbuffer is becoming increasingly
important.
Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
Submitting again (this time copying the mailing list correctly):
The bo_pin ioctl has been discarded in GEN6+ with this patch:
drm/i915: Reject the pin ioctl on gen6+
Especially with ppgtt this kinda stopped making sense. And if we
indeed need this to hack around an issue, we
From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com
These tracepoints are useful for observing the creation and
destruction of Full PPGTTs.
Signed-off-by: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 6 +
From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com
These callbacks can be assigned to specific functions inside an external
validation kernel module. This module can then extract run-time
information to make sure everything is working as expected.
Specifically, these two callbacks
On Tue, Jul 01, 2014 at 04:24:56PM +, Mateo Lozano, Oscar wrote:
Submitting again (this time copying the mailing list correctly):
The bo_pin ioctl has been discarded in GEN6+ with this patch:
drm/i915: Reject the pin ioctl on gen6+
Especially with ppgtt this kinda stopped
It just fix a typo.
v2: removing underscore to let this like all other ring names (Oscar)
Cc: Oscar Mateo oscar.ma...@intel.com
Reviewed-by (v1): Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
1
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Tuesday, July 01, 2014 5:30 PM
To: Mateo Lozano, Oscar
Cc: Intel-gfx@lists.freedesktop.org; Madajczak, Tomasz
Subject: Re: [Intel-gfx] pin OABUFFER to GGTT
On Tue, Jul 01, 2014 at 04:24:56PM +, Mateo
Is there any reason why the WAs are applied in *_init_clock_gating? We are
finding that some of them are lost during reset, and also the default context
ends up with wrong values because the render context is restored saved before
we get to gen8_init_clok_gating (at least with Execlists, I´m
On Tue, Jul 01, 2014 at 04:34:48PM +, Mateo Lozano, Oscar wrote:
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Tuesday, July 01, 2014 5:30 PM
To: Mateo Lozano, Oscar
Cc: Intel-gfx@lists.freedesktop.org; Madajczak, Tomasz
Subject: Re:
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Tuesday, July 01, 2014 5:52 PM
To: Mateo Lozano, Oscar
Cc: Intel-gfx@lists.freedesktop.org; Madajczak, Tomasz; Rutkowski, Adam J;
Jesse Barnes (jbar...@virtuousgeek.org)
Subject: Re: [Intel-gfx] pin
-Original Message-
From: Mateo Lozano, Oscar
Sent: Tuesday, July 01, 2014 6:14 PM
To: 'Chris Wilson'
Cc: Intel-gfx@lists.freedesktop.org; Madajczak, Tomasz; Rutkowski, Adam J;
Jesse Barnes (jbar...@virtuousgeek.org)
Subject: RE: [Intel-gfx] pin OABUFFER to GGTT
-Original
Here be all the patches to make full PPGTT relatively stable on Broadwell. Most
of the work was actually to the generic PPGTT code, and not BDW specific. There
are basically 3 fixes:
1. Make the error state not horrible, but more work still needed.
2. Fix up another tricky from != from case in
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
The bound list is global (all objects which back the VMAs are stored
here). Recently the BUG() in the offset lookup was demoted to a WARN,
but the fault actually lies in the caller, here.
This bug has existed since the initial introduction of PPGTT (however,
it was fixed in unmerged patches to
This is just a cosmetic change to try to put do_switch_rcs on a diet. As
it stands, the function was quite complex, and error prone.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 32
1 file changed, 20 insertions(+),
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_evict.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index bbf4b12..38297d3 100644
---
As what was correctly debugged here:
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
It then becomes apparent that the default context cannot be the context
being
To follow up on the last patch, we can now capture the VMAs instead of
the BOs. The hope if we get more accurate error capture while debugging
PPGTT.
Note that this does not impact the previous argument about whether to
capture all VMAs, or just the guilty VMA. This merely allows the code to
do
The simple explanation is, the docs say to do this for GEN8. Perhaps we
want to do this for GEN7 too, I am not certain.
PDPs are saved and restored with context. Contexts (without execlists)
only exist on the render ring. The docs say that PDPs are not power
context save/restored. I've learned
There are no users of this yet, but the idea is presented and split out
to find bugs.
Also, while here, return -ERESTARTSYS to the caller, in case they want
to do something with it.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
The comment [which was mine] is wrong. The context object can never be
bound in a PPGTT because it is only capable of living in the Global GTT.
So, remove the comment, and reorder the unref. What's nice about the
latter is it keeps the context object alive past the PPGTT. This makes
the destroy
I was dealing with a bug recently where the system would hard hang
somewhere between hangcheck and reset. There was time after error
collection to actually get my error state out, but I couldn't get the
reads to work.
This patch is also useful for when reset kills the machine, and you want
to
Broadwell is perfectly capable of full PPGTT. I've been using it for
some time, and seen no especially ill effects.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1
Rename some variables, and clean up the code a bit to make things
clearer in our error capture.
There isn't an intentional functional change here.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gpu_error.c | 55 ---
1 file changed, 32
Some of the original PPGTT patches in this area where unmerged, and this
left a lot of confusion in our error capture with regard to which vm/obj
we want to capture. There have been at least a couple of patches from
Chris, and myself to try to fix this up; so here is another shot. Nobody
running
The last patch made PPGTT free cases correct. It left a major problem
though where in many cases it was possible to have to idle the GPU in
order to destroy a VM. This is really unfortunate as it is stalling the
active GPU process for the dying GPU process.
The workqueue grew very tricky. I left
If a VM still have objects which are bound (exactly: have a node
reserved in the drm_mm), and we are in the middle of a reset, we have no
hope of the standard methods fixing the situation (ring idle won't
work). We must therefore let the reset handler take it's course, and
then we can resume
The latest intel-gpu-tools has dependency on cairo. We don't use cairo.
Is there any way to build intel-gpu-tools without cairo?
Thank you so much for your help
Ying
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Tue, Jul 01, 2014 at 05:16:30PM +, Mateo Lozano, Oscar wrote:
The issue is they need:
A) A buffer object.
B) Bound to GGTT.
C) That userspace knows the GGTT offset of, so that they can program
OABUFFER with it.
D) That userspace can map so that they can read the reported
2014-06-25 16:01 GMT-03:00 Imre Deak imre.d...@intel.com:
This is a respin of the unmerged part of Daniel's runtime PM for DPMS
patchset [1]. The original one also included a refactoring of the DDI
PCH/CRT encoder modesetting path, I left the corresponding patches out
from this series. This is
On Wed, 2014-07-02 at 07:52 +0800, Zhao, Yakui wrote:
On Tue, 2014-07-01 at 09:26 -0600, Vivi, Rodrigo wrote:
It seems the flexibility on rings is more wanted and needed than I imagined.
Please ignore this patch here...
I liked both execution flag or debugfs, but exec flag would cover
51 matches
Mail list logo
