Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote: > A more complete solution would be to do the mutex_init in the drm core > only for legacy drivers, plus add it to each modern driver that still > needs it, which would also give each its own lockdep key. Trying to do > that

Re: [Intel-gfx] [PATCH] drm/i915: Eliminate dead code in intel_sanitize_enable_ppgtt()

On Wed, Jun 01, 2016 at 06:04:40PM +0100, Chris Wilson wrote: > On Wed, Jun 01, 2016 at 05:01:13PM +0100, Damien Lespiau wrote: > > We exit early if has_aliasing_ppgtt is 0, so towards the end of the > > function has_aliasing_ppgtt can only be 1. > > > > Also: > > > > if (foo) > >

Re: [Intel-gfx] [RFC 4/4] drm/i915/execlists: Preemption!

Quoting Chris Wilson (2017-07-17 10:46:23) > Quoting Chris Wilson (2017-07-17 09:42:35) > > @@ -503,6 +500,49 @@ static void execlists_dequeue(struct intel_engine_cs > > *engine) > > struct i915_priolist *p = rb_entry(rb, typeof(*p), node); > > struct

Re: [Intel-gfx] [PATCH v10] vfio: ABI for mdev display dma-buf operation

Hi, > No need of flag here. If vGPU driver is not loaded in the guest, > there > is no surface being managed by vGPU, in that case this size will be > zero. Ok, we certainly have the same situation with intel. When the guest driver is not loaded (yet) there is no valid surface. We should

Re: [Intel-gfx] [PATCH] drm/i915: Fix bad comparison in skl_compute_plane_wm.

Reviewed-by: Mahesh Kumar On Monday 17 July 2017 04:43 PM, Maarten Lankhorst wrote: ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same as ddb_allocation >= blocks_per_line, so use the latter to simplify this. This fixes the following compiler

[Intel-gfx] [PATCH] drm/i915: Fix bad comparison in skl_compute_plane_wm, v2.

ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same as ddb_allocation >= blocks_per_line, so use the latter to simplify this. This fixes the following compiler warning: drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean expression with an integer other than

[Intel-gfx] [PATCH xf86-video-intel] legacy/i810: remove unused numVisualConfigs

From: Emil Velikov Cc: Chris Wilson Signed-off-by: Emil Velikov --- src/legacy/i810/i810.h | 1 - 1 file changed, 1 deletion(-) diff --git a/src/legacy/i810/i810.h b/src/legacy/i810/i810.h index

[Intel-gfx] [PATCH] drm/i915: Fix bad comparison in skl_compute_plane_wm.

ddb_allocation && ddb_allocation / blocks_per_line >= 1 is the same as ddb_allocation >= blocks_per_line, so use the latter to simplify this. This fixes the following compiler warning: drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean expression with an integer other than

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix bad comparison in skl_compute_plane_wm. (rev2)

== Series Details == Series: drm/i915: Fix bad comparison in skl_compute_plane_wm. (rev2) URL : https://patchwork.freedesktop.org/series/27395/ State : success == Summary == Series 27395v2 drm/i915: Fix bad comparison in skl_compute_plane_wm.

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

On Friday 14 July 2017 07:55 PM, Paulo Zanoni wrote: Em Sex, 2017-07-14 às 19:25 +0530, Praveen Paneri escreveu: Hi Paulo, On Thursday 13 July 2017 02:31 AM, Paulo Zanoni wrote: Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu: Now that we have support for Y-tiled buffers, add

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix error checking/locking in perf/lookup_context()

On Fri, Jul 14, 2017 at 03:28:47PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915: Fix error checking/locking in > perf/lookup_context() > URL : https://patchwork.freedesktop.org/series/27309/ > State : success I pushed both patches to -dinq,

Re: [Intel-gfx] [i-g-t] many testcases skiped

On Mon, Jul 17, 2017 at 12:30:30PM +0200, Gu, HailinX wrote: > Hi~ Hiler > Thank for your reply. > I'm sorry for didn't notice the integradted graphics. > But there is still some cases could not pass and shown requirement not met, > running on i7-4770. > I wonder if these skiped cases only

Re: [Intel-gfx] [PATCH 3/7] drm/atomic-helper: add sync_all helper for gpu reset

Daniel Vetter writes: > i915 needs this. > > Cc: Maarten Lankhorst > Cc: Ville Syrjälä > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_atomic_helper.c | 38 >

Re: [Intel-gfx] [PATCH i-g-t 3/3] tests/gem_reset_stats: Enforce full chip reset mode before run

On Thu, Jul 06, 2017 at 10:29:41AM -0700, Michel Thierry wrote: > On 06/07/17 04:12, Arkadiusz Hiler wrote: > > On Tue, Jun 20, 2017 at 11:25:02AM -0700, Michel Thierry wrote: > > > Platforms with per-engine reset enabled (i915.reset=2) are unlikely to > > > perform a full chip reset, keeping the

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for RFC: duct-tape for the gpu reset vs. modeset deadlock

Op 15-07-17 om 15:45 schreef Daniel Vetter: > On Sat, Jul 15, 2017 at 3:23 PM, Daniel Vetter wrote: >> On Sat, Jul 15, 2017 at 2:00 PM, Patchwork >> wrote: >>> == Series Details == >>> >>> Series: RFC: duct-tape for the gpu reset vs.

Re: [Intel-gfx] drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

Op 17-07-17 om 12:32 schreef Mahesh Kumar: > Hi, > > > On Monday 17 July 2017 03:22 PM, Jani Nikula wrote: >> On Mon, 17 Jul 2017, David Binderman wrote: >>> Hello there, >> Hello. No need to include LKML for stuff like this. But Cc'd the folks >> from the broken commit. >>

[Intel-gfx] Updated drm-intel-testing

Hi all, 2nd round of 4.14 features: - prep for deferred fbdev setup - refactor fixed 16.16 computations and skl+ wm code (Mahesh Kumar) - more cnl paches (Rodrigo, Imre et al) - tighten context cleanup and handling (Chris Wilson) - fix interlaced handling on skl+ (Mahesh Kumar) - small bits as

[Intel-gfx] [RFC 1/4] drm/i915/execlists: Move insert_request()

Move insert_request() earlier to avoid a forward declaration in a later patch. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 128 +++ 1 file changed, 64 insertions(+), 64 deletions(-) diff --git

[Intel-gfx] [RFC 4/4] drm/i915/execlists: Preemption!

When we write to ELSP, it triggers a context preemption at the earliest arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other operations and the explicit MI_ARB_CHECK). If this is to the same context, it triggers a LITE_RESTORE where the RING_TAIL is merely updated (used currently to

[Intel-gfx] [RFC 2/4] drm/i915/execlists: Keep request->priority for its lifetime

With preemption, we will want to "unsubmit" a request, taking it back from the hw and returning it to the priority sorted execution list. In order to know where to insert it into that list, we need to remember its adjust priority (which may change even as it was being executed). Signed-off-by:

[Intel-gfx] [RFC 3/4] drm/i915/execlists: Split insert_request()

In the next patch we will want to reinsert a request not at the end of the priority queue, but at the front. Here we split insert_request() into two, the first function retrieves the priority list (for reuse for unsubmit later) and a wrapper function to insert at the end of that list and to

[Intel-gfx] [PATCH 03/15] drm/i915: Serialize per-engine resets against new requests

We rely on disabling the execlists (by stopping the tasklet) to prevent new requests from submitting to the engine ELSP before we are ready. However, we re-enable the engine before we call init_hw which gives userspace the opportunity to subit a new request which is then overwritten by init_hw --

[Intel-gfx] [PATCH 13/15] drm/i915: Emit a user level message when resetting the GPU (or engine)

Although a banned context will be told to -EIO off if they try to submit more requests, we have a discrepancy between whole device resets and per-engine resets where we report the GPU reset but not the engine resets. This leaves a bit of mystery as to why the context was banned, and also reduces

[Intel-gfx] [PATCH 11/15] drm/i915: Clear engine irq posted following a reset

When the GPU is reset, we want to discard all pending notifications as either we have manually completed them, or they are no longer applicable. Make sure we do reset the engine->irq_posted prior to re-enabling the engine (e.g. the interrupt tasklets) in i915_gem_reset_finish_engine().

[Intel-gfx] [PATCH 01/15] drm/i915: Report execlists irq bit in debugfs

As part of the knowing whether there is outstanding data in the CSB, also check whether there is an outstanding IRQ notification. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Reviewed-by:

[Intel-gfx] [PATCH 07/15] drm/i915: Move idle checks before intel_engine_init_global_seqno()

intel_engine_init_globa_seqno() may be called from an uncontrolled set-wedged path where we have given up waiting for broken hw and declare it defunct. Along that path, any sanity checks that the hw is idle before we adjust its state will expectedly fail, so we simply cannot. Instead of asserting

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Fix leak in disable_all

Op 15-07-17 om 11:31 schreef Daniel Vetter: > The legacy plane->fb pointer is refcounted by calling > drm_atomic_clean_old_fb(). > > In practice this isn't a real problem because: > - The caller in the i915 gpu reset code restores the original state > again, which means the plane->fb pointer

[Intel-gfx] [PATCH 15/15] drm/i915/selftests: Exercise independence of per-engine resets

If all goes well, resetting one engine should not affect the operation of any others. So to test this, we setup a continuous stream of requests onto to each of the "innocent" engines whilst constantly resetting our target engine. Signed-off-by: Chris Wilson Cc: Mika

Re: [Intel-gfx] drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

Hi, On Monday 17 July 2017 03:22 PM, Jani Nikula wrote: On Mon, 17 Jul 2017, David Binderman wrote: Hello there, Hello. No need to include LKML for stuff like this. But Cc'd the folks from the broken commit. drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison

[Intel-gfx] [PATCH 14/15] drm/i915: Disable per-engine reset for Broxton

Triggering a GPU reset for one engine affects another, notably corrupting the context status buffer (CSB) effectively losing track of inflight requests. Adding a few printks: diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index ad41836fa5e5..a969456bc0fa 100644 ---

Re: [Intel-gfx] drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

On Mon, 17 Jul 2017, David Binderman wrote: > Hello there, Hello. No need to include LKML for stuff like this. But Cc'd the folks from the broken commit. > drivers/gpu/drm/i915/intel_pm.c:4467]: (warning) Comparison of a boolean > expression with an integer other than 0 or

Re: [Intel-gfx] drivers/gpu/drm/i915/intel_pm.c:4467: bad comparison ?

Hi, On Monday 17 July 2017 04:01 PM, Maarten Lankhorst wrote: Op 17-07-17 om 12:32 schreef Mahesh Kumar: Hi, On Monday 17 July 2017 03:22 PM, Jani Nikula wrote: On Mon, 17 Jul 2017, David Binderman wrote: Hello there, Hello. No need to include LKML for stuff like

Re: [Intel-gfx] [i-g-t] many testcases skiped

On Mon, Jul 17, 2017 at 12:28:00PM +0800, Hailin Gu wrote: > Hi~ all, > > Does the test program have any hardware or version limitations? > > > I found that most testcase could run on a machine with intel(R) Core(TM) > i7-2600K CPU @ 3.40GHz. > > But can't run on Intel(R) Xeon(R) CPU E5-2699

Re: [Intel-gfx] [RFC 4/4] drm/i915/execlists: Preemption!

Quoting Chris Wilson (2017-07-17 09:42:35) > @@ -503,6 +500,49 @@ static void execlists_dequeue(struct intel_engine_cs > *engine) > struct i915_priolist *p = rb_entry(rb, typeof(*p), node); > struct drm_i915_gem_request *rq, *rn; > > + if (once) { >

Re: [Intel-gfx] [i-g-t] many testcases skiped

Hi~ Hiler Thank for your reply. I'm sorry for didn't notice the integradted graphics. But there is still some cases could not pass and shown requirement not met, running on i7-4770. I wonder if these skiped cases only about the cpu? So different processor must have different test result. Or

Re: [Intel-gfx] [i-g-t] many testcases skiped

On Mon, Jul 17, 2017 at 11:14:03AM +0300, Arkadiusz Hiler wrote: > On Mon, Jul 17, 2017 at 12:28:00PM +0800, Hailin Gu wrote: > > Hi~ all, > > > > Does the test program have any hardware or version limitations? > > > > > > I found that most testcase could run on a machine with intel(R) Core(TM)

Re: [Intel-gfx] [PATCH] drm/i915: Consistently use enum pipe for PCH transcoders

On Fri, Jul 14, 2017 at 06:04:03PM -0700, Matthias Kaehlcke wrote: > The current code uses two different enum types for PCH transcoders and > performs implicit conversions between the two types. This is error prone > and causes clang to raise warnings like this: > >

Re: [Intel-gfx] [PATCH v2 i-g-t] igt/perf: add tests to verify create/destroy userspace configs

On 14/07/17 19:21, Matthew Auld wrote: On 14 July 2017 at 18:57, Lionel Landwerlin wrote: On 14/07/17 18:09, Matthew Auld wrote: On 13 July 2017 at 12:16, Lionel Landwerlin wrote: v2: Add tests regarding removing configs

[Intel-gfx] [PATCH 06/15] drm/i915: Check the execlist queue for pending requests before declaring idle

Including a check against the execlist queue before calling the engine idle and passing hangcheck. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c

[Intel-gfx] [PATCH 10/15] drm/i915: Assert that machine is wedged for nop_submit_request

We should only ever do nop_submit_request when the machine is wedged, so assert it is so. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 05/15] drm/i915: Check execlist/ring status during hangcheck

Before we declare an engine as idle, check if there are any pending execlist context-switches and if the ring itself reports as idle. Otherwise, we may be left in a situation where we miss a crucial execlist event (or something more sinister) yet the requests complete. Since the seqno write

[Intel-gfx] [PATCH 09/15] drm/i915: Wake up waiters after setting the WEDGED bit

After setting the WEDGED bit, make sure that we do wake up waiters as they may not be waiting for a request completion yet, just for its execution. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

[Intel-gfx] [PATCH 08/15] drm/i915: Clear execlist port[] before updating seqno on wedging

When we wedge the device, we clear out the in-flight requests and advance the breadcrumb to indicate they are complete. However, the breadcrumb advance includes an assert that the engine is idle, so that advancement needs to be the last step to ensure we pass our own sanity checks. Signed-off-by:

Re: [Intel-gfx] [PATCH v3 0/2] Handle unsupported configuration with IF-ID

On Fri, Jun 30, 2017 at 05:40:58PM +0530, Mahesh Kumar wrote: > Gen9+ Interlace fetch mode doesn't support few plane configurations & pipe > scaling. > - Y-tile > - 90/270 rotation > - pipe/plane scaling > - 420 planar formats Do we have igt testcases that try to exercise all this? When

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/4] drm/i915/execlists: Move insert_request()

== Series Details == Series: series starting with [RFC,1/4] drm/i915/execlists: Move insert_request() URL : https://patchwork.freedesktop.org/series/27382/ State : success == Summary == Series 27382v1 Series without cover letter

[Intel-gfx] [PATCH 12/15] drm/i915: Make i915_gem_context_mark_guilty() safe for unlocked updates

Since we make call i915_gem_context_mark_guilty() concurrently when resetting different engines in parallel, we need to make sure that our updates are safe for the unlocked access. Signed-off-by: Chris Wilson Cc: Michel Thierry Cc: Mika

[Intel-gfx] [PATCH 02/15] drm/i915: Reset context image on engines after triggering the reset

We try to fixup the context image after the reset to ensure that there are no more pending writes from the hw that may conflict and to fixup any that were in flight. Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery") Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 04/15] drm/i915: Flush the execlist ports if idle

When doing a GPU reset, the CSB register will be trashed and we will lose any context-switch notifications that happened since the tasklet was disabled. If we find that all requests on this engine were completed, we want to make sure that the ELSP tracker is similarly empty so that we do not feed

[Intel-gfx] [PATCH v4 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

The motivation behind this new interface is expose at runtime the creation of new OA configs which can be used as part of the i915 perf open interface. This will enable the kernel to learn new configs which may be experimental, or otherwise not part of the core set currently available through the

[Intel-gfx] [PATCH v4 2/6] drm/i915: prepare scaler for YCBCR420 modeset

To get a YCBCR420 output from intel platforms, we need one scaler to scale down YCBCR444 samples to YCBCR420 samples. This patch: - Does scaler allocation for HDMI ycbcr420 outputs. - Programs PIPE_MISC register for ycbcr420 output. - Adds a new scaler user "HDMI output" to plug-into existing

[Intel-gfx] [PATCH v4 1/6] drm/i915: add config function for YCBCR420 outputs

This patch checks encoder level support for YCBCR420 outputs. The logic goes as simple as this: If the input mode is YCBCR420-only mode: prepare HDMI for YCBCR420 output, else continue with RGB output mode. It checks if the mode is YCBCR420 and source can support this output then it marks the

[Intel-gfx] [PATCH v4 0/6] YCBCR 4:2:0 handling in i915 layer

This patch series is a subset of series "YCBCR 4:2:0 handling in DRM layer" Published and reviewed here: https://patchwork.freedesktop.org/series/26973/ The original series had 14 patches, out of which first 8 (which were in DRM layer) are reviewed merged. These 6 patches are the I915 layer

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_debugfs: Update documentation and clenup

clenup -> cleanup On 17/07/17 18:05, Liviu Dudau wrote: On Mon, Jul 17, 2017 at 04:59:48PM +0300, Arkadiusz Hiler wrote: The documentation was lying. The igt_crc_to_string() is threadsafe and does not return a pointer to an internal buffer. Actually the caller is responsible for the memory

[Intel-gfx] [PATCH v4 0/3] Add support for loadable OA configs

Hi all, Here is a v4 of this series. It is mostly prompted by one of Imre's series [1] that attracted my attention at how we do locking in the perf part of the driver. I believe up to now it was fine due to the fact that we had all configs always present in kernel space. With this series,

[Intel-gfx] [PATCH v4 1/3] drm/i915/perf: fix flex eu registers programming

We were reserving fewer dwords in the ring than necessary. Indeed we're always writing all registers once, so discard the actual number of registers given by the user and just program the whitelisted ones once. Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+") Reported-by:

[Intel-gfx] [PATCH i-g-t] lib/igt_debugfs: Update documentation and clenup

The documentation was lying. The igt_crc_to_string() is threadsafe and does not return a pointer to an internal buffer. Actually the caller is responsible for the memory that is allocated (and they are for all the current cases), so let's put that in the doc too. While I was at it I got rid of

[Intel-gfx] [PATCH] drm/i915: Explicit the connector name for DP link training result

This adds the connector name when printing a debug message about the DP link training result. It is useful to figure out what connector is failing when multiple DP connectors are used. Signed-off-by: Paul Kocialkowski ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Explicit the connector name for DP link training result

== Series Details == Series: drm/i915: Explicit the connector name for DP link training result URL : https://patchwork.freedesktop.org/series/27410/ State : success == Summary == Series 27410v1 drm/i915: Explicit the connector name for DP link training result

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_debugfs: Update documentation and clenup

On Mon, Jul 17, 2017 at 04:59:48PM +0300, Arkadiusz Hiler wrote: > The documentation was lying. The igt_crc_to_string() is threadsafe and > does not return a pointer to an internal buffer. > > Actually the caller is responsible for the memory that is allocated (and > they are for all the current

Re: [Intel-gfx] [PATCH] drm/atomic-helper: Fix leak in disable_all

On Mon, Jul 17, 2017 at 11:39:56AM +0200, Maarten Lankhorst wrote: > Op 15-07-17 om 11:31 schreef Daniel Vetter: > > The legacy plane->fb pointer is refcounted by calling > > drm_atomic_clean_old_fb(). > > > > In practice this isn't a real problem because: > > - The caller in the i915 gpu reset

[Intel-gfx] [Bug Report] Weekly progress report ww28

Highlights: - Bugs open during the week: 17 - Bugs closed during the week: 8 - Bugs labeled ReadyForDev during the week: 9 - Total bugs remain open: 327 - Total bugs labeled ReadyForDev: 130 Details: - Bugs open during the week(priority): 17

Re: [Intel-gfx] [PATCH i-g-t 1/7] igt: lib/igt_crc: Split out CRC functionality

On Thu, Jul 06, 2017 at 05:14:18PM +0100, Liviu Dudau wrote: > From: Brian Starkey > > Separate out the CRC code for better compartmentalisation. Should ease > the addition of more/different CRC sources in the future. > > Signed-off-by: Brian Starkey

Re: [Intel-gfx] [PATCH i-g-t 1/7] igt: lib/igt_crc: Split out CRC functionality

On Mon, Jul 17, 2017 at 04:50:27PM +0300, Arkadiusz Hiler wrote: > On Thu, Jul 06, 2017 at 05:14:18PM +0100, Liviu Dudau wrote: > > From: Brian Starkey > > > > Separate out the CRC code for better compartmentalisation. Should ease > > the addition of more/different CRC

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

On Mon, Jul 17, 2017 at 11:35 AM, Peter Zijlstra wrote: > On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote: >> A more complete solution would be to do the mutex_init in the drm core >> only for legacy drivers, plus add it to each modern driver that still >>

[Intel-gfx] ✓ Fi.CI.BAT: success for YCBCR 4:2:0 handling in i915 layer

== Series Details == Series: YCBCR 4:2:0 handling in i915 layer URL : https://patchwork.freedesktop.org/series/27412/ State : success == Summary == Series 27412v1 YCBCR 4:2:0 handling in i915 layer https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/1/mbox/ Test

[Intel-gfx] [PATCH v3 i-g-t] igt/perf: add tests to verify create/destroy userspace configs

v2: Add tests regarding removing configs (Matthew) Add tests regarding adding/removing configs without permissions (Matthew) v3: Add some flex registers (Matthew) Signed-off-by: Lionel Landwerlin --- tests/perf.c | 207

[Intel-gfx] ✗ Fi.CI.BAT: warning for Add support for loadable OA configs

== Series Details == Series: Add support for loadable OA configs URL : https://patchwork.freedesktop.org/series/27403/ State : warning == Summary == Series 27403v1 Add support for loadable OA configs https://patchwork.freedesktop.org/api/1.0/series/27403/revisions/1/mbox/ Test

[Intel-gfx] [PATCH v4 5/6] drm/i915: set colorspace for YCBCR420 outputs

When output colorspace is YCBCR420, we have to load the corresponding colorspace in AVI infoframe. This patch fills the colorspace of AVI infoframe as per the output mode. V2: Rebase V3: Rebase V4: Rebase V5: Added r-b from Ander V6: Checking RGB/YCBCR420 output only (Ville) V7: Add colorspace

[Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output

To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in full blend mode to use the scaler in 5x3 ratio (bits 26 and 27) This patch: - Adds definition of these bits. - Programs PIPEMISC

[Intel-gfx] [PATCH v4 4/6] drm/i915: prepare csc unit for YCBCR420 output

To support ycbcr output, we need a pipe CSC block to do RGB->YCBCR conversion. Current Intel platforms have only one pipe CSC unit, so we can either do color correction using it, or we can perform RGB->YCBCR conversion. This function adds a csc handler, which uses recommended bspec values to

[Intel-gfx] [PATCH v4 6/6] drm/i915/glk: set HDMI 2.0 identifier

This patch sets the is_hdmi2_src identifier in drm connector for GLK platform. GLK contains a native HDMI 2.0 controller. This identifier will help the EDID handling functions to save lot of work which is specific to HDMI 2.0 sources. V3: Added this patch V4: Rebase V4: Rebase V5: Added r-b from

[Intel-gfx] [Regression report] Weekly regression report WW27

Link to FDO regression list:

Re: [Intel-gfx] [PATCH i-g-t v2 2/2] chamelium: Add support for VGA frame comparison testing

Just one change for this patch below On Wed, 2017-07-12 at 17:57 +0300, Paul Kocialkowski wrote: > This adds support for VGA frame comparison testing with the reference > generated from cairo. The retrieved frame from the chamelium is first > cropped, as it contains the blanking intervals,

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

On Mon, Jul 17, 2017 at 05:06:42PM +0200, Daniel Vetter wrote: > On Mon, Jul 17, 2017 at 11:35 AM, Peter Zijlstra wrote: > > On Sat, Jul 15, 2017 at 11:53:28AM +0200, Daniel Vetter wrote: > >> A more complete solution would be to do the mutex_init in the drm core > >> only

Re: [Intel-gfx] [PATCH i-g-t v4 2/7] chamelium: Calculate CRC from framebuffer instead of hardcoding it

On Wed, 2017-07-12 at 17:50 +0300, Paul Kocialkowski wrote: > This introduces CRC calculation for reference frames, instead of > using > hardcoded values for them. The rendering of reference frames may > differ > from machine to machine, especially due to font rendering, and the > frame itself may

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Unbreak gpu reset vs. modeset locking

Op 15-07-17 om 13:40 schreef Daniel Vetter: > Taking the modeset locks unconditionally isn't the greatest idea, > because atm that part is still broken and times out (and then atomic > keels over). And there's really no reason to do so, the old code > didn't do that either. > > To make the patch a

Re: [Intel-gfx] [PATCH i-g-t v4 0/7] CRC testing with Chamelium improvements

The only thing that needs changing is the thing I mentioned on patch #2. After you make sure exiting prematurely doesn't cause the rest of IGT to segfault or something like that, that should hopefully be the last change that will need to be done. Afterwards I will push the whole series at once.

Re: [Intel-gfx] [PATCH] drm/i915: Consistently use enum pipe for PCH transcoders

El Mon, Jul 17, 2017 at 11:07:01AM +0200 Daniel Vetter ha dit: > On Fri, Jul 14, 2017 at 06:04:03PM -0700, Matthias Kaehlcke wrote: > > The current code uses two different enum types for PCH transcoders and > > performs implicit conversions between the two types. This is error prone > > and

[Intel-gfx] [PATCH] drm/i915: Return correct EDP voltage swing table for 0.85V

For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP. Use the correct table. The error was pointed out by this clang warning: drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable 'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted

Re: [Intel-gfx] [PATCH i-g-t 0/1] chamelium: Add support for VGA frame comparison testing

Hey! The only changes I need on this is the small fix I mentioned for patch #2, and a nitpick regarding the spellings being used for the functions. I wasn't sure whether or not we should be using analog or analogue (us spelling vs. everyone else) but apparently the answer is to use the US

[Intel-gfx] [PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders

The current code uses in some instances enum transcoder for PCH transcoders and enum pipe in others. This is error prone and clang raises warnings like this: drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion from enumeration type 'enum pipe' to different enumeration type

Re: [Intel-gfx] [PATCH] drm/i915: Return correct EDP voltage swing table for 0.85V

This makes sense, it should have returned the edp ddi buf translation table as per the Bspec. Please add this to the commit message: Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.") After that, Reviewed-by: Manasi Navare Manasi On Mon, Jul 17,

[Intel-gfx] [PATCH v2] drm/i915: Return correct EDP voltage swing table for 0.85V

For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP. Use the correct table. The error was pointed out by this clang warning: drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable 'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Return correct EDP voltage swing table for 0.85V

== Series Details == Series: drm/i915: Return correct EDP voltage swing table for 0.85V URL : https://patchwork.freedesktop.org/series/27426/ State : success == Summary == Series 27426v1 drm/i915: Return correct EDP voltage swing table for 0.85V

Re: [Intel-gfx] [PATCH] drm/i915: Return correct EDP voltage swing table for 0.85V

Looks like a typo in cf54ca8 ("drm/i915/cnl: Implement voltage swing sequence.") but Cc'ing Rodrigo, Clint to make sure this wasn't a workaround. -DK On Mon, 2017-07-17 at 11:21 -0700, Matthias Kaehlcke wrote: > For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP. > Use

[Intel-gfx] Skylake / (EE) modeset(0): present flip failed loop

Ok, there must be a problem, sent 5 messages to the list with clear details on how the intel driver is failing for me, got one answer from Chris which sadly was a bit too short to give me a good hint of what I should try next or what further debugging I should give to help fix/improve the driver,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Return correct EDP voltage swing table for 0.85V (rev2)

== Series Details == Series: drm/i915: Return correct EDP voltage swing table for 0.85V (rev2) URL : https://patchwork.freedesktop.org/series/27426/ State : success == Summary == Series 27426v2 drm/i915: Return correct EDP voltage swing table for 0.85V

Re: [Intel-gfx] [PATCH] drm/i915: Return correct EDP voltage swing table for 0.85V

On Mon, 2017-07-17 at 18:55 +, Pandiyan, Dhinakaran wrote: > Looks like a typo in > > cf54ca8 ("drm/i915/cnl: Implement voltage swing sequence.") > > but Cc'ing Rodrigo, Clint to make sure this wasn't a workaround. > > -DK Checked with Clint, this wasn't a workaround, a typo indeed.

Re: [Intel-gfx] Skylake / (EE) modeset(0): present flip failed loop

Marc, please file a bug on freedesktop.org. We expect the modesetting driver to work well and if it's not, it should have a bug associated with it. Sorry for your frustration. On 17-07-17 12:22:00, Marc MERLIN wrote: Ok, there must be a problem, sent 5 messages to the list with clear details

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Assert that machine is wedged for nop_submit_request

On 17/07/17 02:11, Chris Wilson wrote: We should only ever do nop_submit_request when the machine is wedged, so assert it is so. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 1 + 1 file changed, 1 insertion(+) diff --git

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/vc4/vc4_crtc.c between commit: 1ed134e6526b ("drm/vc4: Fix VBLANK handling in crtc->enable() path") from the drm-misc-fixes tree and commit: 0b20a0f8c3cb ("drm: Add old state pointer to CRTC

Re: [Intel-gfx] [PATCH] drm/i915: disable KASAN for handlers

On 03/31/2017, 01:23 PM, Arnd Bergmann wrote: > On Fri, Mar 31, 2017 at 12:29 PM, Jani Nikula > wrote: >> On Fri, 31 Mar 2017, Zhenyu Wang wrote: >>> On 2017.03.30 11:46:27 +0200, Jiri Slaby wrote: Handlers are currently the only blocker

[Intel-gfx] [PATCH] drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence

The condition for setting the Loadgen Select bit of PORT_TX_DW4 register during DDI Vswing Sequence should be Bit rate <=6 GHz whereas the existing code checks only Bit Rate < 6GHz. This patch fixes this condition. While at it also remove the redundant paranthesis. Fixes: cf54ca8bc567

Re: [Intel-gfx] [PATCH 05/15] drm/i915: Check execlist/ring status during hangcheck

On 17/07/17 02:11, Chris Wilson wrote: Before we declare an engine as idle, check if there are any pending execlist context-switches and if the ring itself reports as idle. Otherwise, we may be left in a situation where we miss a crucial execlist event (or something more sinister) yet the

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

Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: Caused by commit b6dcaaac4474 ("drm/vblank: _ioctl posfix for ioctl handler") interacting with commit d5288c88c67c ("switch compat_drm_wait_vblank() to drm_ioctl_kernel()") from

Re: [Intel-gfx] [PATCH 13/15] drm/i915: Emit a user level message when resetting the GPU (or engine)

On 17/07/17 02:11, Chris Wilson wrote: Although a banned context will be told to -EIO off if they try to submit more requests, we have a discrepancy between whole device resets and per-engine resets where we report the GPU reset but not the engine resets. This leaves a bit of mystery as to why

Re: [Intel-gfx] [PATCH 14/15] drm/i915: Disable per-engine reset for Broxton

On 17/07/17 02:11, Chris Wilson wrote: Triggering a GPU reset for one engine affects another, notably corrupting the context status buffer (CSB) effectively losing track of inflight requests. Adding a few printks: diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Serialize per-engine resets against new requests

On 17/07/17 02:11, Chris Wilson wrote: We rely on disabling the execlists (by stopping the tasklet) to prevent new requests from submitting to the engine ELSP before we are ready. However, we re-enable the engine before we call init_hw which gives userspace the opportunity to subit a new request

Re: [Intel-gfx] [PATCH 11/15] drm/i915: Clear engine irq posted following a reset

On 17/07/17 02:11, Chris Wilson wrote: When the GPU is reset, we want to discard all pending notifications as either we have manually completed them, or they are no longer applicable. Make sure we do reset the engine->irq_posted prior to re-enabling the engine (e.g. the interrupt tasklets) in

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence

== Series Details == Series: drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence URL : https://patchwork.freedesktop.org/series/27446/ State : success == Summary == Series 27446v1 drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence

  1   2   >