[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

== Series Details == Series: drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE URL : https://patchwork.freedesktop.org/series/19477/ State : failure == Summary == Series 19477v1 drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Enable fine-tuned RPS for cherryview

== Series Details == Series: series starting with [1/3] drm/i915: Enable fine-tuned RPS for cherryview URL : https://patchwork.freedesktop.org/series/19461/ State : success == Summary == Series 19461v1 Series without cover letter

Re: [Intel-gfx] [PATCH xf86-video-intel v2] tools/backlight_helper: #include "config.h"

On Wed, Dec 07, 2016 at 10:33:34AM -0500, Mike Frysinger wrote: > From: Mike Gilbert > > The file uses defines from config.h but never actually includes it. > > Signed-off-by: Mike Gilbert > Signed-off-by: Mike Frysinger To

Re: [Intel-gfx] [PATCH] drm/i915: Rename conditional GEM execution macros

On Tue, Feb 07, 2017 at 04:16:31PM +0200, Joonas Lahtinen wrote: > On ti, 2017-02-07 at 10:23 +, Chris Wilson wrote: > > After a brief discussion, we settled on a naming convention for the > > conditional GEM debugging data that should be clearer to the casual > > user: GEM_DEBUG > > > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add engine idle check for CI

== Series Details == Series: drm/i915: Add engine idle check for CI URL : https://patchwork.freedesktop.org/series/19456/ State : success == Summary == Series 19456v1 drm/i915: Add engine idle check for CI https://patchwork.freedesktop.org/api/1.0/series/19456/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915: Move the irq_barrier for reset earlier into reset_prepare

On Fri, Feb 10, 2017 at 12:05:53PM -0800, Michel Thierry wrote: > > On 10/02/17 10:52, Chris Wilson wrote: > >When updating the bookkeeping following the reset, we need the seqno to > >be coherent on the CPU prior to trusting its result for deciding whether > >any request is completed. We need

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move the irq_barrier for reset earlier into reset_prepare

== Series Details == Series: drm/i915: Move the irq_barrier for reset earlier into reset_prepare URL : https://patchwork.freedesktop.org/series/19473/ State : failure == Summary == Series 19473v1 drm/i915: Move the irq_barrier for reset earlier into reset_prepare

[Intel-gfx] [PATCH i-g-t] gitignore: Add files starting with .

I cant be the only one that have added .tags by mistake. Cc: Marius Vlad Cc: Petri Latvala Signed-off-by: Michel Thierry --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index

Re: [Intel-gfx] [PATCH] drm/i915: Move the irq_barrier for reset earlier into reset_prepare

On 10/02/17 10:52, Chris Wilson wrote: When updating the bookkeeping following the reset, we need the seqno to be coherent on the CPU prior to trusting its result for deciding whether any request is completed. We need the irq_barrier before we start making these decisions, i.e. in

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

+ /* * Tell the GuC to allocate or deallocate a specific doorbell */ -static int guc_allocate_doorbell(struct intel_guc *guc, -struct i915_guc_client *client) +static int __create_doorbell_hw(struct i915_guc_client *client) I would rather prefer to only

[Intel-gfx] [PATCH] drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

The warnings from parsing the EDID are not driver errors, but the "normal but significant" conditions from the external device. As such, they do not need the ferocity of an *ERROR*, but can use the less harsh DRM_NOTE instead. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

On 10/02/17 05:30, Joonas Lahtinen wrote: Started adding proper teardown to guc_client_alloc, ended up removing quite a few dead ends where errors communicating with the GuC were silently ignored. There also seemed to be quite a few erronous teardown actions performed in case of an error

[Intel-gfx] [PATCH v2 22/22] drm/i915: Differentiate the aliasing_ppgtt with an invalid filp

Use an invalid filp so that the aliasing_ppgtt can be clearly identified. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c

[Intel-gfx] [PATCH v2 21/22] drm/i915: Only preallocate the aliasing GTT to the extents of the global GTT

As the aliasing GTT is only accessed via the global GTT, we will never use more of it than we expose via the Global GTT and so we only need to preallocate sufficient space within the ppgtt for the full GTT. Equally, if the aliasing GTT is smaller than the global GTT, we have a serious issue and

[Intel-gfx] [PATCH v2 17/22] drm/i915: Always mark the PDP as dirty when altered

We want to reload the PDP (and flush the TLB) when the addresses are changed. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH v2 16/22] drm/i915: Remove superfluous posting reads after clear GGTT

The barrier here is not required - we apply the barrier before the range is ever reused by the GPU instead. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 3 --- 1 file changed, 3 deletions(-)

[Intel-gfx] [PATCH v2 20/22] drm/i915: Remove i915_address_space.start

Once upon a time, back in the UMS days, we supported userspace initialising the GTT and sharing portions of the GTT with other users. Now, we own the GTT (both global and per-process) and the tables always start at 0 - so we can remove i915_address_space.start and forget about this old

[Intel-gfx] [PATCH v2 19/22] drm/i915: Remove unused ppgtt->enable()

We never assign or use the ppgtt->enable() callback, so remove it. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_gtt.h | 1 - 1 file changed, 1 deletion(-) diff --git

[Intel-gfx] [PATCH v2 18/22] drm/i915: Remove defunct GTT tracepoints

The tracepoints are now entirely synonymous with binding and unbinding the VMA (and the tracepoints there). Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 4 -- drivers/gpu/drm/i915/i915_trace.h

[Intel-gfx] [PATCH v2 10/22] drm/i915: Remove redundant clear of appgtt

Upon creation of the va range, it is initialised to point at scratch. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 5 - 1 file changed, 5 deletions(-) diff --git

[Intel-gfx] [PATCH v2 11/22] drm/i915: Tidy gen6_write_pde()

Stop passing around unused parameters makes the code more compact. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + 1 file changed, 14 insertions(+), 25

[Intel-gfx] [PATCH v2 08/22] drm/i915: Move allocate_va_range to GTT

In the future, we need to call allocate_va_range on the aliasing-ppgtt which means moving the call down from the vma into the vm (which is more appropriate for calling the vm function). Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ---

[Intel-gfx] [PATCH v2 09/22] drm/i915: Always preallocate gen6/7 ppgtt

The hardware does not cope very well with us changing the PD within an active context (the context must be idle for it to re-read the PD). As we only check whether the page is idle before changing the entry (and on through the PD tree), we cannot reliably replace PD entries on gen6/gen7. To fully

[Intel-gfx] [PATCH v2 13/22] drm/i915: Remove bitmap tracking for used-pdes

We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH v2 15/22] drm/i915: Remove bitmap tracking for used-pml4

We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH v2 06/22] drm/i915: Convert clflushed pagetables over to WC maps

We flush the entire page every time we update a few bytes, making the update of a page table many, many times slower than is required. If we create a WC map of the page for our updates, we can avoid the clflush but incur additional cost for creating the pagetable. We amoritize that cost by reusing

[Intel-gfx] [PATCH v2 07/22] drm/i915: Remove kmap/kunmap wrappers

As these are now both plain and simple kmap_atomic/kunmap_atomic pairs, we can remove the wrappers for a small gain of clarity (in particular, not hiding the atomic critical sections!). Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ---

[Intel-gfx] [PATCH v2 14/22] drm/i915: Remove bitmap tracking for used-pdpes

We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH v2 12/22] drm/i915: Remove bitmap tracking for used-ptes

We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH v2 04/22] drm/i915: Don't special case teardown of aliasing_ppgtt

The aliasing_ppgtt is a regular ppgtt, and we can use the regular i915_ppgtt_put() to properly tear it down. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 50

[Intel-gfx] [PATCH v2 05/22] drm/i915: Split ggtt/alasing_gtt unbind_vma

Similar to how we already split the bind_vma for ggtt/aliasing_gtt, also split up the unbind for symmetry. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 30 ++ 1 file

[Intel-gfx] [PATCH v2 01/22] drm/i915: Micro-optimise i915_get_ggtt_vma_pages()

The predominant VMA class is normal GTT, so allow gcc to emphasize that path and avoid unnecessary stack movement. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 61

[Intel-gfx] [PATCH v2 03/22] drm/i915: Micro-optimise gen8_ppgtt_insert_entries()

Improve the sg iteration and in hte process eliminate a bug in miscomputing the pml4 length as orig_nents< --- drivers/gpu/drm/i915/i915_gem_gtt.c | 157 +++- 1 file changed, 82 insertions(+), 75 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c

[Intel-gfx] [PATCH v2 02/22] drm/i915: Micro-optimise gen6_ppgtt_insert_entries()

Inline the address computation to avoid the vfunc call for every page. We still have to pay the high overhead of sg_page_iter_next(), but now at least GCC can optimise the inner most loop, giving a significant boost to some thrashing Unreal Engine workloads. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] drm/i915: Move the irq_barrier for reset earlier into reset_prepare

When updating the bookkeeping following the reset, we need the seqno to be coherent on the CPU prior to trusting its result for deciding whether any request is completed. We need the irq_barrier before we start making these decisions, i.e. in reset_prepare. References:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Split device release from unload

== Series Details == Series: series starting with [CI,1/3] drm/i915: Split device release from unload URL : https://patchwork.freedesktop.org/series/19467/ State : success == Summary == Series 19467v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for HDMI 2.0: Scrambling in DRM layer (rev2)

== Series Details == Series: HDMI 2.0: Scrambling in DRM layer (rev2) URL : https://patchwork.freedesktop.org/series/19161/ State : success == Summary == Series 19161v2 HDMI 2.0: Scrambling in DRM layer https://patchwork.freedesktop.org/api/1.0/series/19161/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915: Enable HPD interrupts with master ctl interrupt

On Fri, Feb 10, 2017 at 07:37:25PM +0200, Imre Deak wrote: > On Tue, Dec 27, 2016 at 06:59:56PM +0530, Animesh Manna wrote: > > While suspending the device hpd related interrupts are enabled > > to get the interrupt when device is in suspend state. > > > > Though display is in DC9 but system can

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915: Enable fine-tuned RPS for cherryview

== Series Details == Series: series starting with [1/3] drm/i915: Enable fine-tuned RPS for cherryview URL : https://patchwork.freedesktop.org/series/19461/ State : warning == Summary == Series 19461v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915: Enable HPD interrupts with master ctl interrupt

On Tue, Dec 27, 2016 at 06:59:56PM +0530, Animesh Manna wrote: > While suspending the device hpd related interrupts are enabled > to get the interrupt when device is in suspend state. > > Though display is in DC9 but system can be in S0 or S0i3 state. > Hot plug during S0 state will generate

Re: [Intel-gfx] [PATCH v3 3/5] drm/i915/bxt: Added _DSM call to set HPD_CTL.

On Tue, Dec 27, 2016 at 06:59:54PM +0530, Animesh Manna wrote: > _DSM is added to program HPD_CTL(0x1094) register > of PMC from i915 driver which will be called > based on driver feature flag. > > During S0ix display engine is completely powered down. Hot plug will be > missed by display HPD

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/bxt: Corrected the guid for bxt.

On Tue, Dec 27, 2016 at 06:59:52PM +0530, Animesh Manna wrote: > Guid is changed for bxt platform, so corrected the guid for bxt. > > v1: Initial version as RFC. > > v2: Based on review comment from Jani and David, > have kept guid as binary format. > > v3: Based on review comment from Chris

Re: [Intel-gfx] [PATCH] drm/i915: Avoid spurious WARNs about the wrong pipe in the PPS code

On Thu, Feb 09, 2017 at 12:29:04PM +0200, Imre Deak wrote: > On Wed, Feb 08, 2017 at 07:52:54PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Until recently vlv_steal_power_sequencer() wasn't being called for > > normal DP ports, and

Re: [Intel-gfx] [PATCH] drm/i915: Simplify platform checks in intel_fb_pitch_limit()

On Thu, Feb 09, 2017 at 03:15:35PM +0200, Ander Conselvan De Oliveira wrote: > On Wed, 2017-02-08 at 19:53 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Replace the VLV/CHV check with a HAS_GMCH_DISPLAY check > > in Fixed, and pushed

[Intel-gfx] [CI 1/3] drm/i915: Split device release from unload

We may need to keep our memory management alive after we have unloaded the physical pci device. For example, if we have exported an object via dmabuf, that will keep the device around but the pci device may be removed before the dmabuf itself is released, use of the pci hardware will be revoked,

[Intel-gfx] [CI 3/3] drm/i915: Flush the freed object queue on device release

As dmabufs may live beyond the PCI device removal, we need to flush the freed object worker on device release, and include a warning in case there is a leak. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [CI 2/3] drm/i915: Unbind any residual objects/vma from the Global GTT on shutdown

We may unload the PCI device before all users (such as dma-buf) are completely shutdown. This may leave VMA in the global GTT which we want to revoke, whilst keeping the objects themselves around to service the dma-buf. Signed-off-by: Chris Wilson Reviewed-by: Joonas

[Intel-gfx] [PATCH v3 2/6] drm/edid: check for HF-VSDB block

From: Thierry Reding This patch implements a small function that finds if a given CEA db is hdmi-forum vendor specific data block or not. V2: Rebase. V3: Added R-B from Jose. Signed-off-by: Thierry Reding Signed-off-by: Shashank Sharma

Re: [Intel-gfx] [PATCH] drm/i915: Use fault-injection to force the shrinker to run in live GTT tests

On Fri, Feb 10, 2017 at 03:46:52PM +, Matthew Auld wrote: > On 8 February 2017 at 11:40, Chris Wilson wrote: > > It is possible whilst allocating the page-directory tree for a ppgtt > > bind that the shrinker may run and reap unused parts of the tree. If the > >

[Intel-gfx] [PATCH v3 6/6] drm/i915: allow HDMI 2.0 clock rates

Geminilake has a native HDMI 2.0 controller, which is capable of driving clocks upto 594Mhz. This patch updates the max tmds clock limit for the same. V2: rebase V3: rebase Cc: Ander Conselvan De Oliveira Signed-off-by: Shashank Sharma

[Intel-gfx] [PATCH v3 5/6] drm/i915: enable scrambling

Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher clocks, for reduced RF footprint. This patch checks if the monitor supports scrambling, and if required, enables it during the modeset.

[Intel-gfx] [PATCH v3 4/6] drm: scrambling support in drm layer

HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340 MHz. This patch adds few new functions in drm layer for core drivers to enable/disable scrambling. This patch adds: - A function to detect scrambling support parsing HF-VSDB - A function to check scrambling status

[Intel-gfx] [PATCH v3 3/6] drm/edid: detect SCDC support in HF-VSDB

This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected

[Intel-gfx] [PATCH v3 1/6] drm: Add SCDC helpers

From: Thierry Reding SCDC is a mechanism defined in the HDMI 2.0 specification that allows the source and sink devices to communicate. This commit introduces helpers to access the SCDC and provides the symbolic names for the various registers defined in the specification.

[Intel-gfx] [PATCH v3 0/6] HDMI 2.0: Scrambling in DRM layer

HDMI 2.0 spec defines a method to reduce the RF footprint while operating at higher pixel clocks, which is called Scrambling. Scrambling can be controlled over a new set of I2C registers which are accessible over existing DDC I2C lines, called SCDC register set. This patch series contains 6

Re: [Intel-gfx] [PATCH v3 0/5] HPD support during suspend for BXT/APL.

On Tue, Dec 27, 2016 at 06:59:51PM +0530, Animesh Manna wrote: > Along with below patches sharing some background details/design. > - On BXT, Display cannot generate an interrupt when in D3. > - Without display in D3, S0ix can be achieved, Power impact will be > zero if d3 is blocked. PMCSR for

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add engine idle check for CI

== Series Details == Series: drm/i915: Add engine idle check for CI URL : https://patchwork.freedesktop.org/series/19456/ State : failure == Summary == Series 19456v1 drm/i915: Add engine idle check for CI https://patchwork.freedesktop.org/api/1.0/series/19456/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915: Use fault-injection to force the shrinker to run in live GTT tests

On 8 February 2017 at 11:40, Chris Wilson wrote: > It is possible whilst allocating the page-directory tree for a ppgtt > bind that the shrinker may run and reap unused parts of the tree. If the > shrinker happens to remove a chunk of the tree that the >

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

On Fri, Feb 10, 2017 at 03:30:10PM +0200, Joonas Lahtinen wrote: > Started adding proper teardown to guc_client_alloc, ended up removing > quite a few dead ends where errors communicating with the GuC were > silently ignored. There also seemed to be quite a few erronous > teardown actions

[Intel-gfx] [PATCH 1/3] drm/i915: Enable fine-tuned RPS for cherryview

When the RPS tuning was applied to Baytrail, in commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail"), concern was given that it might cause Cherryview excess wakeups of the common power well. However, the static thresholds perform poorly for Kodi, and the GPU is unable to deliver

[Intel-gfx] [PATCH 2/3] drm/i915: Don't accidentally increase the frequency in handling DOWN rps

If we receive a DOWN_TIMEOUT rps interrupt, we respond by reducing the GPU clocks significantly. Before we do, double check that the frequency we pick is actually a decrease. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH 3/3] drm/i915: Only apply the jump to the "efficient RPS" frequency on startup

Currently we apply the jump to rpe if we are below it and the GPU needs more power. For some GPUs, the rpe is 75% of the maximum range causing us to dramatically overshoot low power applications *and* unable to reach the low frequency that can most efficiently deliver their workload.

Re: [Intel-gfx] [PATCH] drm/i915: Always pin contexts into the high GGTT

On Fri, Feb 10, 2017 at 03:39:31PM +0200, Joonas Lahtinen wrote: > On pe, 2017-02-10 at 10:14 +, Chris Wilson wrote: > > Now that we have fast top-down insertion into the drm_mm, we can use it > > for frequent runtime operations like insertion of the context object, > > whereas before we

Re: [Intel-gfx] [PATCH] drm/i915/byt: Take powerwell for reading PIPESTAT in debugfs

On Fri, Feb 10, 2017 at 03:41:46PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > [12493.693827] WARNING: CPU: 1 PID: 14860 at > > drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x5d/0x80 > > [i915] > > [12493.693868] Unclaimed read from

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

On Fri, Feb 10, 2017 at 03:30:10PM +0200, Joonas Lahtinen wrote: > +static unsigned long __reserve_cacheline(struct intel_guc* guc) > { > - const uint32_t cacheline_size = cache_line_size(); > - uint32_t offset; > + unsigned long offset; > > /* Doorbell uses a single cache

Re: [Intel-gfx] [PATCH] drm/i915: Add engine idle check for CI

On Fri, Feb 10, 2017 at 04:11:44PM +0200, Mika Kuoppala wrote: > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -347,9 +347,11 @@ static void execlists_submit_ports(struct > intel_engine_cs *engine) > u64 desc[2]; > > GEM_BUG_ON(port[0].count >

[Intel-gfx] ✗ Fi.CI.BAT: failure for Fix Geminilake DDI power well enable timeouts

== Series Details == Series: Fix Geminilake DDI power well enable timeouts URL : https://patchwork.freedesktop.org/series/19451/ State : failure == Summary == Series 19451v1 Fix Geminilake DDI power well enable timeouts https://patchwork.freedesktop.org/api/1.0/series/19451/revisions/1/mbox/

Re: [Intel-gfx] [GLK MIPI DSI V4 5/8] drm/i915/glk: Add DSI PLL divider range for glk

On Tue, 2017-02-07 at 18:13 +0530, Madhav Chauhan wrote: > From: Deepak M > > PLL divider range for GLK is different than that of > BXT, hence adding the GLK range check in this patch. > > Signed-off-by: Deepak M > Signed-off-by: Madhav Chauhan

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Merge BDW pipe gamma and degamma table code

On Fri, Feb 10, 2017 at 12:14:45PM +0200, Ander Conselvan De Oliveira wrote: > On Thu, 2017-02-09 at 16:47 +0200, Ville Syrjälä wrote: > > On Fri, Feb 03, 2017 at 03:11:13PM +0200, Ander Conselvan de Oliveira wrote: > > > The only difference between the code loading the pipe gamma and degamma > >

[Intel-gfx] [PATCH] drm/i915: Add engine idle check for CI

Assert for hardware idleness when we assign to execlist port, if for some reason we get off the tracks on sw tracking. Cc: Chris Wilson Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_engine_cs.c | 10 ++

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Sanitize GuC client initialization

== Series Details == Series: drm/i915: Sanitize GuC client initialization URL : https://patchwork.freedesktop.org/series/19452/ State : success == Summary == Series 19452v1 drm/i915: Sanitize GuC client initialization https://patchwork.freedesktop.org/api/1.0/series/19452/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm/i915/byt: Take powerwell for reading PIPESTAT in debugfs

Chris Wilson writes: > [12493.693827] WARNING: CPU: 1 PID: 14860 at > drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x5d/0x80 [i915] > [12493.693868] Unclaimed read from register 0x1f0024 > [12493.693905] Modules linked in: vgem i915 drm_kms_helper drm

Re: [Intel-gfx] [PATCH] drm/i915: Always pin contexts into the high GGTT

On pe, 2017-02-10 at 10:14 +, Chris Wilson wrote: > Now that we have fast top-down insertion into the drm_mm, we can use it > for frequent runtime operations like insertion of the context object, > whereas before we limited it to the one-off insertion of the pinned > kernel context. Keeping

[Intel-gfx] [PATCH] drm/i915/byt: Take powerwell for reading PIPESTAT in debugfs

[12493.693827] WARNING: CPU: 1 PID: 14860 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x5d/0x80 [i915] [12493.693868] Unclaimed read from register 0x1f0024 [12493.693905] Modules linked in: vgem i915 drm_kms_helper drm intel_gtt i2c_algo_bit syscopyarea sysfillrect sysimgblt

[Intel-gfx] [PATCH 6/6] drm/i915: Only enable DDI IO power domains after enabling DPLL

According to bspec, the DDI IO power domains should be enabled after enabling the DPLL and mapping it to the DDI. The current order doesn't seem to create problems with Skylake and Kabylake, but causes enable timeouts in Geminilake. Cc: David Weinehall

[Intel-gfx] [PATCH 5/6] drm/i915/glk: Don't attempt to sync DDI IO power well hw state

Geminilake's DDI IO power wells can only be enabled after a DPLL is running and must be disabled before disabling the DPLL. Attempting to change its state outside of this conditions will result in timeouts. That is the case when intel_power_domains_sync_hw() is called from

[Intel-gfx] [PATCH 3/6] drm/i915/glk: Implement WaDDIIOTimeout

Implement WaDDIIOTimeout to avoid a timeout when enabling the DDI IO power domains. Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h | 6 ++ drivers/gpu/drm/i915/i915_reg.h | 5 + drivers/gpu/drm/i915/intel_pm.c |

[Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

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

[Intel-gfx] [PATCH 4/6] drm/i915/glk: Don't enable DDI IO power domains during init

In Geminilake, the DDI IO power domains can't be enabled before a DPLL is running and mapped to the appropriate DDI. At least on Geminilake, attempting to enable those during init will lead to a timeout. The failure to enable the power domain also causes issues with the state verifier during

[Intel-gfx] [PATCH 0/6] Fix Geminilake DDI power well enable timeouts

Geminilake's DDI IO power wells are peculiar in that they can't be enabled without a DPLL running. This leads to enable timeouts in different places during the init and modeset sequence. This patch series attempts to fix those. I'm not particularly happy about adding 5 new power domains in the

[Intel-gfx] [PATCH 1/6] drm/i915: Store aux power domain in intel_dp

The aux power domain only makes sense in the DP code. Storing it in struct intel_dp avoids some indirection. v2: Rebase Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_display.c | 50 -

[Intel-gfx] [PATCH 2/6] drm/i915: Store encoder power domain in struct intel_encoder

The encoder power domain is obviously tied to the encoder, so store it in struct intel_encoder. This avoids some indirection. v2: Rebase Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_crt.c | 21 +

Re: [Intel-gfx] [PATCH] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

On Fri, 10 Feb 2017, Hans de Goede wrote: > On 06-02-17 08:04, Jani Nikula wrote: >> First, I want a big fat warning comment about what's going on >> here. Otherwise someone's bound to "fix" this later on. > > Done for v2, which I will send shortly. Thanks. >> Second, per

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DMC 1.02 for Kabylake

On Friday, 10 February 2017 13:57:47 EET Ander Conselvan De Oliveira wrote: > Seems like neither of the versions of DMC are being tested by CI. Added kbl_dmc_ver1_01.bin to fi-kbl-7500u. Can't see kbl_dmc_ver1_02 in the firmware repo. Tomi > > [1]: > > [3.466858]

Re: [Intel-gfx] [PATCH] drm/i915/guc: In the submission cleanup, do not bail out if there is no execbuf_client

On Thu, Feb 09, 2017 at 02:24:25AM -0800, Oscar Mateo wrote: > There is other stuff that potentially needs cleaning, even if we didn't get > to the point of > creating an execbuf_client. Just because the allocator doesn't employ onion unwinding? Or is there more to come? > Signed-off-by: Oscar

Re: [Intel-gfx] [PATCH 06/46] drm/i915: Add some selftests for sg_table manipulation

On 10/02/2017 10:43, Chris Wilson wrote: On Fri, Feb 10, 2017 at 10:24:41AM +, Tvrtko Ursulin wrote: +static int igt_sg_alloc(void *ignored) +{ + IGT_TIMEOUT(end_time); + const unsigned long max_order = 20; /* approximating a 4GiB object */ + struct rnd_state prng; +

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DMC 1.02 for Kabylake

Seems like neither of the versions of DMC are being tested by CI. [1]: [3.466858] [drm:intel_csr_ucode_init [i915]] Loading i915/kbl_dmc_ver1_02.bin [3.467169] i915 :00:02.0: Direct firmware load for i915/kbl_dmc_ver1_02.bin failed with error -2 [3.467189] i915 :00:02.0:

Re: [Intel-gfx] [PATCH 07/19] drm/i915: Remove kmap/kunmap wrappers

On 2 February 2017 at 15:02, Chris Wilson wrote: > As these are now both plain and simple kmap_atomic/kunmap_atomic pairs, > we can remove the wrappers for a small gain of clarity (in particular, > not hiding the atomic critical sections!). > > Signed-off-by: Chris

[Intel-gfx] [PATCH v2] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation for a vbt in mailbox #4 for this. This fixes the driver not finding the VBT on a jumper ezpad mini3 cherrytrail tablet and on a ACER SW5_017 machine. Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

Hi, On 06-02-17 08:04, Jani Nikula wrote: On Sun, 25 Dec 2016, Hans de Goede wrote: If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation for a vbt in mailbox #4 for this. This fixes

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Always pin contexts into the high GGTT

== Series Details == Series: drm/i915: Always pin contexts into the high GGTT URL : https://patchwork.freedesktop.org/series/19440/ State : success == Summary == Series 19440v1 drm/i915: Always pin contexts into the high GGTT

Re: [Intel-gfx] [PATCH 06/46] drm/i915: Add some selftests for sg_table manipulation

On Fri, Feb 10, 2017 at 10:24:41AM +, Tvrtko Ursulin wrote: > >+static int igt_sg_alloc(void *ignored) > >+{ > >+IGT_TIMEOUT(end_time); > >+const unsigned long max_order = 20; /* approximating a 4GiB object */ > >+struct rnd_state prng; > >+unsigned long prime; > >+ > >+

Re: [Intel-gfx] [PATCH 05/46] drm/i915: Provide a hook for selftests

On Fri, Feb 10, 2017 at 10:19:01AM +, Tvrtko Ursulin wrote: > > On 02/02/2017 09:08, Chris Wilson wrote: > >+static inline u32 i915_prandom_u32_max_state(u32 ep_ro, struct rnd_state > >*state) > >+{ > >+return upper_32_bits((u64)prandom_u32_state(state) * ep_ro); > > What is ep_ro?

Re: [Intel-gfx] [PATCH] drm/i915: Always pin contexts into the high GGTT

Chris Wilson writes: > Now that we have fast top-down insertion into the drm_mm, we can use it > for frequent runtime operations like insertion of the context object, > whereas before we limited it to the one-off insertion of the pinned > kernel context. Keeping the

[Intel-gfx] [PATCH v3 11/12] drm/i915: Add intel_uncore_suspend / resume functions

Rename intel_uncore_early_sanitize to intel_uncore_resume, dropping the (always true) restore_forcewake argument and add a new intel_uncore_resume function to replace the intel_uncore_forcewake_reset(dev_priv, false) calls done from the suspend / runtime_suspend functions and make

[Intel-gfx] [PATCH v3 10/12] i2c: designware-baytrail: Call pmic_bus_access_notifier_chain

Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire / release. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Signed-off-by: Hans de Goede Tested-by: tagorereddy Reviewed-by: Andy Shevchenko

[Intel-gfx] [PATCH v3 12/12] drm/i915: Listen for PMIC bus access notifications

Listen for PMIC bus access notifications and get FORCEWAKE_ALL while the bus is accessed to avoid needing to do any forcewakes, which need PMIC bus access, while the PMIC bus is busy: This fixes errors like these showing up in dmesg, usually followed by a gfx or system freeze:

[Intel-gfx] [PATCH v3 09/12] i2c: designware-baytrail: Acquire P-Unit access on bus acquire

Acquire P-Unit access to stop others from accessing the P-Unit while the PMIC i2c bus is in use. This is necessary because accessing the P-Unit from the kernel may result in the P-Unit trying to access the PMIC i2c bus, which results in a hang when it happens while we own the PMIC i2c bus

[Intel-gfx] [PATCH v3 08/12] i2c: designware-baytrail: Add support for cherrytrail

The cherrytrail punit has the pmic i2c bus access semaphore at a different register address. Signed-off-by: Hans de Goede Reviewed-by: Takashi Iwai Tested-by: Takashi Iwai Reviewed-by: Andy Shevchenko

[Intel-gfx] [PATCH v3 07/12] i2c: designware-baytrail: Fix race when resetting the semaphore

Use iosf_mbi_modify instead of iosf_mbi_read + iosf_mbi_write so that we keep the iosf_mbi_lock locked during the read-modify-write done to reset the semaphore. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Jarkko

  1   2   >