Re: [Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

On 18.05.2017 13:10, Jani Nikula wrote: > Face the fact, there are Display Port sink and branch devices out there > in the wild that don't follow the Display Port specifications, or they > have bugs, or just otherwise require special treatment. Start a common > quirk database the drivers can query

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/gvt: OpRegion support for GVT-g

Hi min, >-Original Message- >From: He, Min >Sent: Thursday, May 18, 2017 11:44 PM >To: Chen, Xiaoguang ; >alex.william...@redhat.com; kra...@redhat.com; intel- >g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; >zhen...@linux.intel.com; Lv, Zhiyuan

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: set initialised only when init_context callback is NULL (rev2)

On 2017.05.12 12:44:48 +0100, Chris Wilson wrote: > On Fri, May 12, 2017 at 11:34:21AM -, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: set initialised only when init_context callback is NULL > > (rev2) > > URL : https://patchwork.freedesktop.org/series/24286/ > >

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

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/intel_dp_mst.c between commit: f424f55e3177 ("drm/i915: Track MST link bandwidth") from the drm tree and commit: 3d65a735d834 ("drm/i915/mst: use max link not sink lane count") from the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Clear the compliance test data for each long pulse

== Series Details == Series: drm/i915/dp: Clear the compliance test data for each long pulse URL : https://patchwork.freedesktop.org/series/24666/ State : success == Summary == Series 24666v1 drm/i915/dp: Clear the compliance test data for each long pulse

[Intel-gfx] [PATCH] drm/i915/dp: Clear the compliance test data for each long pulse

Each time we handle the long pulse, we check for the test request interrupt and populate the compliance data in the intel_dp structure. So the previously populated data becomes stale. Hence we need to clear the compliance data during each long pulse handling. Not clearing the compliance test data

[Intel-gfx] [PATCH -next] drm/i915: Fix return value check in kfence selftests

From: Wei Yongjun Fix the return value check which testing the wrong variable. Signed-off-by: Wei Yongjun --- drivers/gpu/drm/i915/selftests/i915_sw_fence.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [Intel-gfx] [PATCH v5] drm/i915/guc: capture GuC logs if FW fails to load

On 18/05/17 10:08, Michal Wajdeczko wrote: On Tue, May 16, 2017 at 02:52:53PM -0700, Daniele Ceraolo Spurio wrote: We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them

Re: [Intel-gfx] [PATCH 24/24] RFC drm/i915: Expose a PMU interface for perf queries

On 5/18/2017 2:46 AM, Chris Wilson wrote: The first goal is to be able to measure GPU (and invidual ring) busyness without having to poll registers from userspace. (Which not only incurs holding the forcewake lock indefinitely, perturbing the system, but also runs the risk of hanging the

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/g4x: Improve gpu reset reliability

On Thu, May 18, 2017 at 05:28:41PM +0300, Mika Kuoppala wrote: > ELK seems to very picky about the preconditions to reset. > Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does > not like if reset occurs when there is active ring. > > Ville found out that there is workaround with name >

Re: [Intel-gfx] [PATCH v8 1/5] drm/i915: Drop AUX backlight enable check for backlight control

On Wed, 2017-05-17 at 14:04 -0700, Puthikorn Voravootivat wrote: > > On Wed, May 17, 2017 at 1:09 PM, Pandiyan, Dhinakaran > wrote: > > > From: Puthikorn Voravootivat [put...@google.com] on behalf of

Re: [Intel-gfx] [PATCH 3/6] drm/i915/guc: Remove GuC wq reservation

static void nested_enable_signaling(struct drm_i915_gem_request *rq) @@ -1223,6 +1155,9 @@ int i915_guc_submission_enable(struct drm_i915_private *dev_priv) enum intel_engine_id id; int err; + BUILD_BUG_ON(ARRAY_SIZE(engine->execlist_port) * +

Re: [Intel-gfx] [PATCH] drm/i915: Look for active requests earlier in the reset path

On 5/18/2017 2:16 PM, Chris Wilson wrote: On Thu, May 18, 2017 at 02:11:15PM -0700, Michel Thierry wrote: And store the active request so that we only search for it once; this applies for reset-engine and full reset. v2: Check for request completion inside _prepare_engine, don't use ECANCELED,

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Try harder to reset the GPU

On Thu, May 18, 2017 at 09:08:26PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/2] drm/i915: Try harder to reset the GPU > URL : https://patchwork.freedesktop.org/series/24650/ > State : success > > == Summary == > > Series 24650v1 Series without cover

[Intel-gfx] ✓ Fi.CI.BAT: success for Gen8+ engine-reset (rev10)

== Series Details == Series: Gen8+ engine-reset (rev10) URL : https://patchwork.freedesktop.org/series/21868/ State : success == Summary == Series 21868v10 Gen8+ engine-reset https://patchwork.freedesktop.org/api/1.0/series/21868/revisions/10/mbox/ Test gem_exec_flush: Subgroup

Re: [Intel-gfx] [PATCH] drm/i915: Look for active requests earlier in the reset path

On Thu, May 18, 2017 at 02:11:15PM -0700, Michel Thierry wrote: > And store the active request so that we only search for it once; this > applies for reset-engine and full reset. > > v2: Check for request completion inside _prepare_engine, don't use > ECANCELED, remove unnecessary null checks

[Intel-gfx] [PATCH] drm/i915: Look for active requests earlier in the reset path

And store the active request so that we only search for it once; this applies for reset-engine and full reset. v2: Check for request completion inside _prepare_engine, don't use ECANCELED, remove unnecessary null checks (Chris). v3: Capture active requests during reset_prepare and store it the

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Try harder to reset the GPU

== Series Details == Series: series starting with [CI,1/2] drm/i915: Try harder to reset the GPU URL : https://patchwork.freedesktop.org/series/24650/ State : success == Summary == Series 24650v1 Series without cover letter

[Intel-gfx] [CI 2/2] drm/i915: Reorder media/render reset on g4x

Ville found a reference to WaMediaResetBeforeFullReset which we presume means that we should simply do the media reset first. References: https://bugs.freedesktop.org/show_bug.cgi?id=100942 Suggested-by: Ville Syrjälä Signed-off-by: Chris Wilson

[Intel-gfx] [CI 1/2] drm/i915: Try harder to reset the GPU

Repeat the reset a couple of times if at first we do not succeed. v2: differentiate which path/engine failed with a debug message Signed-off-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/20170513083726.502-1-ch...@chris-wilson.co.uk Reviewed-by:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/atomic: Consitfy mode parameter to drm_atomic_set_mode_for_crtc()

== Series Details == Series: series starting with [1/2] drm/atomic: Consitfy mode parameter to drm_atomic_set_mode_for_crtc() URL : https://patchwork.freedesktop.org/series/24645/ State : success == Summary == Series 24645v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Look for active requests earlier in the reset path

On Thu, May 18, 2017 at 11:22:57AM -0700, Michel Thierry wrote: > And store the active request so that we only search for it once; this > applies for reset-engine and full reset. > > v2: Check for request completion inside _prepare_engine, don't use > ECANCELED, remove unnecessary null checks

[Intel-gfx] [PATCH 1/2] drm/atomic: Consitfy mode parameter to drm_atomic_set_mode_for_crtc()

From: Ville Syrjälä drm_atomic_set_mode_for_crtc() doesn't modify the passed mode, so let's make it const. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c | 2 +- include/drm/drm_atomic.h | 2 +- 2 files changed,

[Intel-gfx] [PATCH 2/2] drm/i915: Constify load detect mode

From: Ville Syrjälä Make the mode used for load detection const, and adjust all relevant functions to accept a const mode. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 12 ++--

[Intel-gfx] ✓ Fi.CI.BAT: success for Gen8+ engine-reset (rev9)

== Series Details == Series: Gen8+ engine-reset (rev9) URL : https://patchwork.freedesktop.org/series/21868/ State : success == Summary == Series 21868v9 Gen8+ engine-reset https://patchwork.freedesktop.org/api/1.0/series/21868/revisions/9/mbox/ Test gem_exec_flush: Subgroup

Re: [Intel-gfx] [PATCH] drm/i915: Look for active requests earlier in the reset path

On 5/18/2017 11:22 AM, Michel Thierry wrote: fixes Signed-off-by: Michel Thierry rebase mistake ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Look for active requests earlier in the reset path

And store the active request so that we only search for it once; this applies for reset-engine and full reset. v2: Check for request completion inside _prepare_engine, don't use ECANCELED, remove unnecessary null checks (Chris). v3: Capture active requests during reset_prepare and store it the

Re: [Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

On Thu, 2017-05-18 at 14:10 +0300, Jani Nikula wrote: > Face the fact, there are Display Port sink and branch devices out there > in the wild that don't follow the Display Port specifications, or they > have bugs, or just otherwise require special treatment. Start a common > quirk database the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: Update GLK HuC version

== Series Details == Series: drm/i915/huc: Update GLK HuC version URL : https://patchwork.freedesktop.org/series/24641/ State : success == Summary == Series 24641v1 drm/i915/huc: Update GLK HuC version https://patchwork.freedesktop.org/api/1.0/series/24641/revisions/1/mbox/ fi-bdw-5557u

[Intel-gfx] [PATCH] drm/i915/huc: Update GLK HuC version

Update version of HuC from 01.07.1748 to the version 02.00.1748 Cc: Ander Conselvan Cc: John Spotswood Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_huc.c | 4 ++-- 1 file changed, 2

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Get rid of the enable_guc_loading module parameter

On Fri, May 05, 2017 at 01:23:17PM +, Oscar Mateo wrote: > The decission to enable GuC loading shouldn't be left to the user. > Provided the HW supports the GuC, there are only two reasons to load it: > > - The user has requested GuC submission. > - We have a HuC firmware available (so we

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: i915: Preserve old FBC status for update without new planes

== Series Details == Series: drm: i915: Preserve old FBC status for update without new planes URL : https://patchwork.freedesktop.org/series/24635/ State : success == Summary == Series 24635v1 drm: i915: Preserve old FBC status for update without new planes

Re: [Intel-gfx] [PATCH] drm/i915: Cancel reset-engine if we couldn't find an active request

On 5/18/2017 12:56 AM, Chris Wilson wrote: On Wed, May 17, 2017 at 06:11:06PM -0700, Michel Thierry wrote: On 17/05/17 13:52, Chris Wilson wrote: On Wed, May 17, 2017 at 01:41:34PM -0700, Michel Thierry wrote: @@ -2827,21 +2829,35 @@ int i915_gem_reset_prepare_engine(struct intel_engine_cs

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915/guc: Remove stale comment for q_fail

On Thu, May 18, 2017 at 04:38:01PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915/guc: Remove stale comment for > q_fail > URL : https://patchwork.freedesktop.org/series/24622/ > State : warning > > == Summary == > > Series 24622v1 Series

[Intel-gfx] ✓ Fi.CI.BAT: success for New engine discovery and execbuffer2 engine selection uAPI (rev6)

== Series Details == Series: New engine discovery and execbuffer2 engine selection uAPI (rev6) URL : https://patchwork.freedesktop.org/series/23189/ State : success == Summary == Series 23189v6 New engine discovery and execbuffer2 engine selection uAPI

Re: [Intel-gfx] [PATCH v5] drm/i915/guc: capture GuC logs if FW fails to load

On Tue, May 16, 2017 at 02:52:53PM -0700, Daniele Ceraolo Spurio wrote: > We're currently deleting the GuC logs if the FW fails to load, but those > are still useful to understand why the loading failed. Keeping the > object around allows us to access them after driver load is completed. > > v2:

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On Thu, May 18, 2017 at 05:20:38PM +0100, Tvrtko Ursulin wrote: > > On 18/05/2017 14:37, Chris Wilson wrote: > >On Thu, May 18, 2017 at 02:06:35PM +0100, Tvrtko Ursulin wrote: > >> > >>But this problem in general can also be solved separately from > >>class-instance addressing via engine feature

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Remove misleading comment in request_alloc

== Series Details == Series: series starting with [1/6] drm/i915: Remove misleading comment in request_alloc URL : https://patchwork.freedesktop.org/series/24632/ State : failure == Summary == Series 24632v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI

vmwgfx part: Reviewed-by: Sinclair Yeh On Wed, May 17, 2017 at 09:39:11PM -0400, Robert Foss wrote: > Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI > as a convenience. > > Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up > through the atomic

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915/guc: Remove stale comment for q_fail

== Series Details == Series: series starting with [1/3] drm/i915/guc: Remove stale comment for q_fail URL : https://patchwork.freedesktop.org/series/24622/ State : warning == Summary == Series 24622v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp: device identification and quirks ~v3

== Series Details == Series: drm/dp: device identification and quirks ~v3 URL : https://patchwork.freedesktop.org/series/24619/ State : success == Summary == Series 24619v1 drm/dp: device identification and quirks ~v3 https://patchwork.freedesktop.org/api/1.0/series/24619/revisions/1/mbox/

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On 18/05/2017 14:37, Chris Wilson wrote: On Thu, May 18, 2017 at 02:06:35PM +0100, Tvrtko Ursulin wrote: On 18/05/2017 13:24, Chris Wilson wrote: Yes, I would argue to defer it until later. One problem I have at the moment is that not all members of a class are equal, HEVC-capable engines

[Intel-gfx] [PATCH] drm: i915: Preserve old FBC status for update without new planes

If the atomic commit doesn't include any new plane, there is no need to choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will bail out early. Although, if the FBC setup failed in the previous commit, if the current commit doesn't include new plane update, it tries to overwrite

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/gvt: OpRegion support for GVT-g

Xiaoguang, I have some comments inline. Thanks. > -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Xiaoguang Chen > Sent: Thursday, May 18, 2017 2:50 AM > To: alex.william...@redhat.com; kra...@redhat.com; intel- >

Re: [Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database

On 05/18/2017 04:10 AM, Jani Nikula wrote: Face the fact, there are Display Port sink and branch devices out there in the wild that don't follow the Display Port specifications, or they have bugs, or just otherwise require special treatment. Start a common quirk database the drivers can query

Re: [Intel-gfx] [RFC v4 2/2] drm/i915: Select engines via class and instance in execbuffer2

On Thu, May 18, 2017 at 03:58:26PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Building on top of the previous patch which exported the concept > of engine classes and instances, we can also use this instead of > the current awkward engine selection uAPI. >

[Intel-gfx] [PULL] drm-misc-fixes for 4.12

Hi Dave, 2 fixes for you, one fixes a link error that seems to have been lurking for a while, but aggrevated by rc1. The second patch fixes a bug introduced in the find_panel_or_bridge cleanup set. drm-misc-fixes-2017-05-18: Driver Changes: - host1x: Fix link error when host1x is built-in and

[Intel-gfx] [CI 1/2] drm/i915: Try harder to reset the GPU

Repeat the reset a couple of times if at first we do not succeed. v2: differentiate which path/engine failed with a debug message Signed-off-by: Chris Wilson Link: http://patchwork.freedesktop.org/patch/msgid/20170513083726.502-1-ch...@chris-wilson.co.uk Reviewed-by:

[Intel-gfx] [CI 2/2] drm/i915: Reorder media/render reset on g4x

Ville found a reference to WaMediaResetBeforeFullReset which we presume means that we should simply do the media reset first. References: https://bugs.freedesktop.org/show_bug.cgi?id=100942 Suggested-by: Ville Syrjälä Signed-off-by: Chris Wilson

[Intel-gfx] [RFC v4 2/2] drm/i915: Select engines via class and instance in execbuffer2

From: Tvrtko Ursulin Building on top of the previous patch which exported the concept of engine classes and instances, we can also use this instead of the current awkward engine selection uAPI. This is primarily interesting for the VCS engine selection which is a)

[Intel-gfx] [RFC v3 1/2] drm/i915: Engine discovery uAPI

From: Tvrtko Ursulin Engine discovery uAPI allows userspace to probe for engine configuration and features without needing to maintain the internal PCI id based database. This enables removal of code duplications across userspace components. Probing is done via the

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On 18/05/2017 15:10, Emil Velikov wrote: Hi Tvrtko, On 18 May 2017 at 14:06, Tvrtko Ursulin wrote: struct drm_i915_engine_info { /** Engine instance number. */ __u32 instance; __u32 rsvd; /** Engine specific features and

Re: [Intel-gfx] [PATCH 01/24] drm/i915/selftests: Pretend to be a gfx pci device

On Thu, May 18, 2017 at 02:35:06PM +0100, Tvrtko Ursulin wrote: > > On 18/05/2017 10:46, Chris Wilson wrote: > >Set the class on our mock pci device to GFX. This should be useful for > >utilities like intel-iommu that special case gfx devices. > > > >References:

[Intel-gfx] [PATCH v2 2/2] drm/i915/g4x: Improve gpu reset reliability

ELK seems to very picky about the preconditions to reset. Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does not like if reset occurs when there is active ring. Ville found out that there is workaround with name 'WaMediaResetMainRingCleanup' which suggests that we need to cleanup rings

Re: [Intel-gfx] [PATCH 5/6] drm/i915/scheduler: Split insert_request

On Thu, May 18, 2017 at 03:59:43PM +0200, Michał Winiarski wrote: > We'd like to reuse the priolist lookup in request resubmission path, > let's split insert_request to make that happen. > > Cc: Chris Wilson > Cc: Joonas Lahtinen > Cc:

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Remove misleading comment in request_alloc

On Thu, May 18, 2017 at 03:59:39PM +0200, Michał Winiarski wrote: > Passing NULL ctx to request_alloc would lead to null-ptr-deref. > Let's replace the comment with GEM_BUG_ON. > > Signed-off-by: Michał Winiarski > --- > drivers/gpu/drm/i915/i915_gem_request.c | 4

Re: [Intel-gfx] [PATCH 23/24] drm/i915: Keep a recent cache of freed contexts objects for reuse

On Thu, May 18, 2017 at 02:52:41PM +0100, Tvrtko Ursulin wrote: > > On 18/05/2017 10:46, Chris Wilson wrote: > >Keep the recently freed context objects for reuse. This allows us to use > >the current GGTT bindings and dma bound pages, avoiding any clflushes as > >required. We mark the objects as

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

Hi Tvrtko, On 18 May 2017 at 14:06, Tvrtko Ursulin wrote: > struct drm_i915_engine_info { > /** Engine instance number. */ > __u32 instance; > __u32 rsvd; > > /** Engine specific features and info. */ > #define

[Intel-gfx] ✓ Fi.CI.BAT: success for Remaining patches for WM cleanup series

== Series Details == Series: Remaining patches for WM cleanup series URL : https://patchwork.freedesktop.org/series/24615/ State : success == Summary == Series 24615v1 Remaining patches for WM cleanup series https://patchwork.freedesktop.org/api/1.0/series/24615/revisions/1/mbox/

[Intel-gfx] [PATCH 4/6] drm/i915/scheduler: Remember request priority throughout its lifetime

Since request can be unsubmitted, we need to avoid overriding its priority during submission. Otherwise we won't be able to resubmit it with correct priority. v2: Limit DFS by excluding completed requests (Chris) Cc: Chris Wilson Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 3/6] drm/i915/guc: Remove GuC wq reservation

Now that we have an upper bound on the number of work items being sent to GuC, we can remove the reservation. Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Michal Wajdeczko Cc: Oscar Mateo

[Intel-gfx] [PATCH 6/6] drm/i915/scheduler: Use priorities when resubmitting after reset

Now that we're able to unsubmit requests, we can take advantage of it during reset. Rather than resubmitting the previous workload directly to GuC/ELSP, we can simply move the requests back to priority queue, submitting from the tasklet instead. v2: Move the tasklet schedule out for legacy

[Intel-gfx] [PATCH 5/6] drm/i915/scheduler: Split insert_request

We'd like to reuse the priolist lookup in request resubmission path, let's split insert_request to make that happen. Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Tvrtko Ursulin Signed-off-by: Michał Winiarski

[Intel-gfx] [PATCH 2/6] drm/i915/guc: Submit GuC workitems containing coalesced requests

To create an upper bound on number of GuC workitems, we need to change the way that requests are being submitted. Rather than submitting each request as an individual workitem, we can do coalescing in a similar way we're handlig execlist submission ports. We also need to stop pretending that we're

[Intel-gfx] [PATCH 1/6] drm/i915: Remove misleading comment in request_alloc

Passing NULL ctx to request_alloc would lead to null-ptr-deref. Let's replace the comment with GEM_BUG_ON. Signed-off-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_gem_request.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

Re: [Intel-gfx] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?

Hi, On 16-05-17 12:34, Jani Nikula wrote: On Tue, 16 May 2017, Ville Syrjälä wrote: mn Tue, May 16, 2017 at 10:47:48AM +0300, Jani Nikula wrote: On Mon, 15 May 2017, Hans de Goede wrote: Hi, I'm seeing this on suspend/resume on a

Re: [Intel-gfx] [PATCH] drm/i915: Check C for null pointer rather than B

On Thu, May 18, 2017 at 02:39:42PM +0100, Colin King wrote: > From: Colin Ian King > > There are two occasions where pointer B is being check for a NULL > when it should be pointer C instead. Fix these. > > Detected by CoverityScan, CID#1436348,1436349 ("Logically Dead

Re: [Intel-gfx] [PATCH 23/24] drm/i915: Keep a recent cache of freed contexts objects for reuse

On 18/05/2017 10:46, Chris Wilson wrote: Keep the recently freed context objects for reuse. This allows us to use the current GGTT bindings and dma bound pages, avoiding any clflushes as required. We mark the objects as purgeable under memory pressure, and reap the list of freed objects as soon

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: New ddb allocation algorithm

Hi, On Thursday 18 May 2017 04:45 PM, Lankhorst, Maarten wrote: Mahesh Kumar schreef op do 18-05-2017 om 15:39 [+0530]: From: "Kumar, Mahesh" This patch implements new DDB allocation algorithm as per HW team recommendation. This algo takecare of scenario where we

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: dma-buf support for GVT-g (rev2)

== Series Details == Series: drm/i915/gvt: dma-buf support for GVT-g (rev2) URL : https://patchwork.freedesktop.org/series/23686/ State : success == Summary == Series 23686v2 drm/i915/gvt: dma-buf support for GVT-g https://patchwork.freedesktop.org/api/1.0/series/23686/revisions/2/mbox/ Test

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On Thu, May 18, 2017 at 02:30:56PM +0100, Tvrtko Ursulin wrote: > > On 17/05/2017 17:44, Chris Wilson wrote: > >On Wed, May 17, 2017 at 04:40:57PM +0100, Tvrtko Ursulin wrote: > >>+static struct intel_engine_cs *get_engine_class(struct drm_i915_private > >>*i915, > >>+

[Intel-gfx] [PATCH] drm/i915: Check C for null pointer rather than B

From: Colin Ian King There are two occasions where pointer B is being check for a NULL when it should be pointer C instead. Fix these. Detected by CoverityScan, CID#1436348,1436349 ("Logically Dead Code") Fixes: 47624cc3301b60 ("drm/i915: Import the kfence selftests

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On Thu, May 18, 2017 at 02:06:35PM +0100, Tvrtko Ursulin wrote: > > On 18/05/2017 13:24, Chris Wilson wrote: > >Yes, I would argue to defer it until later. One problem I have at the > >moment is that not all members of a class are equal, HEVC-capable > >engines and the reset do not belong to the

Re: [Intel-gfx] [PATCH 01/24] drm/i915/selftests: Pretend to be a gfx pci device

On 18/05/2017 10:46, Chris Wilson wrote: Set the class on our mock pci device to GFX. This should be useful for utilities like intel-iommu that special case gfx devices. References: https://bugs.freedesktop.org/show_bug.cgi?id=101080 Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On 17/05/2017 17:44, Chris Wilson wrote: On Wed, May 17, 2017 at 04:40:57PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Building on top of the previous patch which exported the concept of engine classes and instances, we can also use this instead of the

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On 18/05/2017 13:24, Chris Wilson wrote: On Thu, May 18, 2017 at 01:13:20PM +0100, Tvrtko Ursulin wrote: On 18/05/2017 12:10, Chris Wilson wrote: On Thu, May 18, 2017 at 01:55:59PM +0300, Joonas Lahtinen wrote: On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 2/2] drm/i915/g4x: Fix unreliable gpu reset

On Thu, May 18, 2017 at 03:51:19PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Thu, May 18, 2017 at 03:34:22PM +0300, Mika Kuoppala wrote: > >> ELK seems to very picky about the preconditions to reset. > >> Evidence on Eaglelake (8086:2e12 (rev 03))

Re: [Intel-gfx] New " Unclaimed read from register 0x1f0034" in 4.12-rc1

Hi, On 18-05-17 14:31, Chris Wilson wrote: On Thu, May 18, 2017 at 02:20:09PM +0200, Hans de Goede wrote: Hi, So while trying to reproduce my previously reported "RPM wakelock ref not held during HW access" in 4.12-rc1 ?" Bug, to test the possible fixes I encountered a new "RPM wakelock ref

Re: [Intel-gfx] [PATCH 2/2] drm/i915/g4x: Fix unreliable gpu reset

Chris Wilson writes: > On Thu, May 18, 2017 at 03:34:22PM +0300, Mika Kuoppala wrote: >> ELK seems to very picky about the preconditions to reset. >> Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does >> not like if reset occurs when there is active ring. >>

Re: [Intel-gfx] [PATCH 2/2] drm/i915/g4x: Fix unreliable gpu reset

On Thu, May 18, 2017 at 03:34:22PM +0300, Mika Kuoppala wrote: > ELK seems to very picky about the preconditions to reset. > Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does > not like if reset occurs when there is active ring. > > Ville found out that there is workaround with name >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/g4x: Fix unreliable gpu reset

Mika Kuoppala writes: > ELK seems to very picky about the preconditions to reset. > Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does > not like if reset occurs when there is active ring. > > Ville found out that there is workaround with name >

[Intel-gfx] [PATCH 2/2] drm/i915/g4x: Fix unreliable gpu reset

ELK seems to very picky about the preconditions to reset. Evidence on Eaglelake (8086:2e12 (rev 03)) shows that it does not like if reset occurs when there is active ring. Ville found out that there is workaround with name 'WaMediaResetMainRingCleanup' which suggests that we need to cleanup rings

[Intel-gfx] [PATCH 1/2] drm/i915: Reorder media/render reset on g4x

From: Chris Wilson Ville found a reference to WaMediaResetBeforeFullReset which we presume means that we should simply do the media reset first. References: https://bugs.freedesktop.org/show_bug.cgi?id=100942 Suggested-by: Ville Syrjälä

Re: [Intel-gfx] New " Unclaimed read from register 0x1f0034" in 4.12-rc1

On Thu, May 18, 2017 at 02:20:09PM +0200, Hans de Goede wrote: > Hi, > > So while trying to reproduce my previously reported > "RPM wakelock ref not held during HW access" in 4.12-rc1 ?" > > Bug, to test the possible fixes I encountered a new > "RPM wakelock ref not held during HW access" error

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/24] drm/i915/selftests: Pretend to be a gfx pci device

== Series Details == Series: series starting with [01/24] drm/i915/selftests: Pretend to be a gfx pci device URL : https://patchwork.freedesktop.org/series/24612/ State : success == Summary == Series 24612v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Fix new -Wint-in-bool-context gcc compiler warning

On Thu, 18 May 2017, Hans de Goede wrote: > This commit fixes the following compiler warning: > > drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’: > drivers/gpu/drm/i915/intel_dsi.c:1487:23: warning: > ?: using integer constants in boolean context

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On Thu, May 18, 2017 at 01:13:20PM +0100, Tvrtko Ursulin wrote: > > On 18/05/2017 12:10, Chris Wilson wrote: > >On Thu, May 18, 2017 at 01:55:59PM +0300, Joonas Lahtinen wrote: > >>On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote: > >>>From: Tvrtko Ursulin > >>> >

[Intel-gfx] New " Unclaimed read from register 0x1f0034" in 4.12-rc1

Hi, So while trying to reproduce my previously reported "RPM wakelock ref not held during HW access" in 4.12-rc1 ?" Bug, to test the possible fixes I encountered a new "RPM wakelock ref not held during HW access" error combined with a "Unclaimed read from register 0x1f0034" error: Which I

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On 18/05/2017 12:10, Chris Wilson wrote: On Thu, May 18, 2017 at 01:55:59PM +0300, Joonas Lahtinen wrote: On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Building on top of the previous patch which exported the concept of engine classes

Re: [Intel-gfx] [PATCH] chamelium: Fix build issues on Android

On Thu, May 18, 2017 at 01:48:01PM +0200, Arkadiusz Hiler wrote: > Makefile.sources are included 1:1 in Android.mk files, and are not > parsed by automake. And yet those had some automake conditional logic. > Moving it to .am file is enough for now. > > Also igt_chamelium.h included config.h

Re: [Intel-gfx] [PATCH i-g-t v2 00/13] Fix IGTs for Android\

On Thu, May 18, 2017 at 11:09:06AM +0300, Petri Latvala wrote: > > Patches 1-4 and 6-13 are Send v2 of patch 5 that incorporates Michal's feedback. > Reviewed-by: Petri Latvala > > Nitpicks on the commit message on patch 6 (replied to it). Sent fixed version.

[Intel-gfx] [PATCH i-g-t v2] tools/Android.mk: Add guc_logger and l3_parity to skip list

Those tools do not build on Android due to "Linux-only" dependencies. Let's blacklist them for now. v2: commit message fixup (P. Latvala) Cc: Petri Latvala Signed-off-by: Arkadiusz Hiler --- tools/Android.mk | 2 ++ 1 file changed, 2

[Intel-gfx] [PATCH] chamelium: Fix build issues on Android

Makefile.sources are included 1:1 in Android.mk files, and are not parsed by automake. And yet those had some automake conditional logic. Moving it to .am file is enough for now. Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H" guard, and the file itself was included

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Remove failed doorbell stat from debugfs

This stat is almost always zero unless fatal error occurs, which should be reported by other means anyway. Suggested-by: Chris Wilson Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 1/3] drm/i915/guc: Remove stale comment for q_fail

This member was dropped long time ago. Fixes: 774439e1 ("drm/i915/guc: re-optimise i915_guc_client layout") Signed-off-by: Michal Wajdeczko Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_uc.h | 2 -- 1 file changed, 2 deletions(-) diff

[Intel-gfx] [PATCH 3/3] drm/i915/guc: Remove last submission result from debugfs

Debugfs does not seems to be a right place to display transient data. If we want to capture errors, we should log them. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Tvrtko Ursulin ---

Re: [Intel-gfx] [BACKPORT v4.12-rc1] drm/i915: Do not sync RCU during shrinking

On Thu, 18 May 2017, Joonas Lahtinen wrote: > Due to the complex dependencies between workqueues and RCU, which > are not easily detected by lockdep, do not synchronize RCU during > shrinking. > > On low-on-memory systems (mem=1G for example), the RCU sync leads >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl+: consider max supported plane pixel rate while scaling

Mahesh Kumar schreef op do 18-05-2017 om 15:39 [+0530]: > From: "Kumar, Mahesh" > > A display resolution is only supported if it meets all the > restrictions > below for Maximum Pipe Pixel Rate. > > The display resolution must fit within the maximum pixel rate output >

Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: New ddb allocation algorithm

Mahesh Kumar schreef op do 18-05-2017 om 15:39 [+0530]: > From: "Kumar, Mahesh" > > This patch implements new DDB allocation algorithm as per HW team > recommendation. This algo takecare of scenario where we allocate less > DDB > for the planes with lower relative pixel

Re: [Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

On Thu, May 18, 2017 at 01:55:59PM +0300, Joonas Lahtinen wrote: > On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > Building on top of the previous patch which exported the concept > > of engine classes and instances, we can also

  1   2   >