On Tue, 2021-11-30 at 01:50 +, Patchwork wrote:
> Patch Details
> Series:drm/i915: Update error capture code to avoid using the current
> vma
> stateURL:https://patchwork.freedesktop.org/series/97385/State:failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21696/index.html
== Series Details ==
Series: drm/i915/dp: Perform 30ms delay after source OUI write (rev2)
URL : https://patchwork.freedesktop.org/series/96871/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10939_full -> Patchwork_21697_full
===
== Series Details ==
Series: drm/i915: Update error capture code to avoid using the current vma state
URL : https://patchwork.freedesktop.org/series/97385/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10939_full -> Patchwork_21696_full
== Series Details ==
Series: drm/i915/dp: Perform 30ms delay after source OUI write (rev2)
URL : https://patchwork.freedesktop.org/series/96871/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10939 -> Patchwork_21697
Summary
== Series Details ==
Series: drm/i915/dp: Perform 30ms delay after source OUI write (rev2)
URL : https://patchwork.freedesktop.org/series/96871/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
While working on supporting the Intel HDR backlight interface, I noticed
that there's a couple of laptops that will very rarely manage to boot up
without detecting Intel HDR backlight support - even though it's supported
on the system. One example of such a laptop is the Lenovo P17 1st
generation.
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/vc4/vc4_kms.c
between commits:
f927767978d2 ("drm/vc4: kms: Fix return code check")
d354699e2292 ("drm/vc4: kms: Don't duplicate pending commit")
from the drm-misc-fixes tree and commit:
16e101051f32 (
== Series Details ==
Series: drm/i915: Update error capture code to avoid using the current vma state
URL : https://patchwork.freedesktop.org/series/97385/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10939 -> Patchwork_21696
==
== Series Details ==
Series: drm/i915: Update error capture code to avoid using the current vma state
URL : https://patchwork.freedesktop.org/series/97385/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separ
== Series Details ==
Series: drm/i915: Update error capture code to avoid using the current vma state
URL : https://patchwork.freedesktop.org/series/97385/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1fc91c09d6c2 drm/i915: Update error capture code to avoid using the current
On Mon, 15 Nov 2021 20:21:48 +, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encryption.
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correc
== Series Details ==
Series: dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()
(rev2)
URL : https://patchwork.freedesktop.org/series/97362/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10938_full -> Patchwork_21695_full
===
KBL issue is associated to
https://gitlab.freedesktop.org/drm/intel/-/issues/4547
But not sure the component of the issue.
Re-reported.
Lakshmi.
-Original Message-
From: Deak, Imre
Sent: Friday, November 26, 2021 5:59 AM
To: Sarvela, Tomi P
Cc: intel-gfx@lists.freedesktop.org; Vudum,
== Series Details ==
Series: dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()
(rev2)
URL : https://patchwork.freedesktop.org/series/97362/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10938 -> Patchwork_21695
=
On Fri, 26 Nov 2021, Uma Shankar wrote:
> Enable Pipe Degamma for XE_LPD. Extend the legacy implementation
> to incorparate the extended lut size for XE_LPD.
>
> v2: Added a helper for degamma lut size (Ville)
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 14
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf.
URL : https://patchwork.freedesktop.org/series/97371/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10938 -> Patchwork_21694
Summary
---
**F
== Series Details ==
Series: drm/i915: Fix DPT suspend/resume on !HAS_DISPLAY platforms
URL : https://patchwork.freedesktop.org/series/97291/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10928_full -> Patchwork_21682_full
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf.
URL : https://patchwork.freedesktop.org/series/97371/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/i915_gem_evict.c:110: warning: Function parameter or
member 'ww'
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf.
URL : https://patchwork.freedesktop.org/series/97371/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Remove short term pins from execbuf.
URL : https://patchwork.freedesktop.org/series/97371/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
21c47bda3457 drm/i915: Remove unused bits of i915_vma/active api
27e1019e84ca drm/i915: Change shrink
If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
Fix this by clearing the PENDING_ERROR status if we return true in
dma_fence_array_signaled().
v2:
- Update Cc list, and add R-b.
Fixes: 1f70b8b812f3 ("dma-fence: Propagate error
== Series Details ==
Series: series starting with [v4,1/2] i915/gvt: Introduce the mmio_info_table.c
to support VFIO new mdev API
URL : https://patchwork.freedesktop.org/series/97369/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10936_full -> Patchwork_21693_full
===
We are moving away from short term pinning, and need a way to evict
objects locked by the current context. Pass the ww context to all
eviction functions, so that they can evict objects that are already
locked by the current ww context.
On top of that, this slightly improves ww handling because the
Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
protected by the object lock.
This removes the need to unpin, which is done by just releasing the
lock.
eb_reserve is slightly reworked for readability, but the same steps
are still done:
- First pass pins with NONBLOCK.
- Second
i915_vma_wait_for_bind needs the vma lock held, fix the caller.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 40 +++--
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915
We want to remove more members of i915_vma, which requires the locking to be
held more often.
Start requiring gem object lock for i915_vma_unbind, as it's one of the
callers that may unpin pages.
Some special care is needed when evicting, because the last reference to the
object may be held by th
Now that we require locking to evict, multiple vmas from the same object
might not be evicted. This is expected and required, because execbuf will
move to short-term pinning by using the lock only. This will cause these
tests to fail, because they create a ton of vma's for the same object.
Unbind
Call drop_pages with the gem object lock held, instead of the other
way around. This will allow us to drop the vma bindings with the
gem object lock held.
We plan to require the object lock for unpinning in the future,
and this is an easy target.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Nir
Now that we require the object lock for all ops, some code handling
race conditions can be removed.
This is required to not take short-term pins inside execbuf.
Signed-off-by: Maarten Lankhorst
Acked-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_vma.c | 40 +--
i915_gem_execbuf will call i915_gem_evict_vm() after failing to pin
all objects in the first round. We are about to remove those short-term
pins, but even without those the objects are still locked. Add a special
case to allow i915_gem_evict_vm to evict locked objects as well.
This might also allo
This duck tape workaround is no longer required, unbind and destroy are
fixed to take the obj->resv mutex before destroying and obj->mm.lock has
been removed, always requiring obj->resv as well.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 4 ++--
drivers/g
Now that we cannot unbind kill the currently locked object directly
because we're removing short term pinning, we may have to unbind the
object from gtt manually, using a i915_gem_evict_vm() call.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18
Big delta, but boils down to moving set_pages to i915_vma.c, and removing
the special handling, all callers use the defaults anyway. We only remap
in ggtt, so default case will fall through.
Because we still don't require locking in i915_vma_unpin(), handle this by
using xchg in get_pages(), as it
Now that freeing objects takes the object lock when destroying the
backing pages, we can confidently take the object lock even for dead
objects.
Use this fact to take the object lock in the shrinker, without requiring
a reference to the object, so all calls to unbind take the object lock.
This is
In the next commit, we don't evict when refcount = 0.
igt_vm_isolation() continuously tries to pin/unpin at same address,
but also calls put() on the object, which means the object may not
be unpinned in time.
Instead of this, re-use the same object over and over, so they can
be unbound as requir
New version of the series, with feedback from previous series added.
First 11 patches are clean, some small fixes might required still for all to
pass.
Maarten Lankhorst (16):
drm/i915: Remove unused bits of i915_vma/active api
drm/i915: Change shrink ordering to use locking around unbinding
TTM already requires this, and we require it for delayed destroy.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915
We will need the lock to unbind the vma, and wait for bind to complete.
Remove the special casing for the !ww path, and force ww locking for all.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 7 ++-
drivers/gpu/drm/i915/i915_gem.c | 26 ++
2
When reworking the code to move the eviction fence to the object,
the best code is removed code.
Remove some functions that are unused, and change the function definition
if it's only used in 1 place.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
[mlankhorst: Remove ne
On 25-10-2021 17:02, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
> wrote:
>> Add a flag PIN_VALIDATE, to indicate we don't need to pin and only
>> protected by the object lock.
>>
>> This removes the need to unpin, which is done by just releasing the
>> lock.
>>
>> eb_res
On 21-10-2021 19:48, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
> wrote:
>> Signed-off-by: Maarten Lankhorst
> Needs a proper commit message.
What about this?
>> ---
>> drivers/gpu/drm/i915/i915_gem.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
== Series Details ==
Series: series starting with [v4,1/2] i915/gvt: Introduce the mmio_info_table.c
to support VFIO new mdev API
URL : https://patchwork.freedesktop.org/series/97369/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10936 -> Patchwork_21693
=
(Switching to my @linux.intel.com address)
Quoting Christian König (2021-11-29 14:55:37)
> Am 29.11.21 um 13:46 schrieb Thomas Hellström:
> > On Mon, 2021-11-29 at 13:33 +0100, Christian König wrote:
> >> Am 29.11.21 um 13:23 schrieb Thomas Hellström:
> >>> Hi, Christian,
> >>>
> >>> On Mon, 2021-
On Fri, Nov 19, 2021 at 11:46:31PM +0100, jim.cro...@gmail.com wrote:
> Vincent's code has the macro magic to define that event, which IIUC
> is what makes it controllable by ftrace, and therefore acceptable in
> principle to Steve.
> Would there be any reason to expand his set of 2 events into de
Am 29.11.21 um 13:46 schrieb Thomas Hellström:
On Mon, 2021-11-29 at 13:33 +0100, Christian König wrote:
Am 29.11.21 um 13:23 schrieb Thomas Hellström:
Hi, Christian,
On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
Am 29.11.21 um 08:35 schrieb Thomas Hellström:
If a dma_fence_array
On 2021-11-25 10:42, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
With both integrated and discrete Intel GPUs in a system, the current
global check of intel_iommu_gfx_mapped, as done from intel_vtd_active()
may not be completely accurate.
In this patch we add i915 parameter to intel_vtd_active(
On Tue, Nov 23, 2021 at 12:24:21PM -0800, Luis Chamberlain wrote:
> There is no need to user boiler plate code to specify a set of base
> directories we're going to stuff sysctls under. Simplify this by using
> register_sysctl() and specifying the directory path directly.
>
> // pycocci sysctl-sub
Am 29.11.21 um 08:35 schrieb Thomas Hellström:
If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
Fix this by clearing the PENDING_ERROR status if we return true in
dma_fence_array_signaled().
Fixes: 1f70b8b812f3 ("dma-fence: Pr
Am 29.11.21 um 13:23 schrieb Thomas Hellström:
Hi, Christian,
On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
Am 29.11.21 um 08:35 schrieb Thomas Hellström:
If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
Fix this
On 16/10/2021 21:42, Claudio Suarez wrote:
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
== Series Details ==
Series: series starting with [v4,1/2] i915/gvt: Introduce the mmio_info_table.c
to support VFIO new mdev API
URL : https://patchwork.freedesktop.org/series/97369/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
20204614807c i915/gvt: Introduce the mmio_info_
On Mon, 2021-11-29 at 13:33 +0100, Christian König wrote:
> Am 29.11.21 um 13:23 schrieb Thomas Hellström:
> > Hi, Christian,
> >
> > On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
> > > Am 29.11.21 um 08:35 schrieb Thomas Hellström:
> > > > If a dma_fence_array is reported signaled by
On 21-10-2021 19:39, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 11:37, Maarten Lankhorst
> wrote:
>> i915_vma_wait_for_bind needs the vma lock held, fix the caller.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/i915_vma.c | 40 +++--
>> 1 fil
On 22-10-2021 12:59, Matthew Auld wrote:
> On Thu, 21 Oct 2021 at 18:30, Matthew Auld
> wrote:
>> On Thu, 21 Oct 2021 at 11:36, Maarten Lankhorst
>> wrote:
>>> Big delta, but boils down to moving set_pages to i915_vma.c, and removing
>>> the special handling, all callers use the defaults anyway.
From: Zhi Wang
To support the new mdev interfaces and the re-factor patches from
Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
initialization path has to be separated into two phases:
a) Early initialization.
The early initialization of GVT requires to be done when lo
From: Zhi Wang
To support the early init of GVT-g, which will be put in i915, after the
GVT-g is moved into a dedicated module, we need to save the MMIO snapshot
in the early init of GVT-g, when the HW hasn't been touched.
v3:
- Fix errors when CONFIG_DRM_I915_WERROR is turned on. (Jani)
Cc: C
Hi, Christian,
On Mon, 2021-11-29 at 09:21 +0100, Christian König wrote:
> Am 29.11.21 um 08:35 schrieb Thomas Hellström:
> > If a dma_fence_array is reported signaled by a call to
> > dma_fence_is_signaled(), it may leak the PENDING_ERROR status.
> >
> > Fix this by clearing the PENDING_ERROR st
== Series Details ==
Series: dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()
URL : https://patchwork.freedesktop.org/series/97362/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10935_full -> Patchwork_21692_full
===
== Series Details ==
Series: dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()
URL : https://patchwork.freedesktop.org/series/97362/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10935 -> Patchwork_21692
On 2021-11-08 at 18:45:46 +0100, Thomas Hellström wrote:
> With asynchronous migrations, the vma state may be several migrations
> ahead of the state that matches the request we're capturing.
> Address that by introducing an i915_vma_snapshot structure that
> can be used to snapshot relevant state
Hi Dave and Daniel,
here's the second PR for drm-misc-next for what will become Linux 5.17.
It's a bit late, as I was on vacation last week. The most significant
change moves the nomodeset parameter entirely into the DRM subsystem.
Best regards
Thomas
drm-misc-next-2021-11-29:
drm-misc-next for
62 matches
Mail list logo
