Quoting Sebastian Brzezinka (2025-07-18 12:28:26)
> Introduce a separate `ret` variable to hold the return value in
> `eb_relocate_vma()`, instead of overloading `remain` for both loop
> control and error reporting.
No need.
-Chris
)
No, that is exactly the misconception I wanted to avoid.
The core kernel's system PAGE_SIZE is not necessarily the same as the
paging boundary used by the GTT.
-Chris
Quoting Krzysztof Karas (2025-06-23 09:40:48)
> Hi Chris,
>
> > > Amend the problem by keeping the mock file open throughout the
> > > duration of this test and calling fput() from the test itself.
> >
> > That is not the problem; that is papering over whateve
the test
> from properly faulting - we'd expect no space left, but an
> object was able to fit in the remaining 1 MiB.
>
> Amend the problem by keeping the mock file open throughout the
> duration of this test and calling fput() from the test itself.
That is not the problem; that is papering over whatever the problem
really is.
-Chris
maining 1 MiB.
>
> Amend the problem by keeping the mock file open throughout the
> duration of this test and calling fput() from the test itself.
The file is owned by vma->vm_file for the duration of the mapping.
-Chris
st
> if they need to allocate whole memory with new objects.
That's a fundamental bug if pages are available on the system but not
being allocated [just because they are currently being freed]. That
breaks the understanding that clients can allocate any and all local
memory.
-Chris
It looks like that was broken by
commit 1bfc03b1375244f9029bb448ee8224b3b6dae99f
Author: Lucas De Marchi
Date: Tue Mar 19 23:03:03 2024 -0700
drm/i915: Remove special handling for !RCS_MASK()
-Chris
* now this test polutes our CI on previous generations.
s/polutes/pollutes/
> +*
> +* https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13697
> + */
> + if (!IS_ENABLED(CONFIG_DRM_I915_SELFTEST_BROKEN))
We could GRAPHICS_VER(i915) == 12 to illustrate the point more if you
want.
Nits notwithstanding,
Reviewed-by: Chris Wilson
-Chris
it) to
> > use as the current->mm? Maybe a better approach would be to create a new
> > mm for the duration of the test, similarly to how the patch Janusz
> > mentioned does it? (51104c19d857)
>
> As per discussion with Chris, using active_mm is the correct way of
> ena
uning section?
> +
> + /*
> +* This bit must be set to enable performance optimization for fast
> +* clears.
> +*/
> + wa_mcr_write_or(wal, GEN8_WM_CHICKEN2,
> WAIT_ON_DEPTH_STALL_DONE_DISABLE);
This should only be applied to rcs contexts, not all.
-Chris
enable CONFIG_DRM_I915_SELFTEST_BROKEN for CI builds.
-Chris
t the HW issue, or
- hide the selftest and stop it running on known bad platforms?
-Chris
-[ end trace ]---
Fix this by avoiding the divide if bpp is 0.
Fixes: c1d6a22b7219 ("drm/dp: Add helpers to calculate the link BW overhead")
Cc: sta...@vger.kernel.org
Acked-by: Imre Deak
Signed-off-by: Chris Bainbridge
---
drivers/gpu/drm/display/drm_dp_helper.c | 7
-[ end trace ]---
Fix this by avoiding the divide if bpp is 0.
Fixes: c1d6a22b7219 ("drm/dp: Add helpers to calculate the link BW overhead")
Cc: sta...@vger.kernel.org
Acked-by: Imre Deak
Signed-off-by: Chris Bainbridge
---
drivers/gpu/drm/display/drm_dp_helper.c | 6 +++
-[ end trace ]---
Fix this by avoiding the divide if bpp is 0.
Fixes: c1d6a22b7219 ("drm/dp: Add helpers to calculate the link BW overhead")
Signed-off-by: Chris Bainbridge
Acked-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_helper.c | 7 +++
1 file changed, 7 ins
d in gt_tlb, and thus igt_cs_tlb
> is obsolete and should be removed.
gt_tlb supersedes igt_cs_tlb, that I can agree on,
Acked-by: Chris Wilson
-Chris
table invalidation is done only for the
> engine executing the request. And the mmio address for the aux_inv
> register is set after the engine instance becomes certain.
>
> Signed-off-by: Chris Wilson
> Signed-off-by: Fei Yang
> ---
> drivers/gpu/drm/i915/gt/gen8_eng
Quoting Janusz Krzysztofik (2022-02-18 17:08:41)
> Hi Chris,
>
> On Friday, 18 February 2022 17:03:01 CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2022-02-18 15:19:35)
> > > @@ -206,15 +229,19 @@ static struct pci_device
> > > *_
Quoting Janusz Krzysztofik (2022-02-18 15:19:35)
> @@ -206,15 +229,19 @@ static struct pci_device
> *__igt_device_get_pci_device(int fd)
> igt_warn("Couldn't find PCI device %04x:%02x:%02x:%02x\n",
> pci_addr.domain, pci_addr.bus,
>
story as that told by the series of
individual patches.
Reviewed-by: Chris Wilson
-Chris
wal)
> static void
> gen9_wa_init_mcr(struct drm_i915_private *i915, struct i915_wa_list *wal)
> {
> - const struct sseu_dev_info *sseu = &i915->gt.info.sseu;
> + const struct sseu_dev_info *sseu = &i915->gt0.info.sseu;
This feels like it should be pulling from uncore->gt, since the MCR is
across an uncore.
Overall though, rather than introduce bare &i915->gt0, how about pulling in
the patch for to_gt(i915)?
-Chris
r in that mode and the
> TypeC subsystem not having anything to do with the port in that case).
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3500
> Reported-and-tested-by: Chris Chiu
> Signed-off-by: Imre Deak
> ---
Tested-by: Chris Chiu
On Thu, May 6, 2021 at 5:46 PM Rafael J. Wysocki wrote:
>
> On Tue, May 4, 2021 at 10:08 AM Chris Chiu wrote:
> >
> > Hi,
> > We have some Intel laptops (11th generation CPU) with NVIDIA GPU
> > suffering the same GPU falling off the bus problem while exiting
&g
t.
I filed a bug on
https://gitlab.freedesktop.org/drm/intel/-/issues/3407 and also
uploaded the journal log with kernel boot parameter
"drm.debug=0x10e".
Can anyone suggest what happens at the replug? What can we do to
identify the cause? Thanks
Chris
__
Quoting Ville Syrjälä (2021-03-22 14:48:44)
> On Sun, Mar 21, 2021 at 04:30:32PM +0000, Chris Wilson wrote:
> > Quoting Chris Wilson (2021-03-21 16:28:07)
> > > Quoting Ville Syrjala (2021-03-21 16:10:38)
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
Quoting Chris Wilson (2021-03-21 16:30:32)
> Quoting Chris Wilson (2021-03-21 16:28:07)
> > Quoting Ville Syrjala (2021-03-21 16:10:38)
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > ind
Quoting Chris Wilson (2021-03-21 16:28:07)
> Quoting Ville Syrjala (2021-03-21 16:10:38)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index ec28a6cde49b..0b2434e29d00 100644
> > --- a/drivers/gpu/d
ite easily on my 85x.
NOEVICT will make it much less eager to remove older bindings, with the
preference then to use smaller views of objects. The theory being that
the workingset is less than the whole object, so we can fit more active
pages in and cause less thrashing when moving the unused pa
gt; We have an access to exec2_list there, we know the gen so we're able to say
> relocations are not supported immediate, without entering
> i915_gem_do_execbuffer().
There's a NORELOC flag you can enforce as mandatory. That's trivial for
userspace to set, really makes sure the
wn by igt it's a critical issue that we have to judicially
chose which errors to ignore. And it's not just the ability to subvert
gen7 and gen9, it's the error tracking employed for preempting contexts
among others. Hence go with the original patch to undo the propagation
along dma-resv.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
mcr being set that were are not handling
correctly. Changing the mask here changing results elsewhere indicate
that the issues are fully addressed, and the fear that undoing some
other mmio is going to introduce other subtle hangs. And we are all
blindly poking at the issue as no one
t
in this case the idea was to return 0 as no testing was done and the
ENOMEM was raised before testing began i.e. not an internal and
unexpected driver allocation failure.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freede
pposed to an internal allocation failure from
the driver.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
which causes the whole desktop to lock up.
The fence error handling is required to prevent user's circumventing
incomplete work, such as security validation or escaping isolation.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists
Quoting Chris Wilson (2021-03-05 12:20:45)
> Quoting Tvrtko Ursulin (2021-03-05 09:23:02)
> > I am not sure if PC8 and DMC could also be involved from what Cooper was
> > saying in a different thread. Maybe another CI run without the DMC, both
> > ffs and fls. Another
Trybot_7612/fi-jsl-1/boot0.txt
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
tructs?
>
> To be honest, the rename came as an afterthought, after Aditya (I think)
> added the STEP_X enums.
>
> For me step everywhere sounds good, I wonder what the native speakers
> think.
IS_DISPLAY_STEPPING(STEP_X) is more flamboyant than
IS_DISPLAY_STEP(STEP_X), but we often make the concession for brevity
and in this case the consistency between macro and enum beats the
inconsistency in English. So STEP reads as a perfectly acceptable synonym
for STEPPING.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Chris Wilson (2021-03-04 11:56:16)
> Quoting Chris Wilson (2021-03-04 09:19:24)
> > Quoting Tvrtko Ursulin (2021-03-04 09:12:26)
> > >
> > > On 02/03/2021 06:27, Cooper Chiou wrote:
> > > > WaProgramMgsrForCorrectSliceSpecificMmioReads applies f
Quoting Chris Wilson (2021-03-04 09:19:24)
> Quoting Tvrtko Ursulin (2021-03-04 09:12:26)
> >
> > On 02/03/2021 06:27, Cooper Chiou wrote:
> > > WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Gen9 to
> > > resolve VP8 hardware encoding system hang u
Quoting Lionel Landwerlin (2021-03-04 09:45:47)
> On 04/03/2021 10:58, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2021-03-04 08:28:59)
> >> On 04/03/2021 02:09, Chris Wilson wrote:
> >>> Quoting Umesh Nerlige Ramappa (2021-03-03 21:28:00)
> >>>
t;
> > Reference: HSD#1508045018,1405586840, BSID#0575
> >
> > Cc: Ville Syrjälä
> > Cc: Rodrigo Vivi
> > Cc: Jani Nikula
> > Cc: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: William Tseng
> > Cc: Lee Shawn C
> >
> > Signed-off
Quoting Lionel Landwerlin (2021-03-04 08:28:59)
> On 04/03/2021 02:09, Chris Wilson wrote:
> > Quoting Umesh Nerlige Ramappa (2021-03-03 21:28:00)
> >> Perf measurements rely on CPU and engine timestamps to correlate
> >> events of interest across these time doma
t; - capture cpu time just before lower dword of cs timestamp
>
> v3: (Chris)
> - use uncore-rpm
> - use __query_cs_timestamp helper
>
> v4: (Lionel)
> - Kernel perf subsytem allows users to specify the clock id to be used
> in perf_event_open. This clock id is used by th
modified.
>
> v2: split context changes, fix defines and improve documentation (Chris),
> add object invalidation logic
>
> Signed-off-by: Bommu Krishnaiah
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Telukuntla Sreedhar
> Cc: Kondapally Kalyan
> Cc: Gupta Anshum
ed to the RESET_STATS ioctl to report the
> invalidation to userspace.
>
> v2: split to its own patch and improve doc (Chris), invalidate contexts
> on teardown
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> Signed-off-by: Daniele Ceraolo Spurio
>
_wait_for_register(gt->uncore,
> + GEN12_KCR_SIP,
> + mask,
> + in_play ? mask : 0,
> + 100);
> +
> + intel_runtime_pm_put(gt->uncore->rpm, wakeref);
Ditto
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
by pxp->work
> +
> + ret = intel_pxp_arb_terminate_session_with_global_terminate(pxp);
> +
> + mutex_unlock(&pxp->mutex);
> +
> + return ret;
Fake error returns.
> +}
-Chris
___
Intel-gfx mailing list
Intel-g
ate another interrupt, at
> which point it is safe to re-create the session.
Why do we do the auto recreation after the teardown interrupt?
>
> v2: use struct completion instead of bool (Chris)
>
> Signed-off-by: Huang, Sean Z
> Signed-off-by: Daniele Ceraolo Spurio
> C
m and ring size (ring size may be
useful here as well for larger SESSION_TERMINATE_LEN())
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
+
> +bool intel_pxp_arb_session_is_in_play(struct intel_pxp *pxp)
> +{
> + return intel_pxp_session_is_in_play(pxp, ARB_SESSION);
> +}
So pxp->arb_is_in_play is not the same as intel_pxp_arb_session_is_in_play().
That's confusing.
-Chris
want to emit a
> teardown operation to make sure we're clean on boot and resume
>
> v2: emit in the ring, use high prio request (Chris)
>
> Signed-off-by: Huang, Sean Z
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/Ma
ate another interrupt, at
> which point it is safe to re-create the session.
>
> v2: use struct completion instead of bool (Chris)
>
> Signed-off-by: Huang, Sean Z
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/Makefi
RESENT;
>
> + GEM_BUG_ON(addr & ~GEN12_GGTT_PTE_ADDR_MASK);
You can also check the dma_get_mask() doesn't exceed the addr mask.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ly but for
> correctness should still be handled.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 311a50e76a33 ("drm/i915: Add support for mandatory cmdparsing")
> Cc: Jon Bloomfield
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> ---
> To catchup with referenced
the vma is included with the guard.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Matthew Auld
Cc: Imre Deak
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
drivers/gpu/drm
the vma is included with the guard.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Matthew Auld
Cc: Imre Deak
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
drivers/gpu/drm
c void intel_plane_disable_noatomic(struct
> intel_crtc *crtc,
> intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
> false);
>
> intel_disable_plane(plane, crtc_state);
> + intel_wait_for_vblank(dev_priv, crtc->pipe);
I could only find paths here from sanitize, so it looks safe from
Quoting Tvrtko Ursulin (2021-02-16 15:59:33)
>
> On 16/02/2021 12:49, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2021-02-16 10:50:50)
> >> From: Tvrtko Ursulin
> >>
> >> Test that periodic reads of engine busyness against a constant 100% load
>
ay not be populated on pre-g4x machines,
> in which case we just fall back to max_bpc==8 and let .compute_config()
> limit the resulting pipe_bpp further if necessary.
>
> Cc: Daniel Vetter
> Reported-by: Chris Wilson
> Signed-off-by: Ville Syrjälä
Tested-by: Chris
In light of the VT-d workarounds, we may introduce padding around the
scanout vma. This should not affect relocations referencing the scanout
on !full-ppgtt where we leak the GGTT address of scanout to users.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
tests
Quoting Matthew Auld (2021-02-16 16:49:28)
> On Tue, 16 Feb 2021 at 14:32, Chris Wilson wrote:
> >
> > In light of the VT-d workarounds, we may introduce padding around the
> > scanout vma. This should not affect relocations referencing the scanout
> > on !full-p
In light of the VT-d workarounds, we may introduce padding around the
scanout vma. This should not affect relocations referencing the scanout
on !full-ppgtt where we leak the GGTT address of scanout to users.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
tests/i915/gem_exec_reloc.c | 102
uration_ns / 1000);
> - if (flags & TEST_TRAILING_IDLE)
> - end_spin(gem_fd, spin, flags);
> - val = pmu_read_single(fd) - val;
> + igt_stats_init_with_size(&s, loops);
> +
> + while (--loops) {
while (loops--)
/o\
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
struct intel_execution_engine2 *e, unsigned int
> flags)
> {
> + unsigned int loops = flags & FLAG_LONG ? 20 : 1;
> + double err_min = DBL_MAX, err_max = -DBL_MAX;
> unsigned long slept;
> igt_spin_t *spin;
> + igt_stats_t s;
> uint6
Quoting Ram Moon, AnandX (2021-02-16 12:05:23)
> Hi Chris,
>
> -Original Message-
> From: dri-devel On Behalf Of Chris
> Wilson
> Sent: Monday, February 15, 2021 6:10 PM
> To: Auld, Matthew ; Ram Moon, AnandX
> ; Surendrakumar Upadhyay, TejaskumarX
> ; Ursul
ly protected by
has_busy_stats, let's try to find a different name.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
checks and placement
restrictions.
v3: Fix the check on the placement upper bound. The request user offset
is relative to the guard offset (not the node.start) and so we should
not include the initial guard offset again when computing the upper
bound of the node.
Signed-off-by: Chris Wilson
Cc
Quoting Matthew Auld (2021-02-15 19:31:39)
> On Mon, 15 Feb 2021 at 18:15, Chris Wilson wrote:
> >
> > Quoting Matthew Auld (2021-02-15 18:04:08)
> > > On Mon, 15 Feb 2021 at 15:56, Chris Wilson
> > > wrote:
> > > >
> > > > Introduce th
Quoting Matthew Auld (2021-02-15 18:04:08)
> On Mon, 15 Feb 2021 at 15:56, Chris Wilson wrote:
> >
> > Introduce the concept of padding the i915_vma with guard pages before
> > and aft. The major consequence is that all ordinary uses of i915_vma
> > must use i915_vma_o
Quoting Dan Carpenter (2021-02-15 15:58:27)
> If the igt_request_alloc() call fails then this should return a
> negative error code, but currently it returns success.
>
> Fixes: 85fddf0b0027 ("drm/i915: Introduce a context barrier callback")
> Signed-off-by: Dan Carpe
which is still used
by the drm_mm itself, into an adjustment of node.start at the point of
use.
v3: Pass the requested guard padding from the caller, so we can drop the
VT-d w/a knowledge from the i915_vma allocator.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Matthew Auld
Reviewed-by
otable exceptions are the selftests that are testing exact
behaviour of i915_vma_pin/i915_vma_insert.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 6 +--
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 3 +-
.../gpu/drm/i9
checks and placement
restrictions.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 12 ++--
drivers/gpu/drm/i915/i915_vma.c | 28 ++-
drivers/gpu/drm/i915/i915_vma.h | 5 +++--
drivers/gpu/drm/i915/i915_vma_types.h
Quoting Ram Moon, AnandX (2021-02-15 12:29:17)
> Hi Chris,
>
> -Original Message-
> From: dri-devel On Behalf Of Chris
> Wilson
> Sent: Wednesday, February 10, 2021 4:15 PM
> To: Ram Moon, AnandX ; Jani Nikula
> ; Auld, Matthew ;
> Surendrakumar Upadhya
ucas De Marchi
And patch 2 answered the question of what about intel_audio_init().
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Emil Velikov (2021-02-12 15:45:04)
> On Fri, 12 Feb 2021 at 15:16, Chris Wilson wrote:
> >
> > Quoting Emil Velikov (2021-02-12 14:57:56)
> > > Hi Chris,
> > >
> > > On Thu, 4 Feb 2021 at 12:11, Chris Wilson
> > > wrote:
> >
Quoting Chris Wilson (2021-02-12 15:22:13)
> Quoting Kai Vehmanen (2021-02-12 14:53:02)
> > This reverts commit 3632610d38316bca9b0cd9d649ce3cefab58520a.
> >
> > DG1 has been supported in upstream since v5.10 with commit
> > 69b08bdfa818 ("ALSA: hda
x27;t have been required to stop CI
from timing out upon snd probing the hdmi components. You need the other
half to be supported as well before CI is ready.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Emil Velikov (2021-02-12 14:57:56)
> Hi Chris,
>
> On Thu, 4 Feb 2021 at 12:11, Chris Wilson wrote:
> >
> > Register with /proc/gpu to provide the client runtimes for generic
> > top-like overview, e.g. gnome-system-monitor can use this information to
> &g
Since we only run test_readonly for a single sync-flag, place it in the
common block.
Signed-off-by: Chris Wilson
---
tests/i915/gem_userptr_blits.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index
Since we only run test_readonly for a single sync-flag, place it in the
common block.
Signed-off-by: Chris Wilson
---
tests/i915/gem_userptr_blits.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index
Quoting Matthew Auld (2021-02-12 13:43:46)
> On Fri, 12 Feb 2021 at 10:22, Chris Wilson wrote:
> >
> > Introduce the concept of padding the i915_vma with guard pages before
> > and aft. The major consequence is that all ordinary uses of i915_vma
> > must use i915_vma_o
of a successful heartbeat. Remove it, but then put it back to handle
large mismatches between the sysfs properties and reality.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
Suggested-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c
which is still used
by the drm_mm itself, into an adjustment of node.start at the point of
use.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
drivers/gpu
the
execobj.offset is transparent and excludes the guards. (On such platforms,
without full-ppgtt, userspace has to use relocations so the presence of
more untouchable regions within its GTT such be of no further issue.)
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggt
otable exceptions are the selftests that are testing exact
behaviour of i915_vma_pin/i915_vma_insert.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 6 ++--
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 29 ++-
drivers/gpu/drm/i915/gem/i915_gem_
ed-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 92 +++---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 ++
.../drm/i915/gt/selftest_engine_heartbeat.c | 93 ---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 5
s and detection of
false/unexpected hang reports.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
Suggested-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 107 +++---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 ++
..
ound as we force the vma to be away from the edges.
Packing the information into the single scanout i915_vma so that we do a
single padded i915_vma_insert seemed to be much easier to manage than
having to do additional i915_vma_inserts on either side (and
Quoting Ville Syrjälä (2021-02-11 16:05:59)
> On Wed, Feb 10, 2021 at 11:39:46PM +0000, Chris Wilson wrote:
> > @@ -637,6 +642,13 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
> > alignment, u64 flags)
> > alignment,
Quoting Matthew Auld (2021-02-11 14:25:41)
> On 10/02/2021 23:39, Chris Wilson wrote:
> > VT-d may cause overfetch of the scanout PTE, both before and after the
> > vma (depending on the scanout orientation). bspec recommends that we
> > provide a tile-row in either direction
Quoting Matthew Auld (2021-02-11 12:27:56)
> On 11/02/2021 11:20, Chris Wilson wrote:
> > If we want to track system/stolen as memory regions, we need to setup
> > our bookkeeping *before* we want to start allocating and reserving
> > objects in those regions. In particular,
s and detection of
false/unexpected hang reports.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
Suggested-by: CQ Tang
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 104 +++---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 ++
..
/libyaml/blob/master/src/emitter.c
under a permissive MIT licence.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
---
Converting to kerneldoc is about the last major task. It uses an
opencoded stack struct which might be nice to convert to a library,
maybe just use XArray?
It has
Rather than try and allocate objects as we perform our early HW probes,
defer the allocation for GGTT objects (such as the scratch page) to later
in the initialisation.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 38 +++-
1
-stolen memory region beforehand.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b708517d3972..139cea4443fd 100644
Quoting Hans de Goede (2021-02-11 10:36:13)
> Hi,
>
> On 2/10/21 1:48 PM, Chris Wilson wrote:
> > Quoting Hans de Goede (2021-02-10 10:37:19)
> >> Hi,
> >>
> >> On 2/10/21 12:07 AM, Chris Wilson wrote:
> >>> Quoting Hans de Goede (2021-02-09
Quoting Rodrigo Vivi (2021-02-11 04:25:17)
> On Wed, Feb 10, 2021 at 10:19:50PM +0000, Chris Wilson wrote:
> > After calling intel_gt_suspend_prepare(), the driver starts to turn off
> > various subsystems, such as clearing the GGTT, before calling
> > intel_gt_suspend_late()
Quoting Rodrigo Vivi (2021-02-11 04:28:41)
> On Wed, Feb 10, 2021 at 10:19:51PM +0000, Chris Wilson wrote:
> > Call intel_gt_suspend_late() to disable the GT before hibernation.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_p
Quoting Hans de Goede (2021-02-10 10:37:19)
> Hi,
>
> On 2/10/21 12:07 AM, Chris Wilson wrote:
> > Quoting Hans de Goede (2021-02-09 11:46:46)
> >> Hi,
> >>
> >> On 2/9/21 12:27 AM, Chris Wilson wrote:
> >>> Quoting Hans de Goede (2021-02-08 2
1 - 100 of 41256 matches
Mail list logo
