Re: [Intel-gfx] [PATCH v2 08/16] drm/i915/guc: Update CT message header definition

On 07/08/17 09:14, Michal Wajdeczko wrote: Flags bits are different in G2H message. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Oscar Mateo Cc: Kelvin Gardiner

Re: [Intel-gfx] [PATCH 01/16] drm/i915: Keep a small stash of preallocated WC pages

On 26 July 2017 at 14:25, Chris Wilson wrote: > We use WC pages for coherent writes into the ppGTT on !llc > architectuures. However, to create a WC page requires a stop_machine(), architectures > i.e. is very slow. To compensate we currently keep a per-vm cache of >

Re: [Intel-gfx] [PATCH v2 15/16] drm/i915/guc: Trace messages from CT while in debug

On 07/08/17 09:14, Michal Wajdeczko wrote: During debug we may want to investigate all communication from the Guc. Add proper tracing macros in debug config. v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal) Signed-off-by: Michal Wajdeczko ---

Re: [Intel-gfx] [PATCH i-g-t] tests/perf: fix userspace configs issues on HSW

On 7 August 2017 at 18:20, Lionel Landwerlin wrote: > We don't have flex eu counters on HSW, so don't try to program for > thoses. > > Reported-by: CI \o/ > Fixes: 609cb5e30b4 ("tests/perf: add tests to verify create/destroy userspace > configs") > Signed-off-by:

Re: [Intel-gfx] [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation

On Mon, 7 Aug 2017 08:11:43 + "Zhang, Tina" wrote: > After going through the previous discussions, here are some summaries may be > related to the current discussion: > 1. How does user mode figure the device capabilities between region and > dma-buf? >

Re: [Intel-gfx] [PATCH] drm/i915: Clear lost context-switch interrupts across reset

On 8/7/2017 5:19 AM, Chris Wilson wrote: During a global reset, we disable the irq. As we disable the irq, the hardware may be raising a GT interrupt that we then ignore, leaving it pending in the GTIIR. After the reset, we then re-enable the irq, triggering the pending interrupt. However, that

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/perf: fix userspace configs issues on HSW

== Series Details == Series: tests/perf: fix userspace configs issues on HSW URL : https://patchwork.freedesktop.org/series/28463/ State : success == Summary == IGT patchset tested on top of latest successful build 79d6f77fa1ff33f198d954a3c7f1028322fcce52 tests/perf: follow up build fix with

Re: [Intel-gfx] [PATCH v4] i915: Add support for drm syncobjs

On Thu, Aug 3, 2017 at 11:58 AM, Chris Wilson wrote: > From: Jason Ekstrand > > This commit adds support for waiting on or signaling DRM syncobjs as > part of execbuf. It does so by hijacking the currently unused cliprects > pointer to instead

[Intel-gfx] [PATCH i-g-t] tests/perf: fix userspace configs issues on HSW

We don't have flex eu counters on HSW, so don't try to program for thoses. Reported-by: CI \o/ Fixes: 609cb5e30b4 ("tests/perf: add tests to verify create/destroy userspace configs") Signed-off-by: Lionel Landwerlin --- tests/perf.c | 29

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/psr: Clean-up intel_enable_source_psr1()

On Mon, Aug 07, 2017 at 08:55:00AM -0700, Jim Bride wrote: > On Fri, Aug 04, 2017 at 10:29:33AM +0300, Jani Nikula wrote: > > On Thu, 03 Aug 2017, Jim Bride wrote: > > > On Fri, Jul 14, 2017 at 12:34:28PM +0300, Jani Nikula wrote: > > >> On Wed, 12 Jul 2017, Chris

Re: [Intel-gfx] [PATCH v2 01/16] drm/i915/guc: Add support for data reporting in GuC responses

On 8/7/2017 9:14 AM, Michal Wajdeczko wrote: GuC may return additional data in the command status response. Format and meaning of this data is action specific. We will use this non-negative data as a new success return value. Currently used actions don't return data that way yet. v2: fix

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/renderstate: Sandybridge golden renderstate is b0rked

== Series Details == Series: drm/i915/renderstate: Sandybridge golden renderstate is b0rked URL : https://patchwork.freedesktop.org/series/28461/ State : success == Summary == Series 28461v1 drm/i915/renderstate: Sandybridge golden renderstate is b0rked

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit

On 8/7/2017 8:33 AM, Daniel Vetter wrote: On Thu, Aug 03, 2017 at 12:44:40PM -0700, Michel Thierry wrote: On 7/20/2017 10:57 AM, Daniel Vetter wrote: Blocking in a worker is ok, that's what the unbound_wq is for. And it unifies the paths between the blocking and nonblocking commit, giving me

Re: [Intel-gfx] [PATCH] drm/i915: add register macro definition style guide

good idea. On Mon, Aug 7, 2017 at 9:10 AM, Daniel Vetter wrote: > On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote: >> This is not to try to force a new style; this is my interpretation of >> what the most common existing style is. >> >> With hopes I don't need to

[Intel-gfx] [PATCH] drm/i915/renderstate: Sandybridge golden renderstate is b0rked

In the null state batch, we try to load the CC_STATE_POINTERS, but pass in a pointer to invalid state for the color-calc and depth-stencil state. In the rendercopy batch this was imported from, the 1024 offset used is known to be 64bytes of zeroes. Tweaking the gen6_null_state_batch to point those

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Support for Guc responses and requests

== Series Details == Series: drm/i915/guc: Support for Guc responses and requests URL : https://patchwork.freedesktop.org/series/28393/ State : failure == Summary == Series 28393v1 drm/i915/guc: Support for Guc responses and requests

Re: [Intel-gfx] [PATCH i-g-t] lib: don't hang on blt on snb

Quoting Daniel Vetter (2017-08-07 17:26:56) > On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-08-04 17:07:22) > > > We now have full (or a lot at least) igt running in beta CI, and snb > > > blt hangs are really unhappy: > > > > > > -

Re: [Intel-gfx] [PATCH i-g-t] lib: don't hang on blt on snb

On Fri, Aug 04, 2017 at 06:05:10PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-08-04 17:07:22) > > We now have full (or a lot at least) igt running in beta CI, and snb > > blt hangs are really unhappy: > > > > - drv_hangman@error-state-capture-blt and gem_exec_capture@capture-blt > >

Re: [Intel-gfx] [PATCH] drm/i915: Fix I915_EXEC_RING_MASK

On Mon, Aug 07, 2017 at 12:43:58PM +0100, Chris Wilson wrote: > This was supposed to be a mask of all known rings, but it is being used > by execbuffer to filter out invalid rings, and so is instead mapping high > unused values onto valid rings. Instead of a mask of all known rings, > we need it

Re: [Intel-gfx] [PATCH i-g-t] tests/kms: increase max threshold time for edid read

On Fri, Aug 04, 2017 at 11:23:18AM -0700, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > Current 50ms max threshold timing for an EDID read is very close to the > actual time for a 2 block HDMI EDID read of 48ms. Any delay like a clock > stretch by the

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_frontbuffer_tracking: convert macros to functions

On Fri, Aug 04, 2017 at 03:30:30PM -0300, Paulo Zanoni wrote: > Em Sex, 2017-08-04 às 18:21 +0200, Daniel Vetter escreveu: > > I guess this was done to have a better indication of which testcase > > and function failed, but igt nowadays dumps an entire stacktrace. > > But we may have multiple

[Intel-gfx] [PATCH v2 16/16] HAX Enable GuC loading & submission

This is just for CI testing, *** DO NOT MERGE *** Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c

[Intel-gfx] [PATCH v2 11/16] drm/i915/guc: Implement response handling in send_ct()

GuC may return not only small data encoded in the status dword, but can also append additional data into the response message. We will copy this extra data into provided buffer, and use number of received data dwords as new success return value. v2: fix timeout and checkpatch warnings (Michal)

[Intel-gfx] [PATCH v2 15/16] drm/i915/guc: Trace messages from CT while in debug

During debug we may want to investigate all communication from the Guc. Add proper tracing macros in debug config. v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal) Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/intel_guc_ct.c | 41

[Intel-gfx] [PATCH v2 13/16] drm/i915/guc: Handle default action received over CT

With enabled CT, instead of programming SCRATCH 15 register with the Guc to host message, Guc will send us unsolicited CT message. Content of the first payload dword of this request has the same format as data expected in the above scratch register. Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH v2 14/16] drm/i915/guc: Enable GuC interrupts when using CT

We will need them in G2H communication to properly handle responses and requests from the Guc. Signed-off-by: Michal Wajdeczko Cc: Oscar Mateo Cc: Daniele Ceraolo Spurio Cc: Michel Thierry

[Intel-gfx] [PATCH v2 12/16] drm/i915/guc: Prepare to process incoming requests from CT

Requests are read from CT in the irq handler, but actual processing will be done in the work thread. Processing of specific actions will be added in the upcoming patches. v2: don't use GEM_BUG_ON (Chris) don't kmalloc too large buffer (Michal) Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH v2 07/16] drm/i915/guc: Create a GuC receive function

From: Oscar Mateo This function, symmetrical to the send(), will handle Guc2Host message interrupts (which at the moment still only covers requests to flush the GuC logs). Cc: Michal Wajdeczko Cc: Daniele Ceraolo Spurio

[Intel-gfx] [PATCH v2 09/16] drm/i915/guc: Prepare to handle messages from CT RECV buffer

GuC can respond to our commands not only by updating SEND buffer descriptor, but can send us message over RECV buffer. Additionally Guc can also send us unsolicited requests over RECV buffer. Lets start reading those messages and make placeholders for actual response/request handlers. v2: misc

[Intel-gfx] [PATCH v2 10/16] drm/i915/guc: Use better name for helper wait function

In next patch we will introduce another way of waiting for the response that will use RECV buffer. To avoid misleading names, rename old wait function to reflect the fact that it is based on descriptor update. v2: fix comment style (Michal) Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH v2 05/16] drm/i915/guc: Move Guc notification handling to separate function

To allow future code reuse. While here, fix comment style. Suggested-by: Oscar Mateo Signed-off-by: Michal Wajdeczko Cc: Oscar Mateo Cc: Sagar Arun Kamble Cc: Daniele Ceraolo Spurio

[Intel-gfx] [PATCH v2 08/16] drm/i915/guc: Update CT message header definition

Flags bits are different in G2H message. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Oscar Mateo Cc: Kelvin Gardiner --- drivers/gpu/drm/i915/intel_guc_fwif.h |

[Intel-gfx] [PATCH v2 06/16] drm/i915/guc: Move flushing the GuC logs outside notification handler

From: Oscar Mateo To allow future code reuse. Cc: Sagar Arun Kamble Cc: Daniele Ceraolo Spurio Signed-off-by: Oscar Mateo Signed-off-by: Michal Wajdeczko ---

[Intel-gfx] [PATCH v2 04/16] drm/i915/guc: Implement response handling in send_mmio()

In addition to already returned small data encoded in the status MMIO, GuC may write more additional data in remaining MMIO regs. Lets copy all that regs into optionally provided response buffer. v2: new line (Michel) Signed-off-by: Michal Wajdeczko Cc: Daniele

[Intel-gfx] [PATCH v2 03/16] drm/i915/guc: Add send_and_receive() helper function

In the previous patch we have changed signature of the send function pointer but we didn't modify signature of the corresponding helper function to minimize number of required changes. Let's add separate helper to expose new functionality but still hide underlying details. v2: enforce response

[Intel-gfx] [PATCH v2 00/16] drm/i915/guc: Support for Guc responses and requests

With this series we will be able to receive more data from the Guc. New Guc firmware will be required to actually use that feature. v2: misc improvements after review + HAX Michal Wajdeczko (14): drm/i915/guc: Add support for data reporting in GuC responses drm/i915/guc: Prepare send()

[Intel-gfx] [PATCH v2 02/16] drm/i915/guc: Prepare send() function to accept bigger response

This is a preparation step for the upcoming patches. We already can return some small data decoded from the command status, but we will need more in the future. Signed-off-by: Michal Wajdeczko Cc: Oscar Mateo Cc: Michel Thierry

[Intel-gfx] [PATCH v2 01/16] drm/i915/guc: Add support for data reporting in GuC responses

GuC may return additional data in the command status response. Format and meaning of this data is action specific. We will use this non-negative data as a new success return value. Currently used actions don't return data that way yet. v2: fix prohibited space after '~' (Michel) update commit

Re: [Intel-gfx] [PATCH] drm/i915: remove unused function declaration

On Fri, Aug 04, 2017 at 03:03:48PM +0100, Lionel Landwerlin wrote: > This function is not part of the driver anymore. > > Signed-off-by: Lionel Landwerlin Fixes: 90f4fcd56bda ("drm/i915: Remove forced stop ring on suspend/unload") Reviewed-by: Daniel Vetter

Re: [Intel-gfx] [PATCH] drm/i915: add register macro definition style guide

On Fri, Aug 04, 2017 at 01:38:36PM +0300, Jani Nikula wrote: > This is not to try to force a new style; this is my interpretation of > what the most common existing style is. > > With hopes I don't need to answer so many questions about style going > forward. > > Cc: Daniel Vetter

Re: [Intel-gfx] [PATCH v4 2/4] drm/i915/psr: Account for sink CRC raciness on some panels

On Fri, Aug 04, 2017 at 06:38:02PM +, Pandiyan, Dhinakaran wrote: > > > > On Thu, 2017-08-03 at 11:07 -0700, Rodrigo Vivi wrote: > > On Tue, Jul 18, 2017 at 2:34 PM, Jim Bride > > wrote: > > > According to the eDP spec, when the count field in TEST_SINK_MISC > >

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/psr: Clean-up intel_enable_source_psr1()

On Fri, Aug 04, 2017 at 10:29:33AM +0300, Jani Nikula wrote: > On Thu, 03 Aug 2017, Jim Bride wrote: > > On Fri, Jul 14, 2017 at 12:34:28PM +0300, Jani Nikula wrote: > >> On Wed, 12 Jul 2017, Chris Wilson wrote: > >> > Quoting Dhinakaran

Re: [Intel-gfx] [PATCH] tests/kms_ccs: Fix the color/ccs surface generation

On Fri, Aug 04, 2017 at 07:56:11AM -0700, Jason Ekstrand wrote: > On August 4, 2017 2:59:56 AM Daniel Stone wrote: > > > Hi Jason, > > > > On 4 August 2017 at 01:52, Jason Ekstrand wrote: > > > Previously, the test used the old 64x64 convention that

Re: [Intel-gfx] [PATCH i-g-t v2] kms_rotation_crc: 90 degree flip test is not a stress test

On Fri, Aug 04, 2017 at 09:43:41AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > To the best of my recollection the page flipping test was added > simply to start exercising page flips with 90/270 rotation. > > There is no need to do 60 flips which can take

Re: [Intel-gfx] [PATCH i-g-t 1/3] lib/igt_aux: Export statistics of signal helper.

On Mon, Aug 07, 2017 at 10:59:55AM +0100, Chris Wilson wrote: > Quoting Maarten Lankhorst (2017-08-07 10:45:38) > > Op 04-08-17 om 09:50 schreef Chris Wilson: > > > Quoting Maarten Lankhorst (2017-08-02 11:29:17) > > >> Export 2 functions, igt_signal_helper_get_num and > > >>

Re: [Intel-gfx] [PATCH 3/7] drm/i915: More surgically unbreak the modeset vs reset deadlock

On Thu, Aug 03, 2017 at 12:35:48PM -0700, Michel Thierry wrote: > Hi, > > First sorry about the delay... > > On 7/20/2017 10:57 AM, Daniel Vetter wrote: > > There's no reason to entirely wedge the gpu, for the minimal deadlock > > bugfix we only need to unbreak/decouple the atomic commit from

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit

On Thu, Aug 03, 2017 at 12:44:40PM -0700, Michel Thierry wrote: > On 7/20/2017 10:57 AM, Daniel Vetter wrote: > > Blocking in a worker is ok, that's what the unbound_wq is for. And it > > unifies the paths between the blocking and nonblocking commit, giving > > me just one path where I have to

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s

Em Seg, 2017-08-07 às 06:51 +, Lofstedt, Marta escreveu: > > -Original Message- > > From: Zanoni, Paulo R > > Sent: Friday, August 4, 2017 9:56 PM > > To: Lofstedt, Marta ; intel- > > g...@lists.freedesktop.org > > Cc: Latvala, Petri

Re: [Intel-gfx] [PATCH igt 2/2] lib: Remove illegal instructions from hang injection

Chris Wilson writes: > The idea behind using an illegal instruction was to hang the GPU must > faster than simply using the recursive batch. However, we stopped doing > so on gen8+ as the CS parser was much laxer and allowed the illegal > command through but still

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [Intel-gfx,1/2] igt/gem_exec_capture: Wait for batch to execute before triggering reset

== Series Details == Series: series starting with [Intel-gfx,1/2] igt/gem_exec_capture: Wait for batch to execute before triggering reset URL : https://patchwork.freedesktop.org/series/28452/ State : success == Summary == IGT patchset tested on top of latest successful build

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Clear lost context-switch interrupts across reset

== Series Details == Series: drm/i915: Clear lost context-switch interrupts across reset URL : https://patchwork.freedesktop.org/series/28450/ State : success == Summary == Series 28450v1 drm/i915: Clear lost context-switch interrupts across reset

[Intel-gfx] [PATCH igt 2/2] lib: Remove illegal instructions from hang injection

The idea behind using an illegal instruction was to hang the GPU must faster than simply using the recursive batch. However, we stopped doing so on gen8+ as the CS parser was much laxer and allowed the illegal command through but still interpreted the packet length (jumping over the recursive

[Intel-gfx] [PATCH igt 1/2] igt/gem_exec_capture: Wait for batch to execute before triggering reset

Signed-off-by: Chris Wilson --- tests/gem_exec_capture.c | 65 1 file changed, 49 insertions(+), 16 deletions(-) diff --git a/tests/gem_exec_capture.c b/tests/gem_exec_capture.c index f8f43d29..a73ece5d 100644 ---

[Intel-gfx] [PATCH i-g-t] intel_gpu_top: Use drm_open_driver, don't need drm master

Signed-off-by: Petri Latvala --- tools/intel_gpu_top.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c index 7848876..3fe77f7 100644 --- a/tools/intel_gpu_top.c +++ b/tools/intel_gpu_top.c @@ -513,7 +513,7

[Intel-gfx] [PATCH] drm/i915: Clear lost context-switch interrupts across reset

During a global reset, we disable the irq. As we disable the irq, the hardware may be raising a GT interrupt that we then ignore, leaving it pending in the GTIIR. After the reset, we then re-enable the irq, triggering the pending interrupt. However, that interrupt was for the stale state from

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Convert gen4- watermarks to atomic. (rev2)

== Series Details == Series: drm/i915: Convert gen4- watermarks to atomic. (rev2) URL : https://patchwork.freedesktop.org/series/23954/ State : failure == Summary == Series 23954v2 drm/i915: Convert gen4- watermarks to atomic.

[Intel-gfx] [PATCH] drm/i915: Fix I915_EXEC_RING_MASK

This was supposed to be a mask of all known rings, but it is being used by execbuffer to filter out invalid rings, and so is instead mapping high unused values onto valid rings. Instead of a mask of all known rings, we need it to be the mask of all possible rings. Fixes: 549f7365820a ("drm/i915:

Re: [Intel-gfx] [PATCH] tests/kms_cursor_legacy: use 'enum pipe' type instead of 'int'

On Wed, Aug 02, 2017 at 07:54:17PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Signed-off-by: Gustavo Padovan Reviewed-by: Arkadiusz Hiler and pushed, thanks! -- Cheers, Arek

Re: [Intel-gfx] a potential dead loop in intel_lrc_irq_handler

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Monday, August 7, 2017 7:13 PM > To: Dong, Chuanxiao ; intel- > g...@lists.freedesktop.org; Joonas Lahtinen > > Subject: RE: a potential dead loop

Re: [Intel-gfx] [PATCH i-g-t] tests/core_auth: set rlimit

On Fri, Aug 04, 2017 at 04:38:51PM +0200, Daniel Vetter wrote: > Some distros have huge rlimits and then the test takes forever, or > worse oom, or even worse, takse down the entire machine (which is > shouldn't be able to, but oh well, oom handling in linux). > > Make sure we have a consistent

Re: [Intel-gfx] a potential dead loop in intel_lrc_irq_handler

Quoting Dong, Chuanxiao (2017-08-07 11:31:57) > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > GPU reset -> clears CSB head/tail > But the GPU reset will make CSB_head = 0 and CSB_tail = 7. Experience says otherwise, but the issue of the delayed

[Intel-gfx] [PATCH 5/7] drm/i915: Program gen4 watermarks atomically

We're already calculating the watermarks correctly, now we have to program them too. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c | 25 +++-- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git

[Intel-gfx] [PATCH 1/7] drm/i915: Calculate gen3- watermarks semi-atomically.

The gen3 watermark calculations are converted to atomic, but the wm update calls are still done through the legacy functions. This will make it easier to bisect things if they go wrong. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH 3/7] drm/i915: Convert pineview watermarks to atomic, v2.

Pineview seems to have different watermarks from the other platforms and are calculated separately. With the change to atomic, cxsr is automatically disabled for intermediate watermarks when required. This will fix fd.org bug #101597 as a nice side effect. Changes since v1: - Fix deadlock in

[Intel-gfx] [PATCH 2/7] drm/i915: Program gen3- watermarks atomically

With the atomic watermark calculations calculate intermediary watermark values and update the watermarks atomically. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 5 ++ drivers/gpu/drm/i915/intel_drv.h | 2 +-

[Intel-gfx] [PATCH 4/7] drm/i915: Calculate gen4 watermarks semiatomically.

Gen4 watermark is handled same as gen3-. Calculate the optimal watermarks atomically first, and program it in the legacy helper. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c | 136 1 file

[Intel-gfx] [PATCH 6/7] drm/i915: Kill off intel_crtc_active.

Use crtc->active directly instead. This is still not completely optimal and needs fixing, but it's about as good as using intel_crtc_active. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 19 ---

[Intel-gfx] [PATCH 7/7] drm/i915: Rip out legacy watermark infrastructure

The legacy watermark infrastructure is now unused, so remove it. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/intel_atomic.c | 2 - drivers/gpu/drm/i915/intel_display.c | 74

[Intel-gfx] [PATCH 0/7] drm/i915: Convert gen4- watermarks to atomic.

Calculate watermarks for gen4 and lower atomically. This has been tested on the pineview system in CI. It fixes bug 101597, which is a vblank wait timed out when running kms_pipe_crc_basic. The changes to CXSR will allow the test to pass. Maarten Lankhorst (7): drm/i915: Calculate gen3-

Re: [Intel-gfx] a potential dead loop in intel_lrc_irq_handler

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Monday, August 7, 2017 5:56 PM > To: Dong, Chuanxiao ; intel- > g...@lists.freedesktop.org; Joonas Lahtinen > > Subject: Re: a potential dead loop

Re: [Intel-gfx] [PATCH i-g-t 1/3] lib/igt_aux: Export statistics of signal helper.

Quoting Maarten Lankhorst (2017-08-07 10:45:38) > Op 04-08-17 om 09:50 schreef Chris Wilson: > > Quoting Maarten Lankhorst (2017-08-02 11:29:17) > >> Export 2 functions, igt_signal_helper_get_num and > >> igt_signal_helper_get_hz. > >> > >> This will allow tests to measure how much time in a test

Re: [Intel-gfx] a potential dead loop in intel_lrc_irq_handler

Quoting Dong, Chuanxiao (2017-08-07 10:41:29) > Hello, > > Found there might be a corner case for intel_lrc_irq_handler() in a dead > loop, want to understand if this can be real or not. > > The scenario is like: > 1. Write wedged to trigger a GPU reset; This is dangerous full stop, but even

Re: [Intel-gfx] [PATCH i-g-t 1/3] lib/igt_aux: Export statistics of signal helper.

Op 04-08-17 om 09:50 schreef Chris Wilson: > Quoting Maarten Lankhorst (2017-08-02 11:29:17) >> Export 2 functions, igt_signal_helper_get_num and >> igt_signal_helper_get_hz. >> >> This will allow tests to measure how much time in a test was spent >> in a uninterruptible state, which is useful

[Intel-gfx] a potential dead loop in intel_lrc_irq_handler

Hello, Found there might be a corner case for intel_lrc_irq_handler() in a dead loop, want to understand if this can be real or not. The scenario is like: 1. Write wedged to trigger a GPU reset; 2. meanwhile, there is one ongoing request in port[0], and its context switch interrupt is

Re: [Intel-gfx] [PATCH] drm: Wake up next in drm_read() chain if we are forced to putback the event

On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote: > After an event is sent, we try to copy it into the user buffer of the > first waiter in drm_read() and if the user buffer doesn't have enough > room we put it back onto the list. However, we didn't wake up any > subsequent waiter, so

Re: [Intel-gfx] [PATCH 12/29] drm/i915: switch to drm_*{get, put} helpers

On Thu, Aug 3, 2017 at 5:52 PM, Cihangir Akturk wrote: > On Thu, Aug 03, 2017 at 02:49:03PM +0200, Daniel Vetter wrote: >> On Thu, Aug 03, 2017 at 03:26:01PM +0300, Jani Nikula wrote: >> > On Thu, 03 Aug 2017, Cihangir Akturk wrote: >> > > drm_*_reference()

[Intel-gfx] [PATCH] dim: symbolic link for the rr-cache

After about a month and a few attempts it's clear that my rr-cache gc logic is busted. When copying stuff back between the git branch and git's rr-cache dir, something somewhere (or maybe it's git rerere itself) touches all files and wreaks the timestamps. End result is that over this month,

Re: [Intel-gfx] [PATCH] dim: Continue also for dry runs

On Thu, Aug 3, 2017 at 2:44 PM, Jani Nikula wrote: > On Thu, 27 Jul 2017, Daniel Vetter wrote: >> It's a bit silly to have to spec both -d and -f to see what dim would >> all complain about. And dry-run should never cause bad side-effects. > >

Re: [Intel-gfx] [GIT PULL] GVT-g fixes for 4.13-rc5

On Mon, 07 Aug 2017, Zhenyu Wang wrote: > Hi, this is gvt fixes for 4.13-rc5, there're two regression fixes for > MMIO handle 65f9f6febf12, and two important vGPU reset fixes. Pulled to drm-intel-fixes, thanks. BR, Jani. > > Thanks > -- > The following changes since

Re: [Intel-gfx] [PATCH i-g-t 3/3] tests: Add kms_atomic_interruptible test.

Op 04-08-17 om 09:50 schreef Mika Kahola: > On Wed, 2017-08-02 at 12:29 +0200, Maarten Lankhorst wrote: >> To make sure that we have test exposure when allowing atomic ioctl's >> to >> fail interruptibly, we add a test that will fail to lock the >> mutexes until the fence is signaled. >> >> If the

Re: [Intel-gfx] [PATCH i-g-t 2/3] lib/igt_kms: Remove vblank wait after plane update.

Op 04-08-17 om 10:07 schreef Mika Kahola: > On Wed, 2017-08-02 at 12:29 +0200, Maarten Lankhorst wrote: >> With the conversion to atomic, this is already handled in the core. >> >> Signed-off-by: Maarten Lankhorst >> --- >> lib/igt_kms.c | 15 --- >>

Re: [Intel-gfx] [PATCH v13 6/7] drm/i915: Introduce GEM proxy

On ti, 2017-07-25 at 17:28 +0800, Tina Zhang wrote: > GEM proxy is a kind of GEM, whose backing physical memory is pinned > and produced by guest VM and is used by host as read only. With GEM > proxy, host is able to access guest physical memory through GEM object > interface. As GEM proxy is such

Re: [Intel-gfx] [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation

After going through the previous discussions, here are some summaries may be related to the current discussion: 1. How does user mode figure the device capabilities between region and dma-buf? VFIO_DEVICE_GET_REGION_INFO could tell if the mdev supports region case. Otherwise, the mdev supports

[Intel-gfx] [GIT PULL] GVT-g fixes for 4.13-rc5

Hi, this is gvt fixes for 4.13-rc5, there're two regression fixes for MMIO handle 65f9f6febf12, and two important vGPU reset fixes. Thanks -- The following changes since commit 26a201a2ba82a801973ce29e1004b64742e81e7e: drm/i915/gvt: Extend KBL platform support in GVT-g (2017-07-25 12:39:41

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s

> -Original Message- > From: Zanoni, Paulo R > Sent: Friday, August 4, 2017 9:56 PM > To: Lofstedt, Marta ; intel- > g...@lists.freedesktop.org > Cc: Latvala, Petri > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase