Re: [Intel-gfx] [i-g-t PATCH v2] tests: do snd_hda_intel unbind before unload in module reload test

Reviewed-by: Libin Yang Regards, Libin > -Original Message- > From: Nikula, Jani > Sent: Monday, October 31, 2016 7:00 PM > To: Nikula, Jani ; intel-gfx@lists.freedesktop.org > Cc: Zhang, Keqiao ; Yang, Libin >

Re: [Intel-gfx] [PATCH 0/2] drm/i915/opregion: proper handling of DIDL and CADL

Your patches fixed the problem in my Asus X450LCP. I'm also looking further to see these patches to land in master. Thanks, On Mon, Oct 31, 2016 at 10:32 AM Jani Nikula wrote: > On Mon, 31 Oct 2016, Jani Nikula wrote: > > On Mon, 31 Oct 2016,

[Intel-gfx] [PATCH] drm/i915/huc: Update the construction of file path for HuC similar to that of GuC

Update the file construction and specifying the required version similar to that of GuC.Add an extra field for the build number. Adopted the approach used in https://patchwork.freedesktop.org/patch/104355/ Cc: Jeff Mcgee Signed-off-by: Anusha Srivatsa

[Intel-gfx] ✗ Fi.CI.BAT: failure for Handle link training failure during modeset for DDI (rev2)

== Series Details == Series: Handle link training failure during modeset for DDI (rev2) URL : https://patchwork.freedesktop.org/series/14556/ State : failure == Summary == Series 14556v2 Handle link training failure during modeset for DDI

Re: [Intel-gfx] [PATCH v8 07/12] drm/i915: Enable i915 perf stream for Haswell OA unit

On 28 October 2016 at 03:14, Robert Bragg wrote: > Gen graphics hardware can be set up to periodically write snapshots of > performance counters into a circular buffer via its Observation > Architecture and this patch exposes that capability to userspace via the > i915 perf

[Intel-gfx] [PATCH v3 1/4] drm: Add a new connector property for link status

A new default connector property is added for keeping track of whether the link is good (link training passed) or link is bad (link training failed). If the link status property is not good, then userspace should fire off a new modeset at the current mode even if there have not been any changes

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A game of OCD dominoes

== Series Details == Series: drm/i915: A game of OCD dominoes URL : https://patchwork.freedesktop.org/series/14634/ State : warning == Summary == Series 14634v1 drm/i915: A game of OCD dominoes https://patchwork.freedesktop.org/api/1.0/series/14634/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Use the full hammer when shutting down the rcu tasks

On Mon, Oct 31, 2016 at 05:15:45PM +, Tvrtko Ursulin wrote: > > On 31/10/2016 10:26, Chris Wilson wrote: > >To flush all call_rcu() tasks (here from i915_gem_free_object()) we need > >to call rcu_barrier() (not synchronize_rcu()). If we don't then we may > >still have objects being freed as

Re: [Intel-gfx] [PATCH] i915/GuC: Make GuC loads default

I agree that the parameter controls could use a clean-up, which could include eventual removal of the enable_guc_loading parameter. But for now loading parameter should be auto by default. Might be a good idea to temporarily set the has_guc parameter to 0 for BXT and KBL since those firmwares

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Avoid accessing request->timeline outside of its lifetime

On Mon, Oct 31, 2016 at 05:35:50PM +, Tvrtko Ursulin wrote: > > On 31/10/2016 10:26, Chris Wilson wrote: > >Whilst waiting on a request, we may do so without holding any locks or > >any guards beyond a reference to the request. In order to avoid taking > >locks within request deallocation, we

Re: [Intel-gfx] [PATCH 00/26] drm/i915: A game of OCD dominoes

On Mon, Oct 31, 2016 at 10:36:59PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I pretty much just wanted to store struct intel_crtc * instead > of struct drm_crtc * in pipe_to_crtc_mapping[] & co. but to > achieve it cleanly I ended up

[Intel-gfx] [PATCH 22/26] drm/i915: Pass dev_priv to single_enabled_crtc()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 22 +- 1 file changed, 9 insertions(+), 13

[Intel-gfx] [PATCH 25/26] drm/i915: Pass dev_priv to ilk_setup_wm_latency() & co.

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 38 +++--- 1 file changed, 15

[Intel-gfx] [PATCH 09/26] drm/i915: Pass dev_priv to g4x wm functions

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-)

[Intel-gfx] [PATCH 08/26] drm/i915: Pass dev_priv to vlv force pll functions

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 14 +++--- drivers/gpu/drm/i915/intel_dp.c | 7

[Intel-gfx] [PATCH 19/26] drm/i915: Pass dev_priv to HAS_FW_BLC

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_pm.c | 2 +- 2 files changed, 2

[Intel-gfx] [PATCH 23/26] drm/i915: Pass dev_priv to init_clock_gating

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_drv.h | 2 +-

[Intel-gfx] [PATCH 18/26] drm/i915: Pass dev_priv to .get_fifo_size()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_pm.c | 22 +- 2

[Intel-gfx] [PATCH 17/26] drm/i915: Pass dev_priv to i915_pineview_get_mem_freq() and i915_ironlake_get_mem_freq()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff

[Intel-gfx] [PATCH 13/26] drm/i915: Pass dev_priv to cdclk update funcs

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 35 +++ 1 file changed, 15

[Intel-gfx] [PATCH 15/26] drm/i915: Pass dev_priv to IS_MOBILE()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 8 +++-

[Intel-gfx] [PATCH 12/26] drm/i915: Pass dev_priv to intel_crtc_init()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-)

[Intel-gfx] [PATCH 06/26] drm/i915: Store struct intel_crtc * in {pipe, plane}_to_crtc_mapping[]

From: Ville Syrjälä A lot of users of the {pipe,plane}_to_crtc_mapping[] will end up casting the result to intel_crtc, so let's just store the intel_crtc pointer in the first place. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 10/26] drm/i915: Pass dev_priv to intel_get_crtc_for_pipe()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_debugfs.c | 3 +-- drivers/gpu/drm/i915/i915_irq.c | 5 +++--

[Intel-gfx] [PATCH 26/26] drm/i915: Pass dev_priv to intel_init_pm()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 2 +-

[Intel-gfx] [PATCH 24/26] drm/i915: Pass dev_priv to intel_suspend_hw()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 2 +-

[Intel-gfx] [PATCH 07/26] drm/i915: Pass dev_priv to intel_wait_for_vblank()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/intel_crt.c | 2 +-

[Intel-gfx] [PATCH 20/26] drm/i915: Pass dev_priv to IS_BROADWATER/IS_CRESTLINE

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.c | 3 +-- drivers/gpu/drm/i915/i915_drv.h | 4 ++--

[Intel-gfx] [PATCH 21/26] drm/i915: Pass dev_priv to rest of IS_FOO() macros for the old platforms

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h| 8 drivers/gpu/drm/i915/i915_gem_stolen.c | 4 ++--

[Intel-gfx] [PATCH 11/26] drm/i915: Always use intel_get_crtc_for_pipe()

From: Ville Syrjälä Replace the open coded dev_priv->pipe_to_crtc_mapping[] usage with intel_get_crtc_for_pipe(). Mostly done with coccinelle, with a few manual tweaks @@ expression E1, E2; @@ ( - E1->pipe_to_crtc_mapping[E2] + intel_get_crtc_for_pipe(E1, E2) | -

[Intel-gfx] [PATCH 16/26] drm/i915: Pass dev_priv to IS_PINEVIEW()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 19

[Intel-gfx] [PATCH 14/26] drm/i915: Pass dev_priv to .get_display_clock_speed()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_display.c| 77

[Intel-gfx] [PATCH 05/26] drm/i915: Use struct intel_crtc in legacy platform wm code

From: Ville Syrjälä Unify our approach to things by using intel_crtc instead of drm_crtc. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 109 1 file changed, 67

[Intel-gfx] [PATCH 04/26] drm/i915: Pass intel_crtc to update_wm functions

From: Ville Syrjälä Unify our approach to things by passing around intel_crtc instead of drm_crtc. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 14 +-

[Intel-gfx] [PATCH 00/26] drm/i915: A game of OCD dominoes

From: Ville Syrjälä I pretty much just wanted to store struct intel_crtc * instead of struct drm_crtc * in pipe_to_crtc_mapping[] & co. but to achieve it cleanly I ended up chasing quite few different things that were accepting the wrong kind of type. And once I

[Intel-gfx] [PATCH 01/26] drm/i915: Pass dev_priv to plane constructors

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 40

[Intel-gfx] [PATCH 03/26] drm/i915: Pass intel_crtc to intel_crtc_active()

From: Ville Syrjälä Unify our approach to things by passing around intel_crtc instead of drm_crtc. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 8 +++- drivers/gpu/drm/i915/intel_drv.h | 2 +-

[Intel-gfx] [PATCH 02/26] drm/i915: Pass dev_priv to skl_init_scalers()

From: Ville Syrjälä Unify our approach to things by passing around dev_priv instead of dev. While at it let's do some house cleaning: s/intel_foo/foo/ and move things into tighter scope. Signed-off-by: Ville Syrjälä ---

Re: [Intel-gfx] [PATCH 7/7] drm/i915/get_params: Add HuC status to getparams

Patch set header includes links to libva intent to use the interface. Thanks Reviewed-by: Jeff McGee On Fri, Oct 28, 2016 at 05:05:46PM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > This patch will allow for getparams to return the

Re: [Intel-gfx] [PATCH 6/7] drm/i915/huc: Add BXT HuC Loading Support

On Fri, Oct 28, 2016 at 05:05:45PM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > This patch adds the HuC Loading for the BXT. > Version 1.7 of the HuC firmware. > > v2: rebased. > v3: rebased. > changed file name to match the install package format. > v7:

Re: [Intel-gfx] [PATCH 5/7] drm/i915/huc: Support HuC authentication

Reviewed-by: Jeff McGee On Fri, Oct 28, 2016 at 05:05:44PM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > The HuC authentication is done by host2guc call. The HuC RSA keys > are sent to GuC for authentication. > > v2: rebased on top of

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

On Fri, Oct 28, 2016 at 05:05:42PM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > The HuC loading process is similar to GuC. The intel_uc_fw_fetch() > is used for both cases. > > HuC loading needs to be before GuC loading. The WOPCM setting must > be done early

Re: [Intel-gfx] [PATCH 2/7] drm/i915/huc: Unified css_header struct for GuC and HuC

Reviewed-by: Jeff McGee On Fri, Oct 28, 2016 at 05:05:41PM -0700, Anusha Srivatsa wrote: > From: Peter Antoine > > HuC firmware css header has almost exactly same definition as GuC > firmware except for the sw_version. Also, add a new member

Re: [Intel-gfx] [PATCH v8 02/12] drm/i915: Add i915 perf infrastructure

On Mon, Oct 31, 2016 at 5:13 PM, Matthew Auld < matthew.william.a...@gmail.com> wrote: > On 31 October 2016 at 16:27, Robert Bragg wrote: > > > > > > On Fri, Oct 28, 2016 at 3:27 PM, Matthew Auld > > wrote: > >> > >> > +/* Note we copy the

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915/skl+: use linetime latency instead of ddb size

Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu: > This patch make changes to use linetime latency instead of allocated > DDB size during plane watermark calculation in switch case, This is > required to implement new DDB allocation algorithm. > > In New Algorithm DDB is allocated based

Re: [Intel-gfx] [PATCH] drm/i915: rename preliminary_hw_support to alpha_support

On Mon, 31 Oct 2016, "Vivi, Rodrigo" wrote: > I was about to put my rv-b here. I do believe we need to find a better > name and the patch was clear and correct. And indeed in a good timing. > > However right before clicking the send button I had a vision that this > will

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Avoid accessing request->timeline outside of its lifetime

On 31/10/2016 10:26, Chris Wilson wrote: Whilst waiting on a request, we may do so without holding any locks or any guards beyond a reference to the request. In order to avoid taking locks within request deallocation, we drop references to its timeline (via the context and ppgtt) upon

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Use the full hammer when shutting down the rcu tasks

On 31/10/2016 10:26, Chris Wilson wrote: To flush all call_rcu() tasks (here from i915_gem_free_object()) we need to call rcu_barrier() (not synchronize_rcu()). If we don't then we may still have objects being freed as we continue to teardown the driver - in particular, the recently released

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gtt: Mark tlbs dirty on clear

On Mon, Oct 31, 2016 at 05:58:15PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Mon, Oct 31, 2016 at 05:24:46PM +0200, Mika Kuoppala wrote: > >> Now when clearing ptes can modify upper level pdp's, > >> we need to mark them dirty so that they will be

Re: [Intel-gfx] [PATCH v8 02/12] drm/i915: Add i915 perf infrastructure

On 31 October 2016 at 16:27, Robert Bragg wrote: > > > On Fri, Oct 28, 2016 at 3:27 PM, Matthew Auld > wrote: >> >> > +/* Note we copy the properties from userspace outside of the i915 perf >> > + * mutex to avoid an awkward lockdep with

Re: [Intel-gfx] [PATCH] i915/GuC: Make GuC loads default

Could someone please ack this? We need this before getting HuC. GuC submission has regressions so the submission is not getting enabled. But we need to have GuC loaded to be able to use HuC. Thanks, Rodrigo. On Thu, Oct 6, 2016 at 11:08 AM, Rodrigo Vivi wrote: > I also

Re: [Intel-gfx] [PATCH] drm/i915: rename preliminary_hw_support to alpha_support

I was about to put my rv-b here. I do believe we need to find a better name and the patch was clear and correct. And indeed in a good timing. However right before clicking the send button I had a vision that this will bring another kind of confusion and miss leading. Traditionally this tag has

Re: [Intel-gfx] [PATCH v8 02/12] drm/i915: Add i915 perf infrastructure

On Fri, Oct 28, 2016 at 3:27 PM, Matthew Auld < matthew.william.a...@gmail.com> wrote: > > +/* Note we copy the properties from userspace outside of the i915 perf > > + * mutex to avoid an awkward lockdep with mmap_sem. > > + * > > + * Note this function only validates properties in isolation it

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_userptr_blits: Test object invalidation more thoroughly

On Mon, Oct 31, 2016 at 03:36:15PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Verify that the userspace will get told if it changes to what the userptr > object backing store points to, *after* having created the GEM object. > > Two variants are tested: >

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/gtt: Fix pte clear range (rev2)

== Series Details == Series: series starting with [1/2] drm/i915/gtt: Fix pte clear range (rev2) URL : https://patchwork.freedesktop.org/series/14620/ State : warning == Summary == Series 14620v2 Series without cover letter

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Set link status property for DP connector

On Sat, 29 Oct 2016, Manasi Navare wrote: > This defines a helper function to set the property value. > This will be used to set the link status to Bad in case > of link training failures. > > v2: > * Simplify the return value (Jani Nikula) > > Cc:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gtt: Mark tlbs dirty on clear

Chris Wilson writes: > On Mon, Oct 31, 2016 at 05:24:46PM +0200, Mika Kuoppala wrote: >> Now when clearing ptes can modify upper level pdp's, >> we need to mark them dirty so that they will be flushed >> correctly. > > I suppose so. It is a bit iffy if we really do,

[Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

Comparing pte index to a number of entries is wrong when clearing a range of pte entries. Use end marker of 'one past' to correctly point adequate number of ptes to the scratch page. v2: assert early instead of warning late (Chris) Fixes: d209b9c3cd28 ("drm/i915/gtt: Split

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gtt: Mark tlbs dirty on clear

On Mon, Oct 31, 2016 at 05:24:46PM +0200, Mika Kuoppala wrote: > Now when clearing ptes can modify upper level pdp's, > we need to mark them dirty so that they will be flushed > correctly. I suppose so. I think we could push this into the cleanup_px() (and alloc) but that is probably a fair chunk

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/gtt: Fix pte clear range

== Series Details == Series: series starting with [1/2] drm/i915/gtt: Fix pte clear range URL : https://patchwork.freedesktop.org/series/14620/ State : warning == Summary == Series 14620v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/14620/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

On Mon, Oct 31, 2016 at 05:24:45PM +0200, Mika Kuoppala wrote: > Comparing pte index to a number of entries is wrong > when clearing a range of pte entries. Use end marker > of 'one past' to correctly point adequate number of > ptes to the scratch page. > > Fixes: d209b9c3cd28 ("drm/i915/gtt:

[Intel-gfx] [PATCH i-g-t] tests/gem_userptr_blits: Test object invalidation more thoroughly

From: Tvrtko Ursulin Verify that the userspace will get told if it changes to what the userptr object backing store points to, *after* having created the GEM object. Two variants are tested: 1. One where the object is used after it has been invalidated but while

Re: [Intel-gfx] [PATCH] drm/i915: Export a function to flush the context upon pinning

On 30 October 2016 at 13:28, Chris Wilson wrote: > For legacy contexts we employ an optimisation to only flush the context > when binding into the global GTT. This avoids stalling onthe GPU when > reloading an active context. Wrap this detail up into a helper and >

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Move the recently scanned objects to the tail after shrinking

On ma, 2016-10-31 at 10:26 +, Chris Wilson wrote: > During shrinking, we walk over the list of objects searching for > victims. Any that are not removed are put back into the global list. > Currently, they are put back in order (at the front) which means they > will be first to be scanned

[Intel-gfx] [PATCH 1/2] drm/i915/gtt: Fix pte clear range

Comparing pte index to a number of entries is wrong when clearing a range of pte entries. Use end marker of 'one past' to correctly point adequate number of ptes to the scratch page. Fixes: d209b9c3cd28 ("drm/i915/gtt: Split gen8_ppgtt_clear_pte_range") References:

[Intel-gfx] [PATCH 2/2] drm/i915/gtt: Mark tlbs dirty on clear

Now when clearing ptes can modify upper level pdp's, we need to mark them dirty so that they will be flushed correctly. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-)

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Reorganize sprite init

On Thu, Oct 27, 2016 at 09:07:13AM +0200, Daniel Vetter wrote: > On Tue, Oct 25, 2016 at 06:58:03PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Kill the switch statement from the sprite init code and replace with a > > more

[Intel-gfx] [PATCH i-g-t] igt/gem_reg_read: update TIMESTAMP register address for gen9+

Since gen9 timestamp should be read from BLT ring (TIMESTAMP_BCSUNIT). On gen9 reading timestamp from RENDER_RING is still working but is deprecated with no guarantee to be supported in next steppings. This commit require whitelist TIMESTAMP_BCSUNIT in kernel. Cc: Chris Wilson

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen9+: Whitelist TIMESTAMP register from BLT ring (rev2)

On Fri, Oct 28, 2016 at 11:46:20AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gen9+: Whitelist TIMESTAMP register from BLT ring (rev2) > URL : https://patchwork.freedesktop.org/series/14482/ > State : warning > > == Summary == > > Series 14482v2 drm/i915/gen9+:

Re: [Intel-gfx] [PATCH v2 1/4] drm: Add a new connector property for link status

On Sat, 29 Oct 2016, Manasi Navare wrote: > A new default connector property is added for keeping > track of whether the link is good (link training passed) or > link is bad (link training failed). If the link status property > is not good, then userspace should fire

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Mark up obj->mm.lock for shrinker

== Series Details == Series: drm/i915: Mark up obj->mm.lock for shrinker URL : https://patchwork.freedesktop.org/series/14608/ State : warning == Summary == Series 14608v1 drm/i915: Mark up obj->mm.lock for shrinker https://patchwork.freedesktop.org/api/1.0/series/14608/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm/i915: Mark up obj->mm.lock for shrinker

On 31/10/2016 12:40, Chris Wilson wrote: As we may allocate from within the obj->mm.lock we may enter the shrinker for direct reclaim. Operating on the current object is prevented by checking for obj->mm.pages (which is only set as the last operation in the allocation path). However, we need to

[Intel-gfx] [PATCH] drm/i915: Mark up obj->mm.lock for shrinker

As we may allocate from within the obj->mm.lock we may enter the shrinker for direct reclaim. Operating on the current object is prevented by checking for obj->mm.pages (which is only set as the last operation in the allocation path). However, we need to identity the single recursion of accessing

Re: [Intel-gfx] [PATCH 0/2] drm/i915/opregion: proper handling of DIDL and CADL

On Mon, 31 Oct 2016, Jani Nikula wrote: > On Mon, 31 Oct 2016, Rainer Koenig wrote: >> Hi Jani, >> >> one quick questions: What happened to those CADL patches. I was >> expecting them to showup in the mainstream kernel.org kernel some day, >>

Re: [Intel-gfx] [PATCH 0/2] drm/i915/opregion: proper handling of DIDL and CADL

On Mon, 31 Oct 2016, Rainer Koenig wrote: > Hi Jani, > > one quick questions: What happened to those CADL patches. I was > expecting them to showup in the mainstream kernel.org kernel some day, > but even in 4.9rc3 I cant't find them. Basically [1] and [2] happened,

Re: [Intel-gfx] [PATCH 0/2] drm/i915/opregion: proper handling of DIDL and CADL

Hi Jani, one quick questions: What happened to those CADL patches. I was expecting them to showup in the mainstream kernel.org kernel some day, but even in 4.9rc3 I cant't find them. Best regards Rainer Am 25.08.2016 um 14:53 schrieb Jani Nikula: > This is the next iteration of [1] and [2].

Re: [Intel-gfx] [PATCH i-g-t v4] tests/kms_plane_multiple: CRC based atomic correctness test

On Mon, 2016-10-24 at 10:28 +0200, Daniel Vetter wrote: > On Thu, Oct 20, 2016 at 12:27:23PM +0300, Mika Kahola wrote: > > > > This is a testcase with multiple planes. The idea here is the > > following > > > >  - draw a uniform frame with blue color > >  - grab crc for reference > >  - put

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Use the full hammer when shutting down the rcu tasks

== Series Details == Series: series starting with [1/6] drm/i915: Use the full hammer when shutting down the rcu tasks URL : https://patchwork.freedesktop.org/series/14606/ State : failure == Summary == Series 14606v1 Series without cover letter

[Intel-gfx] [i-g-t PATCH v2] tests: do snd_hda_intel unbind before unload in module reload test

Try to make sure the snd_hda_intel module is not in use, and can be unloaded. v2: unbind all cards (Libin) Cc: Keqiao Zhang Cc: Libin Yang Signed-off-by: Jani Nikula --- Keqiao, Libin, here's the script this patch is

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: rename preliminary_hw_support to alpha_support

== Series Details == Series: drm/i915: rename preliminary_hw_support to alpha_support URL : https://patchwork.freedesktop.org/series/14604/ State : failure == Summary == Series 14604v1 drm/i915: rename preliminary_hw_support to alpha_support

[Intel-gfx] [PATCH 2/6] drm/i915: Avoid accessing request->timeline outside of its lifetime

Whilst waiting on a request, we may do so without holding any locks or any guards beyond a reference to the request. In order to avoid taking locks within request deallocation, we drop references to its timeline (via the context and ppgtt) upon retirement. We should avoid chasing such pointers

[Intel-gfx] [PATCH 4/6] drm/i915: Discard objects from mm global_list after being shrunk

In the shrinker, we can safely remove an empty object (obj->mm.pages == NULL) after having discarded the pages because we are holding the struct_mutex. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_shrinker.c | 1 + 1 file changed, 1 insertion(+) diff

[Intel-gfx] [PATCH 6/6] drm/i915: Store the vma in an rbtree under the object

With full-ppgtt one of the main bottlenecks is the lookup of the VMA underneath the object. For execbuf there is merit in having a very fast direct lookup of ctx:handle to the vma using a hashtree, but that still leaves a large number of other lookups. One way to speed up the lookup would be to

[Intel-gfx] [PATCH 3/6] drm/i915: Track pages pinned due to swizzling quirk

If we have a tiled object and an unknown CPU swizzle pattern, we pin the pages to prevent the object from being swapped out (and us corrupting the contents as we do not know the access pattern and so cannot convert it to linear and back to tiled on reuse). This requires us to remember to drop the

[Intel-gfx] [PATCH 5/6] drm/i915: Move the recently scanned objects to the tail after shrinking

During shrinking, we walk over the list of objects searching for victims. Any that are not removed are put back into the global list. Currently, they are put back in order (at the front) which means they will be first to be scanned again. If we instead move them to the rear of the list, we will

[Intel-gfx] [PATCH 1/6] drm/i915: Use the full hammer when shutting down the rcu tasks

To flush all call_rcu() tasks (here from i915_gem_free_object()) we need to call rcu_barrier() (not synchronize_rcu()). If we don't then we may still have objects being freed as we continue to teardown the driver - in particular, the recently released rings may race with the memory manager

[Intel-gfx] [PATCH] drm/i915: rename preliminary_hw_support to alpha_support

The term "preliminary hardware support" has always caused confusion both among users and developers. It has always been about preliminary driver support for new hardware, and not so much about preliminary hardware. Of course, initially both the software and hardware are in early stages, but the

Re: [Intel-gfx] [i-g-t PATCH] tests: do snd_hda_intel unbind before unload in module reload test

On Mon, 31 Oct 2016, "Yang, Libin" wrote: >> -Original Message- >> From: Nikula, Jani >> Sent: Monday, October 31, 2016 4:40 PM >> To: intel-gfx@lists.freedesktop.org >> Cc: Nikula, Jani ; Zhang, Keqiao >> ; Yang, Libin

Re: [Intel-gfx] [i-g-t PATCH] tests: do snd_hda_intel unbind before unload in module reload test

> -Original Message- > From: Nikula, Jani > Sent: Monday, October 31, 2016 4:40 PM > To: intel-gfx@lists.freedesktop.org > Cc: Nikula, Jani ; Zhang, Keqiao > ; Yang, Libin > Subject: [i-g-t PATCH] tests: do

Re: [Intel-gfx] [PATCH 1/2] drm: Track drm_mm allocators and show leaks on shutdown

Am 29.10.2016 um 20:42 schrieb Chris Wilson: We can use the kernel's stack tracer and depot to record the allocation site of every drm_mm user and then on shutdown as well as warning that allocated nodes still reside with the drm_mm range manager, we can also display who allocated them to aide

[Intel-gfx] [i-g-t PATCH] tests: add more debugs on failure to unload snd_hda_intel

List open files under sound devices. Signed-off-by: Jani Nikula --- tests/drv_module_reload_basic | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic index c0676fc65db0..bbe11f7fe5bd 100755 ---

[Intel-gfx] [i-g-t PATCH] tests: do snd_hda_intel unbind before unload in module reload test

Try to make sure the snd_hda_intel module is not in use, and can be unloaded. Cc: Keqiao Zhang Cc: Libin Yang Signed-off-by: Jani Nikula --- Keqiao, Libin, here's the script this patch is against:

Re: [Intel-gfx] [PATCH 3/3] igt/kms_flip: Use new igt_spin_batch

On 10/28/2016 07:02 PM, Ville Syrjälä wrote: > On Fri, Oct 28, 2016 at 06:47:26PM +0300, Abdiel Janulgue wrote: >> Cc: Chris Wilson >> Cc: Daniel Vetter >> Signed-off-by: Abdiel Janulgue >> --- >>