Re: [Intel-gfx] linux-next: build failure after merge of the drm tree

On 7/15/16, Stephen Rothwell wrote: > Hi Dave, > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0: > drivers/gpu/drm/i915/intel_opregion.c: In function >

[Intel-gfx] linux-next: build failure after merge of the drm tree

Hi Dave, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0: drivers/gpu/drm/i915/intel_opregion.c: In function 'intel_opregion_get_panel_type':

Re: [Intel-gfx] [PATCH] drm/i915: Acquire intel_runtime_pm for HD-Audio registers

Hi Wilson, > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Thursday, July 14, 2016 10:34 PM > To: Mika Kuoppala ; intel- > g...@lists.freedesktop.org; Takashi Iwai ; Yang, Libin > >

[Intel-gfx] [PATCH d-i-n] drm/i915: Fix build failure in intel_opregion_get_panel_type()

Tested against drm-intel-nightly (2016y-07m-14d-20h-15m-29s UTC). Fixes: aeddda06c1a704bb9 ("drm/i915: Ignore panel type from OpRegion on SKL") CC: intel-gfx@lists.freedesktop.org CC: Ville Syrjälä CC: Daniel Vetter Signed-off-by: Sedat

Re: [Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

On Thu, Jul 14, 2016 at 09:52:24PM +0100, Emil Velikov wrote: > On 14 July 2016 at 21:03, Chris Wilson wrote: > > On Thu, Jul 14, 2016 at 07:54:59PM +0100, Emil Velikov wrote: > >> On 14 July 2016 at 17:49, Chris Wilson wrote: > >> > On Thu,

Re: [Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

On 14 July 2016 at 21:03, Chris Wilson wrote: > On Thu, Jul 14, 2016 at 07:54:59PM +0100, Emil Velikov wrote: >> On 14 July 2016 at 17:49, Chris Wilson wrote: >> > On Thu, Jul 14, 2016 at 05:29:55PM +0100, Emil Velikov wrote: >> >> Hi Marius,

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for Fixes for HPD (rev3)

On Wed, Jun 22, 2016 at 01:22:09PM -, Patchwork wrote: > == Series Details == > > Series: Fixes for HPD (rev3) > URL : https://patchwork.freedesktop.org/series/8870/ > State : warning > > == Summary == > > Series 8870v3 Fixes for HPD >

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, Just 2 regression fixes. I've also realized that a pile of hang fixes for kbl landed in next, and no one thought of backporting it to 4.7 - kbl has lost prelim_hw_support tagging in 4.7-rc1 already. Mika is prepping a topic branch for those, will send you a separate pull request since

Re: [Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

On Thu, Jul 14, 2016 at 07:54:59PM +0100, Emil Velikov wrote: > On 14 July 2016 at 17:49, Chris Wilson wrote: > > On Thu, Jul 14, 2016 at 05:29:55PM +0100, Emil Velikov wrote: > >> Hi Marius, > >> > >> Just double-checking - this is an i-g-t patch, isn't it ? > >> > >>

Re: [Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

On 14 July 2016 at 17:49, Chris Wilson wrote: > On Thu, Jul 14, 2016 at 05:29:55PM +0100, Emil Velikov wrote: >> Hi Marius, >> >> Just double-checking - this is an i-g-t patch, isn't it ? >> >> On 14 July 2016 at 11:39, Marius Vlad wrote: >> >

[Intel-gfx] [drm-intel:drm-intel-nightly 2/10] drivers/gpu/drm/i915/i915_drv.h:2695:26: note: in expansion of macro 'INTEL_INFO'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 2d854c67e3af36b190e8499a3bfad7cdccde0f67 commit: 01734c300fbff01e321d4ff1b3c91e24e0a3b90d [2/10] Merge remote-tracking branch 'origin/drm-intel-next-fixes' into drm-intel-nightly config: i386-allmodconfig (attached as

[Intel-gfx] [drm-intel:drm-intel-nightly 2/10] drivers/gpu/drm/i915/intel_opregion.c:1081:2: note: in expansion of macro 'if'

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 2d854c67e3af36b190e8499a3bfad7cdccde0f67 commit: 01734c300fbff01e321d4ff1b3c91e24e0a3b90d [2/10] Merge remote-tracking branch 'origin/drm-intel-next-fixes' into drm-intel-nightly config: x86_64-randconfig-s1-07150032

Re: [Intel-gfx] [PATCH] drm/i915: Fix legacy gamma lut updates in Linux 4.7-rc6

Ok, so legacy gamma table updates are completely broken for Intel on Linux-4.7-rc7, the final release candidate. The good news is that applying Lionel's patch "drm/i915: add missing condition for committing planes on crtc" from https://patchwork.freedesktop.org/patch/89111/ fixes it nicely.

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid

On Wed, Jul 13, 2016 at 01:17:40PM +0100, Chris Wilson wrote: > On Wed, Jul 13, 2016 at 01:09:28PM +0100, Chris Wilson wrote: > > On Wed, Jul 13, 2016 at 01:59:52PM +0200, Daniel Vetter wrote: > > > I think the proper solution should be to make all the probing and fbdev > > > restoring async. As

Re: [Intel-gfx] [PATCH i-g-t] tests: Fix compilation when some gcc configurations

On Thu, Jul 14, 2016 at 06:44:59PM +0100, Chris Wilson wrote: > On Thu, Jul 14, 2016 at 06:31:37PM +0100, Damien Lespiau wrote: > > Depending how the gcc was compiled it may be necessary to enable SSE4 > > instructions explicitly. Otherwise: > > > > CC gem_gtt_speed.o > > In file included

Re: [Intel-gfx] [PATCH i-g-t] tests: Fix compilation when some gcc configurations

On Thu, Jul 14, 2016 at 06:31:37PM +0100, Damien Lespiau wrote: > Depending how the gcc was compiled it may be necessary to enable SSE4 > instructions explicitly. Otherwise: > > CC gem_gtt_speed.o > In file included from gem_gtt_speed.c:54:0: >

[Intel-gfx] [PATCH i-g-t] tests: Fix compilation when some gcc configurations

Depending how the gcc was compiled it may be necessary to enable SSE4 instructions explicitly. Otherwise: CC gem_gtt_speed.o In file included from gem_gtt_speed.c:54:0: /usr/lib/gcc/x86_64-linux-gnu/4.8/include/smmintrin.h:31:3: error: #error "SSE4.1 instruction set not enabled" # error

Re: [Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

On Thu, Jul 14, 2016 at 05:29:55PM +0100, Emil Velikov wrote: > Hi Marius, > > Just double-checking - this is an i-g-t patch, isn't it ? > > On 14 July 2016 at 11:39, Marius Vlad wrote: > > Required by commit 2603b98ca (aubdump: Support softpin bos). > > > >

Re: [Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

Hi Marius, Just double-checking - this is an i-g-t patch, isn't it ? On 14 July 2016 at 11:39, Marius Vlad wrote: > Required by commit 2603b98ca (aubdump: Support softpin bos). > > Signed-off-by: Marius Vlad > CC: Kristian Høgsberg Kristensen

[Intel-gfx] [drm-intel:drm-intel-nightly 2/10] drivers/gpu/drm/i915/intel_opregion.c:1081:17: error: 'dev' undeclared

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 2d854c67e3af36b190e8499a3bfad7cdccde0f67 commit: 01734c300fbff01e321d4ff1b3c91e24e0a3b90d [2/10] Merge remote-tracking branch 'origin/drm-intel-next-fixes' into drm-intel-nightly config: i386-randconfig-i1-201628 (attached

[Intel-gfx] [PATCH driver/intel] uxa: Don't bother with xf86GARTCloseScreen

We only ever use xserver's AGP support from the i810 driver. Signed-off-by: Adam Jackson --- src/uxa/intel_driver.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c index 73d7f4f..62abdd2 100644 --- a/src/uxa/intel_driver.c

Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Thu, Jul 14, 2016 at 04:36:37PM +0200, Daniel Vetter wrote: > On Thu, Jul 14, 2016 at 02:39:54PM +0100, Chris Wilson wrote: > > On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote: > > > The biggest reason I had against going the sw_sync only route was that > > > vgem should provide

Re: [Intel-gfx] [PATCH 1/2] drm/i915/fbdev: Drain the suspend worker on retiring

On Thu, Jul 14, 2016 at 01:47:49PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > Since the suspend_work can arm itself if the console_lock() is currently > > held elsewhere, simply calling flush_work() doesn't guarantee that the > > work is idle upon return.

Re: [Intel-gfx] [PATCH 1/2] drm/i915/fbdev: Drain the suspend worker on retiring

On Thu, Jul 14, 2016 at 04:45:52PM +0200, Daniel Vetter wrote: > On Thu, Jul 14, 2016 at 01:47:49PM +0300, Mika Kuoppala wrote: > > Chris Wilson writes: > > > > > Since the suspend_work can arm itself if the console_lock() is currently > > > held elsewhere, simply

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbdev: Check for the framebuffer before use

On Wed, Jul 13, 2016 at 06:34:45PM +0100, Chris Wilson wrote: > If the fbdev probing fails, and in our error path we fail to clear the > dev_priv->fbdev, then we can try and use a dangling fbdev pointer, and > in particular a NULL fb. This could also happen in pathological cases > where we try to

Re: [Intel-gfx] [PATCH] drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL

On Wed, Jul 13, 2016 at 04:32:03PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Bspec tells us to keep bashing the PCU for up to 3ms when trying to > inform it about an upcoming change in the cdclk frequency. Currently > we only keep at it

Re: [Intel-gfx] [PATCH 3/6] drm/i915/huc: Add HuC fw loading support

On Thu, 14 Jul 2016, Daniel Vetter wrote: On Wed, Jul 13, 2016 at 03:52:39PM +0100, Peter Antoine wrote: On Wed, 13 Jul 2016, Daniel Vetter wrote: On Thu, Jun 23, 2016 at 02:52:41PM +0100, Peter Antoine wrote: On Thu, 23 Jun 2016, Dave Gordon wrote: On 22/06/16 09:31, Daniel Vetter wrote:

Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Thu, Jul 14, 2016 at 02:39:54PM +0100, Chris Wilson wrote: > On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote: > > The biggest reason I had against going the sw_sync only route was that > > vgem should provide unprivileged fences and that through the bookkeeping > > in vgem we can

Re: [Intel-gfx] [PATCH 3/6] drm/i915/huc: Add HuC fw loading support

On 14/07/16 15:16, Daniel Vetter wrote: On Wed, Jul 13, 2016 at 03:52:39PM +0100, Peter Antoine wrote: On Wed, 13 Jul 2016, Daniel Vetter wrote: On Thu, Jun 23, 2016 at 02:52:41PM +0100, Peter Antoine wrote: On Thu, 23 Jun 2016, Dave Gordon wrote: On 22/06/16 09:31, Daniel Vetter wrote: No,

Re: [Intel-gfx] [PATCH] drm/i915: Acquire intel_runtime_pm for HD-Audio registers

On Wed, Jul 13, 2016 at 05:01:02PM +0300, Marius Vlad wrote: > Did try when you submitted the patch...but can't seem to replicate with > latest nightly on other SKLs, and currently do not have access on > the machine that caused it. So fwiw, Hans de Geode confirmed that only reverting

Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote: > On Thu, Jul 14, 2016 at 02:40:59PM +0200, Daniel Vetter wrote: > > On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote: > > > On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote: > > > > On Thu, Jul 14, 2016 at

Re: [Intel-gfx] [PATCH 1/5] drm/i915: unify first-stage engine struct setup

On Wed, Jul 13, 2016 at 02:24:06PM +0100, Tvrtko Ursulin wrote: > > On 13/07/16 14:16, Tvrtko Ursulin wrote: > > > > On 13/07/16 13:23, Daniel Vetter wrote: > > > On Fri, Jul 01, 2016 at 05:47:11PM +0100, Tvrtko Ursulin wrote: > > > > From: Dave Gordon > > > > > > > >

Re: [Intel-gfx] [PATCH 3/6] drm/i915/huc: Add HuC fw loading support

On Thu, Jul 14, 2016 at 03:08:41PM +0100, Dave Gordon wrote: > On 13/07/16 13:48, Daniel Vetter wrote: > > On Thu, Jun 23, 2016 at 02:52:41PM +0100, Peter Antoine wrote: > > > On Thu, 23 Jun 2016, Dave Gordon wrote: > > > > On 22/06/16 09:31, Daniel Vetter wrote: > > > > No, the *correct* fix is

Re: [Intel-gfx] [PATCH 3/6] drm/i915/huc: Add HuC fw loading support

On Wed, Jul 13, 2016 at 03:52:39PM +0100, Peter Antoine wrote: > On Wed, 13 Jul 2016, Daniel Vetter wrote: > > > On Thu, Jun 23, 2016 at 02:52:41PM +0100, Peter Antoine wrote: > > > On Thu, 23 Jun 2016, Dave Gordon wrote: > > > > On 22/06/16 09:31, Daniel Vetter wrote: > > > > No, the *correct*

[Intel-gfx] [PATCH] drm/i915: Remove misleading CSR firmware loading docs

I forgot to remove these when reworking the firmware loading sequence last year. The new sequence is that we load firmware, and if it's not there we entirely (and permanently) fail dmc setup. Reported-by: Dave Gordon Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [PATCH] drm/i915: Move hangcheck reset from out of the engines into the GPU reset

On Thu, Jul 14, 2016 at 04:59:56PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > Let's not reset the hangcheck as a side-effect of initialising the > > engine, but as part of our GPU reset. > > > > I think TDR will need both the init and the reset. It

Re: [Intel-gfx] [PATCH 3/6] drm/i915/huc: Add HuC fw loading support

On 13/07/16 13:48, Daniel Vetter wrote: On Thu, Jun 23, 2016 at 02:52:41PM +0100, Peter Antoine wrote: On Thu, 23 Jun 2016, Dave Gordon wrote: On 22/06/16 09:31, Daniel Vetter wrote: No, the *correct* fix is to unify all the firmware loaders we have. There should just be ONE piece of code that

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Defer enabling rc6 til after we submit the first batch/context

On Thu, Jul 14, 2016 at 04:56:50PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > Some hardware requires a valid render context before it can initiate > > rc6 power gating of the GPU; the default state of the GPU is not > > sufficient and may lead to undefined

[Intel-gfx] [CI resend 1/2] drm/i915: compile-time consistency check on __EXEC_OBJECT flags

Two different sets of flag bits are stored in the 'flags' member of a 'struct drm_i915_gem_exec_object2', and they're defined in two different source files, increasing the risk of an accidental clash. Some flags in this field are supplied by the user; these are defined in i915_drm.h, and they

Re: [Intel-gfx] [PATCH 2/2] drm/i915: refactor eb_get_batch()

On Thu, Jul 14, 2016 at 02:12:55PM +0100, Dave Gordon wrote: > On 13/07/16 13:44, Chris Wilson wrote: > >On Wed, Jul 13, 2016 at 02:38:16PM +0200, Daniel Vetter wrote: > >>On Thu, Jun 30, 2016 at 04:12:49PM +0100, Dave Gordon wrote: > >>>Precursor for fix to secure batch execution. We will need to

Re: [Intel-gfx] [PATCH] drm/i915: Move hangcheck reset from out of the engines into the GPU reset

Chris Wilson writes: > Let's not reset the hangcheck as a side-effect of initialising the > engine, but as part of our GPU reset. > I think TDR will need both the init and the reset. -Mika > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Defer enabling rc6 til after we submit the first batch/context

Chris Wilson writes: > Some hardware requires a valid render context before it can initiate > rc6 power gating of the GPU; the default state of the GPU is not > sufficient and may lead to undefined behaviour. The first execution of > any batch will load the "golden

[Intel-gfx] [CI resend 2/2] drm/i915: refactor eb_get_batch()

Precursor for fix to secure batch execution. We will need to be able to retrieve the batch VMA (as well as the batch itself) from the eb list, so this patch extracts that part of eb_get_batch() into a separate function, and moves both parts to a more logical place in the file, near where the eb

Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Thu, Jul 14, 2016 at 02:23:04PM +0100, Chris Wilson wrote: > The biggest reason I had against going the sw_sync only route was that > vgem should provide unprivileged fences and that through the bookkeeping > in vgem we can keep them safe, ensure that we don't leak random buffers > or fences.

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/guc: Protect against HAS_GUC_* returning true values other than one (rev4)

On 13/07/16 14:38, Patchwork wrote: == Series Details == Series: drm/i915/guc: Protect against HAS_GUC_* returning true values other than one (rev4) URL : https://patchwork.freedesktop.org/series/9473/ State : warning == Summary == Series 9473v4 drm/i915/guc: Protect against HAS_GUC_*

Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Thu, Jul 14, 2016 at 02:40:59PM +0200, Daniel Vetter wrote: > On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote: > > On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote: > > > On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote: > > > > On Thu, Jul 14, 2016 at

Re: [Intel-gfx] [PATCH] Revert "drm: Resurrect atomic rmfb code"

On Thu, Jul 14, 2016 at 03:16:34PM +0200, Daniel Vetter wrote: > This reverts commit 11c21e73f848844d439cbccb42a1018b8c560e5c. > > For reasons totally unclear this manages to wreak havoc with the audio > rpm refcount: > > [ cut here ] > WARNING: CPU: 0 PID: 215 at

[Intel-gfx] [PATCH] Revert "drm: Resurrect atomic rmfb code"

This reverts commit 11c21e73f848844d439cbccb42a1018b8c560e5c. For reasons totally unclear this manages to wreak havoc with the audio rpm refcount: [ cut here ] WARNING: CPU: 0 PID: 215 at drivers/gpu/drm/i915/intel_runtime_pm.c:1729 intel_display_power_put+0xe8/0x100

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: remove superfluous i915_gem_object_free_mmap_offset call

Merged, thanks for the patch and review. Regards, Joonas On to, 2016-07-14 at 13:14 +0100, Matthew Auld wrote: > On 5 July 2016 at 14:21, Patchwork wrote: > > > > == Series Details == > > > > Series: drm/i915: remove superfluous

Re: [Intel-gfx] [PATCH 2/2] drm/i915: refactor eb_get_batch()

On 13/07/16 13:44, Chris Wilson wrote: On Wed, Jul 13, 2016 at 02:38:16PM +0200, Daniel Vetter wrote: On Thu, Jun 30, 2016 at 04:12:49PM +0100, Dave Gordon wrote: Precursor for fix to secure batch execution. We will need to be able to retrieve the batch VMA (as well as the batch itself) from

Re: [Intel-gfx] [PATCH] drm/i915: Ignore panel type from OpRegion on SKL

On Tue, Jul 12, 2016 at 03:00:37PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Dell XPS 13 9350 apparently doesn't like it when we use the panel type > from OpRegion. The OpRegion panel type (0) tells us to use use low > vswing for eDP,

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Ignore panel type from OpRegion on SKL

On Tue, Jul 12, 2016 at 01:12:20PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Ignore panel type from OpRegion on SKL > URL : https://patchwork.freedesktop.org/series/9752/ > State : warning > > == Summary == > > Series 9752v1 drm/i915: Ignore panel type from OpRegion

Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote: > On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote: > > On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote: > > > On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote: > > > > vGEM buffers are useful for

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Move hangcheck reset from out of the engines into the GPU reset

== Series Details == Series: drm/i915: Move hangcheck reset from out of the engines into the GPU reset URL : https://patchwork.freedesktop.org/series/9871/ State : failure == Summary == Series 9871v1 drm/i915: Move hangcheck reset from out of the engines into the GPU reset

[Intel-gfx] drm-intel.git Committers: Reminder about tagging bugfixes

Hi all, Apparently this wasn't known to everyone, hence this small reminder about correctly tagging bugfixes when pushing them: - add a Bugzilla: or References: link for any bug reported anywhere (bugzilla or mailing list). Also add Reported-by:/Tested-by: for credits. - add Fixes: if it's a

Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Thu, Jul 14, 2016 at 11:11:02AM +0100, Chris Wilson wrote: > So one solution would be to make vgem fences automatically timeout (with > a flag for root to override for the sake of testing hang detection). diff --git a/drivers/gpu/drm/vgem/vgem_fence.c b/drivers/gpu/drm/vgem/vgem_fence.c index

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: remove superfluous i915_gem_object_free_mmap_offset call

On 5 July 2016 at 14:21, Patchwork wrote: > == Series Details == > > Series: drm/i915: remove superfluous i915_gem_object_free_mmap_offset call > URL : https://patchwork.freedesktop.org/series/9516/ > State : failure > > == Summary == > > Series 9516v1

[Intel-gfx] [PATCH] drm/i915: Move hangcheck reset from out of the engines into the GPU reset

Let's not reset the hangcheck as a side-effect of initialising the engine, but as part of our GPU reset. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Arun Siluvery Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 1/5] drm/i915: unify first-stage engine struct setup

On 13/07/16 14:16, Tvrtko Ursulin wrote: On 13/07/16 13:23, Daniel Vetter wrote: On Fri, Jul 01, 2016 at 05:47:11PM +0100, Tvrtko Ursulin wrote: From: Dave Gordon [snip] { -const struct logical_ring_info *info = _rings[id]; +const struct engine_info

Re: [Intel-gfx] [PACTH i-g-t] lib/igt_kms: Fix different order of properties and their name strings

Applied. Thanks! On Mon, Jul 11, 2016 at 03:54:12PM -0400, Robert Foss wrote: > This is a reminder of this series. > > On 2016-06-29 07:22 AM, robert.f...@collabora.com wrote: > >From: Robert Foss > > > >igt_crtc_prop_names and igt_atomic_crtc_properties have different

Re: [Intel-gfx] [PATCH 1/2] drm/i915/fbdev: Drain the suspend worker on retiring

Chris Wilson writes: > Since the suspend_work can arm itself if the console_lock() is currently > held elsewhere, simply calling flush_work() doesn't guarantee that the > work is idle upon return. To do so requires using cancel_work_sync(). > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH igt 01/17] lib: Start weaning off defunct intel_chipset.h

On Thu, Jul 14, 2016 at 11:31:08AM +0100, Emil Velikov wrote: > On 13 July 2016 at 14:34, Chris Wilson wrote: > > On Wed, Jul 13, 2016 at 02:40:49PM +0200, Daniel Vetter wrote: > >> On Wed, Jun 29, 2016 at 12:38:51PM +0100, Chris Wilson wrote: > >> > Several years ago we

[Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

Required by commit 2603b98ca (aubdump: Support softpin bos). Signed-off-by: Marius Vlad CC: Kristian Høgsberg Kristensen --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac

Re: [Intel-gfx] [PATCH igt 01/17] lib: Start weaning off defunct intel_chipset.h

On 13 July 2016 at 14:34, Chris Wilson wrote: > On Wed, Jul 13, 2016 at 02:40:49PM +0200, Daniel Vetter wrote: >> On Wed, Jun 29, 2016 at 12:38:51PM +0100, Chris Wilson wrote: >> > Several years ago we made the plan of only having one canonical source >> > for

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Define a separate variable and control for RPS waitboost frequency

Chris Wilson writes: > To allow the user finer control over waitboosting, allow them to set the > frequency we request for the boost. This also them allows to effectively > disable the boosting by setting the boost request to a low frequency. > > Signed-off-by: Chris

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/7] drm/i915: unify first-stage engine struct setup

On 13/07/16 16:57, Patchwork wrote: == Series Details == Series: series starting with [1/7] drm/i915: unify first-stage engine struct setup URL : https://patchwork.freedesktop.org/series/9821/ State : success == Summary == Series 9821v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Thu, Jul 14, 2016 at 10:59:04AM +0100, Chris Wilson wrote: > On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote: > > On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote: > > > vGEM buffers are useful for passing data between software clients and > > > hardware renders. By

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Move common engine setup into intel_engine_cs.c

On Thu, Jul 14, 2016 at 10:25:39AM +0100, Tvrtko Ursulin wrote: > > On 13/07/16 17:04, Chris Wilson wrote: > >On Wed, Jul 13, 2016 at 04:03:40PM +0100, Tvrtko Ursulin wrote: > >>+ /* > >>+* Catch failures to update intel_engines table when the new engines > >>+* are added to the driver

Re: [Intel-gfx] [PATCH 1/7] drm/i915: unify first-stage engine struct setup

On Thu, Jul 14, 2016 at 10:19:16AM +0100, Tvrtko Ursulin wrote: > > On 13/07/16 17:01, Chris Wilson wrote: > >On Wed, Jul 13, 2016 at 04:03:35PM +0100, Tvrtko Ursulin wrote: > >>From: Dave Gordon > >> > >>intel_lrc.c has a table of "logical rings" (meaning engines),

Re: [Intel-gfx] [PATCH 50/64] drm/i915: Prepare i915_gem_active for annotations

On Thu, Jul 14, 2016 at 10:32:05AM +0100, Tvrtko Ursulin wrote: > > On 13/07/16 16:58, Chris Wilson wrote: > >On Wed, Jul 13, 2016 at 04:40:03PM +0100, Tvrtko Ursulin wrote: > > [snip] > > >>> } else { > >>> for (i = 0; i < I915_NUM_ENGINES; i++) { > >>> struct

Re: [Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

On Thu, Jul 14, 2016 at 10:12:17AM +0200, Daniel Vetter wrote: > On Thu, Jul 14, 2016 at 08:04:19AM +0100, Chris Wilson wrote: > > vGEM buffers are useful for passing data between software clients and > > hardware renders. By allowing the user to create and attach fences to > > the exported vGEM

Re: [Intel-gfx] [PATCH 50/64] drm/i915: Prepare i915_gem_active for annotations

On 13/07/16 16:58, Chris Wilson wrote: On Wed, Jul 13, 2016 at 04:40:03PM +0100, Tvrtko Ursulin wrote: [snip] } else { for (i = 0; i < I915_NUM_ENGINES; i++) { struct drm_i915_gem_request *req; - req =

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Move common engine setup into intel_engine_cs.c

On 13/07/16 17:04, Chris Wilson wrote: On Wed, Jul 13, 2016 at 04:03:40PM +0100, Tvrtko Ursulin wrote: + /* +* Catch failures to update intel_engines table when the new engines +* are added to the driver by a warning and disabling the forgotten +* engines. +

Re: [Intel-gfx] [PATCH 1/7] drm/i915: unify first-stage engine struct setup

On 13/07/16 17:01, Chris Wilson wrote: On Wed, Jul 13, 2016 at 04:03:35PM +0100, Tvrtko Ursulin wrote: From: Dave Gordon intel_lrc.c has a table of "logical rings" (meaning engines), while intel_ringbuffer.c has separately open-coded initialisation for each engine.

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

> -Original Message- > From: Deak, Imre > Sent: Friday, July 1, 2016 21:40 > To: intel-gfx@lists.freedesktop.org > Cc: Ville Syrjälä ; Chris Wilson wilson.co.uk>; Yang, Rong R ; Zhao, Yakui > ;

[Intel-gfx] [PULL] topic/drm-misc

Hi Dave, I recovered dri-devel backlog from my vacation, more misc stuff: - of_put_node fixes from Peter Chen (not all yet) - more patches from Gustavo to use kms-native drm_crtc_vblank_* funcs - docs sphinxification from Lukas Wunner - bunch of fixes all over from Dan Carpenter - more follow up

[Intel-gfx] [PULL] drm-intel-next

Hi Dave, drm-intel-next-2016-07-11: - select igt testing depencies for CONFIG_DRM_I915_DEBUG (Chris) - track outputs in crtc state and clean up all our ad-hoc connector/encoder walking in modest code (Ville) - demidlayer drm_device/drm_i915_private (Chris Wilson) - thundering herd fix from

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Flush GT idle status upon reset

On Thu, Jul 14, 2016 at 10:53:20AM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-13 at 09:10 +0100, Chris Wilson wrote: > > Upon resetting the GPU, we force the engines to be idle by clearing > > their request lists. However, I neglected to clear the GT active status > > and so the next request

Re: [Intel-gfx] [PATCH 1/8] drm/i915: Flush GT idle status upon reset

On ke, 2016-07-13 at 09:10 +0100, Chris Wilson wrote: > Upon resetting the GPU, we force the engines to be idle by clearing > their request lists. However, I neglected to clear the GT active status > and so the next request following the reset was not marking the device > as busy again. (We had to

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: set proper N/M in modeset

== Series Details == Series: drm/i915: set proper N/M in modeset URL : https://patchwork.freedesktop.org/series/9857/ State : failure == Summary == Series 9857v1 drm/i915: set proper N/M in modeset http://patchwork.freedesktop.org/api/1.0/series/9857/revisions/1/mbox Test

[Intel-gfx] [PATCH] drm/i915: set proper N/M in modeset

From: Libin Yang When modeset occurs and the LS_CLK is set to some special values in DP mode, the N/M need to be set manually if audio is playing. Also, the patch applies commit 7e8275c2f2bb ("drm/i915: set proper N/CTS in modeset") to APL platform. Signed-off-by:

[Intel-gfx] [PATCH v3] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

vGEM buffers are useful for passing data between software clients and hardware renders. By allowing the user to create and attach fences to the exported vGEM buffers (on the dma-buf), the user can implement a deferred renderer and queue hardware operations like flipping and then signal the buffer