On Thu, May 28, 2020 at 01:03:53PM -0700, José Roberto de Souza wrote:
> It will be programed right before the link training, so no need to do
> it twice.
> It will not strictly follow BSpec sequences but most of this sequences
> are not matching anyways.
>
> Signed-off-by: José Roberto de Souza
On Thu, May 28, 2020 at 11:54 PM Luben Tuikov wrote:
>
> On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> > 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 annotati
On 5/28/2020 11:17 PM, Paulo Zanoni wrote:
Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu:
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flip
On Thu, May 28, 2020 at 10:58:52PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> > On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > While the current locking/serialization of the glo
On Fri, 29 May 2020, Al Viro wrote:
> Low-hanging fruit in i915 uaccess-related stuff.
> There's some subtler stuff remaining after that; these
> are the simple ones.
Please Cc: intel-gfx@lists.freedesktop.org for i915 changes.
Also added Chris who I believe will be able to best review the
On 4/20/2020 11:28 PM, Paulo Zanoni wrote:
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
Support added only for async flips on primary plane.
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is
On 4/24/2020 11:16 PM, Paulo Zanoni wrote:
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
Make the commit call blocking in case of async flips
so that there is no delay in completing the flip.
I'm trying to understand the code. Can you please elaborate more here
in this commit mes
On 4/20/2020 11:34 PM, Paulo Zanoni wrote:
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
Enable asynchronous flips in i915 for gen9+ platforms.
v2: -Async flip enablement should be a stand alone patch (Paulo)
... and at the very end of the series.
If someone is bisecting the Ker
On 4/24/2020 11:14 PM, Paulo Zanoni wrote:
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called befo
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial
submission
URL : https://patchwork.freedesktop.org/series/77762/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8549_full -> Patchwork_17809_full
=
== Series Details ==
Series: drm/i915/gt: Start timeslice on partial submission
URL : https://patchwork.freedesktop.org/series/77761/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8549_full -> Patchwork_17808_full
Summary
-
Hi Tom,
On 2019-12-21 8:03 a.m., Tom Murphy wrote:
> This patchset converts the intel iommu driver to the dma-iommu api.
Just wanted to note that I've rebased your series on recent kernels and
have done some testing on my old Sandybridge machine (without the DO NOT
MERGE patch) and have found no
== Series Details ==
Series: drm/i915: Track i915_vma with its own reference counter
URL : https://patchwork.freedesktop.org/series/77763/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8550 -> Patchwork_17810
Summary
--
== Series Details ==
Series: drm/i915: Track i915_vma with its own reference counter
URL : https://patchwork.freedesktop.org/series/77763/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
55980f47bd93 drm/i915: Track i915_vma with its own reference counter
-:2210: CHECK:UNCOMMENTE
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial
submission
URL : https://patchwork.freedesktop.org/series/77762/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17809
===
== Series Details ==
Series: series starting with [1/4] drm/i915/display/hsw+: Do not program the
same vswing entry twice
URL : https://patchwork.freedesktop.org/series/77758/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8549_full -> Patchwork_17806_full
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial
submission
URL : https://patchwork.freedesktop.org/series/77762/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be check
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial
submission
URL : https://patchwork.freedesktop.org/series/77762/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dc44da7a88e6 drm/i915/gt: Start timeslice on partial submission
af3a
== Series Details ==
Series: drm/i915/gt: Start timeslice on partial submission
URL : https://patchwork.freedesktop.org/series/77761/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17808
Summary
---
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5472:
drivers/gpu/drm/i915/gt/selftest_lrc.c: In function 'live_timeslice_nopreempt':
drivers/gpu/drm/i915/gt/selftest_lrc.c:1
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17798_full
Summary
---
*
On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> 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 lock
If the real target for a proxy fence is known at the time we are
attaching our awaits, use the real target in preference to hooking up to
the proxy. If use the real target instead, we can optimize the awaits,
e.g. if it along the same engine, we can order the submission and avoid
the wait-for-compl
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
If we get interrupted in the middle of chaining up the relocation
entries, we will fail to submit the relocation batch. However, we will
report having already completed some of the relocations, and so the
reloc.presumed_offset will no longer match the batch contents, causing
confusion and invalid f
Asynchronous waits and signaling form a traditional semaphore with all
the usual ordering problems with taking multiple locks. If we want to
add more than one wait on a shared resource by the GPU, we must ensure
that all the associated timelines are advanced atomically, ergo we must
lock all the ti
Since we have reduced the relocations paths to just use the async GPU,
we can lift the request allocation to the start of the relocations.
Knowing that we use one request for all relocations will simplify
tracking the relocation fence.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_ge
If the execbuf is interrupted after building the cmdparser pipeline, and
before we commit to submitting the request to HW, we would attempt to
clean up the cmdparser early. While we held active references to the vma
being parsed and constructed, we did not hold an active reference for
the buffer po
We may choose to only submit ELSP[0], even though we have sufficient
requests to fill the whole ELSP. Normally, we only start timeslicing if
we fill more than one port, but in this case we need to start
timeslicing for the queue that we choose not to submit.
Signed-off-by: Chris Wilson
Cc: Tvrtko
Although we may chide userspace for reusing the same batches
concurrently from multiple threads, at the same time we must be very
careful to only execute the batch and its relocations as supplied by the
user. If we are not careful, we may allow another thread to rewrite the
current batch with its o
Over the next couple of patches, we will want to lock all the modified
vma for relocation processing under a single ww_mutex. We neither want
to have to include the vma that are skipped (due to no modifications
required) nor do we want those to be marked as written too. So separate
out the reloc va
Reduce the 3 relocation patches down to the single path that accommodates
all. The primary motivation for this is to guard the relocations with a
natural fence (derived from the i915_request used to write the
relocation from the GPU).
The tradeoff in using async gpu relocations is that it increase
One more list iterator variant, for when we want to unwind from inside
one list iterator with the intention of restarting from the current
entry as the new head of the list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_utils.h | 6 ++
1 file changed, 6 insertions(+)
diff --git
Chris Wilson writes:
> We may choose to only submit ELSP[0], even though we have sufficient
> requests to fill the whole ELSP. Normally, we only start timeslicing if
> we fill more than one port, but in this case we need to start
> timeslicing for the queue that we choose not to submit.
If this
We may choose to only submit ELSP[0], even though we have sufficient
requests to fill the whole ELSP. Normally, we only start timeslicing if
we fill more than one port, but in this case we need to start
timeslicing for the queue that we choose not to submit.
Signed-off-by: Chris Wilson
Cc: Tvrtko
== Series Details ==
Series: drm/i915: Special handling for bonded requests (rev2)
URL : https://patchwork.freedesktop.org/series/77688/
State : failure
== Summary ==
Applying: drm/i915: Special handling for bonded requests
error: sha1 information is lacking or useless
(drivers/gpu/drm/i915/g
== Series Details ==
Series: series starting with [1/4] drm/i915/display/hsw+: Do not program the
same vswing entry twice
URL : https://patchwork.freedesktop.org/series/77758/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17806
==
Randomly submit a paired spinner and its cancellation as a bonded
(submit fence) pair. Apply congestion to the engine with more bonded
pairs to see if the execution order fails. If we prevent a cancellation
from running, then the spinner will remain spinning forever.
v2: Test both immediate submis
Quoting Tvrtko Ursulin (2020-05-28 11:20:07)
>
> On 28/05/2020 10:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
> >> +static void
> >> +mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
> >> +{
> >> + /*
> >> +* Give (temporary) special
== Series Details ==
Series: series starting with [1/4] drm/i915/display/hsw+: Do not program the
same vswing entry twice
URL : https://patchwork.freedesktop.org/series/77758/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit w
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath". (rev2)
URL : https://patchwork.freedesktop.org/series/77472/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17805
==
HOBL means hours of battery life, it is a power-saving feature
were supported motherboards can use a special voltage swing table
that uses less power.
So here parsing the VBT to check if this feature is supported.
While at it already added the VRR parameter too.
BSpec: 20150
Signed-off-by: José R
It will be programed right before the link training, so no need to do
it twice.
It will not strictly follow BSpec sequences but most of this sequences
are not matching anyways.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 19 ---
1 file chan
HOBL worked in my TGL RVP even without the necessary HW support, also
it worked in more than half of the TGL machines in CI so it is worthy
to enable it by default.
Even if link training fails with this new vswing table it will only
cause one additional link training, that is worthy the try to get
Hours Of Battery Life is a new GEN12+ power-saving feature that allows
supported motherboards to use a special voltage swing table for eDP
panels that uses less power.
So here if supported by HW, OEM will set it in VBT and i915 will try
to train link with HOBL vswing table if link training fails i
On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > While the current locking/serialization of the global state
> > suffices for protecting the obj->state access and the actual
> > h
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath". (rev2)
URL : https://patchwork.freedesktop.org/series/77472/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath". (rev2)
URL : https://patchwork.freedesktop.org/series/77472/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d9487c8b0b0d Revert "drm/i915/gem: Drop relocation slowpath".
-
On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> While the current locking/serialization of the global state
> suffices for protecting the obj->state access and the actual
> hardware reprogramming, we do have a problem with accessing
> the old/new states du
Hi Dave and Daniel,
Here goes drm-intel-fixes-2020-05-28:
couple compilation fixes for gcc-9+, and couple fixes for timeslicing,
one to respect I915_REQUEST_NOPREEMPT flag and another to incorporate
virtual engine into timeslicing.
Thanks,
Rodrigo.
The following changes since commit 9cb1fd0efd1
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17798_full
Summary
---
*
== Series Details ==
Series: drm/i915/gt: Restore both GGTT bindings on resume
URL : https://patchwork.freedesktop.org/series/77750/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8547_full -> Patchwork_17804_full
Summary
--
== Series Details ==
Series: drm/i915/gem: Mark the buffer pool as active for the cmdparser
URL : https://patchwork.freedesktop.org/series/77749/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8547_full -> Patchwork_17803_full
===
Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu:
> Without async flip support in the kernel, fullscreen apps where game
> resolution is equal to the screen resolution, must perform an extra blit
> per frame prior to flipping.
>
> Asynchronous page flips will also boost the FPS of Mesa benc
Quoting Chris Wilson (2020-05-28 17:50:55)
> Quoting Mika Kuoppala (2020-05-28 17:23:18)
> > Chris Wilson writes:
> >
> > > If the ring submission is stalled on an external request, nothing can be
> > > submitted, not even the heartbeat in the kernel context. Since nothing
> > > is running, reset
Quoting Mika Kuoppala (2020-05-28 17:23:18)
> Chris Wilson writes:
>
> > If the ring submission is stalled on an external request, nothing can be
> > submitted, not even the heartbeat in the kernel context. Since nothing
> > is running, resetting the engine/device does not unblock the system and
Chris Wilson writes:
> If the ring submission is stalled on an external request, nothing can be
> submitted, not even the heartbeat in the kernel context. Since nothing
> is running, resetting the engine/device does not unblock the system and
> is pointless. We can see if the heartbeat is suppose
== Series Details ==
Series: drm/i915/gt: Restore both GGTT bindings on resume
URL : https://patchwork.freedesktop.org/series/77750/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8547 -> Patchwork_17804
Summary
---
*
== Series Details ==
Series: drm/i915/gem: Mark the buffer pool as active for the cmdparser
URL : https://patchwork.freedesktop.org/series/77749/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8547 -> Patchwork_17803
Summary
On Thu, 28 May 2020 at 09:24, Chris Wilson wrote:
>
> Across suspend/resume, we clear the entire GGTT and rebuild from
> scratch. In particular, we only preserve the global entries for use by
> the HW, and delay reinstating the local binds until required by the
> user. This means that we can evict
We should be able to skip restoing LOCAL (user) binds within the GGTT on
resume and let them be restored upon demand. However, our consistency
checks demand that the bind flags match the node state, and we cannot
simply clear the flags, we need to evict as well. For now, make sure we
restore the bi
On Thu, 28 May 2020 at 09:24, Chris Wilson wrote:
>
> We should be able to skip restoing LOCAL (user) binds within the GGTT on
> resume and let them be restored upon demand. However, our consistency
> checks demand that the bind flags match the node state, and we cannot
> simply clear the flags we
If the execbuf is interrupted after building the cmdparser pipeline, and
before we commit to submitting the request to HW, we would attempt to
clean up the cmdparser early. While we held active references to the vma
being parsed and constructed, we did not hold an active reference for
the buffer po
Hi Dave & Daniel,
Two bigger fixes to corner case kernel access faults
and three workload scheduling fixups this week.
CI_DINF_191 at:
https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html?
I got gvt-next-fixes pull today, I'll pull it next week so it
has time to run through CI
On Thu, May 28, 2020 at 3:37 PM Thomas Hellström (Intel)
wrote:
>
> On 2020-05-12 10:59, Daniel Vetter wrote:
> > 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
Hi Chris,
On Thu, 2020-05-28 at 14:41 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2020-05-28 14:34:42)
> > On 28/05/2020 13:10, Janusz Krzysztofik wrote:
> > > Hi Tvrtko,
> > >
> > > On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> > > > On 18/05/2020 19:17, Janusz Krzysztofik
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Restore both GGTT bindings on
resume
URL : https://patchwork.freedesktop.org/series/77734/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8546_full -> Patchwork_17802_full
On 2020-05-12 10:59, Daniel Vetter wrote:
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 go
Quoting Tvrtko Ursulin (2020-05-28 14:34:42)
>
> On 28/05/2020 13:10, Janusz Krzysztofik wrote:
> > Hi Tvrtko,
> >
> > On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> >> On 18/05/2020 19:17, Janusz Krzysztofik wrote:
> >>> Contexts associated with open device file descriptors together
On 28/05/2020 13:10, Janusz Krzysztofik wrote:
Hi Tvrtko,
On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
On 18/05/2020 19:17, Janusz Krzysztofik wrote:
Contexts associated with open device file descriptors together with
their assigned address spaces are now closed on device file cl
On 5/15/20 7:09 PM, Valentin Schneider wrote:
On 15/05/20 01:48, Francisco Jerez wrote:
Valentin Schneider writes:
(+Lukasz)
On 11/05/20 22:01, Francisco Jerez wrote:
What I'm missing is an explanation for why this isn't using the
infrastructure that was build for these kinds of things?
> -Original Message-
> From: Greg KH
> Sent: Wednesday, May 27, 2020 9:02 PM
> To: Ashwin H
> Cc: x...@kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; sta...@kernel.org;
> Srivatsa Bhat ; sriva...@csail.mit.edu;
> rost...@
> -Original Message-
> From: Ashwin H
> Sent: Thursday, May 28, 2020 1:01 PM
> To: Greg KH
> Cc: x...@kernel.org; dri-de...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; sta...@kernel.org;
> Srivatsa Bhat ; sriva...@csail.mit.edu;
> rost...@go
Hi
Am 27.05.20 um 21:34 schrieb Daniel Vetter:
> On Wed, May 27, 2020 at 8:32 PM Thomas Zimmermann wrote:
>>
>> Hi Daniel,
>>
>> what's your plan for this patch set? I'd need this patch for the udl
>> shmem cleanup.
>
> I was pinging some people for a tested-by, I kinda don't want to push
> this
Hi Tvrtko,
On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> On 18/05/2020 19:17, Janusz Krzysztofik wrote:
> > Contexts associated with open device file descriptors together with
> > their assigned address spaces are now closed on device file close. On
>
> i915_gem_driver_remove looks
Hi Dave, Daniel,
Here's this week drm-misc-fixes PR.
Thanks!
Maxime
drm-misc-fixes-2020-05-28:
Two ingenic fixes, one for a wrong cast, the other for a typo in a
comparison
The following changes since commit c54a8f1f329197d83d941ad84c4aa38bf282cbbd:
drm/meson: pm resume add return errno branc
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77729/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8545_full -> Patchwork_17800_full
===
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Restore both GGTT bindings on
resume
URL : https://patchwork.freedesktop.org/series/77734/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8546 -> Patchwork_17802
==
On 28/05/2020 10:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
+static void
+mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
+{
+ /*
+* Give (temporary) special meaning to a pair requests with requested
+* aligned start along
On 18/05/2020 19:17, Janusz Krzysztofik wrote:
Contexts associated with open device file descriptors together with
their assigned address spaces are now closed on device file close. On
i915_gem_driver_remove looks like module unload to me, not device file
close. So..
address space closur
Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
> +static void
> +mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
> +{
> + /*
> +* Give (temporary) special meaning to a pair requests with requested
> +* aligned start along the video engines.
> +*
>
Hi Michał,
On Wed, 2020-05-27 at 21:15 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-05-18 20:17:20)
> > UC firmware is stored in a GEM object. Clean it up on driver remove to
>^ double whitespace
That's a result of my addiction to an o
On Wed, 2020-05-27 at 21:12 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-05-18 20:17:19)
> > GGTT including its scratch page is not cleaned up until driver release.
> > Since DMA mappings still exist before scratch page cleanup, unmapping
> > them on last device close after the
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev3)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17799_full
Summary
---
On 27/05/2020 17:24, Chris Wilson wrote:
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pendin
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77730/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8545 -> Patchwork_17801
===
On Thu, May 28, 2020 at 10:19:46AM +0200, Stefan Agner wrote:
> On 2020-05-28 10:06, Daniel Vetter wrote:
> > On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote:
> >>
> >> Hi Daniel,
> >>
> >> On 2020-05-28 07:46, Daniel Vetter wrote:
> >> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter
Across suspend/resume, we clear the entire GGTT and rebuild from
scratch. In particular, we only preserve the global entries for use by
the HW, and delay reinstating the local binds until required by the
user. This means that we can evict and recover any local binds in the
global GTT, saving any ti
We should be able to skip restoing LOCAL (user) binds within the GGTT on
resume and let them be restored upon demand. However, our consistency
checks demand that the bind flags match the node state, and we cannot
simply clear the flags we need to evict as well. For now, make sure we
restore the bin
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77730/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
006567321620 drm/i915/gt: Prevent timeslicing into unpreempt
On 2020-05-28 10:06, Daniel Vetter wrote:
> On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote:
>>
>> Hi Daniel,
>>
>> On 2020-05-28 07:46, Daniel Vetter wrote:
>> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
>> >> mxsfb has vblank support, is atomic, but doesn't call
>> >> drm
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8545 -> Patchwork_17800
=
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17798_full
Summary
---
*
On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote:
>
> Hi Daniel,
>
> On 2020-05-28 07:46, Daniel Vetter wrote:
> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
> >> mxsfb has vblank support, is atomic, but doesn't call
> >> drm_crtc_vblank_on/off as it should. Not good.
> >>
>
Hi Daniel,
On 2020-05-28 07:46, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote:
>> mxsfb has vblank support, is atomic, but doesn't call
>> drm_crtc_vblank_on/off as it should. Not good.
>>
>> With my next patch to add the drm_crtc_vblank_reset to helpers this
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77729/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won'
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77729/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
55a37e373e5e drm/i915/gt: Prevent timeslicing into unpreem
Hi Jani,
Thanks for the comments and suggestions. Please find my response inline.
On 5/27/2020 7:44 PM, Jani Nikula wrote:
On Wed, 27 May 2020, Ankit Nautiyal wrote:
As per the current HDCP design, the driver selects the highest
version of HDCP that can be used to satisfy the content-protecti
On 5/27/2020 7:48 PM, Jani Nikula wrote:
On Wed, 27 May 2020, Ankit Nautiyal wrote:
For testing and debugging each HDCP version separately, a debugfs
entry for requesting a specific version is required. The vesion
requested via debugfs needs to be stored in hdcp structure. This can
then be c
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to
1 - 100 of 113 matches
Mail list logo
