Re: [Intel-gfx] [PATCH v8 06/10] drm/i915: Make ring buffer size of a LRC context configurable

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 11:30:24AM -0400, Zhi Wang wrote: > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index cbc84e6..344b5d3 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -2478,7 +2478,8 @@ static int

Re: [Intel-gfx] [PATCH 6/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

2016-06-08 Thread Ville Syrjälä
On Wed, Jun 08, 2016 at 05:55:23PM +0300, Imre Deak wrote: > On ke, 2016-06-08 at 17:50 +0300, Ville Syrjälä wrote: > > On Wed, Jun 08, 2016 at 05:41:00PM +0300, Imre Deak wrote: > > > On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote: > > > > On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre

Re: [Intel-gfx] [Nouveau] [PATCH 9/9] drm: Turn off crtc before tearing down its data structure

2016-06-08 Thread Lukas Wunner
On Fri, Jun 03, 2016 at 08:21:50PM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 09:30:06AM +0200, Lukas Wunner wrote: > > On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote: > > > On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote: > > > > On Wed, May 25, 2016 at

Re: [Intel-gfx] [PATCH] drm/i915: Don't unregister fbdev twice

2016-06-08 Thread Lukas Wunner
On Wed, Jun 08, 2016 at 02:09:40PM +0200, Daniel Vetter wrote: > On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote: > > Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is > > superfluous because the framebuffer will subsequently be unregistered by > >

Re: [Intel-gfx] [PATCH 6/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

2016-06-08 Thread Imre Deak
On ke, 2016-06-08 at 17:50 +0300, Ville Syrjälä wrote: > On Wed, Jun 08, 2016 at 05:41:00PM +0300, Imre Deak wrote: > > On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote: > > > On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre Deak wrote: > > > > We can check the power state of the PHY data and

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for gen9 workarounds v3

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 05:28:31PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > [ text/plain ] > > On Tue, Jun 07, 2016 at 02:52:18PM -, Patchwork wrote: > >> == Series Details == > >> > >> Series: gen9 workarounds v3 > >> URL :

[Intel-gfx] ✗ Ro.CI.BAT: warning for Introduce the implementation of GVT context (rev6)

2016-06-08 Thread Patchwork
== Series Details == Series: Introduce the implementation of GVT context (rev6) URL : https://patchwork.freedesktop.org/series/7208/ State : warning == Summary == Series 7208v6 Introduce the implementation of GVT context http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/6/mbox

Re: [Intel-gfx] [PATCH v8 00/10] Introduce the implementation of GVT context

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 11:30:18AM -0400, Zhi Wang wrote: > Bing Niu (1): > drm/i915: Introduce host graphics memory partition for GVT-g > > Zhi Wang (9): > drm/i915: Factor out i915_pvinfo.h > drm/i915: Use offsetof() to calculate the offset of members in PVINFO > page > drm/i915:

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

2016-06-08 Thread Ville Syrjälä
On Wed, Jun 08, 2016 at 04:47:48PM +0200, Maarten Lankhorst wrote: > Op 08-06-16 om 15:35 schreef Ville Syrjälä: > > On Wed, Jun 08, 2016 at 03:23:33PM +0200, Maarten Lankhorst wrote: > >> Op 08-06-16 om 15:12 schreef Ville Syrjälä: > >>> On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst

[Intel-gfx] [PATCH v2 2/6] drm/i915: Factor out intel_power_well_get/put

2016-06-08 Thread Imre Deak
These helpers will be needed by the next patch, so factor them out. No functional change. v2: - Move the refcount==0 WARN to the new put helper. (Ville) CC: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_runtime_pm.c

Re: [Intel-gfx] [PATCH 6/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

2016-06-08 Thread Ville Syrjälä
On Wed, Jun 08, 2016 at 05:41:00PM +0300, Imre Deak wrote: > On ke, 2016-06-08 at 17:19 +0300, Ville Syrjälä wrote: > > On Tue, Jun 07, 2016 at 09:24:33PM +0300, Imre Deak wrote: > > > We can check the power state of the PHY data and common lanes as > > > reported by the PHY. Do this in case we

[Intel-gfx] [PATCH v2 4/6] drm/i915/bxt: Set DDI PHY lane latency optimization during modeset

2016-06-08 Thread Imre Deak
So far we configured a static lane latency optimization during driver loading/resuming. The specification changed at one point and now this configuration depends on the lane count, so move the configuration to modeset time accordingly. It's not clear when this lane configuration takes effect. The

[Intel-gfx] [PATCH v2 6/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

2016-06-08 Thread Imre Deak
We can check the power state of the PHY data and common lanes as reported by the PHY. Do this in case we need to debug problems where the PHY gets stuck in an unexpected state. Note that I only check these when the lanes are expected to be powered on purpose, since it's not clear at what point

Re: [Intel-gfx] [PATCH v8 00/10] Introduce the implementation of GVT context

2016-06-08 Thread Wang, Zhi A
Sure. That's a good idea. :) > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, June 08, 2016 7:01 PM > To: Wang, Zhi A > Cc: Lv, Zhiyuan ; Tian, Kevin ; >

Re: [Intel-gfx] [PATCH v8 07/10] drm/i915: Make addressing mode bits in context descriptor configurable

2016-06-08 Thread Wang, Zhi A
Sure. Will improve that in v9. > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, June 08, 2016 7:09 PM > To: Wang, Zhi A > Cc: Lv, Zhiyuan ; Tian, Kevin ; >

[Intel-gfx] [PATCH v8 06/10] drm/i915: Make ring buffer size of a LRC context configurable

2016-06-08 Thread Zhi Wang
This patch introduces an option for configuring the ring buffer size of a LRC context after the context creation. v8: - Rename the data member in i915_gem_context. (Chris) Reviewed-by: Joonas Lahtinen Cc: Chris Wilson Signed-off-by:

[Intel-gfx] [PATCH v8 04/10] drm/i915: gvt: Introduce the basic architecture of GVT-g

2016-06-08 Thread Zhi Wang
This patch introduces the very basic framework of GVT-g device model, includes basic prototypes, definitions, initialization. v8: - Remove the GVT idr and mutex in intel_gvt_host. (Joonas) v7: - Refine the URL link in Kconfig. (Joonas) - Refine the introduction of GVT-g host support in Kconfig.

[Intel-gfx] [PATCH v8 07/10] drm/i915: Make addressing mode bits in context descriptor configurable

2016-06-08 Thread Zhi Wang
Currently the addressing mode bit in context descriptor is statically generated from the configuration of system-wide PPGTT usage model. GVT-g will load the PPGTT shadow page table by itself and probably one guest is using a different addressing mode with i915 host. The addressing mode bits of a

[Intel-gfx] [PATCH v8 08/10] drm/i915: Introduce execlist context status change notification

2016-06-08 Thread Zhi Wang
This patch introduces an approach to track the execlist context status change. GVT-g uses GVT context as the "shadow context". The content inside GVT context will be copied back to guest after the context is idle. And GVT-g has to know the status of the execlist context. This function is

[Intel-gfx] [PATCH v8 09/10] drm/i915: Support LRC context single submission

2016-06-08 Thread Zhi Wang
This patch introduces the support of LRC context single submission. As GVT context may come from different guests, which require different configuration of render registers. It can't be combined into a dual ELSP submission combo. Only GVT-g will create this kinds of GEM context currently. v8: -

[Intel-gfx] [PATCH v8 03/10] drm/i915: Fold vGPU active check into inner functions

2016-06-08 Thread Zhi Wang
v5: - Let functions take struct drm_i915_private *. (Tvrtko) - Fold vGPU related active check into the inner functions. (Kevin) Reviewed-by: Tvrtko Ursulin Reviewed-by: Joonas Lahtinen Suggested-by: Kevin Tian

[Intel-gfx] [PATCH v8 00/10] Introduce the implementation of GVT context

2016-06-08 Thread Zhi Wang
This patchset introduces the implementation of GVT context. GVT context is a special GEM context used by GVT-g. GVT-g uses it as the shadow context.It doesn't have a drm client nor a PPGTT. And it requires a larger ring buffer with several special features need by GVT-g workload scheduler like

[Intel-gfx] [PATCH v8 02/10] drm/i915: Use offsetof() to calculate the offset of members in PVINFO page

2016-06-08 Thread Zhi Wang
To get the offset of the members in PVINFO page, offsetof() looks much better than the tricky approach in current code. v7: - Move "offsetof()" modification into a dedicated patch. (Joonas) Suggested-by: Joonas Lahtinen Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v8 05/10] drm/i915: Introduce host graphics memory partition for GVT-g

2016-06-08 Thread Zhi Wang
From: Bing Niu This patch introduces host graphics memory partition when GVT-g is enabled. Under GVT-g, i915 host driver only owned limited graphics resources, others are managed by GVT-g resource allocator and kept for other vGPUs. v7: - Add comments about low/high GM

[Intel-gfx] [PATCH v8 10/10] drm/i915: Introduce GVT context creation API

2016-06-08 Thread Zhi Wang
GVT workload scheduler needs special host LRC contexts, the so called "shadow LRC context" to submit guest workload to host i915. During the guest workload submission, workload scheduler fills the shadow LRC context with the content of guest LRC context: engine context is copied without changes,

[Intel-gfx] [PATCH v8 01/10] drm/i915: Factor out i915_pvinfo.h

2016-06-08 Thread Zhi Wang
As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g host (GVT-g kernel device model), factor it out for better code structure. v7: - Split the "offsetof" modification into a dedicated patch. (Joonas) v3: - Use offsetof to calculate the member offset of PVINFO structure

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/bxt: Fix DDI PHY setup for low resolutions (rev4)

2016-06-08 Thread Patchwork
== Series Details == Series: drm/i915/bxt: Fix DDI PHY setup for low resolutions (rev4) URL : https://patchwork.freedesktop.org/series/8414/ State : failure == Summary == Applying: drm/i915/bxt: Wait for PHY1 GRC calibration synchronously Applying: drm/i915/bxt: Sanitiy check the PHY lane

Re: [Intel-gfx] [PATCH v8 07/10] drm/i915: Make addressing mode bits in context descriptor configurable

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 11:30:25AM -0400, Zhi Wang wrote: > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 66fdb8d..6a79c8c 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -879,6 +879,7 @@ struct i915_gem_context {

Re: [Intel-gfx] [PATCH 08/12] drm/i915: s/INTEL_OUTPUT_DISPLAYPORT/INTEL_OUTPUT_DP/

2016-06-08 Thread Kahola, Mika
I'll second this idea. With small typo fixed on commit message this is Reviewed-by: Mika Kahola > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of ville.syrj...@linux.intel.com > Sent: Wednesday, June 8, 2016

[Intel-gfx] ✓ Ro.CI.BAT: success for Support for creating/using Stolen memory backed objects (rev17)

2016-06-08 Thread Patchwork
== Series Details == Series: Support for creating/using Stolen memory backed objects (rev17) URL : https://patchwork.freedesktop.org/series/659/ State : success == Summary == Series 659v17 Support for creating/using Stolen memory backed objects

[Intel-gfx] [PATCH 1/2] lib/gt: Omit illegal instruction on hang injection with gen 8+

2016-06-08 Thread Mika Kuoppala
0x as an illegal command confuses the command execution on gen9 so that the next BB start will get ignored, causing a runaway head past the bb end. This delays the hang detection substantially as hangcheck then observes only a non progressing seqno. Omit the bad instruction on gen8+ and

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Add output_types bitmask into the crtc state

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Rather than looping through encoders to see which encoder types > are being driven by the pipe, add an output_types bitmask into > the crtc state and populate

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

2016-06-08 Thread Maarten Lankhorst
Op 08-06-16 om 15:12 schreef Ville Syrjälä: > On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote: >> This reduces the runtime of the tests from ~200s on my 30 fps 4k panel >> to 10s. > Does it still find the problem reliably on CHV pipe C (if you remove the > kernel w/a)? Yeah, a

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Check for invalid cloning earlier during modeset

2016-06-08 Thread Ville Syrjälä
On Wed, Jun 08, 2016 at 02:15:25PM +0100, Chris Wilson wrote: > On Wed, Jun 08, 2016 at 01:41:46PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Move the encoder cloning check to happen earlier in the modeset. The > > main benefit will

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

2016-06-08 Thread Ville Syrjälä
On Wed, Jun 08, 2016 at 03:23:33PM +0200, Maarten Lankhorst wrote: > Op 08-06-16 om 15:12 schreef Ville Syrjälä: > > On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote: > >> This reduces the runtime of the tests from ~200s on my 30 fps 4k panel > >> to 10s. > > Does it still find

Re: [Intel-gfx] [PATCH 10/38] drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin()

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 11:43:57AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:55:25PM +0100, Chris Wilson wrote: > > Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for > > i915_gem_object_ggtt_pin(), spare us the confustion and remove it. > > Removing it now

Re: [Intel-gfx] 4.7-rc0: redshift stopped working on intel display

2016-06-08 Thread Pavel Machek
Hi! > Could you try to apply the following patch [1], hopefully this fixes > the issue for you. > > [1] https://patchwork.freedesktop.org/patch/89111/ I updated the kernel, applied the patch and yes, that helped. Thanks!

[Intel-gfx] [PATCH 2/2] igt/gem_reset_stats: Add time constraints on hang detection

2016-06-08 Thread Mika Kuoppala
Make sure that injected hang is detected below time threshold. This ensures that we fail if hang was of no-progress type instead of a stuck engine. Cc: Chris Wilson Signed-off-by: Mika Kuoppala --- tests/gem_reset_stats.c | 23

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

2016-06-08 Thread Ville Syrjälä
On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote: > This reduces the runtime of the tests from ~200s on my 30 fps 4k panel > to 10s. Does it still find the problem reliably on CHV pipe C (if you remove the kernel w/a)? > > Cc: Ville Syrjälä >

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Check for invalid cloning earlier during modeset

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 01:41:46PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move the encoder cloning check to happen earlier in the modeset. The > main benefit will be that the debug output from a failed modeset will > be less confusing

Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: refactor doorbell management code

2016-06-08 Thread Tvrtko Ursulin
On 08/06/16 11:55, Dave Gordon wrote: During a hibernate/resume cycle, the driver, the GuC, and the doorbell hardware can end up in inconsistent states. This patch refactors the driver's handling and tracking of doorbells, in preparation for a later one which will resolve the issue. Perhaps a

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/kms_chv_cursor_fail: Remove extra igt_pipe_crc_start.

2016-06-08 Thread Ville Syrjälä
On Wed, Jun 08, 2016 at 01:25:31PM +0200, Maarten Lankhorst wrote: > There is a extra call to igt_pipe_crc_start that is not matched to any > stop. Because of this the exit handler tries to reset the crc source on > exit while the pipe disabled. This causes fails with -EIO: > >

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Add output_types bitmask into the crtc state

2016-06-08 Thread Ville Syrjälä
On Wed, Jun 08, 2016 at 02:25:25PM +0100, Chris Wilson wrote: > On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Rather than looping through encoders to see which encoder types > > are being driven by

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 01:44:27PM +0100, Tvrtko Ursulin wrote: > > On 08/06/16 13:34, Chris Wilson wrote: > >On Wed, Jun 08, 2016 at 12:47:28PM +0100, Tvrtko Ursulin wrote: > >> > >>On 08/06/16 12:24, Chris Wilson wrote: > >>>On Wed, Jun 08, 2016 at 11:16:13AM +0100, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH v7 03/11] drm/i915: Fold vGPU active check into inner functions

2016-06-08 Thread Wang, Zhi A
OK. Will do in the next version. :) > -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Wednesday, June 08, 2016 11:05 AM > To: Wang, Zhi A ; ch...@chris-wilson.co.uk; Lv, Zhiyuan > ; Tian, Kevin

Re: [Intel-gfx] [PATCH v7 04/11] drm/i915: Add teardown path in intel_vgt_ballon()

2016-06-08 Thread Joonas Lahtinen
Patch title s/ballon/balloon/. On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > This function needs to be changed to have a proper goto teardown path. > Destructors/fini functions are only expected to be called after a > successful initialization, so calling it at random phase in init function

Re: [Intel-gfx] [PATCH v7 08/11] drm/i915: Make addressing mode bits in context descriptor configurable

2016-06-08 Thread Wang, Zhi A
Good idea. :) > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, June 08, 2016 10:13 AM > To: Wang, Zhi A > Cc: Lv, Zhiyuan ; Tian, Kevin ; > tvrtko.ursu...@linux.intel.com;

Re: [Intel-gfx] [PATCH v7 08/11] drm/i915: Make addressing mode bits in context descriptor configurable

2016-06-08 Thread Joonas Lahtinen
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > Currently the addressing mode bit in context descriptor is statically > generated from the configuration of system-wide PPGTT usage model. > > GVT-g will load the PPGTT shadow page table by itself and probably one > guest is using a different

Re: [Intel-gfx] [PATCH v7 10/11] drm/i915: Support LRC context single submission

2016-06-08 Thread Joonas Lahtinen
On ke, 2016-06-08 at 08:04 +0100, Chris Wilson wrote: > On Tue, Jun 07, 2016 at 11:18:46AM -0400, Zhi Wang wrote: > > > > This patch introduces the support of LRC context single submission. > > As GVT context may come from different guests, which require different > > configuration of render

[Intel-gfx] [i-g-t RFC 2/3] lib: Capture kcov around ioctls

2016-06-08 Thread Chris Wilson
Use our ioctl overload to enable kcov capture around every ioctl. --- lib/igt_aux.c | 84 +++ lib/igt_aux.h | 5 2 files changed, 84 insertions(+), 5 deletions(-) diff --git a/lib/igt_aux.c b/lib/igt_aux.c index fb1dac2..71067b3

[Intel-gfx] [i-g-t RFC 1/3] lib: Wrap kcov

2016-06-08 Thread Chris Wilson
A small utility for extracting kernel coverage using /sys/kernel/debug/kcov. Signed-off-by: Chris Wilson --- lib/Makefile.sources | 2 + lib/igt_debugfs.c| 20 ++ lib/igt_debugfs.h| 1 + lib/igt_kcov.c | 188

Re: [Intel-gfx] [PATCH 04/62] drm/i915: Restore waitboost credit to the synchronous waiter

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 05:36:29PM +0100, Chris Wilson wrote: > Ideally, we want to automagically have the GPU respond to the > instantaneous load by reclocking itself. However, reclocking occurs > relatively slowly, and to the client waiting for a result from the GPU, > too late. To compensate

Re: [Intel-gfx] [PATCH v7 02/11] drm/i915: Use offsetof() to calculate the offset of members in PVINFO page

2016-06-08 Thread Joonas Lahtinen
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > To get the offset of the members in PVINFO page, offsetof() looks much > better than the tricky approach in current code. > > v7: > > - Move "offsetof()" modification into a dedicated patch. (Joonas) > > Signed-off-by: Zhi Wang

Re: [Intel-gfx] [PATCH v7 03/11] drm/i915: Fold vGPU active check into inner functions

2016-06-08 Thread Joonas Lahtinen
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > v5: > - Let functions take struct drm_i915_private *. (Tvrtko) > > - Fold vGPU related active check into the inner functions. (Kevin) > I already reviewed this patch, so you should add Reviewed-by: and Cc: tags. Also good to add Cc: tag for

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] Revert "drm/i915: Workaround CHV pipe C cursor fail"

2016-06-08 Thread Patchwork
== Series Details == Series: series starting with [1/2] Revert "drm/i915: Workaround CHV pipe C cursor fail" URL : https://patchwork.freedesktop.org/series/8431/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/intel_dp_mst.o CC [M] drivers/gpu/drm/i915/intel_dp.o CC [M]

Re: [Intel-gfx] [RFC 00/12] Support for sustained capturing of GuC firmware logs

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 11:20:19AM +0100, Chris Wilson wrote: > On Fri, Jun 03, 2016 at 03:44:09PM +0530, Goel, Akash wrote: > > > > > > On 6/3/2016 12:45 PM, Daniel Vetter wrote: > > >On Thu, Jun 02, 2016 at 12:21:49PM +0200, Johannes Berg wrote: > > >>On Thu, 2016-06-02 at 10:16 +, Daniel

Re: [Intel-gfx] [PATCH v7 09/11] drm/i915: Introduce execlist context status change notification

2016-06-08 Thread Joonas Lahtinen
On ti, 2016-06-07 at 23:01 +0100, Chris Wilson wrote: > On Tue, Jun 07, 2016 at 11:18:45AM -0400, Zhi Wang wrote: > > > > This patch introduces an approach to track the execlist context status > > change. > > > > GVT-g uses GVT context as the "shadow context". The content inside GVT > > context

Re: [Intel-gfx] [PATCH 02/21] drm/i915: Delay queuing hangcheck to wait-request

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 05:08:34PM +0100, Chris Wilson wrote: > We can forgo queuing the hangcheck from the start of every request to > until we wait upon a request. This reduces the overhead of every > request, but may increase the latency of detecting a hang. Howeever, if > nothing every waits

Re: [Intel-gfx] [PATCH 15/21] drm/i915: Stop setting wraparound seqno on initialisation

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 05:08:47PM +0100, Chris Wilson wrote: > We have testcases to ensure that seqno wraparound works fine, so we can > forgo forcing everyone to encounter seqno wraparound during early > uptime. seqno wraparound incurs a full GPU stall so not forcing it > will eliminate one

Re: [Intel-gfx] [PATCH 4/6] drm/i915/bxt: Set DDI PHY lane latency optimization during modeset

2016-06-08 Thread Imre Deak
On ke, 2016-06-08 at 09:41 +0300, Ander Conselvan De Oliveira wrote: > On Tue, 2016-06-07 at 21:24 +0300, Imre Deak wrote: > > So far we configured a static lane latency optimization during driver > > loading/resuming. The specification changed at one point and now this > > configuration depends

Re: [Intel-gfx] [PATCH v3 29/33] drm/i915: Split idling from forcing context switch

2016-06-08 Thread Joonas Lahtinen
On pe, 2016-06-03 at 15:37 +0100, Chris Wilson wrote: > We only need to force a switch to the kernel context placeholder during > eviction. All other uses of i915_gpu_idle() just want to wait until > existing work on the GPU is idle. Rename i915_gpu_idle() to > i915_gem_wait_for_idle() to avoid

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

2016-06-08 Thread kbuild test robot
Hi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.7-rc2 next-20160608] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Akshu-Agrawal/Revert-drm-i915-Workaround

Re: [Intel-gfx] [PATCH v6 7/9] drm/i915: Introduce execlist context status change notification

2016-06-08 Thread Joonas Lahtinen
On ti, 2016-06-07 at 15:29 +, Wang, Zhi A wrote: > > > > > -Original Message- > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > > Sent: Friday, June 03, 2016 12:40 PM > > To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org; > >

Re: [Intel-gfx] [PATCH v7 01/11] drm/i915: Factor out i915_pvinfo.h

2016-06-08 Thread Joonas Lahtinen
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g > host (GVT-g kernel device model), factor it out for better code structure. > > v7: > - Split the "offsetof" modification into a dedicated patch. (Joonas) > > v3: > -

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/3] drm/i915/guc: fix GuC loading/submission check

2016-06-08 Thread Dave Gordon
On 07/06/16 21:00, Chris Wilson wrote: On Tue, Jun 07, 2016 at 02:23:34PM +0100, Tvrtko Ursulin wrote: On 07/06/16 11:54, Dave Gordon wrote: On 07/06/16 09:43, Patchwork wrote: == Series Details == Series: series starting with [1/3] drm/i915/guc: fix GuC loading/submission check URL :

Re: [Intel-gfx] [PATCH v7 01/11] drm/i915: Factor out i915_pvinfo.h

2016-06-08 Thread Wang, Zhi A
Sure. Moving code in one patch, "offsetof()" guy will be in another patch > -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Wednesday, June 08, 2016 10:55 AM > To: Wang, Zhi A ; ch...@chris-wilson.co.uk; Lv, Zhiyuan >

[Intel-gfx] [PATCH 1/2] Revert "drm/i915: Workaround CHV pipe C cursor fail"

2016-06-08 Thread Akshu Agrawal
This reverts commit ef8dd37af85a8f37ca3a29074647511e52c56181. Will use cropped cursor image for -ve co-ordinates instead of using swcursor. Advantages of cropped cursor being, it will work for non X11 based platform like Chrome and also will use hwcursor. Signed-off-by: Akshu Agrawal

Re: [Intel-gfx] [PATCH v7 05/11] drm/i915: gvt: Introduce the basic architecture of GVT-g

2016-06-08 Thread Joonas Lahtinen
On ti, 2016-06-07 at 11:18 -0400, Zhi Wang wrote: > This patch introduces the very basic framework of GVT-g device model, > includes basic prototypes, definitions, initialization. > > v7: > - Refine the URL link in Kconfig. (Joonas) > - Refine the introduction of GVT-g host support in Kconfig.

[Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

2016-06-08 Thread Akshu Agrawal
CHV pipe C hits underrun when we get -ve X values of cursor. To avoid this we crop the cursor image for by -ve X value and thus use '0' as least X value. Signed-off-by: Akshu Agrawal --- drivers/gpu/drm/i915/intel_display.c | 113 +++

Re: [Intel-gfx] [PATCH v7 07/11] drm/i915: Make ring buffer size of a LRC context configurable

2016-06-08 Thread Joonas Lahtinen
On ke, 2016-06-08 at 08:08 +0100, Chris Wilson wrote: > On Tue, Jun 07, 2016 at 11:18:43AM -0400, Zhi Wang wrote: > > > > This patch introduces an option for configuring the ring buffer size > > of a LRC context after the context creation. > > > > Signed-off-by: Zhi Wang >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

2016-06-08 Thread Daniel Vetter
On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote: > CHV pipe C hits underrun when we get -ve X values of cursor. To avoid > this we crop the cursor image for by -ve X value and thus use '0' as > least X value. You're talking about "-ve" here and there's absolutely no "-ve" anywhere

Re: [Intel-gfx] [PATCH v3 23/33] drm/i915: Move module init/exit to i915_pci.c

2016-06-08 Thread Joonas Lahtinen
On pe, 2016-06-03 at 15:37 +0100, Chris Wilson wrote: > The module init/exit routines are a wrapper around the PCI device > init/exit, so move them across. > > Note that in order to avoid exporting the driver struct, instead of > manipulating driver.features inside i915_init we instead opt to

Re: [Intel-gfx] [PATCH 13/62] drm/i915: Derive GEM requests from dma-fence

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 05:36:38PM +0100, Chris Wilson wrote: > dma-buf provides a generic fence class for interoperation between > drivers. Internally we use the request structure as a fence, and so with > only a little bit of interfacing we can rebase those requests on top of > dma-buf fences.

Re: [Intel-gfx] [PATCH 02/21] drm/i915: Delay queuing hangcheck to wait-request

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 10:42:58AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:08:34PM +0100, Chris Wilson wrote: > > We can forgo queuing the hangcheck from the start of every request to > > until we wait upon a request. This reduces the overhead of every > > request, but may

Re: [Intel-gfx] FW: Wrt golden MMIO/CFG snaphot in GVT-g

2016-06-08 Thread Joonas Lahtinen
On pe, 2016-06-03 at 12:36 +, Tian, Kevin wrote: > > > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > > Sent: Friday, May 27, 2016 7:32 PM > > > > On pe, 2016-05-27 at 10:05 +, Wang, Zhi A wrote: > > > > > > For me I think maybe i915 could save the snapshot for GVT,

Re: [Intel-gfx] The vma leak fix from yonder

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 05:36:25PM +0100, Chris Wilson wrote: > Just to see if anyone is awake this series takes us to the VMA leak fix. > Just the tip of the iceberg when it comes to VMA fixes... Read through it. I think it'd be good (although yes, painful) if we could untangle the ring/engine

Re: [Intel-gfx] [PATCH 10/38] drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin()

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 05:55:25PM +0100, Chris Wilson wrote: > Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for > i915_gem_object_ggtt_pin(), spare us the confustion and remove it. > Removing it now simplifies later patches to change the i915_vma_pin() > (and friends)

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

2016-06-08 Thread Chris Wilson
On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote: > >+static int intel_breadcrumbs_signaler(void *arg) > >+{ > >+struct intel_engine_cs *engine = arg; > >+struct intel_breadcrumbs *b = >breadcrumbs; > >+struct signal *signal; > >+ > >+/* Install ourselves with high

[Intel-gfx] [PATCH v21 00/11] Support for creating/using Stolen memory backed objects

2016-06-08 Thread ankitprasad . r . sharma
From: Ankitprasad Sharma This patch series adds support for creating/using Stolen memory backed objects. Despite being a unified memory architecture (UMA) some bits of memory are more equal than others. In particular we have the thorny issue of stolen memory,

[Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page

2016-06-08 Thread ankitprasad . r . sharma
From: Chris Wilson Introduced a new vm specfic callback insert_page() to program a single pte in ggtt or ppgtt. This allows us to map a single page in to the mappable aperture space. This can be iterated over to access the whole object by using space as meagre as page

Re: [Intel-gfx] [PATCH 27/38] drm/i915: Reduce locking inside swfinish ioctl

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 05:55:42PM +0100, Chris Wilson wrote: > We only need to take the struct_mutex if the object is pinned to the > display engine and so requires checking for clflush. (The race with > userspace pinning the object to a framebuffer is irrelevant.) > > v2: Use access once for

Re: [Intel-gfx] [PATCH 22/38] drm/gem/shrinker: Wait before acquiring struct_mutex under oom

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 11:57:21AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:55:37PM +0100, Chris Wilson wrote: > > Signed-off-by: Chris Wilson > > Shouldn't we only do this as a last resort, i.e. in the oom notifier? > Commit message is a bit sparse on

Re: [Intel-gfx] [PATCH 27/38] drm/i915: Reduce locking inside swfinish ioctl

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 11:59:25AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:55:42PM +0100, Chris Wilson wrote: > > We only need to take the struct_mutex if the object is pinned to the > > display engine and so requires checking for clflush. (The race with > > userspace pinning the

Re: [Intel-gfx] [PATCH 29/38] drm/i915: Remove locking for get_tiling

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 12:02:01PM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:55:44PM +0100, Chris Wilson wrote: > > Since we are not concerned with userspace racing itself with set-tiling > > (the order is indeterminant even if we take a lock), then we can safely > > read back the

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

2016-06-08 Thread Dave Gordon
On 08/06/16 09:40, Daniel Vetter wrote: On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote: CHV pipe C hits underrun when we get -ve X values of cursor. To avoid this we crop the cursor image for by -ve X value and thus use '0' as least X value. You're talking about "-ve" here and

Re: [Intel-gfx] [PATCH 19/21] drm/i915: Move the get/put irq locking into the caller

2016-06-08 Thread Tvrtko Ursulin
On 08/06/16 11:01, Chris Wilson wrote: On Tue, Jun 07, 2016 at 01:46:53PM +0100, Tvrtko Ursulin wrote: On 03/06/16 17:08, Chris Wilson wrote: With only a single callsite for intel_engine_cs->irq_get and ->irq_put, we can reduce the code size by moving the common preamble into the caller, and

[Intel-gfx] [PATCH 12/12] drm/i915: Stop frobbing with DDI encoder->type

2016-06-08 Thread ville . syrjala
From: Ville Syrjälä Now that we have the output_types bitmask in the crtc state, we can use it to indicate in which mode we want to drive the DDI encoders. For pre-DDI output_types will instead indicate what kind of cloning is being done, but as DDI platforms don't

[Intel-gfx] [PATCH 11/12] drm/i915: Check for invalid cloning earlier during modeset

2016-06-08 Thread ville . syrjala
From: Ville Syrjälä Move the encoder cloning check to happen earlier in the modeset. The main benefit will be that the debug output from a failed modeset will be less confusing as output_types can not indicate an invalid configuration during the later computation

[Intel-gfx] [PATCH 09/12] drm/i915: Kill has_dsi_encoder

2016-06-08 Thread ville . syrjala
From: Ville Syrjälä has_dsi_encoder was introduced to indicate that the pipe is driving a DSI encoder. Now that we have the output_types bitmask that can tell us the same thing, let's just kill has_dsi_encoder. v2: Rebase, handle BXT DSI transcoder, rewrote commit

[Intel-gfx] [PATCH 08/12] drm/i915: s/INTEL_OUTPUT_DISPLAYPORT/INTEL_OUTPUT_DP/

2016-06-08 Thread ville . syrjala
From: Ville Syrjälä INTEL_OUTPUT_DISPLAYPORT hsa been bugging me for a long time. It always looks out of place besides INTEL_OUTPUT_EDP and INTEL_OUTPUT_DP_MST. Let's just rename it to INTEL_OUTPUT_DP. v2: Rebase Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 06/12] drm/i915: Kill has_dp_encoder from pipe_config

2016-06-08 Thread ville . syrjala
From: Ville Syrjälä Use the new output_types bitmask instead of has_dp_encoder. To make it less oainlful provide a small helper (intel_crtc_has_dp_encoder()) to do the bitsy stuff. v2: Rebase Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 07/12] drm/i915: Replace some open coded intel_crtc_has_dp_encoder()s

2016-06-08 Thread ville . syrjala
From: Ville Syrjälä A bunch of places still look for DP encoders manually. Just call intel_crtc_has_dp_encoder(). Note that many of these places don't look for EDP or DP_MST, but it's still fine to replace them because * for audio we don't enable audio on eDP

[Intel-gfx] [PATCH 10/12] drm/i915: Simplify hdmi_12bpc_possible()

2016-06-08 Thread ville . syrjala
From: Ville Syrjälä With the output_types bitmask there's no need to loop through the encoders anymore when checking for HDMI+non-HDMI cloning. v2: Use output_types bitmask Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 05/12] drm/i915: Replace manual lvds and sdvo/hdmi counting with intel_crtc_has_type()

2016-06-08 Thread ville . syrjala
From: Ville Syrjälä Since we now have the output_types bitmaks in the crtc state, there's no need to iterate through all the encoders to see if an LVDS or SDVO/HDMI encoder might be present. Signed-off-by: Ville Syrjälä ---

Re: [Intel-gfx] [PATCH 08/21] drm/i915: Use HWS for seqno tracking everywhere

2016-06-08 Thread Chris Wilson
On Mon, Jun 06, 2016 at 03:55:18PM +0100, Tvrtko Ursulin wrote: > > On 03/06/16 17:08, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/i915_irq.c > >b/drivers/gpu/drm/i915/i915_irq.c > >index 2a736f4a0fe5..4013ad92cdc6 100644 > >--- a/drivers/gpu/drm/i915/i915_irq.c > >+++

Re: [Intel-gfx] [PATCH 14/21] drm/i915: Only apply one barrier after a breadcrumb interrupt is posted

2016-06-08 Thread Chris Wilson
On Mon, Jun 06, 2016 at 04:34:27PM +0100, Tvrtko Ursulin wrote: > > On 03/06/16 17:08, Chris Wilson wrote: > >If we flag the seqno as potentially stale upon receiving an interrupt, > >we can use that information to reduce the frequency that we apply the > >heavyweight coherent seqno read (i.e. if

Re: [Intel-gfx] [PATCH 14/21] drm/i915: Only apply one barrier after a breadcrumb interrupt is posted

2016-06-08 Thread Tvrtko Ursulin
On 08/06/16 10:35, Chris Wilson wrote: On Mon, Jun 06, 2016 at 04:34:27PM +0100, Tvrtko Ursulin wrote: On 03/06/16 17:08, Chris Wilson wrote: If we flag the seqno as potentially stale upon receiving an interrupt, we can use that information to reduce the frequency that we apply the

Re: [Intel-gfx] [PATCH 29/38] drm/i915: Remove locking for get_tiling

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 05:55:44PM +0100, Chris Wilson wrote: > Since we are not concerned with userspace racing itself with set-tiling > (the order is indeterminant even if we take a lock), then we can safely > read back the single obj->tiling_mode and do the static lookup of > swizzle mode

Re: [Intel-gfx] [PATCH 32/38] drm/i915: Stop the machine whilst capturing the GPU crash dump

2016-06-08 Thread Daniel Vetter
On Fri, Jun 03, 2016 at 05:55:47PM +0100, Chris Wilson wrote: > The error state is purposefully racy as we expect it to be called at any > time and so have avoided any locking whilst capturing the crash dump. > However, with multi-engine GPUs and multiple CPUs, those races can > manifest into

Re: [Intel-gfx] [PATCH 13/62] drm/i915: Derive GEM requests from dma-fence

2016-06-08 Thread Chris Wilson
On Wed, Jun 08, 2016 at 11:14:23AM +0200, Daniel Vetter wrote: > On Fri, Jun 03, 2016 at 05:36:38PM +0100, Chris Wilson wrote: > > static inline struct drm_i915_gem_request * > > +to_request(struct fence *fence) > > +{ > > + /* We assume that NULL fence/request are interoperable */ > > +

  1   2   >