== Series Details ==
Series: drm/i915: Also drop vm.ref along error paths for vma construction
URL : https://patchwork.freedesktop.org/series/79063/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8701_full -> Patchwork_18074_full
Hi Chris,
On Thu, Jul 02, 2020 at 10:10:15PM +0100, Chris Wilson wrote:
> Not only do we need to release the vm.ref we acquired for the vma on the
> duplicate insert branch, but also for the normal error paths, so roll
> them all into one.
>
> Reported-by: Andi Shyti
> Suggested-by: Andi Shyti
Hi Chris,
On Thu, Jul 02, 2020 at 09:32:05AM +0100, Chris Wilson wrote:
> 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
>
Hi all,
Today's linux-next merge of the kspp tree got a conflict in:
drivers/gpu/drm/drm_edid.c
between commit:
948de84233d3 ("drm : Insert blank lines after declarations.")
from the drm-misc tree and commit:
80b89ab785a4 ("treewide: Remove uninitialized_var() usage")
from the kspp
== Series Details ==
Series: drm/i915: do not read swizzle info if unavailable (rev2)
URL : https://patchwork.freedesktop.org/series/79007/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8700_full -> Patchwork_18073_full
Hi Chris,
> @@ -1312,11 +1314,11 @@ static int set_ppgtt(struct drm_i915_file_private
> *file_priv,
> if (vm == rcu_access_pointer(ctx->vm))
> goto unlock;
>
> + old = __set_ppgtt(ctx, vm);
> +
> /* Teardown the existing obj:vma cache, it will have to be rebuilt.
== 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 : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8698_full -> Patchwork_18072_full
Hi Chris,
> Ta, going to send that as a patch?
mine was a suggestion, it was easier to build the diff than
explain myself :)
If you want I can send it, though.
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
== Series Details ==
Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3)
URL : https://patchwork.freedesktop.org/series/79064/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8702 -> Patchwork_18078
== Series Details ==
Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3)
URL : https://patchwork.freedesktop.org/series/79064/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
== Series Details ==
Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev3)
URL : https://patchwork.freedesktop.org/series/79064/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
15fe500e5d57 drm/i915/gem: Split the context's obj:vma lut into its own
== Series Details ==
Series: Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+" (rev2)
URL : https://patchwork.freedesktop.org/series/79065/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8702 -> Patchwork_18077
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.
Hi Chris,
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 1f63c4a1f055..7fe1f317cd2b 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -198,6 +198,7 @@ vma_create(struct drm_i915_gem_object *obj,
>
== Series Details ==
Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev2)
URL : https://patchwork.freedesktop.org/series/79064/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8702 -> Patchwork_18076
On Thu, Jul 02, 2020 at 04:09:57PM -0700, Matt Atwood wrote:
> The initial CI results did not include a TGL system which includes a
> panel that is having issues with patch. Revert while we triage.
>
> This reverts commit 680c45c767f63e35f063d3ea04f388a9f7ae7079.
>
> Signed-off-by: Matt Atwood
On Thu, Jul 02, 2020 at 03:34:36PM -0700, Souza, Jose wrote:
> On Thu, 2020-07-02 at 15:18 -0700, Matt Atwood wrote:
> > The initial CI results did not include a TGL system which includes a
> > panel that is having issues with patch. Revert while we triage.
> >
> > This reverts commit
On Thu, Jul 02, 2020 at 12:15:26PM +0300, Stanislav Lisovskiy wrote:
> 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
== Series Details ==
Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev2)
URL : https://patchwork.freedesktop.org/series/79064/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
== Series Details ==
Series: drm/i915/gem: Split the context's obj:vma lut into its own mutex (rev2)
URL : https://patchwork.freedesktop.org/series/79064/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e64718ab4fd9 drm/i915/gem: Split the context's obj:vma lut into its own
On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> 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
== Series Details ==
Series: Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
URL : https://patchwork.freedesktop.org/series/79065/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8701 -> Patchwork_18075
Summary
The initial CI results did not include a TGL system which includes a
panel that is having issues with patch. Revert while we triage.
This reverts commit 680c45c767f63e35f063d3ea04f388a9f7ae7079.
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/display/intel_dp.c | 28
On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> 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
== Series Details ==
Series: Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
URL : https://patchwork.freedesktop.org/series/79065/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
138679950a74 Revert "drm/i915/dp: Correctly advertise HBR3 for GEN11+"
-:70:
== Series Details ==
Series: drm/i915: Also drop vm.ref along error paths for vma construction
URL : https://patchwork.freedesktop.org/series/79063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8701 -> Patchwork_18074
== 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_full -> Patchwork_18071_full
On Thu, Jul 02, 2020 at 09:24:49PM +0300, Ville Syrjala wrote:
> 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
On Thu, 2020-07-02 at 15:18 -0700, Matt Atwood wrote:
> The initial CI results did not include a TGL system which includes a
> panel that is having issues with patch. Revert while we triage.
>
> This reverts commit 680c45c767f63e35f063d3ea04f388a9f7ae7079.
Missing the Signed-off-by line also the
On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> 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
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.
The initial CI results did not include a TGL system which includes a
panel that is having issues with patch. Revert while we triage.
This reverts commit 680c45c767f63e35f063d3ea04f388a9f7ae7079.
---
drivers/gpu/drm/i915/display/intel_dp.c | 28 +++--
1 file changed, 17
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.
Quoting Andi Shyti (2020-07-02 23:09:44)
> Hi Chris,
>
> > @@ -1312,11 +1314,11 @@ static int set_ppgtt(struct drm_i915_file_private
> > *file_priv,
> > if (vm == rcu_access_pointer(ctx->vm))
> > goto unlock;
> >
> > + old = __set_ppgtt(ctx, vm);
> > +
> > /*
On Thu, 2020-07-02 at 18:37 +0300, Ville Syrjala wrote:
> 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
== 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_full -> Patchwork_18070_full
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915: do not read swizzle info if unavailable (rev2)
URL : https://patchwork.freedesktop.org/series/79007/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8700 -> Patchwork_18073
Summary
Not only do we need to release the vm.ref we acquired for the vma on the
duplicate insert branch, but also for the normal error paths, so roll
them all into one.
Reported-by: Andi Shyti
Suggested-by: Andi Shyti
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
On Thu, 2020-07-02 at 17:40 +0300, Ville Syrjälä wrote:
> 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
> > >
Quoting Andi Shyti (2020-07-02 21:25:45)
> Hi Chris,
>
> > diff --git a/drivers/gpu/drm/i915/i915_vma.c
> > b/drivers/gpu/drm/i915/i915_vma.c
> > index 1f63c4a1f055..7fe1f317cd2b 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.c
> > +++ b/drivers/gpu/drm/i915/i915_vma.c
> > @@ -198,6 +198,7 @@
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
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
== 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
== 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 : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't
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.
>
>
5: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 20200702 (2020-07-02 21:25:2
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
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
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
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
== 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
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
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
== 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
== 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
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
> > ---
> >
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
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:
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
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
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
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
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
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
== 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
== 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
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
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
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
> >
== 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 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
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
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
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
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
== 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
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
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
---
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
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
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
> >
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
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
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
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
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 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
== 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
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.
== 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
== 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
== 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**
== 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
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
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
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:
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
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
== 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
1 - 100 of 141 matches
Mail list logo
