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
> >
> > The i915_gem_record_rings() code was unconditionally querying and saving
> > state
> > for the batch_obj of a request structure
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 c
Hi Dave -
drm-intel-next-2014-06-20:
- Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and
flip events. This is prep work for proper PSR support and should also be
useful for DRRS&fbc.
- Runtime suspend hardware on system suspend to support the new SOix sleep
state
> -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
On Mon, 30 Jun 2014, Paul Bolle 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
> assert_planes_di
On 27 June 2014 15:15, wrote:
> From: Tim Gore
>
> 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 change these tests to use
> the
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 re
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 :
> On 06/25/2014 07:08 PM, Jani Nikula wrote:
> > On Tue, 24 Jun 2014, Aaron Lu wrote:
> >> Some Thinkpad laptops' firmware will i
On 27 June 2014 15:15, wrote:
> From: Tim Gore
>
> igt_subtest_init mainly does stuff that we also want for
> simple/single tests, such as looking for --list-subtests
> and --help options and calling common_init. So just call
> this from igt_simple_init and then set tests_with_subtests
> to fals
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 accordin
Notifying the BIOS about CDCLK changes lets it program audio controller
EM4/EM5 divider values accordingly.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_opregion.c | 29 +
2 files changed, 35 insertions(+
Signed-off-by: Jani Nikula
---
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 2feb8215f9fa..f8e7a74a21ff 100644
--- a/
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] h
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 spe
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
[2.3
On Tue, 01 Jul 2014, Jani Nikula wrote:
> Notifying the BIOS about CDCLK changes lets it program audio controller
> EM4/EM5 divider values accordingly.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 6 ++
> drivers/gpu/drm/i915/intel_opregion.c | 29 +
On Sat, 28 Jun 2014, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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 the
> time it runs it will try to cha
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
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm
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:
Execution
> -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
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
wrote:
> From: Ben Widaws
On Tue, 1 Jul 2014 15:46:51 +
"Mateo Lozano, Oscar" 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] [PATCH 4/
From: Daniele Ceraolo Spurio
The context used to execute a batchbuffer is becoming increasingly
important.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_trace.h | 12
2 files changed, 9 insertions(+
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 nee
From: Daniele Ceraolo Spurio
These tracepoints are useful for observing the creation and
destruction of Full PPGTTs.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_gem_context.c | 6 +
drivers/gpu/drm/i915/i915_trace.h | 41 +
2 f
From: Daniele Ceraolo Spurio
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 extract information about full PPGTT
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 s
It just fix a typo.
v2: removing underscore to let this like all other ring names (Oscar)
Cc: Oscar Mateo
Reviewed-by (v1): Ben Widawsky
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
> -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 +
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 n
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: R
> -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
>
> > -Ori
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 do_s
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
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 fix
There are two important reasons for this patch. It should make the
existing code a lot more readable. It also makes the next patch much
easier to understand in my opinion. There are 2 main variables that
effect this function, leaving 4 permutations:
ring: RCS vs !RCS
PPGTT: full or not
I didn't fi
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
---
drivers/gpu/drm/i915/i915_gem_context.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
d
Signed-off-by: Ben Widawsky
---
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
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
As what was correctly debugged here:
commit acc240d41ea1ab9c488a79219fb313b5b46265ae
Author: Daniel Vetter
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 switched to for context swi
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 wh
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 th
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
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem
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 ord
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 keep
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
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
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
---
drivers/gpu/drm/i915/i915_gpu_error.c | 55 ---
1 file changed, 32 insertions(+), 23
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 wi
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 i
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 tearin
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
http://lists.freedeskt
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
2014-06-25 16:01 GMT-03:00 Imre Deak :
> 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 because there h
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 this case
> of different applications using different co
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
On Tue, Jul 01, 2014 at 08:54:27PM +0100, Chris Wilson wrote:
> 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
> >
On Tue, Jul 01, 2014 at 11:40:52PM -0700, Ben Widawsky wrote:
> On Tue, Jul 01, 2014 at 08:54:27PM +0100, Chris Wilson wrote:
> > 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.
> > >
57 matches
Mail list logo
