On Tue, May 12, 2020 at 10:48:03AM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's two more fixes for 5.7. One is for recent guest display probe failure,
> which is fixed by setting correct transcoder and DPLL clock against virtual
> display. Another is regression to fix kernel oops for older aliasi
On 11/05/2020 08:57, Chris Wilson wrote:
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the
Quoting Tvrtko Ursulin (2020-05-12 09:41:01)
>
> On 11/05/2020 08:57, Chris Wilson wrote:
> > The second try at staging the transfer of the breadcrumb. In part one,
> > we realised we could not simply move to the second engine as we were
> > only holding the breadcrumb lock on the first. So in com
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: l
Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from shrinker callbacks (which i915 does), and from mm
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc: linux-
This is a bit tricky, since ->notifier_lock is held while calling
dma_fence_wait we must ensure that also the read side (i.e.
dma_fence_begin_signalling) is on the same side. If we mix this up
lockdep complaints, and that's again why we want to have these
annotations.
A nice side effect of this is
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be h
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.
Add dma-fence annotations so that lockdep can check this for us.
I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no exper
Hi all,
I've dragged my feet for years on this, hoping that cross-release lockdep
would do this for us, but well that never really happened unfortunately.
So here we are.
Cc'ed quite a pile of people since this is about the cross-driver contract
around dma_fences. Which is heavily used for dma_bu
My dma-fence lockdep annotations caught an inversion because we
allocate memory where we really shouldn't:
kmem_cache_alloc+0x2b/0x6d0
amdgpu_fence_emit+0x30/0x330 [amdgpu]
amdgpu_ib_schedule+0x306/0x550 [amdgpu]
amdgpu_job_run+0x10f/0x260 [amdgpu]
drm_sched
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.
Originally this
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
i
Design is similar to the lockdep annotations for workers, but with
some twists:
- We use a read-lock for the execution/worker/completion side, so that
this explicit annotation can be more liberally sprinkled around.
With read locks lockdep isn't going to complain if the read-side
isn't neste
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Cc: linux-me...@vge
Not going to bother with a complete&pretty commit message, just
offending backtrace:
kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140 [drm
But only for non-zero timeout, to avoid false positives.
One question here is whether the might_sleep should be unconditional,
or only for real timeouts. I'm not sure, so went with the more
defensive option. But in the interest of locking down the cross-driver
dma_fence rules we might want to be m
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to
I need a canary in a ttm-based atomic driver to make sure the
dma_fence_begin/end_signalling annotations actually work.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris
...
I think it's time to stop this little exercise.
The lockdep splat, for the record:
[ 132.583381] ==
[ 132.584091] WARNING: possible circular locking dependency detected
[ 132.584775] 5.7.0-rc3+ #346 Tainted: GW
[ 132.585461] ---
i915 does tons of allocations from this worker, which lockdep catches.
Also generic infrastructure like this with big potential for how
dma_fence or other cross driver contracts work, really should be
reviewed on dri-devel. Implementing custom wheels for everything
within the driver is a classic c
Quoting Daniel Vetter (2020-05-12 09:59:28)
> But only for non-zero timeout, to avoid false positives.
>
> One question here is whether the might_sleep should be unconditional,
> or only for real timeouts. I'm not sure, so went with the more
> defensive option. But in the interest of locking down
Quoting Daniel Vetter (2020-05-12 09:59:29)
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lockde
Am 12.05.20 um 10:59 schrieb Daniel Vetter:
But only for non-zero timeout, to avoid false positives.
One question here is whether the might_sleep should be unconditional,
or only for real timeouts. I'm not sure, so went with the more
defensive option. But in the interest of locking down the cros
On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-12 09:59:29)
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> > this explicit ann
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Quoting Daniel Vetter (2020-05-12 10:08:47)
> On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2020-05-12 09:59:29)
> > > Design is similar to the lockdep annotations for workers, but with
> > > some twists:
> > >
> > > - We use a read-lock for the execution
According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on tha
== Series Details ==
Series: dma-fence lockdep annotations
URL : https://patchwork.freedesktop.org/series/77178/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
761b03bd55bc dma-fence: add might_sleep annotation to _wait()
-:39: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by:
== Series Details ==
Series: dma-fence lockdep annotations
URL : https://patchwork.freedesktop.org/series/77178/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: dma-fence: add might_sleep annotation to _wait()
Okay!
Commit: dma-fence: basic lockdep ann
== Series Details ==
Series: dma-fence lockdep annotations
URL : https://patchwork.freedesktop.org/series/77178/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8467 -> Patchwork_17631
Summary
---
**FAILURE**
Seriou
Hi,
This includes support for ppgtt update by LRI command which gvt
replaces by shadow ppgtt, another small optimization for shadow
ctx and one workload destroy cleanup.
Thanks
--
The following changes since commit fb55c735522352704c35d899d0b253453cf0e799:
drm/i915/gvt: skip populate shadow
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev11)
URL : https://patchwork.freedesktop.org/series/74739/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d3cd77d67aae drm/i915: Decouple cdclk calculation from modeset checks
65be6d7302db drm/i915: E
On 12/05/2020 09:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-12 09:41:01)
On 11/05/2020 08:57, Chris Wilson wrote:
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrum
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK (rev11)
URL : https://patchwork.freedesktop.org/series/74739/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8467 -> Patchwork_17632
Summary
---
Quoting Tvrtko Ursulin (2020-05-12 11:12:23)
>
> On 12/05/2020 09:49, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-12 09:41:01)
> >> On 11/05/2020 08:57, Chris Wilson wrote:
> >>> The second try at staging the transfer of the breadcrumb. In part one,
> >>> we realised we could not simpl
Chris Wilson writes:
> i915_gem_evict_something() is charged with finding a slot within the GTT
> that we may reuse. Since our goal is not to stall, we first look for a
> slot that only overlaps idle vma. To this end, on the first pass we move
> any active vma to the end of the search list. Howev
Quoting Mika Kuoppala (2020-05-12 11:39:31)
> Chris Wilson writes:
>
> > i915_gem_evict_something() is charged with finding a slot within the GTT
> > that we may reuse. Since our goal is not to stall, we first look for a
> > slot that only overlaps idle vma. To this end, on the first pass we move
Checked on skl+ before sending, older platforms now failing because of ddb_size
== 0 warn..
Need to fix for older platforms as well..
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From:
On Thu, May 07, 2020 at 05:44:58PM +0300, Stanislav Lisovskiy wrote:
> For future Gen12 SAGV implementation we need to
> seemlessly alter wm levels calculated, depending
> on whether we are allowed to enable SAGV or not.
>
> So this accessor will give additional flexibility
> to do that.
>
> Curr
On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> Seems that only skl needs to have SAGV turned off
> for multipipe scenarios, so lets do it this way.
It doesn't afaics. It's just someone added the check for some random
reason. So this should be reworded a bit. Also this isn't
On Thu, May 07, 2020 at 05:44:59PM +0300, Stanislav Lisovskiy wrote:
> Introduce platform dependent SAGV checking in
> combination with bandwidth state pipe SAGV mask.
>
> This is preparation to adding TGL support, which
> requires different way of SAGV checking.
>
> v2, v3, v4, v5, v6: Fix rebas
On Thu, May 07, 2020 at 05:45:01PM +0300, Stanislav Lisovskiy wrote:
> Starting from TGL we need to have a separate wm0
> values for SAGV and non-SAGV which affects
> how calculations are done.
>
> v2: Remove long lines
> v3: Removed COLOR_PLANE enum references
> v4, v5, v6: Fixed rebase conflict
On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> > Seems that only skl needs to have SAGV turned off
> > for multipipe scenarios, so lets do it this way.
>
> It doesn't afaics. It's just someone added the check
On Tue, May 12, 2020 at 5:00 AM Daniel Vetter wrote:
>
> ...
>
> I think it's time to stop this little exercise.
>
> The lockdep splat, for the record:
>
> [ 132.583381] ==
> [ 132.584091] WARNING: possible circular locking dependency detected
On Tue, May 12, 2020 at 03:03:26PM +0300, Ville Syrjälä wrote:
> On Thu, May 07, 2020 at 05:45:01PM +0300, Stanislav Lisovskiy wrote:
> > Starting from TGL we need to have a separate wm0
> > values for SAGV and non-SAGV which affects
> > how calculations are done.
> >
> > v2: Remove long lines
> >
On Tue, May 12, 2020 at 09:09:52AM -0300, Jason Gunthorpe wrote:
> On Tue, May 12, 2020 at 10:59:29AM +0200, Daniel Vetter wrote:
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 6802125349fb..d5c0fd2efc70 100644
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -110,
On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> On Tue, May 12, 2020 at 5:00 AM Daniel Vetter wrote:
> >
> > ...
> >
> > I think it's time to stop this little exercise.
> >
> > The lockdep splat, for the record:
> >
> > [ 132.583381] ===
On Tue, May 12, 2020 at 03:44:06PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> > On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> > > Seems that only skl needs to have SAGV turned off
> > > for multipipe scenarios, so l
On Tue, May 12, 2020 at 03:52:27PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 03:03:26PM +0300, Ville Syrjälä wrote:
> > On Thu, May 07, 2020 at 05:45:01PM +0300, Stanislav Lisovskiy wrote:
> > > Starting from TGL we need to have a separate wm0
> > > values for SAGV and non-SAGV w
On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> > On Tue, May 12, 2020 at 5:00 AM Daniel Vetter
> > wrote:
> > >
> > > ...
> > >
> > > I think it's time to stop this little exercise.
> > >
> > > The lockdep splat, for the r
On Tue, May 12, 2020 at 03:44:06PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> > On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> > > Seems that only skl needs to have SAGV turned off
> > > for multipipe scenarios, so l
On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> > > On Tue, May 12, 2020 at 5:00 AM Daniel Vetter
> > > wrote:
> > > >
> > > > ...
> > > >
> > > > I think it's ti
On Tue, May 12, 2020 at 04:10:46PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 03:52:27PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 03:03:26PM +0300, Ville Syrjälä wrote:
> > > On Thu, May 07, 2020 at 05:45:01PM +0300, Stanislav Lisovskiy wrote:
> > > > Starting from
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we
removed it from the
On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote:
> >
> > On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
> > >
> > > On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> > > > On Tue, May 12, 2020 at 5:00 AM Daniel Vette
On Tue, May 12, 2020 at 04:14:33PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 03:44:06PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> > > On Thu, May 07, 2020 at 05:45:00PM +0300, Stanislav Lisovskiy wrote:
> > > > Seems that onl
On Tue, May 12, 2020 at 04:17:34PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 04:10:46PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 03:52:27PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 03:03:26PM +0300, Ville Syrjälä wrote:
> > > > On Thu, May 0
On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote:
> > >
> > > On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, May 12, 2020 at 08:54:45AM -0400, Ale
On Tue, May 12, 2020 at 04:38:21PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 04:17:34PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 04:10:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 12, 2020 at 03:52:27PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 04:41:26PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 04:38:21PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 04:17:34PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 04:10:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 04:50:46PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 04:41:26PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 04:38:21PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 12, 2020 at 04:17:34PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 1
Some tests may need to take care of closing all device file descriptors
even on subtest failure. For example, if a test would like to
effectively unload the driver module after a subtest failure, that
wouldn't be possible if any device file descriptors were kept open.
That may happen if the subtes
== Series Details ==
Series: drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker
URL : https://patchwork.freedesktop.org/series/77191/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8470 -> Patchwork_17633
Summary
--
On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
> >
> > On Tue, May 12, 2020 at 9:17 AM Daniel Vetter
> > wrote:
> > >
> > > On Tue, May 12, 2020 at 3:12 PM Alex Deucher
> > > wrote:
> > > >
> > > > On Tue, May 12, 2020 at 8:58 AM D
Daniele Ceraolo Spurio writes:
> On 5/7/20 7:20 AM, Mika Kuoppala wrote:
>> All engines, exception being blitter as it does not
>> care about the form, can access compressed surfaces.
>>
>> So we need to add forced aux table invalidates
>> for those engines.
>>
>> v2: virtual instance masking (
On Tue, May 12, 2020 at 04:59:19PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 04:50:46PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 04:41:26PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 04:38:21PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 05:32:21PM +0300, Ville Syrjälä wrote:
> On Tue, May 12, 2020 at 04:59:19PM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 12, 2020 at 04:50:46PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 12, 2020 at 04:41:26PM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 1
On Tue, May 12, 2020 at 06:04:45PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 05:32:21PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 04:59:19PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 04:50:46PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 1
On 12/05/2020 14:22, Chris Wilson wrote:
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the
On Tue, May 12, 2020 at 04:26:53PM +0300, Lisovskiy, Stanislav wrote:
> On Tue, May 12, 2020 at 04:14:33PM +0300, Ville Syrjälä wrote:
> > On Tue, May 12, 2020 at 03:44:06PM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 12, 2020 at 02:39:25PM +0300, Ville Syrjälä wrote:
> > > > On Thu, May 0
Quoting Tvrtko Ursulin (2020-05-12 16:17:30)
>
> On 12/05/2020 14:22, Chris Wilson wrote:
> > The second try at staging the transfer of the breadcrumb. In part one,
> > we realised we could not simply move to the second engine as we were
> > only holding the breadcrumb lock on the first. So in com
Hui what? Of hand that doesn't looks correct to me.
Why the heck should this be an atomic context? If that's correct
allocating memory is the least of the problems we have.
Regards,
Christian.
Am 12.05.20 um 10:59 schrieb Daniel Vetter:
My dma-fence lockdep annotations caught an inversion be
On Thu, May 07, 2020 at 05:45:02PM +0300, Stanislav Lisovskiy wrote:
> According to BSpec 53998, we should try to
> restrict qgv points, which can't provide
> enough bandwidth for desired display configuration.
>
> Currently we are just comparing against all of
> those and take minimum(worst case)
On 12/05/2020 16:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-12 16:17:30)
On 12/05/2020 14:22, Chris Wilson wrote:
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcru
Quoting Janusz Krzysztofik (2020-05-12 15:07:36)
> Some tests may need to take care of closing all device file descriptors
> even on subtest failure. For example, if a test would like to
> effectively unload the driver module after a subtest failure, that
> wouldn't be possible if any device file
On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
> > >
> > > On Tue, May 12, 2020 at 9:17 AM Daniel Vetter
> > > wrote:
> > > >
> > > > On Tue, May 12, 2020 at 3:12 PM Alex D
On Tue, 2020-05-12 at 06:17 +, Lee, Shawn C wrote:
> On Thu, May 11, 2020, Ville Syrjälä wrote:
> > On Thu, May 07, 2020 at 06:46:17PM -0400, Lyude Paul wrote:
> > > On Thu, 2020-04-30 at 02:37 +, Lee, Shawn C wrote:
> > > > On Sat, 2020-04-25, Lyude Paul wrote:
> > > > > Hi! Sorry this too
Last user removed, remove the definition of gem_test_engine().
Signed-off-by: Chris Wilson
---
lib/i915/gem_submission.c | 49 ---
lib/i915/gem_submission.h | 2 --
2 files changed, 51 deletions(-)
diff --git a/lib/i915/gem_submission.c b/lib/i915/gem_submis
After triggering the reset, we would ping the engines with a no-op. But
we already validate the reset, so this would seem superfluous.
Signed-off-by: Chris Wilson
---
tests/i915/gem_eio.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
i
On Tue, May 12, 2020 at 5:56 PM Christian König
wrote:
>
> Hui what? Of hand that doesn't looks correct to me.
It's not GFP_ATOMIC, it's just that GFP_ATOMIC is the only shotgun we
have to avoid direct reclaim. And direct reclaim might need to call
into your mmu notifier, which might need to wait
Quoting Tvrtko Ursulin (2020-05-12 17:07:23)
>
> On 12/05/2020 16:52, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-12 16:17:30)
> >>
> >> On 12/05/2020 14:22, Chris Wilson wrote:
> >>> - spin_lock(&old->breadcrumbs.irq_lock);
> >>> - if (!list_empty(&ve->context.signal_link)) {
An obscure and very dated subtest, it's even covered by the other
subtests -- if the kernel still worked in any fashion assumed by the
test.
Signed-off-by: Chris Wilson
---
tests/i915/i915_pm_rpm.c | 12
1 file changed, 12 deletions(-)
diff --git a/tests/i915/i915_pm_rpm.c b/tests/
On Tue, May 12, 2020 at 6:20 PM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 5:56 PM Christian König
> wrote:
> >
> > Hui what? Of hand that doesn't looks correct to me.
>
> It's not GFP_ATOMIC, it's just that GFP_ATOMIC is the only shotgun we
> have to avoid direct reclaim. And direct reclai
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we
removed it from the
Our 'headless' subtest requires fairly precise measurements to determine
the impact of the dmc upon request latency. The test cannot be effective
if we cannot execute requests quickly, so add a very short pre-pass to
check the test requirements. For this we want to specify the baseline
measurement
== Series Details ==
Series: drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker
URL : https://patchwork.freedesktop.org/series/77191/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8470_full -> Patchwork_17633_full
On 5/1/20 9:57 PM, Matt Roper wrote:
Reads of multicast registers give the value associated with
slice/subslice 0 by default unless we manually steer the reads to a
different slice/subslice. If slice/subslice 0 are fused off in hardware,
performing unsteered reads of multicast registers will
Ah!
So we can't allocate memory while scheduling anything because it could
be that memory reclaim is waiting for the scheduler to finish pushing
things to the hardware, right?
Indeed a nice problem, haven't noticed that one.
Christian.
Am 12.05.20 um 18:27 schrieb Daniel Vetter:
On Tue, Ma
== Series Details ==
Series: drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker (rev2)
URL : https://patchwork.freedesktop.org/series/77191/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8470 -> Patchwork_17634
Sum
From: Ville Syrjälä
Use max() instead of hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm
From: Ville Syrjälä
cpt/ppt support pre-emphasis level 3. Let's actually declare
support for it, instead of clamping things to level 2.
Also tweak the if-ladder in intel_dp_voltage_max() to match
intel_dp_pre_emphasis_max() to make it easier to compare them.
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
These vswing/preemph fixes were previously posted as part of
the link training crtc_state plumbing series, but since
that potentially had some odd behaviour in ci I'm sending
these separately. Hopefully nothing odd pops up with just these...
Ville Syrjälä (7):
drm/i915: Fix
From: Ville Syrjälä
The DP spec says:
"The transmitter shall support at least three levels of voltage
swing (Levels 0, 1, and 2).
If only three levels of voltage swing are supported (VOLTAGE
SWING SET field (bits 1:0) are programmed to 10 (Level 2)),
this bit shall be set to 1, and cleared i
From: Ville Syrjälä
Different platforms have different max vswing/preemph settings.
Turn that into a pair vfuncs so we can decouple intel_dp.c and
intel_ddi.c further.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 21 ++
drivers/gpu/drm/i915/display/intel
From: Ville Syrjälä
IBX supports vswing level 3 and pre-emphasis level 3. Don't
limit it to level 2 for those.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.
From: Ville Syrjälä
The DP spec says:
"When the combination of the requested pre-emphasis level and
voltage swing exceeds the capability of a DPTX, the DPTX shall
set the pre-emphasis level according to the request and use the
highest voltage swing it can output with the given pre-emphasis lev
From: Ville Syrjälä
According to the DP spec supporting vswing 1 + preemph 2 is
mandatory. We don't have the hw settings for that though. In
order to pretend to follow the DP spec let's just select
vswing 0 + preemph 2 in this case (the DP spec says to use
the requested preemph in preference to t
This w/a is fixed in B0 stepping and needs to be restricted for
A0 stepping only.
Bspec: 33451
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 11 +++
drivers/gpu/drm/i915/i915_drv.h | 5 +
2 files changed, 12 insertions(+), 4 deletio
The second try at staging the transfer of the breadcrumb. In part one,
we realised we could not simply move to the second engine as we were
only holding the breadcrumb lock on the first. So in commit 6c81e21a4742
("drm/i915/gt: Stage the transfer of the virtual breadcrumb"), we
removed it from the
1 - 100 of 121 matches
Mail list logo
