Re: [Intel-gfx] [PATCH v2 0/7] Add Y-tiling support into IGTs

HI Paulo, On Sat, Apr 29, 2017 at 12:51 AM, Paulo Zanoni wrote: > Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu: >> This series adds Y-tiled buffer creation support into IGT libraries >> and >> goes on to use this capability to add support into FBC tests

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: New vfunc prepare_request

== Series Details == Series: drm/i915: New vfunc prepare_request URL : https://patchwork.freedesktop.org/series/23727/ State : success == Summary == Series 23727v1 drm/i915: New vfunc prepare_request https://patchwork.freedesktop.org/api/1.0/series/23727/revisions/1/mbox/ fi-bdw-5557u

[Intel-gfx] [PATCH] drm/i915: New vfunc prepare_request

This will be more useful later to support platforms that need to emit HW commands at the beginning of every request (more general than emitting things at the beginning of every batchbuffer, which is already covered by emit_bb_start). Cc: Chris Wilson Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 12/67] drm/i915/cnl: Introduce initial Cannonlake Workarounds.

On 04/06/2017 07:15 PM, Rodrigo Vivi wrote: Let's inherit workarounds from previous platforms that according to wa_database and BSpec are still valid for Cannonlake. v2: Add missed workarounds. v3: Rebase Cc: Mika Kuoppala Signed-off-by: Rodrigo Vivi

[Intel-gfx] ✓ Fi.CI.BAT: success for Adding driver-private objects to atomic state (rev3)

== Series Details == Series: Adding driver-private objects to atomic state (rev3) URL : https://patchwork.freedesktop.org/series/23308/ State : success == Summary == Series 23308v3 Adding driver-private objects to atomic state

[Intel-gfx] [PATCH v8 4/4] drm/dp: Track MST link bandwidth

From: "Pandiyan, Dhinakaran" Use the added helpers to track MST link bandwidth for atomic modesets. Link bw is acquired in the ->atomic_check() phase when CRTCs are being enabled with drm_atomic_find_vcpi_slots(). Similarly, link bw is released during

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Hi Chris, I tried this but I still see tests are failing. I wanted to debug it little further to find a specific condition where clflush is missing but didn't have enough time. I will look into this early next week. Thanks On Thu, Apr 27, 2017 at 03:46:42PM +0100, Chris Wilson wrote: >

Re: [Intel-gfx] [PATCH v7 03/20] drm/i915: Add support for per engine reset recovery

On 4/27/2017 4:50 PM, Chris Wilson wrote: -static void engine_retire_requests(struct intel_engine_cs *engine) +void engine_retire_requests(struct intel_engine_cs *engine) Fortunately stray chunk. I was about to scream. This chunk has been there for quite a long time, at least since v4...

Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Friday, April 28, 2017 05:16:02 PM Imre Deak wrote: > Some drivers - like i915 - may not support the system suspend direct > complete optimization due to differences in their runtime and system > suspend sequence. Add a flag that when set resumes the device before > calling the driver's system

[Intel-gfx] [PATCH] tools/null_state_gen: Add GEN10 golden context batch buffer creation

This batchbuffer is over 4096 bytes, so we need to increase the size of the array (and the KMD has to be modified to deal with more than one page). Notice that there to workarounds embedded here, both applicable to all CNL steppings. v2: WaPSRandomCSNotDone is not A0 only (as per the latest

Re: [Intel-gfx] [alsa-devel] [PATCH v2 11/11] ALSA: x86: Register multiple PCM devices for the LPE audio card

A quick bisect tells me this last patch looks problematic. I don't have time to look further into it today, hope this helps progress in finding the issue. This is on a CHT device with HDMI plugged in and DP left out unconnected for now. $ git bisect good

Re: [Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote: > > > On 04/28/2017 03:41 AM, Takashi Iwai wrote: > > On Thu, 27 Apr 2017 18:02:19 +0200, > > ville.syrj...@linux.intel.com wrote: > >> From: Ville Syrjälä > >> > >> Okay, here's the second

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/27] drm/i915/selftests: Allocate inode/file dynamically (rev6)

== Series Details == Series: series starting with [01/27] drm/i915/selftests: Allocate inode/file dynamically (rev6) URL : https://patchwork.freedesktop.org/series/23227/ State : success == Summary == Series 23227v6 Series without cover letter

Re: [Intel-gfx] [PATCH v2 0/7] Add Y-tiling support into IGTs

Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu: > This series adds Y-tiled buffer creation support into IGT libraries > and > goes on to use this capability to add support into FBC tests to use > Y-tiled buffers. The problem I reported before still happens to me. Please fix it before

[Intel-gfx] [PATCH v14] drm/i915: Squash repeated awaits on the same fence

Track the latest fence waited upon on each context, and only add a new asynchronous wait if the new fence is more recent than the recorded fence for that context. This requires us to filter out unordered timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the absence of a universal

Re: [Intel-gfx] [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 28/04/17 11:51 AM, Herbert Xu wrote: > On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote: >> >> >> On 28/04/17 12:30 AM, Herbert Xu wrote: >>> You are right. Indeed the existing code looks buggy as they >>> don't take sg->offset into account when doing the kmap. Could >>> you

Re: [Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

On 04/28/2017 03:41 AM, Takashi Iwai wrote: On Thu, 27 Apr 2017 18:02:19 +0200, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Okay, here's the second attempt at getting multiple pipes playing back audio on the VLV/CHV HDMI LPE audio device. The main

Re: [Intel-gfx] [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 28/04/17 12:30 AM, Herbert Xu wrote: > You are right. Indeed the existing code looks buggy as they > don't take sg->offset into account when doing the kmap. Could > you send me some patches that fix these problems first so that > they can be easily backported? Ok, I think the only buggy

Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote: > The new batchbuffer for CNL surpasses the 4096 byte mark. > > Cc: Mika Kuoppala > Cc: Ben Widawsky > Signed-off-by: Oscar Mateo Evil, 4k+ of nothing-ness that

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow null render state batchbuffers bigger than one page

== Series Details == Series: drm/i915: Allow null render state batchbuffers bigger than one page URL : https://patchwork.freedesktop.org/series/23713/ State : success == Summary == Series 23713v1 drm/i915: Allow null render state batchbuffers bigger than one page

[Intel-gfx] [PATCH 2/2] tools/null_state_gen: Add GEN10 golden context batch buffer creation

This batchbuffer is over 4096 bytes, so we need to increase the size of the array (and the KMD has to be modified to deal with more than one page). Notice that there to workarounds embedded here: - WaRsGatherPoolEnable is to be applied to all CNL steppings, so it belongs here. -

[Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

The new batchbuffer for CNL surpasses the 4096 byte mark. Cc: Mika Kuoppala Cc: Ben Widawsky Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_gem_render_state.c | 40 +++- 1 file changed, 21

[Intel-gfx] [PATCH 1/2] tools/null_state_gen: Automatically generate the copyright header

Last bit to make the generated files directly usable in i915. Cc: Mika Kuoppala Signed-off-by: Oscar Mateo --- tools/null_state_gen/intel_null_state_gen.c | 41 + 1 file changed, 41 insertions(+) diff --git

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

== Series Details == Series: series starting with [v3,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization URL : https://patchwork.freedesktop.org/series/23707/ State : success == Summary == Series 23707v1 Series without cover letter

Re: [Intel-gfx] [PATCH v7 12/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

On 4/27/2017 4:58 PM, Chris Wilson wrote: On Thu, Apr 27, 2017 at 04:12:52PM -0700, Michel Thierry wrote: +#define WA_REG_WR_GUC_RESTORE(addr, val) do { \ + const int r = guc_wa_add(dev_priv, (addr), (val)); \ + if (r) \ + return r; \ +

Re: [Intel-gfx] [PATCH] drm/i915/guc: Enable send function only after successful init

On 28/04/17 06:30, Michal Wajdeczko wrote: It is safer to setup valid send function after successful GuC hardware initialization. In addition we prepare placeholder where we can setup any alternate GuC communication mechanism. Signed-off-by: Michal Wajdeczko Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/27] drm/i915/selftests: Allocate inode/file dynamically (rev5)

== Series Details == Series: series starting with [01/27] drm/i915/selftests: Allocate inode/file dynamically (rev5) URL : https://patchwork.freedesktop.org/series/23227/ State : success == Summary == Series 23227v5 Series without cover letter

[Intel-gfx] [PATCH v2 6/7] igt/kms_frontbuffer_tracking: Add Y-tiling support

Allow tests to create Y-tiled bufferes using a separate argument to the test without increasing the number of subtests. v2: Changed tiling option to string (Paulo) Signed-off-by: Praveen Paneri --- tests/kms_frontbuffer_tracking.c | 48

[Intel-gfx] [PATCH v2 7/7] igt/kms_fbc_crc.c : Add Y-tile tests

Now that we have support for Y-tiled buffers, add another iteration of tests for Y-tiled buffers. Signed-off-by: Praveen Paneri --- tests/kms_fbc_crc.c | 71 + 1 file changed, 39 insertions(+), 32 deletions(-) diff

[Intel-gfx] [PATCH v2 3/7] lib/igt_draw: Add Y-tiling support

This patch adds Y-tiling support for igt_draw_rect function. v2: Use helper function to get tile sizes (Ville) Signed-off-by: Praveen Paneri --- lib/igt_draw.c | 132 + 1 file changed, 87 insertions(+), 45

[Intel-gfx] [PATCH v2 4/7] lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method

From: Akash Goel v2: Moved identical code into a single function (Paulo) Signed-off-by: Akash Goel Signed-off-by: Praveen Paneri --- lib/igt_draw.c | 33 + 1 file changed, 33 insertions(+)

[Intel-gfx] [PATCH v2 5/7] tests/kms_draw_crc: add support for Y tiling

From: Paulo Zanoni This is the program that's supposed to test lib/igt_draw. We just added Y tiling support for the library, so add the tests now. Signed-off-by: Paulo Zanoni Signed-off-by: Praveen Paneri ---

[Intel-gfx] [PATCH v2 2/7] lib/igt_fb: Add helper function for tile_to_mod

igt_get_fb_tile_size function takes modifer as an argument This helper function will let users to convert tiling to modifier and use igt_get_fb_tile_size() Signed-off-by: Praveen Paneri --- lib/igt_fb.c | 26 ++ lib/igt_fb.h | 1 + 2 files

[Intel-gfx] [PATCH v2 0/7] Add Y-tiling support into IGTs

This series adds Y-tiled buffer creation support into IGT libraries and goes on to use this capability to add support into FBC tests to use Y-tiled buffers. Akash Goel (1): lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method Paulo Zanoni (1): tests/kms_draw_crc: add support for Y

[Intel-gfx] [PATCH v2 1/7] lib/igt_fb: Let others use igt_get_fb_tile_size

This function can be used by igt_draw to get accurate tile dimensions for all tile formats. v2: Added comments to function igt_get_fb_tile_size (Daniel) Signed-off-by: Praveen Paneri --- lib/igt_fb.c | 16 +--- lib/igt_fb.h | 3 ++- 2 files changed, 15

Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

On Fri, 2017-04-28 at 12:44 +, Chauhan, Madhav wrote: > > -Original Message- > > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] > > Sent: Friday, April 28, 2017 2:28 PM > > To: Chauhan, Madhav ; intel- > > g...@lists.freedesktop.org > > Cc:

[Intel-gfx] [PATCH v3 2/2] drm/i915: Prevent the system suspend complete optimization

Since commit bac2a909a096c9110525c18cbb8ce73c660d5f71 Author: Rafael J. Wysocki Date: Wed Jan 21 02:17:42 2015 +0100 PCI / PM: Avoid resuming PCI devices during system suspend PCI devices will default to allowing the system suspend complete optimization where

[Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

Some drivers - like i915 - may not support the system suspend direct complete optimization due to differences in their runtime and system suspend sequence. Add a flag that when set resumes the device before calling the driver's system suspend handlers which effectively disables the optimization.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Enable send function only after successful init

== Series Details == Series: drm/i915/guc: Enable send function only after successful init URL : https://patchwork.freedesktop.org/series/23702/ State : success == Summary == Series 23702v1 drm/i915/guc: Enable send function only after successful init

[Intel-gfx] [PATCH v13] drm/i915: Squash repeated awaits on the same fence

Track the latest fence waited upon on each context, and only add a new asynchronous wait if the new fence is more recent than the recorded fence for that context. This requires us to filter out unordered timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the absence of a universal

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Enable send function only after successful init

Hi, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Patchwork > Sent: Friday, April 28, 2017 4:50 PM > To: Wajdeczko, Michal > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✗ Fi.CI.BAT:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Enable send function only after successful init

== Series Details == Series: drm/i915/guc: Enable send function only after successful init URL : https://patchwork.freedesktop.org/series/23702/ State : failure == Summary == Series 23702v1 drm/i915/guc: Enable send function only after successful init

[Intel-gfx] [PATCH] drm/i915/guc: Enable send function only after successful init

It is safer to setup valid send function after successful GuC hardware initialization. In addition we prepare placeholder where we can setup any alternate GuC communication mechanism. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

> -Original Message- > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] > Sent: Friday, April 28, 2017 2:28 PM > To: Chauhan, Madhav ; intel- > g...@lists.freedesktop.org > Cc: Deepak M ; Nikula, Jani ; >

Re: [Intel-gfx] [PATCH 13/27] drm/i915/execlists: Pack the count into the low bits of the port.request

On Fri, Apr 28, 2017 at 01:02:25PM +0100, Tvrtko Ursulin wrote: > > On 27/04/2017 15:37, Chris Wilson wrote: > >On Thu, Apr 20, 2017 at 03:58:19PM +0100, Tvrtko Ursulin wrote: > >>>static void record_context(struct drm_i915_error_context *e, > >>>diff --git

Re: [Intel-gfx] [PATCH 16/27] drm/i915: Reinstate reservation_object zapping for batch_pool objects

On 19/04/2017 10:41, Chris Wilson wrote: I removed the zapping of the reservation_object->fence array of shared fences prematurely. We don't yet have the code to zap that array when retiring the object, and so currently it remains possible to continually grow the shared array trapping requests

Re: [Intel-gfx] [PATCH 13/27] drm/i915/execlists: Pack the count into the low bits of the port.request

On 27/04/2017 15:37, Chris Wilson wrote: On Thu, Apr 20, 2017 at 03:58:19PM +0100, Tvrtko Ursulin wrote: static void record_context(struct drm_i915_error_context *e, diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index

Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Read link status after exit link training

On 28/04/2017 10:58, Lee, Shawn C wrote: From: "Lee, Shawn C" Display driver read DPCD register 0x202, 0x203 and 0x204 to identify eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source read these registers at the same time. Panel will report EQ & symbol

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: dma-buf support for GVT-g

== Series Details == Series: drm/i915/gvt: dma-buf support for GVT-g URL : https://patchwork.freedesktop.org/series/23686/ State : success == Summary == Series 23686v1 drm/i915/gvt: dma-buf support for GVT-g https://patchwork.freedesktop.org/api/1.0/series/23686/revisions/1/mbox/ Test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: Read link status after exit PSR (rev2)

== Series Details == Series: drm/i915/edp: Read link status after exit PSR (rev2) URL : https://patchwork.freedesktop.org/series/23631/ State : success == Summary == Series 23631v2 drm/i915/edp: Read link status after exit PSR

Re: [Intel-gfx] [PATCH] drm/i915/edp: Read link status after exit PSR

On Fri, Apr 28, 2017 at 03:08:53AM +, Lee, Shawn C wrote: > > > -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Thursday, April 27, 2017 10:39 PM > To: Lee, Shawn C > Cc: intel-gfx@lists.freedesktop.org; Chiou, Cooper

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

== Series Details == Series: drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages URL : https://patchwork.freedesktop.org/series/23680/ State : success == Summary == Series 23680v1 drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

== Series Details == Series: drm/i915: Do not leak dev_priv->l3_parity.remap_info[] URL : https://patchwork.freedesktop.org/series/23679/ State : success == Summary == Series 23679v1 drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

On Fri, Apr 28, 2017 at 10:55:09AM +0100, Tvrtko Ursulin wrote: > > On 28/04/2017 08:41, Chris Wilson wrote: > > [snip] > > >+static int igt_sync(void *arg) > >+{ > >+const struct { > >+const char *name; > >+u32 seqno; > >+bool expected; > >+

Re: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g

On Fri, Apr 28, 2017 at 05:35:29PM +0800, Xiaoguang Chen wrote: > dmabuf for GVT-g can be exported to users who can use the dmabuf to show > the desktop of vm which use intel vgpu. > > Currently we provide query and create new dmabuf operations. > > Users of dmabuf can cache some created dmabufs

Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

On 28/04/2017 08:41, Chris Wilson wrote: [snip] +static int igt_sync(void *arg) +{ + const struct { + const char *name; + u32 seqno; + bool expected; + bool set; + } pass[] = { + { "unset", 0, false, false }, +

Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

On Fri, Apr 28, 2017 at 10:32:58AM +0100, Tvrtko Ursulin wrote: > > On 28/04/2017 08:41, Chris Wilson wrote: > >Track the latest fence waited upon on each context, and only add a new > >asynchronous wait if the new fence is more recent than the recorded > >fence for that context. This requires us

[Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

GVT-g will create an anonymous fd and a vfio device region to deliver the fd to QEMU. QEMU can do ioctl using this fd to query/generate dmabuf on an intel vgpu. Signed-off-by: Xiaoguang Chen --- drivers/gpu/drm/i915/gvt/gvt.c | 2 + drivers/gpu/drm/i915/gvt/gvt.h

[Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g

dmabuf for GVT-g can be exported to users who can use the dmabuf to show the desktop of vm which use intel vgpu. Currently we provide query and create new dmabuf operations. Users of dmabuf can cache some created dmabufs and related information such as the framebuffer's address, size, tiling

[Intel-gfx] [RFC PATCH 1/6] drm/i915/gvt: extend the GVT-g architecture to support vfio device region

Signed-off-by: Xiaoguang Chen --- drivers/gpu/drm/i915/gvt/kvmgt.c | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 1ae0b40..3c6a02b 100644 ---

[Intel-gfx] [RFC PATCH 2/6] drm/i915/gvt: OpRegion support for GVT-g

OpRegion is needed to support display related operation for intel vgpu. A vfio device region is added to intel vgpu to deliver the host OpRegion information to user space so user space can construct the OpRegion for vgpu. Signed-off-by: Bing Niu Signed-off-by: Xiaoguang Chen

[Intel-gfx] [RFC PATCH 4/6] drm/i915: export i915 dmabuf_ops

GVT-g will use i915's dmabuf_ops to implement its own dmabuf so exporting it. Signed-off-by: Xiaoguang Chen --- drivers/gpu/drm/i915/i915_drv.h| 2 ++ drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [RFC PATCH 0/6] drm/i915/gvt: dma-buf support for GVT-g

This patch set adds the dma-buf support for intel GVT-g. dma-buf is a uniform mechanism to share DMA buffers across different devices and sub-systems. dma-buf for intel GVT-g is mainly used to share the vgpu's framebuffer to other users or sub-systems so they can use the dma-buf to show the

[Intel-gfx] [RFC PATCH 3/6] drm/i915/gvt: framebuffer decoder support for GVT-g

decode frambuffer attributes of primary, cursor and sprite plane Signed-off-by: Xiaoguang Chen --- drivers/gpu/drm/i915/gvt/Makefile | 3 +- drivers/gpu/drm/i915/gvt/display.c| 2 +- drivers/gpu/drm/i915/gvt/display.h| 2 +

Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

On 28/04/2017 08:41, Chris Wilson wrote: Track the latest fence waited upon on each context, and only add a new asynchronous wait if the new fence is more recent than the recorded fence for that context. This requires us to filter out unordered timelines, which are noted by

[Intel-gfx] [PATCH v2] drm/i915/edp: Read link status after exit link training

From: "Lee, Shawn C" Display driver read DPCD register 0x202, 0x203 and 0x204 to identify eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source read these registers at the same time. Panel will report EQ & symbol lock not done. It will cause panel display

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Sanitize engine context sizes

On pe, 2017-04-28 at 09:02 +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/4] drm/i915: Sanitize engine context sizes > URL   : https://patchwork.freedesktop.org/series/23678/ > State : success Pushed the series, thanks for the review. Regards, Joonas -- 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Sanitize engine context sizes

== Series Details == Series: series starting with [1/4] drm/i915: Sanitize engine context sizes URL : https://patchwork.freedesktop.org/series/23678/ State : success == Summary == Series 23678v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

On Fri, 2017-04-28 at 08:50 +, Chauhan, Madhav wrote: > > -Original Message- > > From: Conselvan De Oliveira, Ander > > Sent: Friday, April 28, 2017 1:32 PM > > To: intel-gfx@lists.freedesktop.org > > Cc: Conselvan De Oliveira, Ander ; > > Deepak

Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

> -Original Message- > From: Conselvan De Oliveira, Ander > Sent: Friday, April 28, 2017 1:32 PM > To: intel-gfx@lists.freedesktop.org > Cc: Conselvan De Oliveira, Ander ; > Deepak M ; Chauhan, Madhav > ;

Re: [Intel-gfx] [PATCH] drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

On Fri, Apr 28, 2017 at 10:58:39AM +0300, Joonas Lahtinen wrote: > Add intel_irq_fini() for placing the deinitialization code, > starting with freeing dev_priv->l3_parity.remap_info[]. > > Signed-off-by: Joonas Lahtinen > Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

On Thu, 27 Apr 2017 18:02:19 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > Okay, here's the second attempt at getting multiple pipes playing back > audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is > that now the PCM

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Report the ring->space from intel_ring_update_space()

On ke, 2017-04-26 at 09:37 +0100, Chris Wilson wrote: > Some callers immediately want to know the current ring->space after > calling intel_ring_update_space(), which we can freely provide via the > return parameter. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Fix sleep under spinlock during reset

Hi, > -Original Message- > On 12/04/2017 18:16, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [1/2] drm/i915/guc: Fix sleep under spinlock > > during > reset > > URL : https://patchwork.freedesktop.org/series/22937/ > > State : failure > > > > ==

Re: [Intel-gfx] [PATCH 02/11] ALSA: x86: Clear the pdata.notify_lpe_audio pointer before teardown

On Thu, 27 Apr 2017 18:02:21 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > Clear the notify function pointer in the platform data before we tear > down the driver. Otherwise i915 would end up calling a stale function > pointer and

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Fix runtime PM for LPE audio

On Thu, 27 Apr 2017 18:02:20 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > Not calling pm_runtime_enable() means that runtime PM can't be > enabled at all via sysfs. So we definitely need to call it > from somewhere. > > Calling it from

[Intel-gfx] [PATCH] drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

The sequence in glk_dsi_device_ready() enters ULPS then waits until it is *not* active to then disable it. The correct sequence according to the spec is to enter ULPS then wait until the GLK_ULPS_NOT_ACTIVE bit is zero, i.e., ULPS is active, and then disable ULPS. Fixing the codition gets rid of

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Fix sleep under spinlock during reset

On 12/04/2017 18:16, Patchwork wrote: == Series Details == Series: series starting with [1/2] drm/i915/guc: Fix sleep under spinlock during reset URL : https://patchwork.freedesktop.org/series/22937/ State : failure == Summary == Series 22937v1 Series without cover letter

Re: [Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

On Fri, Apr 28, 2017 at 08:41:36AM +0100, Chris Wilson wrote: > Track the latest fence waited upon on each context, and only add a new > asynchronous wait if the new fence is more recent than the recorded > fence for that context. This requires us to filter out unordered > timelines, which are

[Intel-gfx] [PATCH] drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

Add intel_irq_fini() for placing the deinitialization code, starting with freeing dev_priv->l3_parity.remap_info[]. Signed-off-by: Joonas Lahtinen Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala

[Intel-gfx] [PATCH 3/4] drm/i915: Reset ILK during GEM sanitization

ILK should survive a reset without display corruption. Suggested-by: Chris Wilson Signed-off-by: Joonas Lahtinen Cc: Chris Wilson Cc: Ville Syrjälä Reviewed-by: Chris Wilson

[Intel-gfx] [PATCH 4/4] drm/i915: Capture CCID on ILK

CCID register existed already on ILK according to the PRM (Chris verified the address to match too). Signed-off-by: Joonas Lahtinen Cc: Chris Wilson Cc: Ville Syrjälä Reviewed-by: Chris Wilson

[Intel-gfx] [PATCH 2/4] drm/i915: Eliminate HAS_HW_CONTEXTS

HAS_HW_CONTEXTS is misleading condition for GPU reset and CCID, replace it with Gen specific (to be updated in next patches). HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF match also has .has_hw_contexts = 1 set. This leads to us being able to get rid of the property

[Intel-gfx] [PATCH 1/4] drm/i915: Sanitize engine context sizes

Pre-calculate engine context size based on engine class and device generation and store it in the engine instance. v2: - Squash and get rid of hw_context_size (Chris) v3: - Move after MMIO init for probing on Gen7 and 8 (Chris) - Retained rounding (Tvrtko) v4: - Rebase for deferred legacy

[Intel-gfx] [PATCH v10] drm/i915: Squash repeated awaits on the same fence

Track the latest fence waited upon on each context, and only add a new asynchronous wait if the new fence is more recent than the recorded fence for that context. This requires us to filter out unordered timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the absence of a universal

Re: [Intel-gfx] [PATCH v7 13/20] drm/i915/guc: Rename the function that resets the GuC

On 28/04/2017 00:12, Michel Thierry wrote: intel_guc_reset sounds more like the microcontroller is the one performing a reset, while in this case is the opposite. intel_reset_guc not only makes it clearer, it follows the other intel_reset functions available. Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Fix sleep under spinlock during reset

On ke, 2017-04-12 at 16:48 +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Looks like intel_guc_reset had the ability to sleep under the > uncore spinlock since forever but it wasn't detected until the > recent changes annotated the wait for register with