Quoting Yang, Dong (2019-08-14 03:43:44)
> comments updated, please review again.
You seem to have missed the comments to the code itself.
Regards, Joonas
>
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Tuesday, August 13, 2019 8:47 PM
>
Quoting Dong Yang (2019-08-14 03:44:48)
> From: "Yang, Dong"
>
> Broxton steppings starting from GT E0 have fixed the bug, remove
> WA since stepping GT E0.
In i915 patches, we keep a changelog of what was changed compared to the
previous iteration (see git log drivers/gpu/drm/i915 for example)
== Series Details ==
Series: series starting with [v3] drm/i915: Push the wakeref->count deferral to
the backend (rev3)
URL : https://patchwork.freedesktop.org/series/65129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6697_full -> Patchwork_14002_full
==
From: "Yang, Dong"
Broxton steppings starting from GT E0 have fixed the bug, remove
WA since stepping GT E0.
v2: add comment in code, by:
Joonas Lahtinen
Signed-off-by: Yang, Dong
---
drivers/gpu/drm/i915/i915_drv.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/driv
Quoting Daniele Ceraolo Spurio (2019-08-14 01:21:45)
> The engine->guc_id is GuC FW defined and it is not guaranteed to be
> below I915_NUM_ENGINES, so we shouldn't use it with the i915-defined
> client->submissions, as we might overflow.
> Instead of fixing it, just get rid of client->submissions,
Quoting Chris Wilson (2019-08-14 09:00:18)
> Quoting Daniele Ceraolo Spurio (2019-08-14 01:21:45)
> > The engine->guc_id is GuC FW defined and it is not guaranteed to be
> > below I915_NUM_ENGINES, so we shouldn't use it with the i915-defined
> > client->submissions, as we might overflow.
> > Inste
== Series Details ==
Series: drm/i915: Remove i915 ggtt WA since GT E0 (rev2)
URL : https://patchwork.freedesktop.org/series/65160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6701 -> Patchwork_14009
Summary
---
**
Quoting Srivatsa, Anusha (2019-08-14 00:41:15)
>
>
> > -Original Message-
> > From: Chris Wilson
> > Sent: Tuesday, August 13, 2019 11:21 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson ; Daniel Vetter
> > ; Maarten Lankhorst
> > ; Srivatsa, Anusha
> >
> > Subject: [PATC
Quoting dong.y...@intel.com (2019-08-14 08:54:05)
> From: "Yang, Dong"
>
> Broxton steppings starting from GT E0 have fixed the bug, remove
> WA since stepping GT E0.
If you have a supply of these, could you arrange for one to be put into
CI. We have no coverage of bxt-iommu to assess your claim
Quoting Chris Wilson (2019-08-13 18:55:46)
> Quoting Stuart Summers (2019-08-13 18:41:20)
> > Use render class instead of RCS0 when printing CCID.
> >
> > Signed-off-by: Stuart Summers
>
> One day, one day, this will be using some lists of registers.
>
> Reviewed-by: Chris Wilson
Pushed this
Quoting Chris Wilson (2019-08-13 23:09:05)
> We use the request pointer inside the i915_active_node as the indicator
> of the barrier's status; we mark it as used during
> i915_request_add_active_barriers(), and search for an available barrier
> in reuse_idle_barrier(). That check must be carefully
Move the active tracking for the frontbuffer operations out of the
i915_gem_object and into its own first class (refcounted) object. In the
process of detangling, we switch from low level request tracking to the
easier i915_active -- with the plan that this avoids any potential
atomic callbacks as
Convert the list manipulation of active to use spinlocks so that we can
perform the updates from underneath a quick interrupt callback.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c| 10 --
drivers/gpu/drm/i915
As every i915_active_request should be serialised by a dedicated lock,
i915_active consists of a tree of locks; one for each node. Markup up
the i915_active_request with what lock is supposed to be guarding it so
that we can verify that the serialised updated are indeed serialised.
Signed-off-by:
We use timeline->mutex to protect modifications to
context->active_count, and the associated enable/disable callbacks.
Due to complications with engine-pm barrier there is a path where we used
a "superlock" to provide serialised protect and so could not
unconditionally assert with lockdep that it w
Forgo the struct_mutex requirement for request retirement as we have
been transitioning over to only using the timeline->mutex for
controlling the lifetime of a request on that timeline.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 183 ++
drive
In preparation for removing struct_mutex from around context retirement,
we need to make timeline pinning safe. Since multiple engines/contexts
can share a single timeline, it needs to be protected by a mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 27 +++
On Wed, Aug 14, 2019 at 07:58:27AM +0200, Gerd Hoffmann wrote:
> > Hi Gerd,
> >
> > I've been seeing a regression on Nouveau with recent linux-next releases
> > and git bisect points at this commit as the first bad one. If I revert
> > it (there's a tiny conflict with a patch that was merged subse
== Series Details ==
Series: drm/i915: Serialise read/write of the barrier's engine
URL : https://patchwork.freedesktop.org/series/65152/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6698_full -> Patchwork_14003_full
Summa
Lift moving the timeline to/from the active_list on enter/exit in order
to shorten the active tracking span in comparison to the existing
pin/unpin.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 1 -
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
drivers
If we only call process_csb() from the tasklet, though we lose the
ability to bypass ksoftirqd interrupt processing on direct submission
paths, we can push it out of the irq-off spinlock.
The penalty is that we then allow schedule_out to be called concurrently
with schedule_in requiring us to hand
On Sat, Aug 10, 2019 at 12:02:19AM +0530, Anshuman Gupta wrote:
> We need to have a S/W flag based upon which driver can switch to DC3CO.
> If it is only edp display connected and it has psr2 capability,
> then set a prefer_dc3co flag to true, which will be used to
> switch to dc3co as well as to p
Check that we can run a second request even if an equal priority spinner
is hogging the engine.
Extend the testing with some undying timeslice behaviour that requires
hangcheck to intervene.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
tests/i9
Hi,
> > Changing the order doesn't look hard. Patch attached (untested, have no
> > test hardware). But maybe I missed some detail ...
>
> I came up with something very similar by splitting up nouveau_bo_new()
> into allocation and initialization steps, so that when necessary the GEM
> object
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.
This should enable us to reload driver with sl
From: Michał Winiarski
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.
v2: rebased
Signed-off-by: Michał Winiarski
Signed-off-by: Michal Wajdeczko
Cc
== Series Details ==
Series: drm/i915: Include engine->mmio_base in the debug duump
URL : https://patchwork.freedesktop.org/series/65157/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6699_full -> Patchwork_14004_full
Summa
Quoting dong.y...@intel.com (2019-08-14 10:54:05)
> From: "Yang, Dong"
>
> Broxton steppings starting from GT E0 have fixed the bug, remove
> WA since stepping GT E0.
>
> v2: add comment in code, by:
> Joonas Lahtinen
I didn't suggest any comments, I suggested to change the code.
>
> Signed-
Hi,
Sorry for the delay, I was on vacation. The machine fi-skl-6770hq was
not marked as having an LSPCON. This is now done, and this means that
this issue should be covered by ab existing bug.
I queued another run, and we'll see if it gives us a green (new tests
don't need to pass on all machines
== Series Details ==
Series: drm/ttm: make ttm bo a gem bo subclass (rev4)
URL : https://patchwork.freedesktop.org/series/64701/
State : failure
== Summary ==
Applying: drm/ttm: add gem base object
Using index info to reconstruct a base tree...
M include/drm/ttm/ttm_bo_api.h
Falling back
== Series Details ==
Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out
of the irq-off spinlock
URL : https://patchwork.freedesktop.org/series/65169/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c067af237d77 drm/i915/execlists: Lift process_csb() ou
== Series Details ==
Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out
of the irq-off spinlock
URL : https://patchwork.freedesktop.org/series/65169/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Lift pr
Discussed this a bit with Chris, I think a comment here is warranted
that this will be bad once we have more than one i915 instance. And
lockdep won't catch it.
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 6 ++
1 file c
The trouble with having a plain nesting flag for locks which do not
naturally nest (unlike block devices and their partitions, which is
the original motivation for nesting levels) is that lockdep will
never spot a true deadlock if you screw up.
This patch is an attempt at trying better, by highlig
Quoting Daniel Vetter (2019-08-14 13:49:33)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index d474c6ac4100..1ea3c3c96a5a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_
== Series Details ==
Series: series starting with [1/8] drm/i915/execlists: Lift process_csb() out
of the irq-off spinlock
URL : https://patchwork.freedesktop.org/series/65169/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6706 -> Patchwork_14011
=
== Series Details ==
Series: series starting with [1/2] drm/i915/wopcm: Try to use already locked
WOPCM layout
URL : https://patchwork.freedesktop.org/series/65175/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6706 -> Patchwork_14012
=
== Series Details ==
Series: drm/i915/guc: Remove client->submissions
URL : https://patchwork.freedesktop.org/series/65159/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6700_full -> Patchwork_14005_full
Summary
---
+ Abdiel/intel-gfx
Quoting Joonas Lahtinen (2019-08-14 15:46:01)
> Quoting Chris Wilson (2019-08-14 13:31:10)
> > Quoting Lukasz Kalamarz (2019-08-14 11:21:38)
> > > +/**
> > > + * gem_get_page_size:
> > > + * @fd: open i915 drm file descriptor
> > > + * @mem_region_type: used memory_region typ
On 8/13/19 1:16 PM, Daniele Ceraolo Spurio wrote:
>
>
> On 8/13/19 9:26 AM, Fernando Pacheco wrote:
>> We should not be skipping uc_fini_hw on finding GuC
>> is no longer running. There is plenty of hw and internal
>> state that can be cleaned up without having to communicate
>> with GuC.
>>
>
> B
== Series Details ==
Series: drm/i915: Remove i915 ggtt WA since GT E0
URL : https://patchwork.freedesktop.org/series/65160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6700_full -> Patchwork_14006_full
Summary
---
>-Original Message-
>From: james qian wang (Arm Technology China) [mailto:james.qian.w...@arm.com]
>Sent: Tuesday, August 13, 2019 3:12 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maa
== Series Details ==
Series: HDCP2.2 Phase II (rev15)
URL : https://patchwork.freedesktop.org/series/57232/
State : failure
== Summary ==
Applying: drm: Add Content protection type property
Using index info to reconstruct a base tree...
M drivers/gpu/drm/drm_atomic_uapi.c
M drivers
== Series Details ==
Series: series starting with [1/2] drm/i915: Comment userptr recursion on
struct_mutex
URL : https://patchwork.freedesktop.org/series/65177/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ea422f4a5a9e drm/i915: Comment userptr recursion on struct_mutex
-:30
On 8/13/19 1:18 PM, Michal Wajdeczko wrote:
> On Tue, 13 Aug 2019 18:26:28 +0200, Fernando Pacheco
> wrote:
>
>> We should not be skipping uc_fini_hw on finding GuC
>> is no longer running. There is plenty of hw and internal
>> state that can be cleaned up without having to communicate
>> with G
On Wed, Aug 14, 2019 at 3:06 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-08-14 13:49:33)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index d474c6ac4100..1ea3c3c96a5a 100644
> > --- a/drivers/gpu/drm/i915/g
== Series Details ==
Series: series starting with [1/2] drm/i915: Comment userptr recursion on
struct_mutex
URL : https://patchwork.freedesktop.org/series/65177/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6707 -> Patchwork_14014
Sorry I burried myself in some other stuff ...
On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > Quoting Christian König (2019-08-07 14:53:12)
> > > The only remaining use for this is to protect against setting a new
> > > exclusive
This is a note to let you know that I've just added the patch titled
drm/i915: Fix wrong escape clock divisor init for GLK
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
d
Quoting Daniel Vetter (2019-08-14 16:39:08)
> Sorry I burried myself in some other stuff ...
>
> On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> > Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > > Quoting Christian König (2019-08-07 14:53:12)
> > > > The only remaining use for th
This is a note to let you know that I've just added the patch titled
drm/i915: Fix wrong escape clock divisor init for GLK
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
d
On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> > Sorry I burried myself in some other stuff ...
> >
> > On Sat, Aug 10, 2019 at 12:51:00PM +0200, Christian König wrote:
> > > Am 07.08.19 um 16:17 schrieb Chris Wilson:
> > > > Quoting C
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by
Quoting Chris Wilson (2019-08-14 17:42:48)
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> >
> > What if someone is real fast (like really real fast) and recycles the
> > exclusive fence so you read the same pointer twice, b
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by
From: Stanislav Lisovskiy
commit 73a0ff0b30af79bf0303d557eb82f1d1945bb6ee upstream.
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by
On Fri, Aug 09, 2019 at 05:36:39PM +0200, Heinrich wrote:
> Store the timestamp of the current vblank in the new field 'time' of the
> vblank trace event. If the timestamp is calculated by a driver that
> supports high-precision vblank timing, set the field 'high-prec' to
> 'true'.
>
> User space
This is a note to let you know that I've just added the patch titled
drm/i915: Fix wrong escape clock divisor init for GLK
to the 5.2-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
dr
On Sun, Aug 11, 2019 at 10:15:23AM +0100, Chris Wilson wrote:
> Now that dma_fence_signal always takes the spinlock to flush the
> cb_list, simply take the spinlock and call dma_fence_signal_locked() to
> avoid code repetition.
>
> Suggested-by: Christian König
> Signed-off-by: Chris Wilson
> Cc
Quoting Daniel Vetter (2019-08-14 18:06:26)
> On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
[snip]
> > > > > > if (old)
> > > > > > - old->shared_count = 0;
> > > > > > - write_seqcount_end(&obj->seq);
> >
Quoting Chris Wilson (2019-08-14 18:06:18)
> Quoting Chris Wilson (2019-08-14 17:42:48)
> > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > >
> > > What if someone is real fast (like really real fast) and recycles the
> >
Hi Sasha,
On Mon, Aug 12, 2019 at 07:05:47PM +, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: d3862e44daa7 dma-buf/sw-sync: Fix locking around sync_timeline
> lists.
>
> The bot has tested t
Quoting Chris Wilson (2019-08-14 18:22:53)
> Quoting Chris Wilson (2019-08-14 18:06:18)
> > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > > + } while (rcu_access_pointer(obj->fence_excl) != *excl);
> > > >
> > > > What if someone is
Quoting Chris Wilson (2019-08-14 18:38:20)
> Quoting Chris Wilson (2019-08-14 18:22:53)
> > Quoting Chris Wilson (2019-08-14 18:06:18)
> > > Quoting Chris Wilson (2019-08-14 17:42:48)
> > > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> > > > > > > > + } while (rcu_access_pointer(obj->fence_
On Wed, Aug 14, 2019 at 06:20:28PM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2019-08-14 18:06:26)
> > On Wed, Aug 14, 2019 at 05:42:48PM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2019-08-14 16:39:08)
> [snip]
> > > > > > > if (old)
> > > > > > > - old-
Am 14.08.19 um 19:48 schrieb Chris Wilson:
> Quoting Chris Wilson (2019-08-14 18:38:20)
>> Quoting Chris Wilson (2019-08-14 18:22:53)
>>> Quoting Chris Wilson (2019-08-14 18:06:18)
Quoting Chris Wilson (2019-08-14 17:42:48)
> Quoting Daniel Vetter (2019-08-14 16:39:08)
> + }
---
drivers/gpu/drm/i915/Makefile | 7 +
drivers/gpu/drm/i915/ttm/Makefile | 5 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.c | 4 +
drivers/gpu/drm/i915/ttm/i915_ttm_drv.h | 12 ++
drivers/gpu/drm/i915/ttm/i915_ttm_ppgtt.c | 174 ++
drivers/gpu/drm/i
Quoting Chris Wilson (2019-08-14 19:22:54)
You saw nothing; wrong experimental branch.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
This reverts
67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
5d344f58da76 ("dma-buf: nuke reservation_object seq number")
The scenario that
Quoting Chris Wilson (2019-08-14 19:24:01)
> This reverts
> 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
> dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
> 0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
> 5d344f58da76 ("dma-buf: nu
== Series Details ==
Series: ttm
URL : https://patchwork.freedesktop.org/series/65194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f98f53ff57bd ttm
-:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
-:33: WARNING:FILE_PATH_CHANGES: added, moved
I was going to ask the status of this and then I looked and realized that I
never provided a commit message blrub. Oops. Here you go:
On Broadwell, the sampler was changed to not require extra padding for
simple (no arrays, mipmapping, or MSAA) 1D, 2D, and buffer surfaces.
Setting the GEN9_DISAB
== Series Details ==
Series: drm/i915: Remove i915 ggtt WA since GT E0 (rev2)
URL : https://patchwork.freedesktop.org/series/65160/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6701_full -> Patchwork_14009_full
Summary
---
The trouble with having a plain nesting flag for locks which do not
naturally nest (unlike block devices and their partitions, which is
the original motivation for nesting levels) is that lockdep will
never spot a true deadlock if you screw up.
This patch is an attempt at trying better, by highlig
Quoting Koenig, Christian (2019-08-14 18:58:32)
> Am 14.08.19 um 19:48 schrieb Chris Wilson:
> > Quoting Chris Wilson (2019-08-14 18:38:20)
> >> Quoting Chris Wilson (2019-08-14 18:22:53)
> >>> Quoting Chris Wilson (2019-08-14 18:06:18)
> Quoting Chris Wilson (2019-08-14 17:42:48)
> > Quot
Quoting Daniel Vetter (2019-08-14 19:49:41)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index d474c6ac4100..1ea3c3c96a5a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_
== Series Details ==
Series: ttm
URL : https://patchwork.freedesktop.org/series/65194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6709 -> Patchwork_14015
Summary
---
**SUCCESS**
No regressions found.
Externa
== Series Details ==
Series: dma-buf: Restore seqlock around dma_resv updates
URL : https://patchwork.freedesktop.org/series/65196/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cffdefd474fc dma-buf: Restore seqlock around dma_resv updates
-:7: ERROR:GIT_COMMIT_ID: Please use g
On Wed, Aug 14, 2019 at 02:49:32PM +0200, Daniel Vetter wrote:
> Discussed this a bit with Chris, I think a comment here is warranted
> that this will be bad once we have more than one i915 instance. And
> lockdep won't catch it.
>
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Signed-off-by: Daniel
== Series Details ==
Series: dma-buf: Restore seqlock around dma_resv updates
URL : https://patchwork.freedesktop.org/series/65196/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6709 -> Patchwork_14016
Summary
---
**
The trouble with having a plain nesting flag for locks which do not
naturally nest (unlike block devices and their partitions, which is
the original motivation for nesting levels) is that lockdep will
never spot a true deadlock if you screw up.
This patch is an attempt at trying better, by highlig
== Series Details ==
Series: series starting with [1/2] drm/i915: Comment userptr recursion on
struct_mutex (rev3)
URL : https://patchwork.freedesktop.org/series/65177/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
68f7d12ba111 drm/i915: Comment userptr recursion on struct_mut
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse what is already programmed, maybe there will be a fit.
== Series Details ==
Series: series starting with [1/2] drm/i915: Comment userptr recursion on
struct_mutex (rev3)
URL : https://patchwork.freedesktop.org/series/65177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6709 -> Patchwork_14017
=
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
From: Michał Winiarski
While we need to know WOPCM size to do this sanity check, it has more to
do with FW than with WOPCM. Let's move the check to fetch phase, it's
not like WOPCM is going to grow in the meantime.
v2: rebased
Signed-off-by: Micha
On Wed, Aug 14, 2019 at 07:26:44PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2019-08-14 19:24:01)
> > This reverts
> > 67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
> > dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
> > 0e1d8083bddb ("dma-buf: further
On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we will be unable to enforce it and fail. Instead we should try
to reuse
Similar to the warning in the mmu notifer, warning if an hmm mirror
callback gets it's blocking vs. nonblocking handling wrong, or if it
fails with anything else than -EAGAIN.
Cc: Jason Gunthorpe
Cc: Ralph Campbell
Cc: John Hubbard
Cc: Dan Williams
Cc: Dan Carpenter
Cc: Matthew Wilcox
Cc: Ar
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not al
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return va
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But
Hi all (but I guess mostly Jason),
Finally gotten around to rebasing the previous version, fixing the rebase
fail in there, update the commit message a bit and give this a spin with
some tests. Nicely caught a lockdep splat that we're now discussing in
i915, and seems to not have misfired anywhere
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job d
On Wed, 14 Aug 2019 22:20:24 +0200 Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This wi
On Wed, 14 Aug 2019 22:10:51 +0200, Daniele Ceraolo Spurio
wrote:
On 8/14/19 12:51 PM, Daniele Ceraolo Spurio wrote:
On 8/14/19 4:38 AM, Michal Wajdeczko wrote:
If WOPCM layout is already locked in HW we shouldn't continue
with our own partitioning as it could be likely different and
we
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
This simplifies the code to not have so many one line functions and extra
logic. __mmu_notifier_register() simply becomes the entry point to
register the notifier, and the other one calls it under lock.
Also add a lockdep_assert
On 8/6/19 4:15 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
A prior commit e0f3c3f78da2 ("mm/mmu_notifier: init notifier if necessary")
made an attempt at doing this, but had to be reverted as calling
the GFP_KERNEL allocator under the i_mmap_mutex causes deadlock, see
commit 35cfa2b0b491
On Wed, Aug 14, 2019 at 03:58:34PM +, Jason Gunthorpe wrote:
> On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote:
> > Looks good,
> >
> > Reviewed-by: Christoph Hellwig
>
> Dimitri, are you OK with this patch?
>
I think this looks OK.
Reviewed-by: Dimitri Sivanich
This series updates DRM drivers to use new CEC notifier API.
Changes since v6:
Made CEC notifiers' registration and de-registration symmetric
in tda998x and dw-hdmi drivers. Also, accidentally dropped one
patch in v6 (change to drm_dp_cec), brought it back now.
Changes sinc
On Thu, Aug 08, 2019 at 12:25:56PM +0200, Christoph Hellwig wrote:
> Looks good,
>
> Reviewed-by: Christoph Hellwig
Dimitri, are you OK with this patch?
Thanks,
Jason
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop
1 - 100 of 131 matches
Mail list logo
