On Thu, Jul 02, 2020 at 12:24:44AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix the old vs. new epoch counter check during hotplug
> detect
> URL : https://patchwork.freedesktop.org/series/79006/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_
== Series Details ==
Series: drm/i915: Fix the old vs. new epoch counter check during hotplug detect
URL : https://patchwork.freedesktop.org/series/79006/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8688_full -> Patchwork_18060_full
==
Hi Dave and Daniel,
here's the PR for the current drm-misc-fixes.
Best regards
Thomas
drm-misc-fixes-2020-07-02:
* dma-buf: fix a use-after-free bug
* sun4i: remove HPD polling
The following changes since commit dc5bdb68b5b369d5bc7d1de96fa64cc1737a6320:
drm/fb-helper: Fix vt restore (2020-
== Series Details ==
Series: Introduce DG1 (rev4)
URL : https://patchwork.freedesktop.org/series/77496/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dbe37e6fd3b8 drm/i915: Add has_master_unit_irq flag
a57df38e220b drm/i915/dg1: add initial DG-1 definitions
-:41: CHECK:MACRO_AR
== Series Details ==
Series: Introduce DG1 (rev4)
URL : https://patchwork.freedesktop.org/series/77496/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display
Re-reported.
-Original Message-
From: Imre Deak
Sent: Thursday, July 2, 2020 9:31 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Fix the old vs. new epoch
counter check during hotplug detect
On Thu, Jul 02, 2020 at 12:
== Series Details ==
Series: Introduce DG1 (rev4)
URL : https://patchwork.freedesktop.org/series/77496/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8691 -> Patchwork_18064
Summary
---
**SUCCESS**
No regressions
On 25/06/2020 15:43, Christian König wrote:
Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not tr
Am 02.07.20 um 10:26 schrieb Lionel Landwerlin:
On 25/06/2020 15:43, Christian König wrote:
Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:
This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.
This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bi
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, move the
waiting outside of the lock into the async binding pipeline.
Signed-off-by: Chris
Pull the GGTT binding for the secure batch dispatch into the common vma
pinning routine for execbuf, so that there is just a single central
place for all i915_vma_pin().
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 88 +++
1 file changed, 51 ins
Remove the stub i915_vma_pin() used for incrementally pining objects for
execbuf (under the severe restriction that they must not wait on a
resource as we may have already pinned it) and replace it with a
i915_vma_pin_inplace() that is only allowed to reclaim the currently
bound location for the vm
Rather than reuse the common ctx->mutex for locking the execbuffer LUT,
split it into its own lock to avoid being taken [as part of ctx->mutex]
at inappropriate times. In particular to avoid the inversion from taking
the timeline->mutex for the whole execbuf submission in the next patch.
Signed-of
As a prelude to the next step where we want to perform all the object
allocations together under the same lock, we first must delay the
i915_vma_pin() as that implicitly does the allocations for us, one by
one. As it only does the allocations one by one, it is not allowed to
wait/evict, whereas pul
As we allow for parallel threads to create vma instances in parallel,
and we only filter out the duplicates upon reacquiring the spinlock for
the rbtree, we have to free the loser of the constructors' race. When
freeing, we should also drop any resource references acquired for the
redundant vma.
F
Our timeline lock is our defence against a concurrent execbuf
interrupting our request construction. we need hold it throughout or,
for example, a second thread may interject a relocation request in
between our own relocation request and execution in the ring.
A second, major benefit, is that it a
Allocate a few dma fence context id that we can use to associate async work
[for the CPU] launched on behalf of this context. For extra fun, we allow
a configurable concurrency width.
A current example would be that we spawn an unbound worker for every
userptr get_pages. In the future, we wish to
Sometimes we have to be very careful not to allocate underneath a mutex
(or spinlock) and yet still want to track activity. Enter
i915_active_acquire_for_context(). This raises the activity counter on
i915_active prior to use and ensures that the fence-tree contains a slot
for the context.
Signed-
The GEM object is grossly overweight for the practicality of tracking
large numbers of individual pages, yet it is currently our only
abstraction for tracking DMA allocations. Since those allocations need
to be reserved upfront before an operation, and that we need to break
away from simple system
Reuse the ppgtt_bind_vma() for aliasing_ppgtt_bind_vma() so we can
reduce some code near-duplication. The catch is that we need to then
pass along the i915_address_space and not rely on vma->vm, as they
differ with the aliasing-ppgtt.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more freedom of workqueue ordering
during shutdow
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
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_utils.h | 6 ++
1 file changed,
We need to make the DMA allocations used for page directories to be
performed up front so that we can include those allocations in our
memory reservation pass. The downside is that we have to assume the
worst case, even before we know the final layout, and always allocate
enough page directories fo
In preparation for making eb_vma bigger and heavy to run inn parallel,
we need to stop apply an in-place swap() to reorder around ww_mutex
deadlocks. Keep the array intact and reorder the locks using a dedicated
list.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c
From: Maarten Lankhorst
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Chan
Rename the current list of unbound objects so that we can track of all
objects that we need to bind, as well as the list of currently unbound
[unprocessed] objects.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++---
1 file changed, 7 insertions(+)
Since we no longer always take struct_mutex around everything, and want
the freedom to create GEM objects, actually taking struct_mutex inside
the lock creation ends up pulling the mutex inside other looks. Since we
don't use generally use struct_mutex, we can relax the tainting.
Signed-off-by: Ch
It is reasonably common for userspace (even modern drivers like iris) to
reuse an active address for a new buffer. This would cause the
application to stall under its mutex (originally struct_mutex) until the
old batches were idle and it could synchronously remove the stale PTE.
However, we can que
The prospect of locking the entire submission sequence under a wide
ww_mutex re-imposes some key restrictions, in particular that we must
not call copy_(from|to)_user underneath the mutex (as the faulthandlers
themselves may need to take the ww_mutex). To satisfy this requirement,
we need to split
Pull the cmdparser allocations in to the reservation phase, and then
they are included in the common vma pinning pass.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 316 ++
1 file changed, 172 insertions(+), 144 deletions(-)
diff --git a/drivers
Acquire all the objects and their backing storage, and page directories,
as used by execbuf under a single common ww_mutex. Albeit we have to
restart the critical section a few times in order to handle various
restrictions (such as avoiding copy_(from|to)_user and mmap_sem).
Signed-off-by: Chris W
Currently, if an error is raised we always call the cleanup locally
[and skip the main work callback]. However, some future users may need
to take a mutex to cleanup and so we cannot immediately execute the
cleanup as we may still be in interrupt context.
With the execute-immediate flag, for most
On Thu, Jul 02, 2020 at 07:50:47AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix the old vs. new epoch counter check during hotplug
> detect
> URL : https://patchwork.freedesktop.org/series/79006/
> State : success
Thanks for the review and re-reporting, merged to dr
Quoting Souza, Jose (2020-07-02 00:24:19)
> On Wed, 2020-07-01 at 21:37 +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/dp: Correctly advertise HBR3 for GEN11+ (rev2)
> > URL : https://patchwork.freedesktop.org/series/61546/
> > State : success
> >
> > == Summary ==
>
We still need "Bump up CDCLK" workaround otherwise getting
underruns - however currently it blocks 8K as CDCLK = Pixel rate,
in 8K case would require CDCLK to be around 1 Ghz which is not
possible.
v2: - Convert to expression(max(min_cdclk, min(pixel_rate, max_cdclk))
(Ville Syrjälä)
- U
== Series Details ==
Series: series starting with [01/23] drm/i915: Drop vm.ref for duplicate vma on
construction
URL : https://patchwork.freedesktop.org/series/79037/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2b716a4a1108 drm/i915: Drop vm.ref for duplicate vma on constru
== Series Details ==
Series: series starting with [01/23] drm/i915: Drop vm.ref for duplicate vma on
construction
URL : https://patchwork.freedesktop.org/series/79037/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be
Hi, this seems to have been stuck on the list for a while now, how to
get it merged?
I've CC'd Paulo Matos who has tested it and found working. Paulo, you
might want to add a 'Tested-by' here.
On 19.3.2020 18.38, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Some new eDP panels don't like to
Chris Wilson writes:
> As we ensure that the heartbeat is reasonably fast (and should not
> block), move the heartbeat work into the system_highprio_wq to avoid
> having this essential task be blocked behind other slow work, such as
> our own retire_work_handler.
>
> References: https://gitlab.fr
Chris Wilson writes:
> If the driver get stuck holding the kernel timeline, we cannot issue a
> heartbeat and so fail to discover that the driver is indeed stuck and do
> not issue a GPU reset (which would hopefully unstick the driver!).
> Switch to using a trylock so that we can query if the hea
== Series Details ==
Series: series starting with [01/23] drm/i915: Drop vm.ref for duplicate vma on
construction
URL : https://patchwork.freedesktop.org/series/79037/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8692 -> Patchwork_18065
==
On Wed, Jun 24, 2020 at 9:25 AM Daniel Vetter wrote:
>
> On Fri, Jun 12, 2020 at 06:00:51PM +0200, Daniel Vetter wrote:
> > Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> > which means vblank state isn't ill-defined and fail-y at driver load
> > before the first modeset
If the driver gets stuck holding the kernel timeline, we cannot issue a
heartbeat and so fail to discover that the driver is indeed stuck and do
not issue a GPU reset (which would hopefully unstick the driver!).
Switch to using a trylock so that we can query if the heartbeat's
timeline mutex is loc
As we ensure that the heartbeat is reasonably fast (and should not
block), move the heartbeat work into the system_highpri_wq to avoid
having this essential task be blocked behind other slow work, such as
our own retire_work_handler.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/21
On Thu, 2020-07-02 at 11:41 +0200, Daniel Vetter wrote:
> On Wed, Jun 24, 2020 at 9:25 AM Daniel Vetter wrote:
> > On Fri, Jun 12, 2020 at 06:00:51PM +0200, Daniel Vetter wrote:
> > > Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> > > which means vblank state isn't ill-d
Hi,
On 30/06/2020 23:27, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
>
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay SOC. The SOC's display pipeline
== Series Details ==
Series: drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K (rev2)
URL : https://patchwork.freedesktop.org/series/78940/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8693 -> Patchwork_18066
Summa
== Series Details ==
Series: Introduce DG1 (rev4)
URL : https://patchwork.freedesktop.org/series/77496/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8691_full -> Patchwork_18064_full
Summary
---
**FAILURE**
Serio
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against
a stuck driver
URL : https://patchwork.freedesktop.org/series/79042/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
905d2359cfb2 drm/i915/gt: Harden the heartbeat against a stuc
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against
a stuck driver
URL : https://patchwork.freedesktop.org/series/79042/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't b
Hi Daniel,
Thank you for the patch.
On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. s
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against
a stuck driver
URL : https://patchwork.freedesktop.org/series/79042/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8693 -> Patchwork_18067
On Thu, Jul 2, 2020 at 1:27 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote:
> > Only when vblanks are supported ofc.
> >
> > Some drivers do this already, but most unfortunately missed it. This
> > opens up b
On 02/07/2020 09:32, Chris Wilson wrote:
As we allow for parallel threads to create vma instances in parallel,
and we only filter out the duplicates upon reacquiring the spinlock for
the rbtree, we have to free the loser of the constructors' race. When
freeing, we should also drop any resource
On 02/07/2020 09:32, Chris Wilson wrote:
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more
Hi Lucas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20200702]
[cannot apply to v5.8-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
While the test is blocked, we keep trying the gen12_single_ctx_helper().
As this is using the parent's drm_fd, all of our context allocations are
persistent. Reopen the device in the child so that when we exit, our
allocations are freed along with the process -- avoiding a total memory
leak if the
Quoting Tvrtko Ursulin (2020-07-02 13:35:41)
>
> On 02/07/2020 09:32, Chris Wilson wrote:
> > Avoid waking up the device and taking stale locks if we know that the
> > object is not currently mmapped. This is particularly useful as not many
> > object are actually mmapped and so we can destroy the
Quoting Chris Wilson (2020-07-02 13:47:00)
> Quoting Tvrtko Ursulin (2020-07-02 13:35:41)
> >
> > On 02/07/2020 09:32, Chris Wilson wrote:
> > > Avoid waking up the device and taking stale locks if we know that the
> > > object is not currently mmapped. This is particularly useful as not many
> >
Am 25.06.20 um 15:59 schrieb Daniel Vetter:
On Thu, Jun 25, 2020 at 3:23 PM Lionel Landwerlin
wrote:
On 25/06/2020 16:18, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-06-25 13:34:43)
There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_cha
Could be a particularly slow PIPE_CONTROL instruction on TGL.
We assumed that in a sequence of instructions : PC0, MI_RPC0, PC1, MI_RPC1
The delta of time PC1 - PC0 would be with 500ns of MI_RPC1 - MI_RPC0.
That does sound a bit broken tbf...
Patch looks good :
Reviewed-by: Lionel Landwerlin
Only a GGTT mmaping will use the aperture detiling registers, so only a
tiling change for an object, we only need to revoke those mmapings and
not the CPU mmapings (which are always linear irrespective of the tiling).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more freedom of workqueue ordering
during shutdow
== Series Details ==
Series: series starting with [01/23] drm/i915: Drop vm.ref for duplicate vma on
construction
URL : https://patchwork.freedesktop.org/series/79037/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8692_full -> Patchwork_18065_full
Quoting Chris Wilson (2020-07-02 14:06:05)
> Avoid waking up the device and taking stale locks if we know that the
> object is not currently mmapped. This is particularly useful as not many
> object are actually mmapped and so we can destroy them without waking
> the device up, and gives us a littl
Op 30-06-2020 om 16:16 schreef Tvrtko Ursulin:
>
> On 24/06/2020 12:05, Maarten Lankhorst wrote:
>> Killing context before taking ctx->mutex fixes a hang in
>> gem_ctx_persistence.close-replace-race, where lut_close
>> takes obj->resv.lock which is already held by execbuf,
>> causing a stalling ind
In order to avoid functional breakage of mis-programmed applications that
have grown to depend on unused MOCS entries, we are programming
those entries to be equal to fully cached ("L3 + LLC") entry.
These reserved and unspecified entries should not be used as they may be
changed to less performan
In order to avoid functional breakage of mis-programmed applications that
have grown to depend on unused MOCS entries, we are programming
those entries to be equal to fully cached ("L3 + LLC") entry.
These reserved and unspecified entries should not be used as they may be
changed to less performan
On Wed, Jul 01, 2020 at 10:24:07AM -0700, Lucas De Marchi wrote:
> On Wed, Jul 01, 2020 at 08:04:30PM +0300, Ville Syrjälä wrote:
> >On Wed, Jun 24, 2020 at 05:11:18PM -0700, Lucas De Marchi wrote:
> >> Identify 3 possible cases in which the index numbers can be different
> >> from the "port" and a
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/gem: Only revoke the GGTT
mmappings on aperture detiling changes
URL : https://patchwork.freedesktop.org/series/79046/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8696 -> Patchwork_18068
===
On Tue, Jun 30, 2020 at 11:42:36PM +, Souza, Jose wrote:
> On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
> > for iterating through multiple ext blocks of the same type by
> > pass
On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
> wrote:
> >
> > On 2020-06-23 at 21:29:05 +0530, Sean Paul wrote:
> > Hi Sean,
> > I am new to DP MST stuff, I am looking to DP MST spec DP v1.2a.
> > I have looked the entire series, i will take u
On 02/07/2020 14:26, Maarten Lankhorst wrote:
> Op 30-06-2020 om 16:16 schreef Tvrtko Ursulin:
>>
>> On 24/06/2020 12:05, Maarten Lankhorst wrote:
>>> Killing context before taking ctx->mutex fixes a hang in
>>> gem_ctx_persistence.close-replace-race, where lut_close
>>> takes obj->resv.lock which
== Series Details ==
Series: drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev3)
URL : https://patchwork.freedesktop.org/series/78012/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8696 -> Patchwork_18069
S
== Series Details ==
Series: drm/i915: Clamp min_cdclk to max_cdclk_freq to unblock 8K (rev2)
URL : https://patchwork.freedesktop.org/series/78940/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8693_full -> Patchwork_18066_full
=
From: Ville Syrjälä
The MSG_FBC_REND_STATE register only exists on snb+. For older
platforms (would also work for snb+) we can simply rewite DSPSURF
to trigger a flip nuke.
While generally RMW is considered harmful we'll use it here for
simplicity. And since FBC doesn't exist in i830 we don't ha
From: Ville Syrjälä
Unlike all the other pre-snb desktop platforms i865 actually
supports FBC. Let's enable it.
Quote from the spec:
"DevSDG provides the same Run-Length Encoded Frame Buffer
Compression (RLEFBC) function as exists in DevMGM."
As i865 only has the one pipe we want to skip massa
From: Ville Syrjälä
Normally i85x/i865 3D activity will block FBC until a 2D blit
occurs. I suppose this was meant to avoid recompression while
3D activity is still going on but the frame hasn't yet been
presented. Unfortunately that also means that a page flipped
3D workload will permanently blo
From: Ville Syrjälä
Leftovers from the earlier FBC series.
Ville Syrjälä (4):
drm/i915/fbc: Use the correct plane stride
drm/i915/fbc: Fix nuke for pre-snb platforms
drm/i915/fbc: Enable fbc on i865
drm/i915/fbc: Allow FBC to recompress after a 3D workload on i85x/i865
drivers/gpu/drm/
From: Ville Syrjälä
Consult the actual plane stride instead of the fb stride. The two
will disagree when we remap the gtt. The plane stride is what the
hw will be fed so that's what we should look at for the FBC
retrictions/cfb allocation.
Since we no longer require a fence we are going to attem
Chris Wilson writes:
> Pull the repeated check for the last active request being completed to a
> single spot, when deciding whether or not execlist preemption is
> required.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 14 --
> 1 file changed, 4 ins
On 02/07/2020 14:06, Chris Wilson wrote:
Only a GGTT mmaping will use the aperture detiling registers, so only a
tiling change for an object, we only need to revoke those mmapings and
not the CPU mmapings (which are always linear irrespective of the tiling).
Signed-off-by: Chris Wilson
Cc: Tv
On 02/07/2020 14:06, Chris Wilson wrote:
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more
Quoting Mika Kuoppala (2020-07-02 16:46:22)
> Chris Wilson writes:
>
> > Pull the repeated check for the last active request being completed to a
> > single spot, when deciding whether or not execlist preemption is
> > required.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i9
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Harden the heartbeat against
a stuck driver
URL : https://patchwork.freedesktop.org/series/79042/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8693_full -> Patchwork_18067_full
==
== Series Details ==
Series: drm/i915: FBC fixes (rev3)
URL : https://patchwork.freedesktop.org/series/76714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8697 -> Patchwork_18070
Summary
---
**SUCCESS**
No regres
Only a GGTT mmapping will use the aperture detiling registers, so on a
tiling change for an object, we only need to revoke those mmappings and
not the CPU mmappings (which are always linear irrespective of the tiling).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
-
Avoid waking up the device and taking stale locks if we know that the
object is not currently mmapped. This is particularly useful as not many
object are actually mmapped and so we can destroy them without waking
the device up, and gives us a little more freedom of workqueue ordering
during shutdow
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gem: Only revoke the GGTT
mmappings on aperture detiling changes
URL : https://patchwork.freedesktop.org/series/79053/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8697 -> Patchwork_18071
===
While the test is blocked, we keep trying the gen12_single_ctx_helper().
As this is using the parent's drm_fd, all of our context allocations are
persistent. Reopen the device in the child so that when we exit, our
allocations are freed along with the process -- avoiding a total memory
leak if the
On Fri, Jun 12, 2020 at 01:41:17PM -0400, Alex Deucher wrote:
> On Fri, Jun 12, 2020 at 1:24 PM Harry Wentland wrote:
> >
> > On 2020-06-12 12:00 p.m., Daniel Vetter wrote:
> > > Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> > > which means vblank state isn't ill-define
From: Ville Syrjälä
Stop using HBR2/3 support as a proxy for TPS3/4 support.
The two are no longer 1:1 in the hardware, arguably they
never were due to HSW ULX which does support TPS3 while
being limited to HBR1.
In more recent times GLK gained support for TPS4 while
being limited to HBR2. And o
From: Ville Syrjälä
Currently we claim to use TPS7 when using TPS4. That is just
confusing, so let's fix the debug print.
And while we're touching this let's add the customary
encoder id/name as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 26 ++
to drm-next (2020-06-24 15:45:51
+1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-07-02
for you to fetch changes up to d524b87f77364db096855d7eb714ffacec974ddf:
drm/i915: Update DRIVER_DATE to 202
On Thu, Jul 02, 2020 at 09:24:50PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we claim to use TPS7 when using TPS4. That is just
> confusing, so let's fix the debug print.
>
> And while we're touching this let's add the customary
> encoder id/name as well.
>
> Signed-off-by
== Series Details ==
Series: series starting with [1/2] drm/i915: Enable TPS3/4 on all platforms
that support them
URL : https://patchwork.freedesktop.org/series/79060/
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 [v2,1/2] drm/i915/gem: Only revoke the GGTT
mmappings on aperture detiling changes
URL : https://patchwork.freedesktop.org/series/79046/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8696_full -> Patchwork_18068_full
=
== Series Details ==
Series: series starting with [1/2] drm/i915: Enable TPS3/4 on all platforms
that support them
URL : https://patchwork.freedesktop.org/series/79060/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8698 -> Patchwork_18072
=
Since gen8 we don't use swizzle anymore. Don't dump registers related to
it: registers may or may not be there.
v2: pull the rest of driver state reporting before the read out (Chris)
Cc: Matt Roper
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 +-
1 f
Quoting Lucas De Marchi (2020-07-02 21:07:14)
> Since gen8 we don't use swizzle anymore. Don't dump registers related to
> it: registers may or may not be there.
>
> v2: pull the rest of driver state reporting before the read out (Chris)
>
> Cc: Matt Roper
> Signed-off-by: Lucas De Marchi
Revie
1 - 100 of 141 matches
Mail list logo
