Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

On Mon, 2016-08-15 at 19:36 -0300, Paulo Zanoni wrote: > Ever since I started working on FBC I was already aware that FBC can > really amplify the FIFO underrun symptoms. On systems where FIFO > underruns were harmless error messages, enabling FBC would cause the > underruns to give black screens.

Re: [Intel-gfx] GPU hang with high media workload on BSW

One more thing to add, if allocate the ringbuffer not from stolen memory but normal memory, issue is gone. static int intel_alloc_ringbuffer_obj(struct drm_device *dev, struct intel_ringbuffer *ringbuf) { struct drm_i915_gem_object *obj; obj

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable upfront link training on DDI platforms (rev3)

== Series Details == Series: Enable upfront link training on DDI platforms (rev3) URL : https://patchwork.freedesktop.org/series/10821/ State : failure == Summary == Series 10821v3 Enable upfront link training on DDI platforms

Re: [Intel-gfx] [PATCH] drm/i915: Drop mutex around clearing error state

On Thu, Sep 01, 2016 at 09:55:10PM +0100, Chris Wilson wrote: > The error state itself is guarded by a spinlock (admittedly even that is > overkill for a single pointer!) and doesn't require us to take the > struct_mutex in the debugfs/sysfs interface. Removing the struct_mutex > removes one more

[Intel-gfx] [PATCH v2 01/14] drm/i915: Don't pass crtc_state to intel_dp_set_link_params()

From: Ander Conselvan de Oliveira Decouple intel_dp_set_link_params() from struct intel_crtc_state. This will be useful for implementing DP upfront link training. v2: * Rebased on atomic state changes (Manasi) Reviewed-by: Durgadoss R

[Intel-gfx] [PATCH v3 07/14] drm/i915/dp: Add a standalone function to obtain shared dpll for HSW/BDW/SKL/BXT

From: Jim Bride Add the PLL selection code for HSW/BDW/BXT/SKL into a stand-alone function in order to allow for the implementation of a platform neutral upfront link training function. v3: * Add Hooks for all DDI platforms into this standalone function v2: * Change

[Intel-gfx] [PATCH 06/14] drm/i915: Split hsw_get_dpll()

Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code that calculates the pll so that it doesn't depend on crtc state. This will be used for acquiring port pll when doing upfront link training. Reviewed-by: Durgadoss R

[Intel-gfx] [PATCH 05/14] drm/i915: Split skl_get_dpll()

From: Jim Bride Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code does not directly depend on crtc state, so that the code can be used for upfront link training. Reviewed-by: Manasi Navare

[Intel-gfx] [PATCH v11 13/14] drm/i915/dp: Enable Upfront link training for typeC DP support on HSW/BDW/SKL/BXT (DDI platforms)

From: Durgadoss R To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel

[Intel-gfx] [PATCH v2 02/14] drm/i915: Remove ddi_pll_sel from intel_crtc_state

From: Ander Conselvan de Oliveira The value of ddi_pll_sel is derived from the selection of shared dpll, so just calculate the final value when necessary. v2: Actually remove it from crtc state and delete remaining usages. (CI) Reviewed-by: Durgadoss R

[Intel-gfx] [PATCH v2 04/14] drm/i915: Split bxt_ddi_pll_select()

From: Durgadoss R Split out of bxt_ddi_pll_select() the logic that calculates the pll dividers and dpll_hw_state into a new function that doesn't depend on crtc state. This will be used for enabling the port pll when doing upfront link training. v2: * Refactored code so

[Intel-gfx] [PATCH 08/14] drm/i915/dp: Move max. vswing check to it's own function

From: Dhinakaran Pandiyan Wrap the max. vswing check in a separate function. This makes the clock recovery phase of DP link training cleaner Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp_link_training.c | 16

[Intel-gfx] [PATCH 11/14] drm/i915: Fallback to lower link rate and lane count during link training

According to the DisplayPort Spec, in case of Clock Recovery failure the link training sequence should fall back to the lower link rate followed by lower lane count until CR succeeds. On CR success, the sequence proceeds with Channel EQ. In case of Channel EQ failures, it should fallback to lower

[Intel-gfx] [PATCH 10/14] drm/i915: Make DP link training channel equalization DP 1.2 Spec compliant

Fix the number of tries in channel euqalization link training sequence according to DP 1.2 Spec. It returns a boolean depending on channel equalization pass or failure. Signed-off-by: Dhinakaran Pandiyan Signed-off-by: Manasi Navare ---

[Intel-gfx] [PATCH 12/14] drm/i915: Reverse the loop in intel_dp_compute_config

While configuring the pipe during modeset, it should loop starting from max clock and max lane count reducing the lane count and clock in each iteration until the requested mode rate is less than or equal to available link BW. Signed-off-by: Manasi Navare ---

[Intel-gfx] [PATCH 14/14] drm/i915/dp/mst: Add support for upfront link training for DP MST

From: Jim Bride Add upfront link training to intel_dp_mst_mode_valid() so that we know topology constraints before we validate the legality of modes to be checked. Call the function that loops through the link rates and lane counts starting from highest supported link

[Intel-gfx] [PATCH 09/14] drm/dp/i915: Make clock recovery in the link training compliant with DP Spec 1.2

From: Dhinakaran Pandiyan This function cleans up clock recovery loop in link training compliant tp Dp Spec 1.2. It tries the clock recovery 5 times for the same voltage or until max voltage swing is reached and removes the additional non compliant retries. This

[Intel-gfx] [PATCH 00/14] Enable Upfront Link Training on DDI platforms

This patch series enables upfront link training on DDI platforms (SKL/BDW/HSW/BXT) for DP SST and MST. They are based on some of the patches submitted earlier by Ander and Durgadoss. The upfront link training had to be factored out of long pulse hanlder because of deadlock issues seen on DP MST

[Intel-gfx] [PATCH v3 03/14] drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions

Split intel_ddi_pre_enable() into encoder type specific versions that don't depend on crtc_state. The necessary parameters are passed as function arguments. This split will be necessary for implementing DP upfront link training. v3: * Rebased onto latest kernel (Manasi) v2: * Rebased onto kernel

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Drop mutex around clearing error state

== Series Details == Series: drm/i915: Drop mutex around clearing error state URL : https://patchwork.freedesktop.org/series/11911/ State : failure == Summary == Series 11911v1 drm/i915: Drop mutex around clearing error state

[Intel-gfx] [PATCH] drm/i915: Drop mutex around clearing error state

The error state itself is guarded by a spinlock (admittedly even that is overkill for a single pointer!) and doesn't require us to take the struct_mutex in the debugfs/sysfs interface. Removing the struct_mutex removes one more potential blockage when trying to debug a deadlock. Signed-off-by:

Re: [Intel-gfx] igt/gem_exec_nop parallel test: why it isn't useful

On Thu, Sep 01, 2016 at 05:51:09PM +0100, Dave Gordon wrote: > The gem_exec_nop test generally works by submitting batches to an > engine as fast as possible for a fixed time, then finally calling > gem_sync() to wait for the last submitted batch to complete. The > time-per-batch is then

Re: [Intel-gfx] [PATCH] Another flavour of for_each_engine_masked()

On 01/09/16 15:48, Chris Wilson wrote: On Thu, Sep 01, 2016 at 03:17:44PM +0100, Dave Gordon wrote: This macro was recently updated to skip testing for non-existent or uninteresting engines by using ffs() to directly find the next engine of interest. However, it required the introduction of a

[Intel-gfx] igt/gem_exec_nop parallel test: why it isn't useful

The gem_exec_nop test generally works by submitting batches to an engine as fast as possible for a fixed time, then finally calling gem_sync() to wait for the last submitted batch to complete. The time-per-batch is then calculated as the total elapsed time, divided by the total number of

Re: [Intel-gfx] [PATCH] Another flavour of for_each_engine_masked()

On Thu, Sep 01, 2016 at 03:17:44PM +0100, Dave Gordon wrote: > This macro was recently updated to skip testing for non-existent or > uninteresting engines by using ffs() to directly find the next engine of > interest. However, it required the introduction of a caller-provided > temporary variable,

Re: [Intel-gfx] [PATCH] Another flavour of for_each_engine_masked()

On to, 2016-09-01 at 15:17 +0100, Dave Gordon wrote: > This macro was recently updated to skip testing for non-existent or > uninteresting engines by using ffs() to directly find the next engine of > interest. However, it required the introduction of a caller-provided > temporary variable, which

[Intel-gfx] [PATCH] Another flavour of for_each_engine_masked()

This macro was recently updated to skip testing for non-existent or uninteresting engines by using ffs() to directly find the next engine of interest. However, it required the introduction of a caller-provided temporary variable, which some people regard as inelegant. So, this patch provides

Re: [Intel-gfx] [PATCH igt 2/2] igt: Add exerciser for execbuf fence-out <-> fence-in

Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use atomic for dev_priv->mm.bsd_engine_dispatch_index

On to, 2016-09-01 at 15:32 +0300, Joonas Lahtinen wrote: > On to, 2016-09-01 at 13:27 +0100, Chris Wilson wrote: > > > > On Thu, Sep 01, 2016 at 12:20:18PM -, Patchwork wrote: > > > > > > Test prime_vgem: > > > Subgroup basic-fence-flip: > > > pass   -> FAIL   

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use atomic for dev_priv->mm.bsd_engine_dispatch_index

On to, 2016-09-01 at 13:27 +0100, Chris Wilson wrote: > On Thu, Sep 01, 2016 at 12:20:18PM -, Patchwork wrote: > > Test prime_vgem: > > Subgroup basic-fence-flip: > > pass   -> FAIL   (fi-bdw-5557u) > Hmm, this is probably some condition I forgot to drain before

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use atomic for dev_priv->mm.bsd_engine_dispatch_index

On Thu, Sep 01, 2016 at 12:20:18PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Use atomic for dev_priv->mm.bsd_engine_dispatch_index > URL : https://patchwork.freedesktop.org/series/11890/ > State : failure > > == Summary == > > Series 11890v1 drm/i915: Use atomic for

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Use atomic for dev_priv->mm.bsd_engine_dispatch_index

== Series Details == Series: drm/i915: Use atomic for dev_priv->mm.bsd_engine_dispatch_index URL : https://patchwork.freedesktop.org/series/11890/ State : failure == Summary == Series 11890v1 drm/i915: Use atomic for dev_priv->mm.bsd_engine_dispatch_index

Re: [Intel-gfx] [PATCH] drm/i915: Use atomic for dev_priv->mm.bsd_engine_dispatch_index

On Thu, Sep 01, 2016 at 02:58:21PM +0300, Joonas Lahtinen wrote: > Use atomic type and operands for dev_priv->mm.bsd_engine_dispatch_index > to avoid one struct_mutex locking scenario. > > Cc: Chris Wilson > Cc: Imre Deak > Cc: Zhao Yakui

[Intel-gfx] [PATCH] drm/i915: Use atomic for dev_priv->mm.bsd_engine_dispatch_index

Use atomic type and operands for dev_priv->mm.bsd_engine_dispatch_index to avoid one struct_mutex locking scenario. Cc: Chris Wilson Cc: Imre Deak Cc: Zhao Yakui Cc: Daniel Vetter Signed-off-by:

[Intel-gfx] ✗ Fi.CI.BAT: failure for Prep. for DP audio MST support (rev8)

== Series Details == Series: Prep. for DP audio MST support (rev8) URL : https://patchwork.freedesktop.org/series/11129/ State : failure == Summary == Series 11129v8 Prep. for DP audio MST support http://patchwork.freedesktop.org/api/1.0/series/11129/revisions/8/mbox/ Test kms_cursor_legacy:

Re: [Intel-gfx] [PATCH 09/10] drm/doc: Document color space handling

On 31/08/16 17:09, Daniel Vetter wrote: Again move it from the unmaintainable csv into DOC free-form overview sections. Cc: Lionel Landwerlin Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst| 12 +

Re: [Intel-gfx] [PATCH 08/10] drm: Extract drm_color_mgmt.[hc]

On 31/08/16 17:09, Daniel Vetter wrote: For both the new degamm/lut/gamma atomic combo, and the old legacy gamma tables. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/drm_color_mgmt.c| 248

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: read out slice/subslice masks (rev2)

== Series Details == Series: drm/i915: read out slice/subslice masks (rev2) URL : https://patchwork.freedesktop.org/series/33/ State : failure == Summary == Series 33v2 drm/i915: read out slice/subslice masks http://patchwork.freedesktop.org/api/1.0/series/33/revisions/2/mbox/ Test

[Intel-gfx] ✗ Fi.CI.BAT: failure for More splitting for drm_crtc.c

== Series Details == Series: More splitting for drm_crtc.c URL : https://patchwork.freedesktop.org/series/11834/ State : failure == Summary == Series 11834v1 More splitting for drm_crtc.c http://patchwork.freedesktop.org/api/1.0/series/11834/revisions/1/mbox/ Test kms_busy: Subgroup

Re: [Intel-gfx] [PATCH v4] drm/i915/dp: DP audio API changes for MST

The changes in this version are primarily in i915. I have carried over Takashi's R-B from the previous version and removed Ville's. From: Pandiyan, Dhinakaran Sent: Thursday, September 01, 2016 12:50 AM To: intel-gfx@lists.freedesktop.org Cc:

[Intel-gfx] [PATCH v4] drm/i915/dp: DP audio API changes for MST

DP MST provides the capability to send multiple video and audio streams through a single port. This requires the API's between i915 and audio drivers to distinguish between multiple audio capable displays that can be connected to a port. Currently only the port identity is shared in the APIs. This