[Intel-gfx] [PATCH v2 2/2] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA

[Intel-gfx] [PATCH v2 1/2] drm/i915/vlv: Make intel_crt_reset() per-encoder

This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. CC: sta...@vger.kernel.org Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_crt.c | 10 +- 1 file changed, 5 insertions(+), 5

[Intel-gfx] [PATCH] drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMR

The workaround added in c6782b76d31a ("drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR") needs to be applied on Kabylake too as shown by the corresponding timeout errors about power well 1 and MISC IO power well disabling in the latest CI run. CC: Patrik Jakobsson

Re: [Intel-gfx] [PATCH 0/5] PowerManagement Toggle for PowerTOP

On Thu, 2016-04-14 at 11:48 +0200, Daniel Vetter wrote: > On Wed, Apr 13, 2016 at 10:06:57PM +, Vivi, Rodrigo wrote: > > On Wed, 2016-04-13 at 22:46 +0200, Daniel Vetter wrote: > > > On Wed, Apr 13, 2016 at 10:38 PM, Vivi, Rodrigo < > > > rodrigo.v...@intel.com> wrote: > > > > On Wed,

[Intel-gfx] [PATCH 1/6] drm/i915: Rename the magic polymorphic macro __I915__

To open up the future of using a generic to_i915() convenience macro, rename the existing __I915__ superconvenience macro. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-)

[Intel-gfx] [PATCH 5/6] drm/i915: Teach to_i915() how to extract drm_i915_private from requests

Since drm_i915_gem_request already contains a backpointer to drm_i915_private, this is a fairly trivial operation. However, using a consistent interface does lean convenience to when we need to query device properties, for example. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 4/6] drm/i915: Use to_i915() instead of guc_to_i915()

The convenience of saving a few characters by using a consistent interface to obtain our drm_i915_private struct from intel_guc. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h| 5 - drivers/gpu/drm/i915/i915_guc_submission.c | 17

[Intel-gfx] [PATCH 6/6] drm/i915: Teach to_i915() how to extract drm_i915_private from engines

This is primarily intended to simplify later patches that add various backpointers to the structs, but in the meantime we can enjoy various little syntactic conveniences. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_cmd_parser.c | 12 +-

[Intel-gfx] [PATCH 2/6] drm/i915: Allow passing any known pointer to for_each_engine()

Rather than require the user to grab a drm_i915_private, allow them to pass anything that we know how to derive such a pointer user to_i915() Note this fixes a macro bug in for_each_engine_masked() which was not using its dev_priv__ parameter. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 3/6] drm/i915: Extend magic to_i915() to work with drm_i915_gem_object

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c| 7 ++--- drivers/gpu/drm/i915/i915_drv.h| 18 ++- drivers/gpu/drm/i915/i915_gem.c| 48 +++--- drivers/gpu/drm/i915/i915_gem_execbuffer.c

[Intel-gfx] Polymorphic to_i915()

Final canvas for opinions for using a magic macro to reduce typing in the common operation of getting our drm_i915_private from the object. 21 files changed, 333 insertions(+), 392 deletions(-) Not to mention the ease it makes for later patches to reduce the pointer dance. -Chris

Re: [Intel-gfx] Fixing i915/opregion issues with firmware which lists more then 8 output devices

Hello It seems this patch works on 4.4 kernel. https://bugzilla.kernel.org/attachment.cgi?id=195071 Maybe we can have it directly in future releases? :) Regards, Le 23/03/2016 12:36, Jani Nikula a écrit : On Tue, 22 Mar 2016, Nicolas Repentin wrote: I'm searching

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Enable/disable VGA hotplugging properly

Huh, neither am I now. I seem to be able to reproduce the problem just fine again. Anyway I'll send the new versions of the patches in a little bit On Fri, 2016-04-15 at 18:49 +0300, Ville Syrjälä wrote: > On Fri, Apr 15, 2016 at 09:47:51AM -0400, Lyude Paul wrote: > > > > Looks like we might

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: fix CHV dsi encoder hardware state readout on port C

== Series Details == Series: drm/i915/dsi: fix CHV dsi encoder hardware state readout on port C URL : https://patchwork.freedesktop.org/series/5781/ State : failure == Summary == Series 5781v1 drm/i915/dsi: fix CHV dsi encoder hardware state readout on port C

Re: [Intel-gfx] [PATCH v4 1/2] shmem: Support for registration of driver/file owner specific ops

On Mon, Apr 04, 2016 at 02:18:10PM +0100, Chris Wilson wrote: > From: Akash Goel > > This provides support for the drivers or shmem file owners to register > a set of callbacks, which can be invoked from the address space > operations methods implemented by shmem. This

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Enable/disable VGA hotplugging properly

On Fri, Apr 15, 2016 at 09:47:51AM -0400, Lyude Paul wrote: > Looks like we might not need to worry about this patch anymore actually, looks > like this problem got fixed by accident by one of the other vlv fixes you > pushed. Not sure what exactly changed for you, but we definitely need to

[Intel-gfx] ✗ Fi.CI.BAT: warning for GuC premature LRC unpin

== Series Details == Series: GuC premature LRC unpin URL : https://patchwork.freedesktop.org/series/5776/ State : warning == Summary == Series 5776v1 GuC premature LRC unpin http://patchwork.freedesktop.org/api/1.0/series/5776/revisions/1/mbox/ Test gem_busy: Subgroup basic-blt:

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: compile-time consistency check on __EXEC_OBJECT flags

== Series Details == Series: series starting with [1/4] drm/i915: compile-time consistency check on __EXEC_OBJECT flags URL : https://patchwork.freedesktop.org/series/5775/ State : warning == Summary == Series 5775v1 Series without cover letter

Re: [Intel-gfx] [PATCH v6 3/4] drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read()

On Fri, Apr 15, 2016 at 10:25:35AM -0400, Lyude wrote: > This is part of a patch series to migrate all of the workarounds for > commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's > DP helper. > > Some sinks will just return garbage for the first aux tranaction they >

[Intel-gfx] [PATCH v6 3/4] drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read()

This is part of a patch series to migrate all of the workarounds for commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's DP helper. Some sinks will just return garbage for the first aux tranaction they receive when coming out of sleep mode, so we need to perform an

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [resend-for-CI,1/2] drm/i915: Show pin mapped status in describe_obj

On 15/04/16 14:50, Patchwork wrote: == Series Details == Series: series starting with [resend-for-CI,1/2] drm/i915: Show pin mapped status in describe_obj URL : https://patchwork.freedesktop.org/series/5771/ State : success == Summary == Series 5771v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [resend-for-CI,1/2] drm/i915: Show pin mapped status in describe_obj

== Series Details == Series: series starting with [resend-for-CI,1/2] drm/i915: Show pin mapped status in describe_obj URL : https://patchwork.freedesktop.org/series/5771/ State : success == Summary == Series 5771v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for mm/vmalloc: Keep a separate lazy-free list (rev2)

== Series Details == Series: mm/vmalloc: Keep a separate lazy-free list (rev2) URL : https://patchwork.freedesktop.org/series/5574/ State : failure == Summary == Series 5574v2 mm/vmalloc: Keep a separate lazy-free list http://patchwork.freedesktop.org/api/1.0/series/5574/revisions/2/mbox/

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Enable/disable VGA hotplugging properly

Looks like we might not need to worry about this patch anymore actually, looks like this problem got fixed by accident by one of the other vlv fixes you pushed. Now it's not always modesetting on hotplug when it was before though :(, so I'll get to work on bisecting that. On Thu, 2016-04-14 at

Re: [Intel-gfx] [PATCH] drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variations.

On to, 2016-04-14 at 15:37 -0700, Dongwon Kim wrote: > This patch is to correct one thing in this commit: > > commit 25a56705332add0363e47b3a0eca001d6fbd5bec > Author: Dongwon Kim > Date:   Wed Mar 16 18:06:13 2016 -0700 > > drm/i915/bxt: Reversed polarity of

Re: [Intel-gfx] [PATCH v5 16/24] ARM: explicitly apply PWM config extracted from pwm_args

On 04/14/2016 09:17 PM, Boris Brezillon wrote: > Call pwm_apply_args() just after requesting the PWM device so that the > polarity and period are initialized according to the information provided > in pwm_args. > > This is an intermediate state, and pwm_apply_args() should be dropped as > soon as

Re: [Intel-gfx] [PATCH v5 02/24] pwm: use pwm_get/set_xxx() helpers where appropriate

On 14 April 2016 at 21:17, Boris Brezillon wrote: > Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx > field. Doing that will ease adaptation of the PWM framework to support > atomic update. > > Signed-off-by: Boris Brezillon

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV

On Fri, Apr 15, 2016 at 04:09:31PM +0300, Jani Nikula wrote: > On Tue, 12 Apr 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While > > the DPLL isn't used to provide the

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Refactor execlists default context pinning

On 15/04/16 13:16, Chris Wilson wrote: On Fri, Apr 15, 2016 at 12:54:33PM +0100, Tvrtko Ursulin wrote: From: Chris Wilson Refactor pinning and unpinning of contexts, such that the default context for an engine is pinned during initialisation and unpinned during

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Keep the previous context pinned until the next one has been completed

On 15/04/16 13:12, Chris Wilson wrote: On Fri, Apr 15, 2016 at 12:54:34PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In GuC mode submitting requests is only putting them into the GuC queue with the actual submission to hardware following at some future point.

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHV

On Tue, 12 Apr 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While > the DPLL isn't used to provide the clock we still need the refclock, and > it appears that the pixel repeat

[Intel-gfx] [PATCH] tests/kms_addfb_basic: Move tiling tests into their own groups

So those subtests that require tiling don't cause unrelated subtests to be skipped. Signed-off-by: Tomeu Vizoso --- tests/kms_addfb_basic.c | 148 1 file changed, 73 insertions(+), 75 deletions(-) diff --git

Re: [Intel-gfx] [PATCH] drm/i915/dsi: fix CHV dsi encoder hardware state readout on port C

On Fri, Apr 15, 2016 at 03:47:31PM +0300, Jani Nikula wrote: > Due to "some hardware limitation" the DPI enable bit in port C control > register does not get set on VLV. As a workaround we check the status in > pipe B conf register instead. The workaround was added in > > commit

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Rest of my DSI and DPLL stuff

On Tue, 12 Apr 2016, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Here is the remainder of my DSI/DPLL series [1]. Everything else got merged > already. The first patch in the series is the only one to lack an r-b. > > Tested on BYT FFRD8 only, BXT

[Intel-gfx] [PATCH] drm/i915/dsi: fix CHV dsi encoder hardware state readout on port C

Due to "some hardware limitation" the DPI enable bit in port C control register does not get set on VLV. As a workaround we check the status in pipe B conf register instead. The workaround was added in commit c0beefd29fcb1ca998f0f9ba41be8539f8eeba9b Author: Gaurav K Singh

Re: [Intel-gfx] [PATCH v3] drm: Release driver references to handle before making it available again

On Fri, Apr 15, 2016 at 12:55:08PM +0100, Chris Wilson wrote: > When userspace closes a handle, we remove it from the file->object_idr > and then tell the driver to drop its references to that file/handle. > However, as the file/handle is already available again for reuse, it may > be reallocated

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/3] drm/edid: Add drm_edid_get_monitor_name()

On Fri, Apr 15, 2016 at 06:26:18AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v4,1/3] drm/edid: Add > drm_edid_get_monitor_name() > URL : https://patchwork.freedesktop.org/series/5731/ > State : failure > > == Summary == > > Series 5731v1 Series without

Re: [Intel-gfx] [PATCH v2 05/11] drm/i915: Allow mmio updates on all platforms, v2.

On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote: > Rename intel_unpin_work to intel_flip_work and use it for mmio flips > and unpinning. I think the rename should be a separate patch. Ander > Use flip_queued_req to hold the wait request in the > mmio case and allow the vblank

Re: [Intel-gfx] [PATCH 4/4] drm/i915: fix relocation of secure buffers

On 15/04/2016 12:43, Chris Wilson wrote: On Fri, Apr 15, 2016 at 12:32:57PM +0100, Dave Gordon wrote: There is a problem with the relocation of batches submitted with the I915_EXEC_SECURE flag: although the batch itself will be mapped into the GGTT, any relocations referring to it will use its

Re: [Intel-gfx] [PATCH v2 03/11] drm/i915: Remove intel_prepare_page_flip.

On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote: > Do it in 1 step instead, use atomic_read since INTEL_FLIP_COMPLETE > is no longer useful. What's the deal with "use atomic_read"? I couldn't find where that is different from the old code. > > Signed-off-by: Maarten Lankhorst

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/2] drm/i915: Show pin mapped status in describe_obj

== Series Details == Series: series starting with [resend-for-CI,1/2] drm/i915: Show pin mapped status in describe_obj URL : https://patchwork.freedesktop.org/series/5771/ State : failure == Summary == Series 5771v1 Series without cover letter

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Refactor execlists default context pinning

On Fri, Apr 15, 2016 at 12:54:33PM +0100, Tvrtko Ursulin wrote: > From: Chris Wilson > > Refactor pinning and unpinning of contexts, such that the default > context for an engine is pinned during initialisation and unpinned > during teardown (pinning of the context

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Keep the previous context pinned until the next one has been completed

On Fri, Apr 15, 2016 at 12:54:34PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In GuC mode submitting requests is only putting them into the > GuC queue with the actual submission to hardware following at > some future point. This makes the per engine last

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: Fix/enable display power well support/runtime PM (rev5)

On ti, 2016-04-05 at 12:19 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/bxt: Fix/enable display power well support/runtime > PM (rev5) > URL   : https://patchwork.freedesktop.org/series/5177/ > State : success Thanks for the reviews, I pushed the patchset to -dinq. As

[Intel-gfx] [PATCH] lib: Declare loop variable as volatile before setjmp

The variable used as loop counter in the igt_fixture macro had unspecified value from the setjmp(3) man page quoted below. Because of that, in certain circumstances and with -O2 and -Os, the initialization of that variable would be eliminated and the compiler would complain of uninitialized usage.

[Intel-gfx] [PATCH v3] drm: Release driver references to handle before making it available again

When userspace closes a handle, we remove it from the file->object_idr and then tell the driver to drop its references to that file/handle. However, as the file/handle is already available again for reuse, it may be reallocated back to userspace and active on a new object before the driver has had

[Intel-gfx] [PATCH 0/3] GuC premature LRC unpin

From: Tvrtko Ursulin Just exercising the fix for GuC premature LRC unpin on the CI. Chris Wilson (1): drm/i915: Refactor execlists default context pinning Tvrtko Ursulin (2): drm/i915/guc: Keep the previous context pinned until the next one has been completed

[Intel-gfx] [PATCH 3/3] DO NOT MERGE: drm/i915: Enable GuC submission

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_params.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Keep the previous context pinned until the next one has been completed

From: Tvrtko Ursulin In GuC mode submitting requests is only putting them into the GuC queue with the actual submission to hardware following at some future point. This makes the per engine last context tracking insufficient for closing the premature context unpin race.

[Intel-gfx] [PATCH 1/3] drm/i915: Refactor execlists default context pinning

From: Chris Wilson Refactor pinning and unpinning of contexts, such that the default context for an engine is pinned during initialisation and unpinned during teardown (pinning of the context handles the reference counting). Thus we can eliminate the special case

Re: [Intel-gfx] [PATCH v2] mm/vmalloc: Keep a separate lazy-free list

On Fri, Apr 15, 2016 at 1:07 PM, Chris Wilson wrote: > When mixing lots of vmallocs and set_memory_*() (which calls > vm_unmap_aliases()) I encountered situations where the performance > degraded severely due to the walking of the entire vmap_area list each > invocation.

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: keep GuC objects mapped in kernel

On 15/04/16 12:12, Dave Gordon wrote: On 15/04/2016 11:04, Tvrtko Ursulin wrote: On 14/04/16 18:19, Dave Gordon wrote: With the new i915_gem_obj_pin_map() interface, it makes sense to keep GuC objects (which are always pinned in memory and in the GGTT anyway) mapped into kernel address

Re: [Intel-gfx] [PATCH 4/4] drm/i915: fix relocation of secure buffers

On Fri, Apr 15, 2016 at 12:32:57PM +0100, Dave Gordon wrote: > There is a problem with the relocation of batches submitted with the > I915_EXEC_SECURE flag: although the batch itself will be mapped into the > GGTT, any relocations referring to it will use its address in the PPGTT, > which almost

[Intel-gfx] [PATCH 1/4] drm/i915: compile-time consistency check on __EXEC_OBJECT flags

Two different sets of flag bits are stored in the 'flags' member of a 'struct drm_i915_gem_exec_object2', and they're defined in two different source files, increasing the risk of an accidental clash. Some flags in this field are supplied by the user; these are defined in i915_drm.h, and they

[Intel-gfx] [PATCH 2/4] drm/i915: clarify eb_get_batch()

It may not be obvious, but the current execbuffer2 ioctl interface requires that the buffer object containing the batch-to-be-executed be the LAST entry in the exec2_list[] array (I expected it to be the first!). To clarify this, we can replace the rather obscure construct

[Intel-gfx] [PATCH 3/4] drm/i915: refactor eb_get_batch()

Precursor for fix to secure batch execution. We will need to be able to retrieve the batch VMA (as well as the batch itself) from the eb list, so this patch extracts that part of eb_get_batch() into a separate function, and moves both parts to a more logical place in the file, near where the eb

[Intel-gfx] [PATCH 4/4] drm/i915: fix relocation of secure buffers

There is a problem with the relocation of batches submitted with the I915_EXEC_SECURE flag: although the batch itself will be mapped into the GGTT, any relocations referring to it will use its address in the PPGTT, which almost certainly won't be the same. Hence a batch containing an

Re: [Intel-gfx] [for-CI-v2] drm/i915/mocs: Program MOCS for all engines on init

On Fri, Apr 15, 2016 at 10:16:25AM +0100, Peter Antoine wrote: > Thanks for tidying up and pushing. Fwiw, I extended the test to demonstrate that !rcs engines are also suspectible to the same pollution where one process can affect the register settings of an another. -Chris -- Chris Wilson,

Re: [Intel-gfx] [PATCH] mm/vmalloc: Keep a separate lazy-free list

On Thu, Apr 14, 2016 at 04:44:48PM +0200, Roman Peniaev wrote: > On Thu, Apr 14, 2016 at 3:49 PM, Chris Wilson > wrote: > > On Thu, Apr 14, 2016 at 03:13:26PM +0200, Roman Peniaev wrote: > >> Hi, Chris. > >> > >> Is it made on purpose not to drop VM_LAZY_FREE flag in >

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: keep GuC objects mapped in kernel

On 15/04/2016 11:04, Tvrtko Ursulin wrote: On 14/04/16 18:19, Dave Gordon wrote: With the new i915_gem_obj_pin_map() interface, it makes sense to keep GuC objects (which are always pinned in memory and in the GGTT anyway) mapped into kernel address space, rather than mapping and unmapping them

[Intel-gfx] [PATCH v2] mm/vmalloc: Keep a separate lazy-free list

When mixing lots of vmallocs and set_memory_*() (which calls vm_unmap_aliases()) I encountered situations where the performance degraded severely due to the walking of the entire vmap_area list each invocation. One simple improvement is to add the lazily freed vmap_area to a separate lockless free

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison

On Wednesday 13 April 2016 08:16 PM, Daniel Vetter wrote: On Wed, Apr 13, 2016 at 06:34:25PM +0530, Ramalingam C wrote: On Wednesday 13 April 2016 05:27 PM, Daniel Vetter wrote: On Wed, Apr 13, 2016 at 1:48 PM, Daniel Vetter wrote: On Wed, Apr 13, 2016 at 1:06 PM, Jani

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915:bxt: Enable Pooled EU support (rev2)

Daniel, are we able to upstream the pooled EU support now. Looks like an open Source user will be with us soon. This is basically the same patch that Arun submitted last year, just rebased. Further comments welcome of course Tim Tim Gore  Intel Corporation (UK) Ltd. - Co. Reg. #1134945 -

Re: [Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

On 15/04/16 11:38, Chris Wilson wrote: On Fri, Apr 15, 2016 at 11:19:30AM +0100, Tvrtko Ursulin wrote: On 15/04/16 11:00, Chris Wilson wrote: On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote: On 13/04/16 16:12, Chris Wilson wrote: On Wed, Apr 13, 2016 at 03:47:58PM +0100,

Re: [Intel-gfx] [PATCH] drm/i915: Remove a couple pointless WARN_ONs

On Fri, Apr 15, 2016 at 11:37:18AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Just two WARN_ONs followed by pointer dereference I spotted by accident. > > Signed-off-by: Tvrtko Ursulin I too keep removing these. Reviewed-by:

Re: [Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

On Fri, Apr 15, 2016 at 11:19:30AM +0100, Tvrtko Ursulin wrote: > On 15/04/16 11:00, Chris Wilson wrote: > >On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote: > >> > >>On 13/04/16 16:12, Chris Wilson wrote: > >>>On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote: > + /*

[Intel-gfx] [PATCH] drm/i915: Remove a couple pointless WARN_ONs

From: Tvrtko Ursulin Just two WARN_ONs followed by pointer dereference I spotted by accident. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c| 2 -- drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +-- 2 files

[Intel-gfx] [PATCH resend-for-CI 2/2] drm/i915: Show pin mapped counts and sizes in debugfs

From: Tvrtko Ursulin Show a total and purgeable number of pin mapped objects and their total and purgeable size. Example output (new stat prefixed with a star): # cat i915_gem_objects 19920 objects, 289243136 bytes 19920 [18466] objects, 288714752 [267911168]

[Intel-gfx] [PATCH resend-for-CI 1/2] drm/i915: Show pin mapped status in describe_obj

From: Tvrtko Ursulin Reflect the status of obj->mapping as added with the i915_gem_object_pin_map API. 'M' was chosen to designate the pin mapped status. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Reviewed-by:

Re: [Intel-gfx] [PATCH] tests/kms_addfb_basic: Set tiling in addfb25 subtest

On 15/04/16 10:50, Tomeu Vizoso wrote: When moving the call to gem_set_tiling into the subtests, the one needed by addfb25-framebuffer-vs-set-tiling was left out. Signed-off-by: Tomeu Vizoso --- tests/kms_addfb_basic.c | 1 + 1 file changed, 1 insertion(+) diff

Re: [Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

On 15/04/16 11:00, Chris Wilson wrote: On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote: On 13/04/16 16:12, Chris Wilson wrote: On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote: + /* We also want to clear any cached iomaps as they wrap vmap */ +

Re: [Intel-gfx] [PATCH] drm/i915: Clean up PCI config register handling

On Fri, Apr 15, 2016 at 12:17:18PM +0300, Joonas Lahtinen wrote: > Do not use magic numbers, do not prefix stuff with "PCI_", do not > declare registers in implementation files. Also move the PCI > registers under correct comment in i915_reg.h. > > Cc: Jani Nikula > Cc:

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_module_reload_basic: Do not require snd-hda-intel

On Fri, Apr 15, 2016 at 10:19:32AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Recent refactoring has made absence of snd-hda-intel a test > failure do the respective modprobe being at the end of a > reload function now. > > Only fail in this case if module

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: stop using kmap_atomic() during request submission

On 14/04/16 18:19, Dave Gordon wrote: From: Alex Dai Now that we keep GuC shared objects mapped into kernel space for their entire lifetime, we can simplify the code for accessing the doorbells and work queue, which were previously calling kmap_atomic() on *each* request

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: keep GuC objects mapped in kernel

On 14/04/16 18:19, Dave Gordon wrote: With the new i915_gem_obj_pin_map() interface, it makes sense to keep GuC objects (which are always pinned in memory and in the GGTT anyway) mapped into kernel address space, rather than mapping and unmapping them on each access. This preliminary patch

Re: [Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote: > > On 13/04/16 16:12, Chris Wilson wrote: > >On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote: > >>+ /* We also want to clear any cached iomaps as they wrap vmap */ > >>+ list_for_each_entry_safe(vma, next, > >>+

[Intel-gfx] [PATCH] tests/kms_addfb_basic: Set tiling in addfb25 subtest

When moving the call to gem_set_tiling into the subtests, the one needed by addfb25-framebuffer-vs-set-tiling was left out. Signed-off-by: Tomeu Vizoso --- tests/kms_addfb_basic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/kms_addfb_basic.c

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up PCI config register handling

== Series Details == Series: drm/i915: Clean up PCI config register handling URL : https://patchwork.freedesktop.org/series/5768/ State : failure == Summary == Series 5768v1 drm/i915: Clean up PCI config register handling http://patchwork.freedesktop.org/api/1.0/series/5768/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

On 13/04/16 16:12, Chris Wilson wrote: On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote: + /* We also want to clear any cached iomaps as they wrap vmap */ + list_for_each_entry_safe(vma, next, +_priv->ggtt.base.inactive_list, vm_link) +

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915:bxt: Enable Pooled EU support (rev2)

== Series Details == Series: drm/i915:bxt: Enable Pooled EU support (rev2) URL : https://patchwork.freedesktop.org/series/5725/ State : failure == Summary == Series 5725v2 drm/i915:bxt: Enable Pooled EU support http://patchwork.freedesktop.org/api/1.0/series/5725/revisions/2/mbox/ Test

[Intel-gfx] [PATCH i-g-t] igt/drv_module_reload_basic: Do not require snd-hda-intel

From: Tvrtko Ursulin Recent refactoring has made absence of snd-hda-intel a test failure do the respective modprobe being at the end of a reload function now. Only fail in this case if module was previously unloaded. Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [for-CI-v2] drm/i915/mocs: Program MOCS for all engines on init

Thanks for tidying up and pushing. Peter. On Thu, 14 Apr 2016, Chris Wilson wrote: On Wed, Apr 13, 2016 at 03:03:25PM +0100, Chris Wilson wrote: From: Peter Antoine Allow for the MOCS to be programmed for all engines. Currently we program the MOCS when the first

[Intel-gfx] [PATCH] drm/i915: Clean up PCI config register handling

Do not use magic numbers, do not prefix stuff with "PCI_", do not declare registers in implementation files. Also move the PCI registers under correct comment in i915_reg.h. Cc: Jani Nikula Cc: Chris Wilson Cc: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variations.

== Series Details == Series: drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variations. URL : https://patchwork.freedesktop.org/series/5751/ State : success == Summary == Series 5751v1 drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variations.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Use readl/writel for ring buffer access

On 14/04/16 17:37, Patchwork wrote: == Series Details == Series: series starting with [1/3] drm/i915: Use readl/writel for ring buffer access URL : https://patchwork.freedesktop.org/series/5714/ State : failure == Summary == Series 5714v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915:bxt: Enable Pooled EU support

From: Tim Gore This is a re-send of patch 3/3 from Arun Siluvery's patch series "Add Pooled EU support to BXT", originally submitted 20 July 2015. Patches 1 and 2 are already merged in preparation. This final patch actually enables the feature. The rest of this commit message

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [V2,1/3] PSR status on sysfs interface

== Series Details == Series: series starting with [V2,1/3] PSR status on sysfs interface URL : https://patchwork.freedesktop.org/series/5750/ State : success == Summary == Series 5750v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/5750/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 04/14] drm/i915: use drm_crtc_send_vblank_event()

On Thu, Apr 14, 2016 at 10:48:15AM -0700, Gustavo Padovan wrote: > From: Gustavo Padovan > > Replace the legacy drm_send_vblank_event() with the new helper function. > > Signed-off-by: Gustavo Padovan Applied to drm-intel.git,

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Clear VLV_IER around irq processing

Mika Kuoppala writes: > [ text/plain ] > ville.syrj...@linux.intel.com writes: > >> [ text/plain ] >> From: Ville Syrjälä >> >> On VLV/CHV the master interrupt enable bit only affects GT/PM >> interrupts. Display interrupts are not

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix eDP low vswing for Broadwell (rev3)

On Thursday 14 April 2016 19:20:22 Ville Syrjälä wrote: > On Wed, Apr 13, 2016 at 05:07:04PM -, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Fix eDP low vswing for Broadwell (rev3) > > URL : https://patchwork.freedesktop.org/series/4499/ > > State : failure > > > >

Re: [Intel-gfx] [PATCH] drm/i915/skl: Update eDRAM calculation

Ben Widawsky writes: > [ text/plain ] > On Thu, Apr 14, 2016 at 07:48:13AM -0700, Ben Widawsky wrote: >> On Thu, Apr 14, 2016 at 11:14:48AM +0300, Jani Nikula wrote: >> > On Thu, 14 Apr 2016, Jani Nikula wrote: >> > > On Wed, 13 Apr 2016, Ben

[Intel-gfx] ✗ Fi.CI.BAT: failure for pwm: add support for atomic update (rev2)

== Series Details == Series: pwm: add support for atomic update (rev2) URL : https://patchwork.freedesktop.org/series/5071/ State : failure == Summary == Series 5071v2 pwm: add support for atomic update http://patchwork.freedesktop.org/api/1.0/series/5071/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH v2 02/11] drm/i915: Remove stallcheck special handling.

On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote: > Re-use unpin_work->pending, but also set vblank count before > intel_mark_page_flip_active to be sure. Be sure of what? > > Signed-off-by: Maarten Lankhorst > --- >

Re: [Intel-gfx] [PATCH v5 07/24] regulator: pwm: use pwm_get_args() where appropriate

On Thu, Apr 14, 2016 at 09:17:27PM +0200, Boris Brezillon wrote: > The PWM framework has clarified the concept of reference PWM config > (the platform dependent config retrieved from the DT or the PWM > lookup table) and real PWM state. Acked-by: Mark Brown signature.asc

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/guc: keep GuC objects mapped in kernel

== Series Details == Series: series starting with [1/3] drm/i915/guc: keep GuC objects mapped in kernel URL : https://patchwork.freedesktop.org/series/5732/ State : failure == Summary == Series 5732v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/3] drm/edid: Add drm_edid_get_monitor_name()

== Series Details == Series: series starting with [v4,1/3] drm/edid: Add drm_edid_get_monitor_name() URL : https://patchwork.freedesktop.org/series/5731/ State : failure == Summary == Series 5731v1 Series without cover letter