[Intel-gfx] [PATCH 9/9] drm/i915: Don't populate plane->plane for cursors and sprites

From: Ville Syrjälä With plane->plane now purely reserved for the primary planes, let's not even populate it for cursors and sprites. Let's switch the type to enum plane as well since it's no longer being abused for anything else. Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915: avoid harmless empty-body warning

On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote: > The newly added assert_kernel_context_is_current introduces a warning > when built with W=1: > > drivers/gpu/drm/i915/i915_gem.c: In function > ‘assert_kernel_context_is_current’: > drivers/gpu/drm/i915/i915_gem.c:4417:63: error:

[Intel-gfx] [drm-intel:topic/drm-misc 1/14] warning: (KMEMCHECK && ..) selects STACKTRACE which has unmet direct dependencies (STACKTRACE_SUPPORT)

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 93ce75fa3dba8781c5c042bd7a61d438662ed73c commit: 5705670d0463423337c82d00877989e7df8b169d [1/14] drm: Track drm_mm allocators and show leaks on shutdown config: alpha-allmodconfig (attached as .config) compiler:

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Remove some duplicated plane swapping logic

On Tue, Nov 08, 2016 at 04:47:11PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC > capable plane feeding the LVDS port by default. We have the logic for > the plane

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Don't populate plane->plane for cursors and sprites

On Tue, Nov 08, 2016 at 04:47:19PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > With plane->plane now purely reserved for the primary planes, let's > not even populate it for cursors and sprites. Let's switch the type > to enum plane as

[Intel-gfx] [PATCH 1/9] drm/i915: Remove some duplicated plane swapping logic

From: Ville Syrjälä On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC capable plane feeding the LVDS port by default. We have the logic for the plane swapping duplicated in many places. Let's remove a bit of the duplication by having the crtc

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald: > Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula: > > On Mon, 07 Nov 2016, Martin Steigerwald wrote: > > > It is also the same kind of corruptions as shown in > > > > > > [Bug 177701]

[Intel-gfx] [PATCH 5/9] drm/i915: Use enum plane_id in SKL plane code

From: Ville Syrjälä Replace the intel_plane->plane and hardcoded 0 usage in the SKL plane code with intel_plane->id. This should make the SKL "primary" and "sprite" code virtually identical, so the next logical step would likely be dropping one of the copies.

[Intel-gfx] [PATCH 3/9] drm/i915: Add crtc->plane_ids_mask

From: Ville Syrjälä Add a mask of which planes are available for each pipe. This doesn't quite work for old platforms with dynamic plane<->pipe assignment, but as we don't support that sort of stuff (yet) we can get away with it. The main use I have for this is

[Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

From: Ville Syrjälä As I told people in [1] we really should not be confusing enum plane as a per-pipe plane identifier. Looks like that happened nonetheless, so let's fix it up by splitting the two into two enums. We'll also want something we just directly pass

[Intel-gfx] [PATCH 7/9] drm/i915: Use enum plane_id in VLV/CHV wm code

From: Ville Syrjälä Let's try not to abuse plane->plane for sprites on VLV/CHV and instead use plane->id. Since out watermark structures aren't entirely plane type agnostic (for now) and start indexing sprites from 0 we'll add a small helper to convert between the

[Intel-gfx] [PATCH 0/9] drm/i915: Add a per-pipe plane identifier enum

From: Ville Syrjälä This series aims to clean up the mess we have with intel_plane->plane by adding a new intel_plane->id thing. Afterwards the two are clearly separated so that intel_plane->id is the per-pipe plane identifier, and intel_plane->plane is the legacy

[Intel-gfx] [PATCH 4/9] drm/i915: Use enum plane_id in SKL wm code

From: Ville Syrjälä Nuke skl_wm_plane_id() and just use the new intel_plane->id. Cc: Matt Roper Cc: Paulo Zanoni Cc: Maarten Lankhorst Cc: Lyude

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula: > On Mon, 07 Nov 2016, Martin Steigerwald wrote: > > It is also the same kind of corruptions as shown in > > > > [Bug 177701] warning in intel_dp_aux_transfer > >

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 02:24:48PM +0100, Peter Zijlstra wrote: > On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote: > > On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote: > > > Hi all, > > > > > > FIXME: Add owner of second tree to To: > > >Add author(s)/SOB of

[Intel-gfx] [PATCH 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

From: Ville Syrjälä Use intel_plane->id to derive the VLV/CHV sprite register offsets instead of abusing plane->plane which is really meant to for primary planes only. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 8/9] drm/i915: Rename the local 'plane' variable to 'plane_id' in primary plane code

From: Ville Syrjälä Now we've rename the local plane id variable as 'plane_id' everywhere except the pre-SKL primary plane code. Let's do the rename there as well so that we'll free up the name 'plane' for use with struct intel_plane*. Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Remove some duplicated plane swapping logic

On Tue, Nov 08, 2016 at 03:23:14PM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 04:47:11PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC > > capable plane

Re: [Intel-gfx] [PULL] GVT-g device model fixes

On Mon, Nov 07, 2016 at 05:18:21PM +0800, Zhenyu Wang wrote: > > Hi, > > This is current fixes for GVT-g device model part. Most notable is to > fix a regression from e95433c73a11 ("drm/i915: Rearrange > i915_wait_request() accounting with callers") which has stopped our > testing. > > As for

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Spin until breadcrumb threads are complete

On Tue, Nov 08, 2016 at 03:16:13PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Spin until breadcrumb threads are complete > URL : https://patchwork.freedesktop.org/series/14977/ > State : success > > == Summary == > > Series 14977v1 drm/i915: Spin until breadcrumb

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

On Tue, Nov 08, 2016 at 04:47:16PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Use intel_plane->id to derive the VLV/CHV sprite register offsets > instead of abusing plane->plane which is really meant to for > primary planes only. > >

Re: [Intel-gfx] [PATCH] drm/i915: avoid harmless empty-body warning

On Tue, Nov 08, 2016 at 02:49:05PM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote: > > The newly added assert_kernel_context_is_current introduces a warning > > when built with W=1: > > > > drivers/gpu/drm/i915/i915_gem.c: In function > >

[Intel-gfx] [PATCH] drm/i915: Spin until breadcrumb threads are complete

When we need to reset the global seqno on wraparound, we have to wait until the current rbtrees are drained (or otherwise the next waiter will be out of sequence). The current mechanism to kick and spin until complete, may exit too early as it would break if the target thread was currently

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Spin until breadcrumb threads are complete

== Series Details == Series: drm/i915: Spin until breadcrumb threads are complete URL : https://patchwork.freedesktop.org/series/14977/ State : success == Summary == Series 14977v1 drm/i915: Spin until breadcrumb threads are complete

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > As I told people in [1] we really should not be confusing enum plane > as a per-pipe plane identifier. Looks like that happened nonetheless, so > let's fix it

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Don't populate plane->plane for cursors and sprites

On Tue, Nov 08, 2016 at 03:30:33PM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 04:47:19PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > With plane->plane now purely reserved for the primary planes, let's > > not even populate

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

On Tue, Nov 08, 2016 at 03:26:31PM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > As I told people in [1] we really should not be confusing enum plane > > as a per-pipe

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Add a per-pipe plane identifier enum

== Series Details == Series: drm/i915: Add a per-pipe plane identifier enum URL : https://patchwork.freedesktop.org/series/14978/ State : warning == Summary == Series 14978v1 drm/i915: Add a per-pipe plane identifier enum

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote: > > You're talking about: > > > > lkml.kernel.org/r/20161007154351.gl3...@twins.programming.kicks-ass.net > > > > ? I got no feedback from you DRM guys on that so I kinda forgot about > > that in the hope we'd not have to do this

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

On Tue, Nov 08, 2016 at 04:04:23PM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 04:47:16PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Use intel_plane->id to derive the VLV/CHV sprite register offsets > > instead of abusing

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote: > > Now, I know you're working on getting rid of this entirely for i915, but > > what about that MSM driver? Will we continue to need it there, is > > anybody actually maintaining that thing? > > Rob Clark is, and since he's a one-man

[Intel-gfx] [PATCH v2 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

From: Ville Syrjälä Use intel_plane->id to derive the VLV/CHV sprite register offsets instead of abusing plane->plane which is really meant to for primary planes only. v2: Convert assert_sprites_disabled() over as well Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v2 4/9] drm/i915: Use enum plane_id in SKL wm code

From: Ville Syrjälä Nuke skl_wm_plane_id() and just use the new intel_plane->id. v2: Convert skl_write_plane_wm() as well Cc: Matt Roper Cc: Paulo Zanoni Cc: Maarten Lankhorst

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Add a per-pipe plane identifier enum (rev3)

== Series Details == Series: drm/i915: Add a per-pipe plane identifier enum (rev3) URL : https://patchwork.freedesktop.org/series/14978/ State : warning == Summary == Series 14978v3 drm/i915: Add a per-pipe plane identifier enum

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()

== Series Details == Series: drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb() URL : https://patchwork.freedesktop.org/series/14984/ State : success == Summary == Series 14984v1 drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 06:04:15PM +0100, Peter Zijlstra wrote: > On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote: > > > Now, I know you're working on getting rid of this entirely for i915, but > > > what about that MSM driver? Will we continue to need it there, is > > > anybody

[Intel-gfx] [PATCH] drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()

One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB partitioning for multi-screen cases"), and the other was added by 01c72d6c17 ("drm/i915/gen9: fix DDB partitioning for multi-screen cases"). I'm confused and I'll let the maintainers find out what went wrong here. Cc: Jani

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

== Series Details == Series: drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases URL : https://patchwork.freedesktop.org/series/14990/ State : success == Summary == Series 14990v1 drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

[Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

The previous spec version said "double Ytile planes minimum lines", and I interpreted this as referring to what the spec calls "Y tile minimum", but in fact it was referring to what the spec calls "Minimum Scanlines for Y tile". I noticed that Mahesh Kumar had a different interpretation, so I sent

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: move allocation out of drm_get_format_name() (rev3)

== Series Details == Series: drm: move allocation out of drm_get_format_name() (rev3) URL : https://patchwork.freedesktop.org/series/14873/ State : failure == Summary == CC [M] drivers/gpu/drm/i915/dvo_ns2501.o CC [M] drivers/gpu/drm/i915/dvo_sil164.o CC [M]

Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote: > The previous spec version said "double Ytile planes minimum lines", > and I interpreted this as referring to what the spec calls "Y tile > minimum", but in fact it was referring to what the spec calls "Minimum > Scanlines for Y tile".

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

: Track drm_mm allocators and show leaks on shutdown") I hate used the drm-misc tree from next-20161108 for today. -- Cheers, Stephen Rothwell ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > As I told people in [1] we really should not be confusing enum plane > as a per-pipe plane identifier. Looks like that happened nonetheless, so > let's fix it

Re: [Intel-gfx] [PATCH] drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()

On Tue, Nov 08, 2016 at 03:21:22PM -0200, Paulo Zanoni wrote: > One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB > partitioning for multi-screen cases"), and the other was added by > 01c72d6c17 ("drm/i915/gen9: fix DDB partitioning for multi-screen > cases"). I'm confused and

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wed, Nov 09, 2016 at 02:09:16AM +0100, Daniel Vetter wrote: > On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote: > > The function's behaviour was changed in 90844f00049e, without changing > > its signature, causing people to keep using it the old way without > > realising they were

Re: [Intel-gfx] [PATCH 0/2] extend page_track for external usage

On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote: > >> Paolo, for this case, do you think it's feasible we pick them through > >> drm/i915 merge path? As currently initial KVMGT patch sets require these > >> exported symbols, that's why I ask how we should handle this dependency. > > > > Then

[Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

The function's behaviour was changed in 90844f00049e, without changing its signature, causing people to keep using it the old way without realising they were now leaking memory. Rob Clark also noticed it was also allocating GFP_KERNEL memory in atomic contexts, breaking them. Instead of having to

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wed, Nov 09, 2016 at 12:17:52AM +, Eric Engestrom wrote: > The function's behaviour was changed in 90844f00049e, without changing > its signature, causing people to keep using it the old way without > realising they were now leaking memory. > Rob Clark also noticed it was also allocating

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote: > On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > FIXME: Add owner of second tree to To: > >Add author(s)/SOB of conflicting commits. > > > > Today's linux-next merge of the tip tree got

Re: [Intel-gfx] [PATCH 05/19] drm/atomic: Make add_affected_connectors look at crtc_state.

On Thu, Nov 03, 2016 at 05:32:42PM +0200, Ville Syrjälä wrote: > On Mon, Oct 17, 2016 at 02:37:04PM +0200, Maarten Lankhorst wrote: > > This kills another dereference of connector->state. connector_mask > > holds all unchanged connectors at least and any changed connectors > > are already in state

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Enable drm_mm debug when enabling DRM_I915_DEBUG

On Sat, Oct 29, 2016 at 07:42:14PM +0100, Chris Wilson wrote: > A frequent issue that arises on shutdown is the drm_mm range manager > complaining of a leak. To aide debugging those, drm can now track the > allocation callsite and print those for the leaks. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe

On Thu, Nov 03, 2016 at 02:52:00PM -0400, Rob Clark wrote: > On Sun, Aug 14, 2016 at 8:02 PM, Eric Engestrom wrote: > > Signed-off-by: Eric Engestrom > > --- > > > > I moved the main bits to be the first diffs, shouldn't affect anything > > when applying the

Re: [Intel-gfx] [PATCH 07/19] drm/atomic: Fix atomic helpers to use the new iterator macros.

On Thu, Nov 03, 2016 at 06:22:05PM +0200, Ville Syrjälä wrote: > This thing could use a commit message I think. Could at least lay out > the basic rules on the foo->state/foo_state vs. old_state/new_state > replacements. Might help someone understand it who doesn't know so much > about the current

Re: [Intel-gfx] [PATCH v2] drm: move allocation out of drm_get_format_name()

On Mon, Nov 07, 2016 at 07:38:25PM +0200, Jani Nikula wrote: > On Mon, 07 Nov 2016, Eric Engestrom wrote: > > On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote: > >> On Mon, 07 Nov 2016, Eric Engestrom wrote: > >> > Fixes:

Re: [Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote: > Hi all, > > FIXME: Add owner of second tree to To: >Add author(s)/SOB of conflicting commits. > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/gpu/drm/i915/i915_gem_shrinker.c > > between

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove two sloppy inline functions from .h (rev2)

On ti, 2016-11-08 at 07:46 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Remove two sloppy inline functions from .h (rev2) > URL   : https://patchwork.freedesktop.org/series/14931/ > State : success > Merged the patch, thanks for the review. Regards, Joonas -- Joonas

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Fix scaling check for 90/270 degree plane rotation

On Mon, Nov 07, 2016 at 09:28:58PM +, Chris Wilson wrote: > On Mon, Nov 07, 2016 at 10:20:53PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Starting from commit b63a16f6cd89 ("drm/i915: Compute display surface > > offset in the

Re: [Intel-gfx] [RFC i-g-t 3/4] igt_aux: Add some list helpers from wayland

On Mon, Nov 07, 2016 at 07:05:15PM -0500, Lyude wrote: > Since we're going to be using lists for keeping track of EDIDs we've > allocated on the chamelium, add some generic list helpers from the > wayland project. We are a little more familiar with the kernel naming convention. -Chris -- Chris

Re: [Intel-gfx] [RFC i-g-t 2/4] igt_aux: Add igt_set_autoresume_delay()

On Mon, Nov 07, 2016 at 07:05:14PM -0500, Lyude wrote: > The default autoresume delay is about 5 seconds. It's possible on a > system that's not very fast this might not be a long enough time, since > an asynchronous hotplug event we scheduled on the chamelium that was > intended to happen during

Re: [Intel-gfx] [PATCH igt v2 2/6] igt/gem_exec_parse: remove oacontrol checks

On Mon, Nov 07, 2016 at 10:26:59PM +, Robert Bragg wrote: > The command parser no longer whitelists or does anything special for the > OACONTROL register which is now considered owned by i915-perf. > > As a follow up the plan is to at least check that attempting to write to > OACONTROL from

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Create distinct lockclasses for execution vs user timelines

On Tue, Nov 08, 2016 at 09:43:21AM +0200, Joonas Lahtinen wrote: > On ma, 2016-11-07 at 13:59 +, Chris Wilson wrote: > > @@ -56,6 +61,24 @@ int i915_gem_timeline_init(struct drm_i915_private *i915, > >   return 0; > >  } > >   > > +int i915_gem_timeline_init(struct drm_i915_private *i915, >

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote: > Op 01-11-16 om 14:09 schreef Ville Syrjälä: > > On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote: > >> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to > >> replace the old

Re: [Intel-gfx] [PATCH v2 02/11] drm/i915: Split request submit/execute phase into two

On ma, 2016-11-07 at 13:59 +, Chris Wilson wrote: > In order to support deferred scheduling, we need to differentiate > between when the request is ready to run (i.e. the submit fence is > signaled) and when the request is actually run (a new execute fence). > This is typically split between

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Always flush the dirty CPU cache when pinning the scanout

On Sun, Nov 06, 2016 at 01:00:00PM +, Chris Wilson wrote: > Currently we only clflush the scanout if it is in the CPU domain. Also > flush if we have a pending CPU clflush. We also want to treat the > dirtyfb path similar, and flush any pending writes there as well. > > Signed-off-by: Chris

[Intel-gfx] [drm-intel:topic/drm-misc 1/13] ERROR: "depot_save_stack" [drivers/gpu/drm/drm.ko] undefined!

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 3835b46e5535d9ad534776bc93670db097682556 commit: 5705670d0463423337c82d00877989e7df8b169d [1/13] drm: Track drm_mm allocators and show leaks on shutdown config: i386-randconfig-i1-201645 (attached as .config) compiler: gcc-4.8

Re: [Intel-gfx] [PATCH v4 1/3] lib: add igt_dummyload

By the way, series was tested on CI with no regressions. - Abdiel On 11/07/2016 09:48 AM, Abdiel Janulgue wrote: > A lot of igt testcases need some GPU workload to make sure a race > window is big enough. Unfortunately having a fixed amount of > workload leads to spurious test failures or

Re: [Intel-gfx] [PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl

On Tue, 2016-11-08 at 03:47 -0800, Robert Bragg wrote: > > > On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta > wrote: > On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote: > > The maximum OA sampling frequency is now configurable via a > >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Always flush the dirty CPU cache when pinning the scanout

On Tue, Nov 08, 2016 at 01:33:41PM +0200, Ville Syrjälä wrote: > On Sun, Nov 06, 2016 at 01:00:00PM +, Chris Wilson wrote: > > - i915_gem_object_flush_cpu_write_domain(obj); > > + if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) > > +

Re: [Intel-gfx] [PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl

On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta wrote: > On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote: > > The maximum OA sampling frequency is now configurable via a > > dev.i915.oa_max_sample_rate sysctl parameter. > > > > Following the precedent set by perf's

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

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 planes randomly on top with the same blue color - punch holes with black color into the primary framebuffer - ideally the planes should cover these

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Update connector status for DP MST hotplugs

On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote: > Hotplugging a monitor in DP MST configuration triggers short pulses. > Although the short pulse handling path ends up in the MST hotplug function, > we do not perform a detect before sending the hotplug uvent. This leads to >

Re: [Intel-gfx] [PATCH igt] igt/gem_exec_reloc: Check we write the full 64bit relocation

On Fri, Nov 04, 2016 at 03:03:59PM +, Chris Wilson wrote: > Recently a patch ran successfully through BAT that broke 64bit > relocations on a couple of machines. Oops. So lets add a very fast set > of tests to check basic relocation handling. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915/scheduler: Record all dependencies upon request construction

On Mon, Nov 07, 2016 at 01:59:45PM +, Chris Wilson wrote: > The scheduler needs to know the dependencies of each request for the > lifetime of the request, as it may choose to reschedule the requests at > any time and must ensure the dependency tree is not broken. This is in > additional to

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove chipset flush after cache flush

On Mon, Nov 07, 2016 at 06:16:00PM +0200, Joonas Lahtinen wrote: > On ma, 2016-11-07 at 12:10 +, Chris Wilson wrote: > > On Mon, Nov 07, 2016 at 02:01:46PM +0200, Joonas Lahtinen wrote: > > > > > > On su, 2016-11-06 at 12:59 +, Chris Wilson wrote: > > > > > > > > We always flush the

[Intel-gfx] [PATCH v3 04/11] drm/i915/gen9+: Kill off hw_ddb from intel_crtc.

This member is only used in skl_update_crtcs now. It's easy to remove it by keeping track of which ddb entries in an array, and update them after we update the crtc. This removes the last bits of SKL-style watermarks kept outside of crtc_state. Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH v3 01/11] drm/i915: Add a atomic evasion step to watermark programming, v3.

Allow the driver to write watermarks during atomic evasion. This will make it possible to write the watermarks in a cleaner way on gen9+. intel_atomic_state is not used here yet, but will be used when we program all watermarks as a separate step during evasion. This also writes linetime all the

[Intel-gfx] [PATCH v3 05/11] drm/i915/gen9+: Do not initialise active_crtcs for !modeset

This is a hack and not needed. Use the right mask by checking intel_state->modeset. This works for watermark sanitization too. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c | 38 +++--- 1 file changed, 15

[Intel-gfx] [PATCH v3 08/11] drm/edid: Remove drm_select_eld

The only user was i915, which is now gone. Signed-off-by: Maarten Lankhorst Reviewed-by: Ville Syrjälä Acked-by: Dave Airlie #irc Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/drm_edid.c | 26

[Intel-gfx] [PATCH v3 03/11] drm/i915/gen9+: Preserve old allocation from crtc_state.

This is the last bit required for making nonblocking modesets work correctly. The state in intel_crtc->hw_ddb is not updated until somewhere in atomic commit, while the previous crtc state should be accurate if the ddb hasn't changed. Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH v3 07/11] drm/i915: Pass atomic state to intel_audio_codec_enable, v2.

drm_select_eld requires mode_config.mutex and connection_mutex because it looks at the connector list and at the legacy encoders. This is not required, because when we call audio_codec_enable we know which connector it was called for, so pass the state. This also removes having to look at

[Intel-gfx] [PATCH v3 02/11] drm/i915/gen9+: Program watermarks as a separate step during evasion, v3.

The watermark updates for SKL style watermarks are no longer done in the plane callbacks, but are now called in a separate watermark update function that's called during the same vblank evasion, before the plane updates. This also gets rid of the global skl_results, which was required for keeping

[Intel-gfx] [PATCH v3 06/11] drm/i915: Convert intel_hdmi to use atomic state

This is the last connector still looking at crtc->config. Fix this. Signed-off-by: Maarten Lankhorst Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_hdmi.c | 48 +-- 1 file changed,

[Intel-gfx] [PATCH v3 10/11] drm/i915: Pass atomic state to verify_connector_state

This gets rid of a warning that the connectors are used without locking when doing a nonblocking modeset. Signed-off-by: Maarten Lankhorst Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 24

[Intel-gfx] [PATCH] drm/i915: avoid harmless empty-body warning

The newly added assert_kernel_context_is_current introduces a warning when built with W=1: drivers/gpu/drm/i915/i915_gem.c: In function ‘assert_kernel_context_is_current’: drivers/gpu/drm/i915/i915_gem.c:4417:63: error: suggest braces around empty body in an ‘else’ statement [-Werror=empty-body]

Re: [Intel-gfx] [PATCH v3 07/11] drm/i915: Pass atomic state to intel_audio_codec_enable, v2.

On Tue, Nov 08, 2016 at 01:55:38PM +0100, Maarten Lankhorst wrote: > drm_select_eld requires mode_config.mutex and connection_mutex > because it looks at the connector list and at the legacy encoders. > > This is not required, because when we call audio_codec_enable we know > which connector it

Re: [Intel-gfx] [PATCH v3 09/11] drm/i915: Update atomic modeset state synchronously, v2.

On Tue, Nov 08, 2016 at 01:55:40PM +0100, Maarten Lankhorst wrote: > All of this state should be updated as soon as possible. It shouldn't be > done later because then future updates may not depend on it. > > Changes since v1: > - Move the modeset update to before drm_atomic_state_get. (Ville) >

Re: [Intel-gfx] [PATCH v3 05/11] drm/i915/gen9+: Do not initialise active_crtcs for !modeset

On Tue, Nov 08, 2016 at 01:55:36PM +0100, Maarten Lankhorst wrote: > This is a hack and not needed. Use the right mask by checking > intel_state->modeset. This works for watermark sanitization too. > > Signed-off-by: Maarten Lankhorst > --- >

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

Op 08-11-16 om 12:54 schreef Mika Kahola: > 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 planes randomly on top with the same blue color > - punch holes with black color into the primary

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

On Tue, 2016-11-08 at 14:14 +0100, Maarten Lankhorst wrote: > Op 08-11-16 om 12:54 schreef Mika Kahola: > > > > 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 planes randomly on

[Intel-gfx] ✓ Fi.CI.BAT: success for Skylake watermark fixes and nonblocking modeset.

== Series Details == Series: Skylake watermark fixes and nonblocking modeset. URL : https://patchwork.freedesktop.org/series/14966/ State : success == Summary == Series 14966v1 Skylake watermark fixes and nonblocking modeset.

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Always flush the dirty CPU cache when pinning the scanout

On Tue, Nov 08, 2016 at 11:42:38AM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 01:33:41PM +0200, Ville Syrjälä wrote: > > On Sun, Nov 06, 2016 at 01:00:00PM +, Chris Wilson wrote: > > > - i915_gem_object_flush_cpu_write_domain(obj); > > > + if (obj->cache_dirty ||

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

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 planes randomly on top with the same blue color - punch holes with black color into the primary framebuffer - ideally the planes should cover these

[Intel-gfx] [PATCH v2] drm/i915: don't whitelist oacontrol in cmd parser

This v2 patch bumps the command parser version so it can be referenced in corresponding i-g-t gem_exec_parse changes. --- >8 --- Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable

[Intel-gfx] [PATCH v3 11/11] drm/i915: Enable support for nonblocking modeset

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ee8b6db0b425..759b1fdbb009 100644 ---

[Intel-gfx] [PATCH v3 09/11] drm/i915: Update atomic modeset state synchronously, v2.

All of this state should be updated as soon as possible. It shouldn't be done later because then future updates may not depend on it. Changes since v1: - Move the modeset update to before drm_atomic_state_get. (Ville) Signed-off-by: Maarten Lankhorst ---

[Intel-gfx] [PATCH v3 00/11] Skylake watermark fixes and nonblocking modeset.

These are the remaining watermark fixes required before nonblocking modeset can be enabled, plus the patches required to enable nonblocking modeset support in i915. Maarten Lankhorst (11): drm/i915: Add a atomic evasion step to watermark programming, v3. drm/i915/gen9+: Program watermarks as

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev2)

== Series Details == Series: Enable i915 perf stream for Haswell OA unit (rev2) URL : https://patchwork.freedesktop.org/series/14935/ State : failure == Summary == Series 14935v2 Enable i915 perf stream for Haswell OA unit

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Use intel_fb_gtt_offset() also for gen2/3 primary plane

On Mon, Nov 07, 2016 at 09:20:05PM +, Chris Wilson wrote: > On Mon, Nov 07, 2016 at 10:20:57PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > The code to determine the primary plane offset for gen2/3 looks > > different than the