Re: [Intel-gfx] [PATCH] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection

Chris Wilson writes: > Similar to the staging around handling of engine->submit_request, we > need to stop adding to the execlists->queue prior to calling > engine->cancel_requests. cancel_requests will move requests from the > queue onto the timeline, so if we add a

Re: [Intel-gfx] [PATCH igt 01/16] igt/gem_sync: Exercise and measure idle requests

For some reason, I've reviewed these from the middle of the series (maybe transport delay?). Are the rest still applicable or refreshed somewhere? Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 02/15] drm/i915/guc: Create common entry points for log register/unregister

On Mon, Mar 05, 2018 at 12:39:58PM +0530, Sagar Arun Kamble wrote: > Overall change looks good. Could you please clarify on below: > > intel_uc_log_register|unregister are removed in patch later in the series. > Should we just stay with inner functions then to minimize changes? I've done this to

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Removed unused GuC parameters. (rev2)

== Series Details == Series: drm/i915/guc: Removed unused GuC parameters. (rev2) URL : https://patchwork.freedesktop.org/series/39154/ State : failure == Summary == Series 39154v2 drm/i915/guc: Removed unused GuC parameters.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle changing enable_fbc parameter at runtime better.

== Series Details == Series: drm/i915: Handle changing enable_fbc parameter at runtime better. URL : https://patchwork.freedesktop.org/series/39375/ State : success == Summary == Series 39375v1 drm/i915: Handle changing enable_fbc parameter at runtime better.

[Intel-gfx] [PATCH v2] drm/i915/guc: Remove GUC_CTL_DEVICE_INFO parameter

It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter where we are passing GT type and Core family values. Lets stop setup this parameter and remove related definitions. v2: (this time without squashed HAX) - New title and description - Remove also GUC_CORE_FAMILY_*

Re: [Intel-gfx] i915 vs checkpatch

On Thu, Mar 01, 2018 at 11:17:50PM +, Chris Wilson wrote: > Quoting Arkadiusz Hiler (2018-03-01 09:47:06) > > Hey all, > > > > Since not so long ago our CI is running and reporting sparse and > > checkpatch. Sparse is doing just fine but I had to disable checkpatch > > for the time being -

Re: [Intel-gfx] i915 vs checkpatch

On Mon, Mar 05, 2018 at 01:10:21PM +0200, Jani Nikula wrote: > On Mon, 05 Mar 2018, Daniel Vetter wrote: > > I'd recommend not making checkpatch ever fail CI, but at most warning. > > Agreed. But we want the automated warnings on the list, neutrally from a > bot instead of a

[Intel-gfx] [PATCH i-g-t] intel-gpu-overlay: Update for renamed tracepoints

From: Tvrtko Ursulin Request tracepoints have been renames so update the tool to be able to find them. Also support falling back to the old name for compatibility. Signed-off-by: Tvrtko Ursulin --- Compile tested only so also looking for

[Intel-gfx] [PATCH] drm/i915: Handle changing enable_fbc parameter at runtime better.

If i915.enable_fbc is cleared at runtime, but FBC was previously enabled then we don't disable FBC until the next time the crtc is disabled. Make sure that if the module param is changed, we disable FBC in intel_fbc_post_update so we never have to worry about disabling. Signed-off-by: Maarten

Re: [Intel-gfx] [PATCH] drm/i915: Assert that the request is indeed complete when signaled from irq

On 05/03/2018 11:21, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-05 11:12:45) On 05/03/2018 10:41, Chris Wilson wrote: After we call dma_fence_signal(), confirm that the request was indeed complete. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH v2] drm/i915: add schedule out notification of preempted but completed request

On 05/03/2018 11:18, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-05 11:06:23) On 24/02/2018 02:59, Weinan Li wrote: There is one corner case missing schedule out notification of the preempted request. The preempted request is just completed when preemption happen, then it will be

Re: [Intel-gfx] [PATCH] drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path

Quoting Ville Syrjälä (2018-03-05 11:12:12) > On Mon, Mar 05, 2018 at 10:33:12AM +, Chris Wilson wrote: > > If we fail to acquire a fence when we must, we must unwind before > > reporting the error. Otherwise, we lose tracking of the vma pinning and > > eventually hit a bug like > > > > <3>[

Re: [Intel-gfx] [PATCH 07/15] drm/i915/guc: Flush directly in log unregister

On Mon, Mar 05, 2018 at 05:28:33PM +0530, Sagar Arun Kamble wrote: > > > On 2/27/2018 6:22 PM, Michał Winiarski wrote: > > Having both guc_flush_logs and guc_log_flush functions is confusing. > > While we could just rename things, guc_flush_logs implementation is > > quite simple. Let's get rid

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Assert that the request is indeed complete when signaled from irq

== Series Details == Series: drm/i915: Assert that the request is indeed complete when signaled from irq URL : https://patchwork.freedesktop.org/series/39369/ State : success == Summary == Series 39369v1 drm/i915: Assert that the request is indeed complete when signaled from irq

Re: [Intel-gfx] [PATCH 07/15] drm/i915/guc: Flush directly in log unregister

On 2/27/2018 6:22 PM, Michał Winiarski wrote: Having both guc_flush_logs and guc_log_flush functions is confusing. While we could just rename things, guc_flush_logs implementation is quite simple. Let's get rid of it and move its content to unregister. Signed-off-by: Michał Winiarski

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path

== Series Details == Series: drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path URL : https://patchwork.freedesktop.org/series/39367/ State : success == Summary == Series 39367v1 drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path

Re: [Intel-gfx] [PATCH 06/15] drm/i915/guc: Merge log relay file and channel creation

On 2/27/2018 6:22 PM, Michał Winiarski wrote: We have all the information we need at relay_open call time. Since there's no reason to split the process into relay_open and relay_late_setup_files, let's remove the extra code. Signed-off-by: Michał Winiarski Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Assert that the request is indeed complete when signaled from irq

Quoting Tvrtko Ursulin (2018-03-05 11:12:45) > > On 05/03/2018 10:41, Chris Wilson wrote: > > After we call dma_fence_signal(), confirm that the request was indeed > > complete. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > >

Re: [Intel-gfx] [PATCH v2] drm/i915: add schedule out notification of preempted but completed request

Quoting Tvrtko Ursulin (2018-03-05 11:06:23) > > On 24/02/2018 02:59, Weinan Li wrote: > > There is one corner case missing schedule out notification of the preempted > > request. The preempted request is just completed when preemption happen, > > then it will be canceled and won't be resubmitted

Re: [Intel-gfx] [PATCH] drm/i915: Assert that the request is indeed complete when signaled from irq

On 05/03/2018 10:41, Chris Wilson wrote: After we call dma_fence_signal(), confirm that the request was indeed complete. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_irq.c | 1 + 1 file changed, 1

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

On Fri, 2018-03-02 at 12:53 +0530, Sagar Arun Kamble wrote: > > On 3/2/2018 12:44 AM, John Spotswood wrote: > > On Thu, 2018-03-01 at 17:35 +0530, Sagar Arun Kamble wrote: > > > On 3/1/2018 1:32 PM, Chris Wilson wrote: > > > > Quoting Michel Thierry (2018-02-28 22:07:51) > > > > > On 28/02/18

Re: [Intel-gfx] [PATCH] drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path

On Mon, Mar 05, 2018 at 10:33:12AM +, Chris Wilson wrote: > If we fail to acquire a fence when we must, we must unwind before > reporting the error. Otherwise, we lose tracking of the vma pinning and > eventually hit a bug like > > <3>[ 46.163202] i915_vma_unpin:333

Re: [Intel-gfx] i915 vs checkpatch

On Mon, 05 Mar 2018, Daniel Vetter wrote: > I'd recommend not making checkpatch ever fail CI, but at most warning. Agreed. But we want the automated warnings on the list, neutrally from a bot instead of a developer spending time nitpicking this stuff. And the committers should

Re: [Intel-gfx] [PATCH v2] drm/i915: add schedule out notification of preempted but completed request

On 24/02/2018 02:59, Weinan Li wrote: There is one corner case missing schedule out notification of the preempted request. The preempted request is just completed when preemption happen, then it will be canceled and won't be resubmitted later, GVT-g will lost the schedule out notification.

[Intel-gfx] [PATCH igt] Bump measure_ring_size() timer interval

It appears that waiting for a 100us period whereby we are unable to submit another batch and proclaim the ring full, may have the false positive where the scheduler intervenes and we are signalled twice before having slept on ring space. Increasing the interval reduces the likelihood of the

Re: [Intel-gfx] [PATCH v3] drm/i915/icl: remove port A/E lane sharing limitation.

On Mon, 05 Mar 2018, "Kumar, Mahesh" wrote: > Please review. Pushed to drm-intel-next-queued, thanks for the patch. Personally, I would have split this into 2-3 patches: 1) code movement to allow 2) abstraction of the function and 3) functional change of the limit on

[Intel-gfx] [PATCH] drm/i915: Assert that the request is indeed complete when signaled from irq

After we call dma_fence_signal(), confirm that the request was indeed complete. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_irq.c | 1 + 1 file changed, 1 insertion(+) diff --git

[Intel-gfx] [PATCH] drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path

If we fail to acquire a fence when we must, we must unwind before reporting the error. Otherwise, we lose tracking of the vma pinning and eventually hit a bug like <3>[ 46.163202] i915_vma_unpin:333 GEM_BUG_ON(!i915_vma_is_pinned(vma)) <4>[ 46.163424] [ cut here ] <2>[

Re: [Intel-gfx] [PATCH 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay

On 2/27/2018 6:22 PM, Michał Winiarski wrote: Currently, we're treating relay and mapping of GuC log as a separate concepts. We're also using inconsistent locking, sometimes using relay_lock, sometimes using struct mutex. Let's correct that. Anything touching the runtime is now serialized

[Intel-gfx] [PATCH igt] igt/drv_hangman: Check that the error state does hold the expected state

Actually check the error state exists (!"No error state captured") and that it contains the expected engine dump. v2: Throw in some debug clues. Signed-off-by: Chris Wilson --- tests/drv_hangman.c | 12 1 file changed, 12 insertions(+) diff --git

Re: [Intel-gfx] [igt-dev] [PATCH igt 2/5] igt/gem_spin_batch: Avoid waiting when running concurrently

On Wed, Feb 28, 2018 at 03:51:35PM +, Chris Wilson wrote: > If we do a global wait while trying to execute spinners in parallel, > it ends badly with a GPU hang. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104352 > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/atomic: Call ww_acquire_done after drm_modeset_lock_all

Op 21-02-18 om 20:39 schreef Harry Wentland: > On 2018-02-21 01:36 PM, Daniel Vetter wrote: >> On Wed, Feb 21, 2018 at 04:23:31PM +0100, Maarten Lankhorst wrote: >>> After we acquired all generic modeset locks in drm_modeset_lock_all, it's >>> unsafe acquire any other so just mark acquisition as

Re: [Intel-gfx] [PATCH 04/15] drm/i915/guc: Keep GuC interrupts enabled when using GuC

On 2/27/2018 6:22 PM, Michał Winiarski wrote: The GuC log contains a separate space used for crash dump. We even get a separate notification for it. While we're not handling crash differently yet, it makes sense to decouple the two right now to simplify the following patches. Signed-off-by:

Re: [Intel-gfx] i915 vs checkpatch

On Thu, Mar 01, 2018 at 11:47:06AM +0200, Arkadiusz Hiler wrote: > Hey all, > > Since not so long ago our CI is running and reporting sparse and > checkpatch. Sparse is doing just fine but I had to disable checkpatch > for the time being - too much "false" positives causing people to > complain.

Re: [Intel-gfx] [PULL] drm-misc-next

On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote: > On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul wrote: > > > > Hi Dave, > > Here's this weeks pull, relatively small when you pull out the trivial > > fixes. > > > > drm-misc-next-2018-02-28: > > drm-misc-next for

<    1   2