Re: [Intel-gfx] [PATCH 08/17] drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI

On Thu, Mar 22, 2018 at 05:10:22PM -0700, Paulo Zanoni wrote: > From: Manasi Navare > > This is an important part of the DDI initalization as well as > for changing the voltage during DisplayPort link training. > > The Voltage swing seqeuence is similar to Cannonlake.

Re: [Intel-gfx] [PATCH 0/3] Optimize use of DBuf slices

On Thu, Apr 26, 2018 at 07:55:14PM +0530, Mahesh Kumar wrote: > Patches in this series were originally part of series: > https://patchwork.freedesktop.org/series/36993/ > > Reposting it here after rebase > use kernel types u8/u16 etc instead of uint8_t > > Changes: > - Rebase the series pushed

[Intel-gfx] [PATCH 1/3] drm/i915/guc: Load GuC v11.98 for Geminilake.

From: John Spotswood load the v11.98 guC on geminilake. Cc: Tomi Sarvela Cc: Jani Saarinen Signed-off-by: Anusha Srivatsa Signed-off-by: John Spotswood ---

[Intel-gfx] [PATCH 0/3] GuC, HuC Loading Support for Geminilake

The following changes since commit b562d2f3583f19ecda22b08e514ced57dd1e5f4d: linux-firmware: update wil6210 firmware to 5.2.0.18 (2018-04-16 09:55:50 -0400) are available in the git repository at: https://cgit.freedesktop.org/drm/drm-firmware/ master for you to fetch changes up to

[Intel-gfx] [PATCH 3/3] HAX enable guc, huc for CI

Enable guc loading for Geminilake. Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..1d23c41

[Intel-gfx] [PATCH 2/3] drm/i915/huc: Load HuC v03.00.2555 for Geminilake.

load the v03.00.2555 huC on geminilake. Cc: Tomi Sarvela Cc: Jani Saarinen Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_huc_fw.c | 12 1 file changed, 12 insertions(+) diff --git

Re: [Intel-gfx] [PATCH] drm/core: Remove drm_dev_unref() and it's uses

Hi, On 26/04/2018 15:45:44+0300, Laurent Pinchart wrote: > Hi Daniel, > > On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote: > > On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote: > > > It's been a while since we introduced drm_dev{get/put} functions > > > to replace

[Intel-gfx] [PATCH 3/8] drm/i915/icl: add basic support for the ICL clocks

This commit introduces the definitions for the ICL clocks and adds the basic functions to the shared DPLL framework. It adds code for the Enable and Disable sequences for some PLLs, but it does not have the code to compute the actual PLL values, which are marked as TODO comments and should be

[Intel-gfx] [PATCH] drm/i915: configure the transcoder clocks before touching pipeconf on HSW+

For all platforms that run haswell_crtc_enable, our spec tells us to configure the transcoder clocks before it tells us to set pipeconf and the other pipe/transcoder/plane registers. For some reason we've been able to get away with doing what we were doing until now, but starting from Icelake, we

Re: [Intel-gfx] [PATCH 2/8] drm/i915/icl: add definitions for the ICL PLL registers

On Wed, Mar 28, 2018 at 02:57:57PM -0700, Paulo Zanoni wrote: > There's a lot of code for the PLL enabling, so let's first only > introduce the register definitions in order to make patch reviewing a > little easier. > > v2: Coding style (Jani). > v3: Preparation for upstreaming. > v4: Fix

Re: [Intel-gfx] [PATCH v2] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

On 4/27/2018 1:35 PM, Chris Wilson wrote: Quoting Michel Thierry (2018-04-27 21:27:46) On 4/27/2018 1:24 PM, Chris Wilson wrote: Previously, we just reset the ring register in the context image such that we could skip over the broken batch and emit the closing breadcrumb. However, on resume

[Intel-gfx] [PATCH 0/5] Enable HuC authentication in Icelake

Bare minimum number of patches to get the GuC to authenticate the HuC correctly (i915.enable_guc=2). Oscar Mateo (5): drm/i915/icl/guc: Do not allow GuC submission on Icelake for now drm/i915/icl/guc: Pass the bare minimum GuC init parameters for Icelake drm/i915/icl/guc: Define the GuC

[Intel-gfx] [PATCH 1/5] drm/i915/icl/guc: Do not allow GuC submission on Icelake for now

Sanitize the enable_guc option so that we can enable HuC authentication, but nothing else. The firmware interface has changed quite dramatically in Gen11, so it will take a while before we can submit workloads to the GuC with guarantees. Signed-off-by: Oscar Mateo Cc:

[Intel-gfx] [PATCH 3/5] drm/i915/icl/guc: Define the GuC firmware version for Icelake

A GuC firmware for Icelake is now available. Let's use it. v2: Split out the Cannonlake stuff in a separate patch (Michal) v3: Rebased v4: - Rebased - Split out MODULE_FIRMWARE so we don't accidentally push it before linux-firmware (Joonas) v5: Use the latest firmware (v23.120) v6: Use

[Intel-gfx] [PATCH 4/5] drm/i915/icl/huc: Correctly authenticate the HuC for Icelake

The register to check for correct HuC authentication by the GuC has changed in Icelake. Look into the right register & bit. v2: rebased. v3: rebased. v4: Fix I915_PARAM_HUC_STATUS as well (Tony) BSpec: 19686 Signed-off-by: Oscar Mateo Cc: Tony Ye Cc:

[Intel-gfx] [PATCH 5/5] drm/i915/icl/huc: Define the HuC firmware version for Icelake

This patch adds the support to load HuC on ICL. Version 8.02.2678 v2 (James): Rebase Signed-off-by: Oscar Mateo Cc: Tony Ye Cc: Vinay Belgaumkar Cc: Michel Thierry Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 2/5] drm/i915/icl/guc: Pass the bare minimum GuC init parameters for Icelake

Only enough to achieve HuC authentication. No GuC submission or any other feature for the time being. Signed-off-by: Oscar Mateo Cc: Joonas Lahtinen Cc: Michal Wajdeczko Cc: John Spotswood

Re: [Intel-gfx] [PATCH v2] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

Quoting Michel Thierry (2018-04-27 21:27:46) > On 4/27/2018 1:24 PM, Chris Wilson wrote: > > Previously, we just reset the ring register in the context image such > > that we could skip over the broken batch and emit the closing > > breadcrumb. However, on resume the context image and GPU state

[Intel-gfx] [PATCH v3] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

Previously, we just reset the ring register in the context image such that we could skip over the broken batch and emit the closing breadcrumb. However, on resume the context image and GPU state would be reloaded, which may have been left in an inconsistent state by the reset. The presumption was

Re: [Intel-gfx] [PATCH v2] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

On 4/27/2018 1:24 PM, Chris Wilson wrote: Previously, we just reset the ring register in the context image such that we could skip over the broken batch and emit the closing breadcrumb. However, on resume the context image and GPU state would be reloaded, which may have been left in an

[Intel-gfx] [PATCH v2] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

Previously, we just reset the ring register in the context image such that we could skip over the broken batch and emit the closing breadcrumb. However, on resume the context image and GPU state would be reloaded, which may have been left in an inconsistent state by the reset. The presumption was

Re: [Intel-gfx] [PATCH] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

Quoting Michel Thierry (2018-04-27 21:12:38) > On 4/27/2018 12:32 PM, Chris Wilson wrote: > > Previously, we just reset the ring register in the context image such > > that we could skip over the broken batch and emit the closing > > breadcrumb. However, on resume the context image and GPU state

Re: [Intel-gfx] [PATCH] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

On 4/27/2018 12:32 PM, Chris Wilson wrote: Previously, we just reset the ring register in the context image such that we could skip over the broken batch and emit the closing breadcrumb. However, on resume the context image and GPU state would be reloaded, which may have been left in an

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [CI,1/4] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42419/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4108_full -> Patchwork_8828_full = == Summary - FAILURE ==

Re: [Intel-gfx] [PATCH v7 1/2] drm: content-type property for HDMI connector

On Mon, Apr 23, 2018 at 10:34:41AM +0300, StanLis wrote: > From: Stanislav Lisovskiy > > Added content_type property to drm_connector_state > in order to properly handle external HDMI TV content-type setting. > > v2: > * Moved helper function which attaches

[Intel-gfx] [PATCH] drm/i915/lrc: Scrub the GPU state of the guilty hanging request

Previously, we just reset the ring register in the context image such that we could skip over the broken batch and emit the closing breadcrumb. However, on resume the context image and GPU state would be reloaded, which may have been left in an inconsistent state by the reset. The presumption was

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Print error state times relative to capture (rev2)

== Series Details == Series: drm/i915: Print error state times relative to capture (rev2) URL : https://patchwork.freedesktop.org/series/41749/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4108_full -> Patchwork_8827_full = == Summary - WARNING == Minor unknown changes

[Intel-gfx] ✗ Fi.CI.IGT: failure for Aspect ratio support in DRM layer

== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/42403/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4107_full -> Patchwork_8825_full = == Summary - FAILURE == Serious unknown changes coming with

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [CI,1/4] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42419/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4108 -> Patchwork_8828 = == Summary - WARNING == Minor

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [CI,1/4] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42419/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Stop tracking timeline->inflight_seqnos

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [CI,1/4] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42419/ State : warning == Summary == $ dim checkpatch origin/drm-tip f4428c86a843 drm/i915: Stop tracking timeline->inflight_seqnos

[Intel-gfx] [CI 4/4] drm/i915: Only track live rings for retiring

We don't need to track every ring for its lifetime as they are managed by the contexts/engines. What we do want to track are the live rings so that we can sporadically clean up requests if userspace falls behind. We can simply restrict the gt->rings list to being only gt->live_rings. v2:

[Intel-gfx] [CI 3/4] drm/i915: Retire requests along rings

In the next patch, rings are the central timeline as requests may jump between engines. Therefore in the future as we retire in order along the engine timeline, we may retire out-of-order within a ring (as the ring now occurs along multiple engines), leading to much hilarity in miscomputing the

[Intel-gfx] [CI 1/4] drm/i915: Stop tracking timeline->inflight_seqnos

In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we moved from a global inflight counter to per-engine counters in the hope that will be easy to run concurrently in future. However, with the advent of the desire to move requests between engines, we do need a global counter to

[Intel-gfx] [CI 2/4] drm/i915: Wrap engine->context_pin() and engine->context_unpin()

Make life easier in upcoming patches by moving the context_pin and context_unpin vfuncs into inline helpers. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-

[Intel-gfx] ✓ Fi.CI.IGT: success for Aspect ratio support in DRM layer

== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/42403/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4107_full -> Patchwork_8824_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH] drm/i915: Promote .format_mod_supported() to the lead role

On Fri, Mar 30, 2018 at 12:06:11PM -0700, Eric Anholt wrote: > Ville Syrjala writes: > > > From: Ville Syrjälä > > > > Up to now we've used the plane's modifier list as the primary > > source of information for which modifiers are

Re: [Intel-gfx] [PATCH igt 0/8] Non-Intel test suite fixes

Hi Ulrich, On Thursday, 15 March 2018 16:45:36 EEST Ulrich Hecht wrote: > Hi! > > I have run the tests on a Renesas R-Car M3-W's DU device, and have found a > number of false negatives that mostly stem from use of Intel-specifics > without checking if that makes sense first. So here's a bunch of

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Lazily unbind vma on close

Quoting Tvrtko Ursulin (2018-04-27 16:38:47) > > On 26/04/2018 18:49, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > > index c74f5df3fb5a..f627a8c47c58 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Lazily unbind vma on close

On 26/04/2018 18:49, Chris Wilson wrote: When userspace is passing around swapbuffers using DRI, we frequently have to open and close the same object in the foreign address space. This shows itself as the same object being rebound at roughly 30fps (with a second object also being rebound at

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Print error state times relative to capture (rev2)

== Series Details == Series: drm/i915: Print error state times relative to capture (rev2) URL : https://patchwork.freedesktop.org/series/41749/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4108 -> Patchwork_8827 = == Summary - WARNING == Minor unknown changes coming

Re: [Intel-gfx] [PATCH] drm/i915: Print error state times relative to capture

Quoting Mika Kuoppala (2018-04-27 16:12:48) > @@ -427,8 +428,10 @@ static void error_print_context(struct > drm_i915_error_state_buf *m, > } > > static void error_print_engine(struct drm_i915_error_state_buf *m, > - const struct drm_i915_error_engine *ee) > +

[Intel-gfx] [PATCH] drm/i915: Print error state times relative to capture

Using plain jiffies in error state output makes the output time differences relative to the current system time. This is wrong as it makes output time differences dependent of when the error state is printed rather than when it is captured. Store capture jiffies into error state and use it when

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Split i915_gem_timeline into individual timelines

Quoting Tvrtko Ursulin (2018-04-27 15:37:58) > > On 26/04/2018 18:49, Chris Wilson wrote: > > -static bool engine_has_idle_kernel_context(struct intel_engine_cs *engine) > > +static struct i915_request * > > +last_timeline_request(struct i915_timeline *timeline, > > + struct

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Potential uninitialized return in live_reset_whitelist()

== Series Details == Series: drm/i915/selftests: Potential uninitialized return in live_reset_whitelist() URL : https://patchwork.freedesktop.org/series/42407/ State : failure == Summary == Applying: drm/i915/selftests: Potential uninitialized return in live_reset_whitelist() Using index

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Split i915_gem_timeline into individual timelines

On 26/04/2018 18:49, Chris Wilson wrote: We need to move to a more flexible timeline that doesn't assume one fence context per engine, and so allow for a single timeline to be used across a combination of engines. This means that preallocating a fence context per engine is now a hindrance, and

Re: [Intel-gfx] [PATCH] drm/dp: Rename the edp_sdp_header as dp_sdp_header

On Thu, Apr 26, 2018 at 12:27:48PM -0700, Manasi Navare wrote: > No functional changes in this patch. > > The SDP Header is a generic header for secondary data packets for > both eDP and DP so call it dp_sdp_header. This header gets used for > different SDP types already defined. > Also header

Re: [Intel-gfx] [PATCH] drm: Don't pass the index to drm_property_add_enum()

On Thu, Apr 26, 2018 at 12:45:13PM +, Lisovskiy, Stanislav wrote: > Reviewed-by: Stanislav Lisovskiy Thanks. Pushed to drm-misc-next. > > Best Regards, > > Lisovskiy Stanislav > > Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Potential uninitialized return in live_reset_whitelist()

Quoting Dan Carpenter (2018-04-27 15:06:16) > Smatch complains that "err" could be uninitialized at the end. I don't > know the code well but that seems like a reasonable warning. > > Signed-off-by: Dan Carpenter Thanks for the report, Gustavo Silva already submitted

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Potential uninitialized return in live_reset_whitelist()

On Fri, Apr 27, 2018 at 05:06:16PM +0300, Dan Carpenter wrote: > Smatch complains that "err" could be uninitialized at the end. I don't > know the code well but that seems like a reasonable warning. > > Signed-off-by: Dan Carpenter > > diff --git

Re: [Intel-gfx] [PATCH v2 RESEND] drm/i915: add support for specifying DMC firmware override by module param

On Tue, Apr 24, 2018 at 03:20:16PM +0300, Jani Nikula wrote: > Use i915.dmc_firmware_path to override default firmware for the platform > and bypassing version checks. > > v2: add missing param struct member declaration (David) > > Tested-by: David Weinehall >

[Intel-gfx] [PATCH] drm/i915/selftests: Potential uninitialized return in live_reset_whitelist()

Smatch complains that "err" could be uninitialized at the end. I don't know the code well but that seems like a reasonable warning. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c

Re: [Intel-gfx] [PATCH v12 08/10] drm: Expose modes with aspect ratio, only if requested

On Fri, Apr 27, 2018 at 05:44:54PM +0530, Nautiyal, Ankit K wrote: > From: Ankit Nautiyal > > We parse the EDID and add all the modes in the connector's modelist. > This adds CEA modes with aspect ratio information too, regadless of > whether user space requested this

[Intel-gfx] ✓ Fi.CI.IGT: success for x86: Mark up large pm4/5 constants with UL

== Series Details == Series: x86: Mark up large pm4/5 constants with UL URL : https://patchwork.freedesktop.org/series/42387/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4107_full -> Patchwork_8823_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH v12 07/10] drm: Handle aspect ratio info in legacy modeset path

On Fri, Apr 27, 2018 at 05:44:53PM +0530, Nautiyal, Ankit K wrote: > From: Ankit Nautiyal > > If the user-space does not support aspect-ratio, and requests for a > modeset with mode having aspect ratio bits set, then the given > user-mode must be rejected. Secondly,

[Intel-gfx] ✓ Fi.CI.BAT: success for Aspect ratio support in DRM layer

== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/42403/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4107 -> Patchwork_8825 = == Summary - WARNING == Minor unknown changes coming with Patchwork_8825 need to

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Aspect ratio support in DRM layer

== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/42403/ State : warning == Summary == $ dim checkpatch origin/drm-tip 26bd319b4abf drm/modes: Introduce drm_mode_match() -:39: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr : Add psr1 live status (rev2)

== Series Details == Series: drm/i915/psr : Add psr1 live status (rev2) URL : https://patchwork.freedesktop.org/series/42021/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4107_full -> Patchwork_8821_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [RFC] drm/i915: Rework "Potential atomic update error" to handle PSR exit

Quoting Ville Syrjälä (2018-04-27 13:41:42) > On Thu, Apr 26, 2018 at 08:09:56PM -0700, Tarun Vyas wrote: > > On a second thought, I was doing it wrong in the initial RFC. Can't do a > > wait_for_register with irqs disabled by local_irq_disable(). So, will have > > to *poll* the PSR_STATE, but

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Move timeline from GTT to ring

On 26/04/2018 18:49, Chris Wilson wrote: In the future, we want to move a request between engines. To achieve this, we first realise that we have two timelines in effect here. The first runs through the GTT is required for ordering vma access, which is tracked currently by engine. The second is

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Retire requests along rings

Quoting Tvrtko Ursulin (2018-04-27 13:50:44) > > On 26/04/2018 18:49, Chris Wilson wrote: > > +static void __retire_engine_request(struct intel_engine_cs *engine, > > + struct i915_request *rq) > > +{ > > + GEM_TRACE("%s(%s) fence %llx:%d, global=%d, current

[Intel-gfx] ✗ Fi.CI.BAT: failure for Aspect ratio support in DRM layer

== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/42403/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4107 -> Patchwork_8824 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8824

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Only track live rings for retiring

On 26/04/2018 18:49, Chris Wilson wrote: We don't need to track every ring for its lifetime as they are managed by the contexts/engines. What we do want to track are the live rings so that we can sporadically clean up requests if userspace falls behind. We can simply restrict the gt->rings list

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Retire requests along rings

On 26/04/2018 18:49, Chris Wilson wrote: In the next patch, rings are the central timeline as requests may jump between engines. Therefore in the future as we retire in order along the engine timeline, we may retire out-of-order within a ring (as the ring now occurs along multiple engines),

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Aspect ratio support in DRM layer

== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/42403/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6d0e3d322715 drm/modes: Introduce drm_mode_match() -:39: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open

Re: [Intel-gfx] [RFC] drm/i915: Rework "Potential atomic update error" to handle PSR exit

On Thu, Apr 26, 2018 at 08:09:56PM -0700, Tarun Vyas wrote: > On Thu, Apr 26, 2018 at 02:39:04PM -0700, Tarun Vyas wrote: > > On Thu, Apr 26, 2018 at 10:47:40AM -0700, Dhinakaran Pandiyan wrote: > > > > > > > > > > > > On Thu, 2018-04-26 at 16:41 +0300, Ville Syrjälä wrote: > > > > On Wed, Apr

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Wrap engine->context_pin() and engine->context_unpin()

On 26/04/2018 18:49, Chris Wilson wrote: Make life easier in upcoming patches by moving the context_pin and context_unpin vfuncs into inline helpers. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-

[Intel-gfx] [PATCH v12 06/10] drm: Add DRM client cap for aspect-ratio

From: Ankit Nautiyal To enable aspect-ratio support in DRM, blindly exposing the aspect ratio information along with mode, can break things in existing non-atomic user-spaces which have no intention or support to use this aspect ratio information. To avoid this, a

[Intel-gfx] [PATCH v12 10/10] drm: Add and handle new aspect ratios in DRM layer

From: "Sharma, Shashank" HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise

[Intel-gfx] [PATCH v12 09/10] drm: Add aspect ratio parsing in DRM layer

From: "Sharma, Shashank" Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due

[Intel-gfx] [PATCH v12 08/10] drm: Expose modes with aspect ratio, only if requested

From: Ankit Nautiyal We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regadless of whether user space requested this information or not. This patch prunes the modes with aspect-ratio

[Intel-gfx] [PATCH v12 00/10] Aspect ratio support in DRM layer

From: Ankit Nautiyal This patch series is a re-attempt to enable aspect ratio support in DRM layer. Currently the aspect ratio information gets lost in translation during a user->kernel mode or vice versa. The old patch series

[Intel-gfx] [PATCH v12 01/10] drm/modes: Introduce drm_mode_match()

From: Ville Syrjälä Make mode matching less confusing by allowing the caller to specify which parts of the modes should match via some flags. Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma ---

[Intel-gfx] [PATCH v12 05/10] video/hdmi: Reject illegal picture aspect ratios

From: Ville Syrjälä AVI infoframe can only carry none, 4:3, or 16:9 picture aspect ratios. Return an error if the user asked for something different. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma

[Intel-gfx] [PATCH v12 02/10] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

From: Ville Syrjälä Use drm_mode_equal_no_clocks_no_stereo() in drm_match_hdmi_mode_clock_tolerance() for consistency as we also use it in drm_match_hdmi_mode() and the cea mode matching functions. This doesn't actually change anything since the input mode comes

[Intel-gfx] [PATCH v12 03/10] drm/edid: Fix cea mode aspect ratio handling

From: Ville Syrjälä commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's

[Intel-gfx] [PATCH v12 07/10] drm: Handle aspect ratio info in legacy modeset path

From: Ankit Nautiyal If the user-space does not support aspect-ratio, and requests for a modeset with mode having aspect ratio bits set, then the given user-mode must be rejected. Secondly, while preparing a user-mode from kernel mode, the aspect-ratio info must not

[Intel-gfx] [PATCH v12 04/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

From: Ville Syrjälä If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Stop tracking timeline->inflight_seqnos

On 26/04/2018 18:49, Chris Wilson wrote: In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we moved from a global inflight counter to per-engine counters in the hope that will be easy to run concurrently in future. However, with the advent of the desire to move requests

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp: Rename the edp_sdp_header as dp_sdp_header

== Series Details == Series: drm/dp: Rename the edp_sdp_header as dp_sdp_header URL : https://patchwork.freedesktop.org/series/42363/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4106_full -> Patchwork_8819_full = == Summary - WARNING == Minor unknown changes coming

[Intel-gfx] ✓ Fi.CI.BAT: success for x86: Mark up large pm4/5 constants with UL

== Series Details == Series: x86: Mark up large pm4/5 constants with UL URL : https://patchwork.freedesktop.org/series/42387/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4107 -> Patchwork_8823 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readout

== Series Details == Series: drm/i915: Correctly populate user mode h/vdisplay with pipe src size during readout URL : https://patchwork.freedesktop.org/series/42351/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4106_full -> Patchwork_8817_full = == Summary - WARNING ==

Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for x86: Mark up large pm4/5 constants with UL

Quoting Patchwork (2018-04-27 11:54:51) > == Series Details == > > Series: x86: Mark up large pm4/5 constants with UL > URL : https://patchwork.freedesktop.org/series/42387/ > State : warning > > == Summary == > > $ dim sparse origin/drm-tip > Commit: x86: Mark up large pm4/5 constants with

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for x86: Mark up large pm4/5 constants with UL

== Series Details == Series: x86: Mark up large pm4/5 constants with UL URL : https://patchwork.freedesktop.org/series/42387/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: x86: Mark up large pm4/5 constants with UL -./arch/x86/include/asm/pgalloc.h:115:31: warning:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for x86: Mark up large pm4/5 constants with UL

== Series Details == Series: x86: Mark up large pm4/5 constants with UL URL : https://patchwork.freedesktop.org/series/42387/ State : warning == Summary == $ dim checkpatch origin/drm-tip 33874ebb33b3 x86: Mark up large pm4/5 constants with UL -:22: WARNING:SPACE_BEFORE_TAB: please, no space

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42360/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4107 -> Patchwork_8822 = == Summary - FAILURE == Serious

Re: [Intel-gfx] [PATCH v7 1/2] drm: content-type property for HDMI connector

Ping. On Mon, 2018-04-23 at 13:45 +, Lisovskiy, Stanislav wrote: > Ping > > From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf > of StanLis [stanislav.lisovs...@intel.com] > Sent: Monday, April 23, 2018 10:34 AM > To:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42360/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Stop tracking timeline->inflight_seqnos

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42360/ State : warning == Summary == $ dim checkpatch origin/drm-tip 346302027794 drm/i915: Stop tracking timeline->inflight_seqnos -:17:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr : Add psr1 live status (rev2)

== Series Details == Series: drm/i915/psr : Add psr1 live status (rev2) URL : https://patchwork.freedesktop.org/series/42021/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4107 -> Patchwork_8821 = == Summary - SUCCESS == No regressions found. External URL:

[Intel-gfx] ✓ Fi.CI.IGT: success for 4.17-rc2: Could not determine valid watermarks for inherited state

== Series Details == Series: 4.17-rc2: Could not determine valid watermarks for inherited state URL : https://patchwork.freedesktop.org/series/42348/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4106_full -> Patchwork_8816_full = == Summary - WARNING == Minor unknown

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/psr : Add psr1 live status (rev2)

== Series Details == Series: drm/i915/psr : Add psr1 live status (rev2) URL : https://patchwork.freedesktop.org/series/42021/ State : warning == Summary == $ dim checkpatch origin/drm-tip f386581d5e6f drm/i915/psr : Add psr1 live status -:105: CHECK:PARENTHESIS_ALIGNMENT: Alignment should

[Intel-gfx] ✗ Fi.CI.BAT: failure for dma-fence doc polish and small cleanup

== Series Details == Series: dma-fence doc polish and small cleanup URL : https://patchwork.freedesktop.org/series/42373/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4107 -> Patchwork_8820 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8820

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dma-fence doc polish and small cleanup

== Series Details == Series: dma-fence doc polish and small cleanup URL : https://patchwork.freedesktop.org/series/42373/ State : warning == Summary == $ dim checkpatch origin/drm-tip d608bb886c37 dma-fence: Some kerneldoc polish for dma-fence.h d3e894db59f2 dma-fence: remove fill_driver_data

[Intel-gfx] ✓ Fi.CI.IGT: success for Optimize use of DBuf slices (rev3)

== Series Details == Series: Optimize use of DBuf slices (rev3) URL : https://patchwork.freedesktop.org/series/41180/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4106_full -> Patchwork_8815_full = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp: Rename the edp_sdp_header as dp_sdp_header

== Series Details == Series: drm/dp: Rename the edp_sdp_header as dp_sdp_header URL : https://patchwork.freedesktop.org/series/42363/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4106 -> Patchwork_8819 = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On Wed, 25 Apr 2018, Ian W MORRISON wrote: > Can I ask if this is on anyone's radar as I'm concerned this patch will > stall otherwise? Pushed to drm-intel-next-queued, thanks for the patch. I opted to drop the Cc: stable for now. This doesn't mean it can't be backported

[Intel-gfx] [PATCH] x86: Mark up large pm4/5 constants with UL

To silence sparse while maintaining compatibility with the assembly, use _UL which conditionally only appends the UL suffix for C code. Signed-off-by: Chris Wilson --- arch/x86/include/asm/pgtable_64_types.h | 8 1 file changed, 4 insertions(+), 4 deletions(-)

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42360/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4106 -> Patchwork_8818 = == Summary - FAILURE == Serious

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos

== Series Details == Series: series starting with [1/7] drm/i915: Stop tracking timeline->inflight_seqnos URL : https://patchwork.freedesktop.org/series/42360/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Stop tracking timeline->inflight_seqnos

  1   2   >