[Intel-gfx] ✗ Ro.CI.BAT: failure for CHV vblank failures when PSR is active

== Series Details == Series: CHV vblank failures when PSR is active URL : https://patchwork.freedesktop.org/series/8477/ State : failure == Summary == Applying: drm: Add vblank prepare and unprepare hooks. Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_irq.c M

Re: [Intel-gfx] [PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts are enabled

Hi, [auto build test WARNING on v4.7-rc2] [cannot apply to drm-intel/for-linux-next drm/drm-next 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/Dhinakaran-Pandiyan/CHV-vblank

[Intel-gfx] [PATCH 2/3] drm/i915: Move drm_crtc_vblank_get out of disabled pre-emption area.

From: Rodrigo Vivi drm_crtc_vblank_get call the drm_vblank_prepare that will be used soon to control power saving states or anything else that needs a mutex before the vblank happens. local_irq_disable disables kernel preemption so we won't be able to use mutex inside

[Intel-gfx] [PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts are enabled

PSR in CHV, unlike HSW, can get activated even if vblanks interrupts are enabled. But, the pipe is not expected to generate timings signals when PSR is active. Specifically, we do not get vblank interrupts in CHV if PSR becomes active. This has led to drm_wait_vblank timing out. Let's disable PSR

[Intel-gfx] [PATCH 1/3] drm: Add vblank prepare and unprepare hooks.

From: Rodrigo Vivi This will allow drivers to control specific power saving feature and power domains when dealing with vblanks. Vblanks code are protected by spin_locks where we can't have anything that can sleep. While power saving features and power domain code have

[Intel-gfx] [PATCH 0/3] CHV vblank failures when PSR is active

IGT vblank tests fail on CHV by timing out on VBIs if PSR is enabled. We do not get VBIs as the source timing generation is disabled when PSR is active. The first two patches written by Rodrigo add drm hooks. Patch 3 deactivates PSR when VBI are needed. [PATCH 1/3] drm: Add vblank prepare and

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

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 v8 07/10] drm/i915: Make addressing mode bits in context descriptor configurable

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 ; >

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

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 v8 07/10] drm/i915: Make addressing mode bits in context descriptor configurable

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 v8 00/10] Introduce the implementation of GVT context

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 06/10] drm/i915: Make ring buffer size of a LRC context configurable

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

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

== 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 00/10] Introduce the implementation of GVT context

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:

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

== 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

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

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

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

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

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

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

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

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

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 06/10] drm/i915: Make ring buffer size of a LRC context configurable

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

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

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 05/10] drm/i915: Introduce host graphics memory partition for GVT-g

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

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 02/10] drm/i915: Use offsetof() to calculate the offset of members in PVINFO page

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 01/10] drm/i915: Factor out i915_pvinfo.h

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] [PATCH v8 00/10] Introduce the implementation of GVT context

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

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

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] ✓ Ro.CI.BAT: success for gen9 workarounds v3

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 :

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

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] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

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

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

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

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

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 wrote: This reduces the runtime of the tests from ~200s on my 30 fps

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

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 need to debug problems where the > > PHY gets stuck in an unexpected

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Remaining PSR fixes

== Series Details == Series: drm/i915: Remaining PSR fixes URL : https://patchwork.freedesktop.org/series/8046/ State : warning == Summary == Series 8046v1 drm/i915: Remaining PSR fixes http://patchwork.freedesktop.org/api/1.0/series/8046/revisions/1/mbox Test kms_sink_crc_basic:

Re: [Intel-gfx] [PATCH 27/27] drm/i915/gen9: Add WaFbcHighMemBwCorruptionAvoidance

Ville Syrjälä writes: > [ text/plain ] > On Tue, Jun 07, 2016 at 05:19:19PM +0300, Mika Kuoppala wrote: >> Add this fbc related workaround for all gen9 >> >> Cc: Ville Syrjälä >> Signed-off-by: Mika Kuoppala

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

Chris Wilson writes: > [ text/plain ] > On Tue, Jun 07, 2016 at 02:52:18PM -, Patchwork wrote: >> == Series Details == >> >> Series: gen9 workarounds v3 >> URL : https://patchwork.freedesktop.org/series/8405/ >> State : success >> >> == Summary == >> >> Series

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

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 need to debug problems where the > PHY gets stuck in an unexpected state. > > Note that I only check these when the lanes are

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

On Wed, Jun 08, 2016 at 04:07:18PM +0300, Mika Kuoppala wrote: > 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

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast

Hi, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20160608] [cannot apply to v4.7-rc2] [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/ankitprasad-r

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

On Wed, Jun 08, 2016 at 04:07:17PM +0300, Mika Kuoppala wrote: > 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

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

On Tue, Jun 07, 2016 at 09:24:29PM +0300, Imre Deak wrote: > These helpers will be needed by the next patch, so factor them out. > > No functional change. > > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 23 +-- > 1 file

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

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 i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

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 03/12] drm/i915: Add output_types bitmask into the crtc state

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 11/12] drm/i915: Check for invalid cloning earlier during modeset

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 03/12] drm/i915: Add output_types bitmask into the crtc state

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.

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 i-g-t 1/2] tests/kms_chv_cursor_fail: Remove extra igt_pipe_crc_start.

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 3/4] drm/i915/guc: refactor doorbell management code

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 11/12] drm/i915: Check for invalid cloning earlier during modeset

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

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

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

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

== 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

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

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ä >

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

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 08/12] drm/i915: s/INTEL_OUTPUT_DISPLAYPORT/INTEL_OUTPUT_DP/

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

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

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!

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

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] [PATCH 19/21] drm/i915: Move the get/put irq locking into the caller

On Wed, Jun 08, 2016 at 12:49:14PM +0100, Tvrtko Ursulin wrote: > > On 08/06/16 12:10, Chris Wilson wrote: > >On Wed, Jun 08, 2016 at 11:18:59AM +0100, Tvrtko Ursulin wrote: > >> > >>On 08/06/16 11:01, Chris Wilson wrote: > >>>On Tue, Jun 07, 2016 at 01:46:53PM +0100, Tvrtko Ursulin wrote: >

[Intel-gfx] [PATCH 11/11] drm/i915: Extend GET_APERTURE ioctl to report available map space

From: Ankitprasad Sharma When constructing a batchbuffer, it is sometimes crucial to know the largest hole into which we can fit a fenceable buffer (for example when handling very large objects on gen2 and gen3). This depends on the fragmentation of pinned buffers

[Intel-gfx] [PATCH 09/11] drm/i915: Migrate stolen objects before hibernation

From: Chris Wilson Ville reminded us that stolen memory is not preserved across hibernation, and a result of this was that context objects now being allocated from stolen were being corrupted on S4 and promptly hanging the GPU on resume. We want to utilise stolen for

[Intel-gfx] [PATCH 10/11] drm/i915: Disable use of stolen area by User when Intel RST is present

From: Ankitprasad Sharma The BIOS RapidStartTechnology may corrupt the stolen memory across S3 suspend due to unalarmed hibernation, in which case we will not be able to preserve the User data stored in the stolen region. Hence this patch tries to identify

Re: [Intel-gfx] [PATCH 2/4] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

On 08/06/16 11:55, Dave Gordon wrote: Just code movement, no actual change to the function. This is in preparation for the next patch, which will reorganise all the other doorbell code, but doesn't change this function. So let's shuffle it down near its caller rather than leaving it mixed in

[Intel-gfx] [PATCH 04/11] drm/i915: Clearing buffer objects via CPU/GTT

From: Ankitprasad Sharma This patch adds support for clearing buffer objects via CPU/GTT. This is particularly useful for clearing out the non shmem backed objects. Currently intend to use this only for buffers allocated from stolen region. v2: Added kernel doc

[Intel-gfx] [PATCH 08/11] drm/i915: Support for pread/pwrite from/to non shmem backed objects

From: Ankitprasad Sharma This patch adds support for extending the pread/pwrite functionality for objects not backed by shmem. The access will be made through gtt interface. This will cover objects backed by stolen memory as well as other non-shmem backed objects.

[Intel-gfx] [PATCH 05/11] drm/i915: Support for creating Stolen memory backed objects

From: Ankitprasad Sharma Extend the drm_i915_gem_create structure to add support for creating Stolen memory backed objects. Added a new flag through which user can specify the preference to allocate the object from stolen memory, which if set, an attempt will be

[Intel-gfx] [PATCH 06/11] drm/i915: Propagating correct error codes to the userspace

From: Ankitprasad Sharma Propagating correct error codes to userspace by using ERR_PTR and PTR_ERR macros for stolen memory based object allocation. We generally return -ENOMEM to the user whenever there is a failure in object allocation. This patch helps user to

[Intel-gfx] [PATCH 02/11] drm/i915: Introduce i915_gem_object_get_dma_address()

From: Chris Wilson This utility function is a companion to i915_gem_object_get_page() that uses the same cached iterator for the scatterlist to perform fast sequential lookup of the dma address associated with any page within the object. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 07/11] drm/i915: Add support for stealing purgable stolen pages

From: Chris Wilson If we run out of stolen memory when trying to allocate an object, see if we can reap enough purgeable objects to free up enough contiguous free space for the allocation. This is in principle very much like evicting objects to free up enough contiguous space in the vma when

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

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 03/11] drm/i915: Use insert_page for pwrite_fast

From: Ankitprasad Sharma In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First, we try a nonblocking pin for the whole object (since that is fastest if reused), then failing that we try to grab one page in the mappable aperture. It also allows us

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

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 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

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: On 08/06/16 10:48, Chris Wilson wrote: On Tue, Jun 07, 2016 at 01:04:22PM +0100,

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

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: > >> > >>On 08/06/16 10:48, Chris Wilson wrote: > >>>On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

On 08/06/16 11:55, Dave Gordon wrote: To properly verify the driver->doorbell->GuC functionality, validation needs to know how the driver has assigned the doorbell cache lines and registers, so make them visible through debugfs. Signed-off-by: Dave Gordon ---

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

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 > drm_framebuffer_free() when unreferenced in drm_framebuffer_remove(). > The call is

Re: [Intel-gfx] [PATCH 01/62] drm/i915: Only start retire worker when idle

On ke, 2016-06-08 at 12:06 +0100, Chris Wilson wrote: > On Wed, Jun 08, 2016 at 11:53:15AM +0100, Chris Wilson wrote: > > > > On Tue, Jun 07, 2016 at 02:31:07PM +0300, Joonas Lahtinen wrote: > > > > > > On pe, 2016-06-03 at 17:36 +0100, Chris Wilson wrote: > > > > > > > >  

Re: [Intel-gfx] [PATCH 12/62] drm/i915: Skip capturing an error state if we already have one

On Wed, Jun 08, 2016 at 04:44:45PM +0530, Arun Siluvery wrote: > On 03/06/2016 22:06, Chris Wilson wrote: > >As we only ever keep the first error state around, we can avoid some > >work that can be quite intrusive if we don't record the error the second > >time around. This does move the race

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Don't unregister fbdev twice

== Series Details == Series: drm/i915: Don't unregister fbdev twice URL : https://patchwork.freedesktop.org/series/8443/ State : success == Summary == Series 8443v1 drm/i915: Don't unregister fbdev twice http://patchwork.freedesktop.org/api/1.0/series/8443/revisions/1/mbox Test

Re: [Intel-gfx] [PATCH 08/62] drm/i915: Remove stop-rings debugfs interface

On 03/06/2016 22:06, Chris Wilson wrote: Now that we have (near) universal GPU recovery code, we can inject a real hang from userspace and not need any fakery. Not only does this mean that the testing is far more realistic, but we can simplify the kernel in the process. Signed-off-by: Chris

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

On 08/06/16 12:10, Chris Wilson wrote: On Wed, Jun 08, 2016 at 11:18:59AM +0100, Tvrtko Ursulin wrote: 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

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

On 08/06/16 12:24, Chris Wilson wrote: On Wed, Jun 08, 2016 at 11:16:13AM +0100, Tvrtko Ursulin wrote: On 08/06/16 10:48, Chris Wilson wrote: On Tue, Jun 07, 2016 at 01:04:22PM +0100, Tvrtko Ursulin wrote: +static int intel_breadcrumbs_signaler(void *arg) +{ + struct intel_engine_cs

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: updates to GuC doorbell handling

== Series Details == Series: drm/i915: updates to GuC doorbell handling URL : https://patchwork.freedesktop.org/series/8441/ State : success == Summary == Series 8441v1 drm/i915: updates to GuC doorbell handling http://patchwork.freedesktop.org/api/1.0/series/8441/revisions/1/mbox

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

On Wed, Jun 08, 2016 at 12:06:05PM +0200, Daniel Vetter wrote: > 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

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

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: (kms_chv_cursor_fail:2643) igt-debugfs-CRITICAL: Test assertion failure function

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

This reduces the runtime of the tests from ~200s on my 30 fps 4k panel to 10s. Cc: Ville Syrjälä Signed-off-by: Maarten Lankhorst --- tests/kms_chv_cursor_fail.c | 18 +++--- 1 file changed, 11 insertions(+), 7

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

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 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

On Wed, Jun 08, 2016 at 11:16:13AM +0100, Tvrtko Ursulin wrote: > > On 08/06/16 10:48, Chris Wilson wrote: > >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-gfx] [PATCH] drm/i915: Don't unregister fbdev twice

Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is superfluous because the framebuffer will subsequently be unregistered by drm_framebuffer_free() when unreferenced in drm_framebuffer_remove(). The call is a leftover, when it was introduced by commit 362063619cf6 ("drm:

Re: [Intel-gfx] [PATCH 12/62] drm/i915: Skip capturing an error state if we already have one

On 03/06/2016 22:06, Chris Wilson wrote: As we only ever keep the first error state around, we can avoid some work that can be quite intrusive if we don't record the error the second time around. This does move the race whereby the user could discard one error state as the second is being

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Eliminate DDI encoder->type frobbery

== Series Details == Series: drm/i915: Eliminate DDI encoder->type frobbery URL : https://patchwork.freedesktop.org/series/8439/ State : success == Summary == Series 8439v1 drm/i915: Eliminate DDI encoder->type frobbery http://patchwork.freedesktop.org/api/1.0/series/8439/revisions/1/mbox

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

On Wed, Jun 08, 2016 at 11:18:59AM +0100, Tvrtko Ursulin wrote: > > 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

Re: [Intel-gfx] [PATCH 01/62] drm/i915: Only start retire worker when idle

On Wed, Jun 08, 2016 at 11:53:15AM +0100, Chris Wilson wrote: > On Tue, Jun 07, 2016 at 02:31:07PM +0300, Joonas Lahtinen wrote: > > On pe, 2016-06-03 at 17:36 +0100, Chris Wilson wrote: > > >  i915_gem_idle_work_handler(struct work_struct *work) > > >  { > > >   struct drm_i915_private *dev_priv

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

On Wed, Jun 08, 2016 at 12:02:28PM +0300, Joonas Lahtinen wrote: > On pe, 2016-06-03 at 15:37 +0100, Chris Wilson wrote: > > @@ -261,11 +298,17 @@ int i915_gem_evict_vm(struct i915_address_space *vm, > > bool do_idle) > >   trace_i915_gem_evict_vm(vm); > >   > >   if (do_idle) { > > -

[Intel-gfx] [PATCH 2/4] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

Just code movement, no actual change to the function. This is in preparation for the next patch, which will reorganise all the other doorbell code, but doesn't change this function. So let's shuffle it down near its caller rather than leaving it mixed in with the setup code. Unlike the doorbell

[Intel-gfx] [PATCH 0/4] drm/i915: updates to GuC doorbell handling

The Linux hibernate/resume sequence involves booting one kernel, and then replacing(!) its in-memory image with that of the previously hibernated system. This can lead to inconsistencies in the state of the hardware, in particular where a driver does not or cannot reset it to a well-defined

[Intel-gfx] [PATCH 1/4] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

To properly verify the driver->doorbell->GuC functionality, validation needs to know how the driver has assigned the doorbell cache lines and registers, so make them visible through debugfs. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_debugfs.c | 9

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

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. Signed-off-by: Dave Gordon

  1   2   >