[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

== Series Details == Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable URL : https://patchwork.freedesktop.org/series/21090/ State : success == Summary == Series 21090v1 Series without cover letter

[Intel-gfx] [PATCH 3/3] drm/i915/guc: Update rps.pm_intrmsk_mbz in guc_interrupts_capture/release

Different state is to be maintained for rps.pm_intrmsk_mbz for GuC and Execlists. Updating it inside guc_interrupts_* routines as in those routines GuC load/submission params are sanitized and it should not be set based on HAS_GUC_SCHED during intel_irq_init. Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 2/3] drm/i915: s/pm_intr_keep/pm_intrmsk_mbz

"pm_intr_keep" is not conveying the intent that it is bitmask of interrupts that must be zero(mbz) in GEN6_PMINTRMSK. Name it "pm_intrmsk_mbz". Cc: Chris Wilson Cc: Radoslaw Szwichtenberg Reviewed-by: Chris Wilson

[Intel-gfx] [PATCH 1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

Like capture of GuC interrupts while enabling GuC submission, release them while disabling GuC submission. Cc: Tvrtko Ursulin Cc: Chris Wilson Cc: Oscar Mateo Reviewed-by: Chris Wilson

[Intel-gfx] [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping.

On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has had the surprising behavior of doing a synchronized GTT mapping. This is obviously not what the user of the API wanted. Eric left a comment indicating a valid concern: if the CPU and GPU caches are incoherent, we don't keep track

[Intel-gfx] [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating

Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go to zero after updating db_status before we call the GuC to release the doorbell. Kudos to Daniele for finding this out. Cc: Joonas Lahtinen Cc: Daniele Ceraolo Spurio

[Intel-gfx] [05/11 v2] drm/i915/guc: Break out the GuC log extras into their own "runtime" struct

When initializing the GuC log struct, there is an object we need to allocate always, since the GuC needs its address at fw load time. The rest is only needed during runtime, in the sense that we only create if we actually enable GuC logging. Make that distinction explicit by subdividing further

[Intel-gfx] [03/11 v3] drm/i915/guc: Add onion teardown to the GuC setup

Starting with intel_guc_loader, down to intel_guc_submission and finally to intel_guc_log. v2: - Null execbuf client outside guc_client_free (Daniele) - Assert if things try to get allocated twice (Daniele/Joonas) - Null guc->log.buf_addr when destroyed (Daniele) - Newline between

[Intel-gfx] [07/11] drm/i915/guc: Improve the GuC documentation & comments about proxy submissions

While at it, fix a typo (s/ring_lcra/ring_lrca) and improve the naming of one firware interface field (s/ring_tail/submit_element_info, since it can contain more than just the ring tail). No change in functionality. Signed-off-by: Oscar Mateo ---

[Intel-gfx] [10/11] drm/i915/guc: Refactor the concept "GuC context descriptor" into "GuC stage descriptor"

A GuC context and a HW context are in no way related, so the name "GuC context descriptor" is very unfortunate, because a new reader of the code gets overwhelmed very quickly with a lot of things called "context" that refer to different things. We can improve legibility a lot by simply renaming

[Intel-gfx] [09/11] drm/i915/guc: A little bit more of doorbell sanitization

Some recent refactoring patches have left the doorbell creation outside the GuC client allocation, which does not make a lot of sense (a client without a doorbell is something useless). Move it back there, and refactor the init_doorbell_hw consequently. Thanks to this, we can do some other

[Intel-gfx] [01/11 v3] drm/i915/guc: Sanitize GuC client initialization

Started adding proper teardown to guc_client_alloc, ended up removing quite a few dead ends where errors communicating with the GuC were silently ignored. There also seemed to be quite a few erronous teardown actions performed in case of an error (ordering wrong). v2: - Increase function

[Intel-gfx] [06/11 v3] drm/i915/guc: Make intel_guc_send a function pointer

Prepare for an alternate GuC communication interface. v2: Make a few functions static and name them correctly while we are at it (Oscar), but leave an intel_guc_send_mmio interface for users that require old-style communication. v3: Send intel_uc_init_early back to the top (Michal).

[Intel-gfx] [02/11 v3] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access

The GuC descriptor is big in size. If we use a local definition of guc_desc we have a chance to overflow stack, so avoid it. Also, Chris abhors scatterlists :) v2: Rebased, helper function to retrieve the context descriptor, s/ctx_pool_vma/ctx_pool/ v3: Zero out guc_context_desc before

[Intel-gfx] [00/11 v2] Various improvements around the GuC topic

They have been discussed in various threads, but I am putting them together as a series for clarity. They now include Joonas' "Sanitize GuC client initialization" with a small tweak, plus an extra doorbell refactoring patch at the end, so they are self-contained and... ready to merge?. Oscar

[Intel-gfx] [04/11 v2] drm/i915/guc: s/ads_vma/addon

This vma contains much more than just the additional data struct (ads) and since we were already using the word "addon" as an object in guc_addon_create, make it the preffered one. No need for the vma suffix either, as that dependency is given by the type. While at it, add an explanation of what

Re: [Intel-gfx] [PATCH 2/2] drm/i915/vbt: split out defaults that are set when there is no VBT

On Fri, Mar 10, 2017 at 03:27:58PM +0200, Jani Nikula wrote: > The main thing are the DDI ports. If there's a VBT that says there are > no outputs, we should trust that, and not have semi-random > defaults. Unfortunately, the defaults have resulted in some Chromebooks > without VBT to rely on this

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enhancement to intel_dp_aux_backlight driver

== Series Details == Series: Enhancement to intel_dp_aux_backlight driver URL : https://patchwork.freedesktop.org/series/21086/ State : failure == Summary == Series 21086v1 Enhancement to intel_dp_aux_backlight driver https://patchwork.freedesktop.org/api/1.0/series/21086/revisions/1/mbox/

[Intel-gfx] [PATCH v2 0/4] Enhancement to intel_dp_aux_backlight driver

This patch set contain 4 patches. - First two patches allow enable DPCD backlight control when panel can also do that via PWM pin and fix the usage of enable register. - Next patch adds enable DBC by default - Last patch makes the driver restore last brightness level after turning display off

[Intel-gfx] [PATCH v2 4/4] drm/i915: Store brightness level in aux backlight driver

Some panel will default to zero brightness when turning the panel off and on again. This patch stores last brightness level before turning off and set them back when panel is turning on. Signed-off-by: Puthikorn Voravootivat --- drivers/gpu/drm/i915/intel_dp_aux_backlight.c

[Intel-gfx] [PATCH v2 2/4] drm/i915: Correctly enable blacklight adjustment via DPCD

intel_dp_aux_enable_backlight() assumed that the register BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01 (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize. This patch fixed that by handling all cases of that register. Change-Id: Ic6ee6508d7c4a564bd879f36c9d2b971c49e64bc

[Intel-gfx] [PATCH v2 3/4] drm/i915: Support dynamic backlight via DPCD register

This patch enables dynamic backlight by default for eDP panel that supports this feature via DPCD register and set minimum / maximum brightness to 0% and 100% of the normal brightness. Change-Id: I7140d4e838c654b6527df38b5780ad1533848d6c Signed-off-by: Puthikorn Voravootivat

[Intel-gfx] [PATCH v2 1/4] drm/i915: Add DPCD prefered mode for backlight control

Currently the intel_dp_aux_backlight driver requires eDP panel to not also support backlight adjustment via PWM pin to use this driver. This force the eDP panel that support both ways of backlight adjustment to do it via PWM pin. This patch adds the new prefer DPCD mode in the i915_param to make

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restore engine->submit_request before unwedging (rev2)

== Series Details == Series: drm/i915: Restore engine->submit_request before unwedging (rev2) URL : https://patchwork.freedesktop.org/series/20982/ State : success == Summary == Series 20982v2 drm/i915: Restore engine->submit_request before unwedging

[Intel-gfx] [PATCH v2] drm/i915: Restore engine->submit_request before unwedging

When we wedge the device, we override engine->submit_request with a nop to ensure that all in-flight requests are marked in error. However, igt would like to unwedge the device to test -EIO handling. This requires us to flush those in-flight requests and restore the original

Re: [Intel-gfx] [PATCH] drm/i915: make context status notifier head be per engine

On Thu, Mar 09, 2017 at 07:27:24PM +0800, changbin...@intel.com wrote: > From: Changbin Du > > GVTg has introduced the context status notifier to schedule the GVTg > workload. At that time, the notifier is bound to GVTg context only, > so GVTg is not aware of host

[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC: drm/i915: annote drop_caches debugfs interface with lockdep

== Series Details == Series: RFC: drm/i915: annote drop_caches debugfs interface with lockdep URL : https://patchwork.freedesktop.org/series/21063/ State : failure == Summary == CHECK usr/include/linux/hdlc/ (1 files) CHECK usr/include/linux/spi/ (1 files) CHECK

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/vbt: defaults handling for no VBT case

== Series Details == Series: drm/i915/vbt: defaults handling for no VBT case URL : https://patchwork.freedesktop.org/series/21061/ State : failure == Summary == Series 21061v1 drm/i915/vbt: defaults handling for no VBT case

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged (rev2)

== Series Details == Series: drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged (rev2) URL : https://patchwork.freedesktop.org/series/21030/ State : success == Summary == Series 21030v2 drm/i915: Wait for reset to complete before returning from

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: Stop using RP_DOWN_EI on Baytrail

On Fri, Mar 10, 2017 at 04:10:29PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Baytrail, we manually calculate busyness over the evaluation interval > > to avoid issues with miscaluations with RC6 enabled. However, it turns > > out that the DOWN_EI

[Intel-gfx] ✗ Fi.CI.BAT: warning for GuC Scrub vol. 1 (rev11)

== Series Details == Series: GuC Scrub vol. 1 (rev11) URL : https://patchwork.freedesktop.org/series/16856/ State : warning == Summary == Series 16856v11 GuC Scrub vol. 1 https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/11/mbox/ Test gem_exec_flush: Subgroup

[Intel-gfx] [PATCH i-g-t 1/2] lib: Add i915 and drm-mm selftest headers from the kernel

Copied as of commit commit 496b575e3ccbf6fbe57a674c721af43dc8826361 Author: Chris Wilson Date: Mon Feb 13 17:15:58 2017 + drm/i915: Add initial selftests for hang detection and resets The headers are used to enumerate available tests when the running

[Intel-gfx] [PATCH i-g-t 0/2] Kernel selftest plumbing

IGT subtest enumeration must work regardless of what the running environment is. Kernel selftest launchers want to expose everything the running kernel can execute. These two things are mutually exclusive. This series is an attempt for a best-of-both-worlds approach: After constructing subtests

[Intel-gfx] [PATCH i-g-t 2/2] Always expose IGT subtests for known kernel selftests

Even when the running kernel does not support selftests, make subtest enumeration list known kselftests. The list is generated using selftest listing headers copied from the kernel. If the running kernel gains new selftest subtests, they are listed even without copying the headers over and

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: Stop using RP_DOWN_EI on Baytrail

On Fri, Mar 10, 2017 at 04:10:29PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Baytrail, we manually calculate busyness over the evaluation interval > > to avoid issues with miscaluations with RC6 enabled. However, it turns > > out that the DOWN_EI

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Defer unmasking RPS interrupts until after making adjustments

Chris Wilson writes: > To make our adjustments to RPS requires taking a mutex and potentially > sleeping for an unknown duration - until we have completed our > adjustments further RPS interrupts are immaterial (they are based on > stale thresholds) and we can safely

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: Stop using RP_DOWN_EI on Baytrail

Chris Wilson writes: > On Baytrail, we manually calculate busyness over the evaluation interval > to avoid issues with miscaluations with RC6 enabled. However, it turns > out that the DOWN_EI interrupt generator is completely bust - it > operates in two modes,

Re: [Intel-gfx] [PATCH 1/2] drm/i915/vbt: don't propagate errors from intel_bios_init()

On Fri, Mar 10, 2017 at 03:27:57PM +0200, Jani Nikula wrote: > We don't use the error return for anything other than reporting and > logging that there is no VBT. We can pull the logging in the function, > and remove the error status return. Moreover, if we needed the > information for something

Re: [Intel-gfx] [PATCH] RFC: drm/i915: annote drop_caches debugfs interface with lockdep

On Fri, Mar 10, 2017 at 02:31:22PM +0100, Daniel Vetter wrote: > The trouble we have is that we can't really test all the shrinker > recursion stuff exhaustively in BAT because any kind of thrashing > stress test just takes too long. > > But that leaves a really big gap open, since shrinker

Re: [Intel-gfx] [PATCH] drm/i915: Extend debugfs/i915_drop_caches to call i915_gem_shrink_all()

On Fri, Mar 10, 2017 at 01:06:51PM +, Tvrtko Ursulin wrote: > > On 08/03/2017 14:46, Chris Wilson wrote: > >Sometimes we want to explicitly page out all available objects from igt, > >i.e. call i915_gem_shrink_all() and check that subsequent operations > >succeed. This adds DROP_SHRINK_ALL

[Intel-gfx] [PATCH] RFC: drm/i915: annote drop_caches debugfs interface with lockdep

The trouble we have is that we can't really test all the shrinker recursion stuff exhaustively in BAT because any kind of thrashing stress test just takes too long. But that leaves a really big gap open, since shrinker recursions are one of the most annoying bugs. Now lockdep already has support

[Intel-gfx] [PATCH 0/2] drm/i915/vbt: defaults handling for no VBT case

This is my proposed alternative to [1]. BR, Jani. [1] http://patchwork.freedesktop.org/patch/msgid/1488546102-27789-1-git-send-email-manasi.d.nav...@intel.com Jani Nikula (2): drm/i915/vbt: don't propagate errors from intel_bios_init() drm/i915/vbt: split out defaults that are set when

[Intel-gfx] [PATCH 2/2] drm/i915/vbt: split out defaults that are set when there is no VBT

The main thing are the DDI ports. If there's a VBT that says there are no outputs, we should trust that, and not have semi-random defaults. Unfortunately, the defaults have resulted in some Chromebooks without VBT to rely on this behaviour, so we split out the defaults for the missing VBT case.

[Intel-gfx] [PATCH 1/2] drm/i915/vbt: don't propagate errors from intel_bios_init()

We don't use the error return for anything other than reporting and logging that there is no VBT. We can pull the logging in the function, and remove the error status return. Moreover, if we needed the information for something later on, we'd probably be better off storing the bit in dev_priv, and

Re: [Intel-gfx] [PATCH] drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged

On 10/03/2017 13:23, Chris Wilson wrote: On Fri, Mar 10, 2017 at 01:14:33PM +, Tvrtko Ursulin wrote: On 10/03/2017 12:21, Chris Wilson wrote: Provide some serialisation between user operations by waiting for the reset initiated by setting i915_wedged to complete. Signed-off-by: Chris

Re: [Intel-gfx] [PATCH] drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged

On Fri, Mar 10, 2017 at 01:14:33PM +, Tvrtko Ursulin wrote: > > On 10/03/2017 12:21, Chris Wilson wrote: > >Provide some serialisation between user operations by waiting for the > >reset initiated by setting i915_wedged to complete. > > > >Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH v3] drm/i915/cmdparser: Limit clflush to active cachelines

On Fri, Mar 10, 2017 at 02:41:16PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > We only need to clflush those cachelines that we have validated to be > > read by the GPU. Userspace typically fills the batch length in > > correctly, the exceptions tend to be

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Improve rounding caused by pre-CSC gamma tables

== Series Details == Series: drm/i915/glk: Improve rounding caused by pre-CSC gamma tables URL : https://patchwork.freedesktop.org/series/21049/ State : success == Summary == Series 21049v1 drm/i915/glk: Improve rounding caused by pre-CSC gamma tables

Re: [Intel-gfx] [PATCH] drm/i915: Restore engine->submit_request before unwedging

On Fri, Mar 10, 2017 at 12:59:47PM +, Tvrtko Ursulin wrote: > > On 09/03/2017 10:22, Chris Wilson wrote: > >+void i915_gem_unset_wedged(struct drm_i915_private *dev_priv) > >+{ > >+struct i915_gem_timeline *tl; > >+int i; > >+ > >+lockdep_assert_held(_priv->drm.struct_mutex); > >+

Re: [Intel-gfx] [PATCH] drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged

On 10/03/2017 12:21, Chris Wilson wrote: Provide some serialisation between user operations by waiting for the reset initiated by setting i915_wedged to complete. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala

Re: [Intel-gfx] [PATCH] drm/i915: Extend debugfs/i915_drop_caches to call i915_gem_shrink_all()

On 08/03/2017 14:46, Chris Wilson wrote: Sometimes we want to explicitly page out all available objects from igt, i.e. call i915_gem_shrink_all() and check that subsequent operations succeed. This adds DROP_SHRINK_ALL [0x8] to the set of flags for Not 0x20 ? debugfs/i915_drop_caches.

Re: [Intel-gfx] [PATCH] drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly

Chris Wilson writes: > On Fri, Mar 10, 2017 at 09:57:47AM +, Tvrtko Ursulin wrote: >> From: Tvrtko Ursulin >> >> If we avoid initializing forcewake domains when running as >> a guest, and also use gen2 mmio accessors in that case, we >>

Re: [Intel-gfx] [PATCH] drm/i915: Restore engine->submit_request before unwedging

On 09/03/2017 10:22, Chris Wilson wrote: When we wedge the device, we override engine->submit_request with a nop to ensure that all in-flight requests are marked in error. However, igt would like to unwedge the device to test -EIO handling. This requires us to flush those in-flight requests and

Re: [Intel-gfx] [PATCH] drm/i915/glk: Improve rounding caused by pre-CSC gamma tables

On Fri, Mar 10, 2017 at 12:18:34PM +0200, Ander Conselvan de Oliveira wrote: > The 33rd entry in the pre-CSC gamma table in Geminilake can represent a > value of 1.0 as 17 bits fixed point with one integer bit. However, the > table was generated such that the value of 1.0 would be 0. with >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly

== Series Details == Series: drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly URL : https://patchwork.freedesktop.org/series/21047/ State : success == Summary == Series 21047v1 drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly

Re: [Intel-gfx] [PATCH v3] drm/i915/cmdparser: Limit clflush to active cachelines

Chris Wilson writes: > We only need to clflush those cachelines that we have validated to be > read by the GPU. Userspace typically fills the batch length in > correctly, the exceptions tend to be explicit tests within igt. > > v2: Use ptr_mask_bits() to make Mika happy

[Intel-gfx] [PATCH 3.16 260/370] drm/i915: Don't leak edid in intel_crt_detect_ddc()

3.16.42-rc1 review patch. If anyone has any objections, please let me know. -- From: Ander Conselvan de Oliveira commit c34f078675f505c4437919bb1897b1351f16a050 upstream. In the path where intel_crt_detect_ddc() detects a CRT, if would

[Intel-gfx] [PATCH] drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged

Provide some serialisation between user operations by waiting for the reset initiated by setting i915_wedged to complete. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala ---

Re: [Intel-gfx] [PATCH v6] drm/i915/guc: Simplify intel_guc_init_hw()

On Fri, Mar 10, 2017 at 12:46:06PM +0100, Arkadiusz Hiler wrote: > Current version of intel_guc_init_hw() does a lot: > - cares about submission > - loads huc > - implement WA > > This change offloads some of the logic to intel_uc_init_hw(), which now > cares about the above. > > v2: rename

[Intel-gfx] [PATCH v3] drm/i915/cmdparser: Limit clflush to active cachelines

We only need to clflush those cachelines that we have validated to be read by the GPU. Userspace typically fills the batch length in correctly, the exceptions tend to be explicit tests within igt. v2: Use ptr_mask_bits() to make Mika happy v3: cmd is not advanced on MI_BBE, so make sure to

Re: [Intel-gfx] [PATCH v3] drm/i915: Fix forcewake active domain tracking

On 10/03/2017 10:54, Chris Wilson wrote: On Fri, Mar 10, 2017 at 09:32:49AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In commit 003342a50021 ("drm/i915: Keep track of active forcewake domains in a bitmask") I forgot to adjust the newly introduce

[Intel-gfx] [PATCH v6] drm/i915/guc: Simplify intel_guc_init_hw()

Current version of intel_guc_init_hw() does a lot: - cares about submission - loads huc - implement WA This change offloads some of the logic to intel_uc_init_hw(), which now cares about the above. v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko) v3: rename once again v4:

Re: [Intel-gfx] [PATCH v2] drm/i915/cmdparser: Limit clflush to active cachelines

On Fri, Mar 10, 2017 at 01:19:01PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > We only need to clflush those cachelines that we have validated to be > > read by the GPU. Userspace typically fills the batch length in > > correctly, the exceptions tend to be

Re: [Intel-gfx] [PATCH v2] drm/i915/cmdparser: Limit clflush to active cachelines

Chris Wilson writes: > We only need to clflush those cachelines that we have validated to be > read by the GPU. Userspace typically fills the batch length in > correctly, the exceptions tend to be explicit tests within igt. > > v2: Use ptr_mask_bits() to make Mika happy

Re: [Intel-gfx] [PATCH v3] drm/i915: Fix forcewake active domain tracking

On Fri, Mar 10, 2017 at 09:32:49AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In commit 003342a50021 ("drm/i915: Keep track of active > forcewake domains in a bitmask") I forgot to adjust the > newly introduce fw_domains_active state across reset. > > This

Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: Limit clflush to active cachelines

On Fri, Mar 10, 2017 at 12:42:34PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Fri, Mar 10, 2017 at 12:26:10PM +0200, Mika Kuoppala wrote: > >> Chris Wilson writes: > >> > >> > On Fri, Mar 10, 2017 at 10:04:16AM +, Chris

[Intel-gfx] [PATCH v2] drm/i915/cmdparser: Limit clflush to active cachelines

We only need to clflush those cachelines that we have validated to be read by the GPU. Userspace typically fills the batch length in correctly, the exceptions tend to be explicit tests within igt. v2: Use ptr_mask_bits() to make Mika happy Signed-off-by: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix forcewake active domain tracking (rev4)

== Series Details == Series: drm/i915: Fix forcewake active domain tracking (rev4) URL : https://patchwork.freedesktop.org/series/21004/ State : success == Summary == Series 21004v4 drm/i915: Fix forcewake active domain tracking

Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: Limit clflush to active cachelines

Chris Wilson writes: > On Fri, Mar 10, 2017 at 12:26:10PM +0200, Mika Kuoppala wrote: >> Chris Wilson writes: >> >> > On Fri, Mar 10, 2017 at 10:04:16AM +, Chris Wilson wrote: >> >> On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala

Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: Limit clflush to active cachelines

On Fri, Mar 10, 2017 at 12:26:10PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Fri, Mar 10, 2017 at 10:04:16AM +, Chris Wilson wrote: > >> On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala wrote: > >> > Chris Wilson

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c

On Thu, 2017-03-09 at 17:17 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Remove intel_ prefix from encoder variables in intel_ddi.c > URL : https://patchwork.freedesktop.org/series/20992/ > State : success Pushed to drm-intel-next-queued. Thanks for the patch. Ander >

Re: [Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Add a subtest with a 256x256 gradient cursor

On Fri, 2017-03-10 at 12:18 +0200, Ander Conselvan de Oliveira wrote: > Some of the kms_cursor_crc subtests where failing on Geminilake. The > root cause was an error on programming the pre-CSC gamma tables, which > led to small rounding errors that, although not sufficient to change the > image

Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: Limit clflush to active cachelines

Chris Wilson writes: > On Fri, Mar 10, 2017 at 10:04:16AM +, Chris Wilson wrote: >> On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala wrote: >> > Chris Wilson writes: >> > >> > > We only need to clflush those cachelines that we have

Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: Limit clflush to active cachelines

On Fri, Mar 10, 2017 at 10:04:16AM +, Chris Wilson wrote: > On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala wrote: > > Chris Wilson writes: > > > > > We only need to clflush those cachelines that we have validated to be > > > read by the GPU. Userspace

[Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Add a subtest with a 256x256 gradient cursor

Some of the kms_cursor_crc subtests where failing on Geminilake. The root cause was an error on programming the pre-CSC gamma tables, which led to small rounding errors that, although not sufficient to change the image as captured at 8bpc with the Chamelium, were enough to generate a different

[Intel-gfx] [PATCH] drm/i915/glk: Improve rounding caused by pre-CSC gamma tables

The 33rd entry in the pre-CSC gamma table in Geminilake can represent a value of 1.0 as 17 bits fixed point with one integer bit. However, the table was generated such that the value of 1.0 would be 0. with all the intervals scaled accordingly. For instance, 0.5 mapped to 0.7fff instead of

Re: [Intel-gfx] [PATCH] drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly

On Fri, Mar 10, 2017 at 09:57:47AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > If we avoid initializing forcewake domains when running as > a guest, and also use gen2 mmio accessors in that case, we > can avoid the timer traffic and any looping through the >

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Optimize VLV/CHV display FIFO updates

On Thu, Mar 09, 2017 at 09:26:36PM +, Chris Wilson wrote: > On Thu, Mar 09, 2017 at 05:44:34PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Use I915_{READ,WRITE}_FW() for updating the DSPARB registers on > > VLV/CHV. This is less

Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: Limit clflush to active cachelines

On Fri, Mar 10, 2017 at 11:58:44AM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > We only need to clflush those cachelines that we have validated to be > > read by the GPU. Userspace typically fills the batch length in > > correctly, the exceptions tend to be

Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: Limit clflush to active cachelines

Chris Wilson writes: > We only need to clflush those cachelines that we have validated to be > read by the GPU. Userspace typically fills the batch length in > correctly, the exceptions tend to be explicit tests within igt. > > Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] drm/i915/vgpu: Neuter forcewakes for VGPU more thouroughly

From: Tvrtko Ursulin If we avoid initializing forcewake domains when running as a guest, and also use gen2 mmio accessors in that case, we can avoid the timer traffic and any looping through the forcewake code which is currently just so it can end up in the no-op

[Intel-gfx] [PATCH] drm/i915/cmdparser: Limit clflush to active cachelines

We only need to clflush those cachelines that we have validated to be read by the GPU. Userspace typically fills the batch length in correctly, the exceptions tend to be explicit tests within igt. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_cmd_parser.c |

[Intel-gfx] [PATCH v3] drm/i915: Fix forcewake active domain tracking

From: Tvrtko Ursulin In commit 003342a50021 ("drm/i915: Keep track of active forcewake domains in a bitmask") I forgot to adjust the newly introduce fw_domains_active state across reset. This caused the assert_forcewakes_inactive to trigger during suspend and resume if

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix forcewake active domain tracking (rev2)

== Series Details == Series: drm/i915: Fix forcewake active domain tracking (rev2) URL : https://patchwork.freedesktop.org/series/21004/ State : success == Summary == Series 21004v2 drm/i915: Fix forcewake active domain tracking

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix forcewake active domain tracking

On 10/03/2017 08:50, Chris Wilson wrote: On Fri, Mar 10, 2017 at 07:32:51AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In commit 003342a50021 ("drm/i915: Keep track of active forcewake domains in a bitmask") I forgot to adjust the newly introduce

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged

== Series Details == Series: drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged URL : https://patchwork.freedesktop.org/series/21030/ State : success == Summary == Series 21030v1 drm/i915: Wait for reset to complete before returning from debugfs/i915_wedged

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix vGPU balloon for ggtt guard page (rev2)

== Series Details == Series: drm/i915: Fix vGPU balloon for ggtt guard page (rev2) URL : https://patchwork.freedesktop.org/series/20983/ State : success == Summary == Series 20983v2 drm/i915: Fix vGPU balloon for ggtt guard page

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move whole object to CPU domain for coherent shmem access

== Series Details == Series: drm/i915: Move whole object to CPU domain for coherent shmem access URL : https://patchwork.freedesktop.org/series/21020/ State : failure == Summary == Series 21020v1 drm/i915: Move whole object to CPU domain for coherent shmem access

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Forward declare struct platform_device

== Series Details == Series: drm: Forward declare struct platform_device URL : https://patchwork.freedesktop.org/series/21017/ State : success == Summary == Series 21017v1 drm: Forward declare struct platform_device https://patchwork.freedesktop.org/api/1.0/series/21017/revisions/1/mbox/

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/3] drm/i915: Stop using RP_DOWN_EI on Baytrail

== Series Details == Series: series starting with [v3,1/3] drm/i915: Stop using RP_DOWN_EI on Baytrail URL : https://patchwork.freedesktop.org/series/21014/ State : success == Summary == Series 21014v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3] drm/i915: Stop using RP_DOWN_EI on Baytrail (rev2)

== Series Details == Series: series starting with [v3] drm/i915: Stop using RP_DOWN_EI on Baytrail (rev2) URL : https://patchwork.freedesktop.org/series/20314/ State : success == Summary == Series 20314v2 Series without cover letter

[Intel-gfx] [CI] drivers/gpu/drm/i915/selftests/i915_selftest.c: fix build with gcc-4.4.4

From: Andrew Morton gcc-4.4.4 has issues with anonymous union initializers. In file included from drivers/gpu/drm/i915/selftests/i915_selftest.c:68: drivers/gpu/drm/i915/selftests/i915_mock_selftests.h:11: error: unknown field 'mock' specified in initializer

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix forcewake active domain tracking

On Fri, Mar 10, 2017 at 07:32:51AM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In commit 003342a50021 ("drm/i915: Keep track of active > forcewake domains in a bitmask") I forgot to adjust the > newly introduce fw_domains_active state across reset. > > This

[Intel-gfx] [patch 1/1] drivers/gpu/drm/i915/selftests/i915_selftest.c: fix build with gcc-4.4.4

From: Andrew Morton Subject: drivers/gpu/drm/i915/selftests/i915_selftest.c: fix build with gcc-4.4.4 gcc-4.4.4 has issues with anonymous union initializers. In file included from drivers/gpu/drm/i915/selftests/i915_selftest.c:68: