On Thu, Jan 25, 2024 at 11:08:04AM +0200, Ville Syrjälä wrote:
> On Fri, Jan 19, 2024 at 01:12:11AM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 17, 2024 at 06:46:24PM +0100, Nirmoy Das wrote:
> > >
> > > On 1/17/2024 3:13 PM, Michał Winiarski wrote:
> > >
On Tue, Jan 16, 2024 at 09:56:25AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that the GGTT PTE updates go straight to GSMBASE (bypassing
> GTTMMADR) there should be no more risk of system hangs? So the
> "binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer
> necessary,
ts/mock_gem_device.c | 1 -
> > 4 files changed, 11 insertions(+), 14 deletions(-)
>
> Michal, Michal and Tomasz, can you please check here?
>
> Thanks,
> Andi
Acked-by: Michał Winiarski
-Michał
On Fri, Aug 25, 2023 at 12:59:26PM -0400, James Zhu wrote:
>
> On 2023-07-24 17:14, Michał Winiarski wrote:
> > IDR is deprecated, and since XArray manages its own state with internal
> > locking, it simplifies the locking on DRM side.
> > Additionally, don't use the
e side by allocating minors from the >=192 range
(without the need of having >64 physical devices connected).
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/dri
scheme where 0-63 is used for primary, 64-127 is reserved
(formerly for control) and 128-191 is used for render.
For minors >= 192, we're allocating minors dynamically on a first-come,
first-served basis.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 12
1 file chan
.
Signed-off-by: Michał Winiarski
---
drivers/accel/drm_accel.c | 110 +++--
drivers/gpu/drm/drm_drv.c | 66 ++--
drivers/gpu/drm/drm_file.c | 2 +-
drivers/gpu/drm/drm_internal.h | 4 --
include/drm/drm_accel.h| 18
IDR is deprecated, and since XArray manages its own state with internal
locking, it simplifies the locking on DRM side.
Additionally, don't use the IRQ-safe variant, since operating on drm
minor is not done in IRQ context.
Signed-off-by: Michał Winiarski
Suggested-by: Matthew Wilcox
gt; v4:
Convert from IDR to XArray (Matthew Wilcox)
v4 -> v5:
Fixup IDR to XArray conversion (Matthew Wilcox)
v5 -> v6:
Also convert Accel to XArray
Rename skip_legacy_minors to force_extended_minors
Michał Winiarski (4):
drm: Use XArray instead of IDR for minors
accel: Use XArray inst
On Thu, Mar 02, 2023 at 09:34:22AM +0100, Thomas Hellström wrote:
> Add a suballocator test to get some test coverage for the new drm
> suballocator, and perform some basic timing (elapsed time).
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/Kconfig | 1 +
>
On Thu, Nov 03, 2022 at 04:23:02PM +0100, Mauro Carvalho Chehab wrote:
> Hi,
>
> I'm facing a couple of issues when testing KUnit with the i915 driver.
>
> The DRM subsystem and the i915 driver has, for a long time, his own
> way to do unit tests, which seems to be added before KUnit.
>
> I'm
On Sun, Nov 06, 2022 at 04:51:39PM +0200, Oded Gabbay wrote:
> On Wed, Nov 2, 2022 at 4:23 PM Oded Gabbay wrote:
> >
> > On Mon, Sep 12, 2022 at 12:17 AM Michał Winiarski
> > wrote:
> > >
> > > IDR is deprecated, and since XArray manages its own state wit
IDR is deprecated, and since XArray manages its own state with internal
locking, it simplifies the locking on DRM side.
Additionally, don't use the IRQ-safe variant, since operating on drm
minor is not done in IRQ context.
Signed-off-by: Michał Winiarski
Suggested-by: Matthew Wilcox
On Thu, Oct 13, 2022 at 03:18:51PM +0200, Maxime Ripard wrote:
> +static struct kunit_case drm_pick_cmdline_tests[] = {
> + KUNIT_CASE(drm_pick_cmdline_res_1920_1080_60),
> + {}
> +};
drm_test_pick_cmdline_res_1920_1080_60, since we adopted a consistent naming
convention for test cases in
scheme where 0-63 is used for primary, 64-127 is reserved
(formerly for control) and 128-191 is used for render.
For minors >= 192, we're allocating minors dynamically on a first-come,
first-served basis.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 13 +++--
1 f
e side by allocating minors from the >=192 range
(without the need of having >64 physical devices connected).
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/dri
IDR is deprecated, and since XArray manages its own state with internal
locking, it simplifies the locking on DRM side.
Additionally, don't use the IRQ-safe variant, since operating on drm
minor is not done in IRQ context.
Signed-off-by: Michał Winiarski
Suggested-by: Matthew Wilcox
gt; v4:
Convert from IDR to XArray (Matthew Wilcox)
v4 -> v5:
Fixup IDR to XArray conversion (Matthew Wilcox)
Michał Winiarski (3):
drm: Use XArray instead of IDR for minors
drm: Expand max DRM device number to full MINORBITS
drm: Introduce skip_legacy_minors modparam
drivers/gpu/
On Tue, Sep 06, 2022 at 10:02:24PM +0100, Matthew Wilcox wrote:
> On Tue, Sep 06, 2022 at 10:16:27PM +0200, Michał Winiarski wrote:
> > IDR is deprecated, and since XArray manages its own state with internal
> > locking, it simplifies the locking on DRM side.
> > Additional
scheme where 0-63 is used for primary, 64-127 is reserved
(formerly for control) and 128-191 is used for render.
For minors >= 192, we're allocating minors dynamically on a first-come,
first-served basis.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 9 +
1 file changed
e side by allocating minors from the >=192 range
(without the need of having >64 physical devices connected).
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/dri
IDR is deprecated, and since XArray manages its own state with internal
locking, it simplifies the locking on DRM side.
Additionally, don't use the IRQ-safe variant, since operating on drm
minor is not done in IRQ context.
Signed-off-by: Michał Winiarski
Suggested-by: Matthew Wilcox
gt; v4:
Convert from IDR to XArray (Matthew Wilcox)
Michał Winiarski (3):
drm: Use XArray instead of IDR for minors
drm: Expand max DRM device number to full MINORBITS
drm: Introduce skip_legacy_minors modparam
drivers/gpu/drm/drm_drv.c | 66 +++
1 f
, while dropping intel_gt_set_wedged_on_fini() from
__intel_gt_disable() proved to break some driver probe error unwind
paths as well as mock selftest exit path.
Signed-off-by: Janusz Krzysztofik
Cc: Michał Winiarski
Reviewed-by: Michał Winiarski
-Michał
---
Resending with Cc: dri-de
>
> Signed-off-by: Michal Wajdeczko
> Signed-off-by: Matthew Brost
> Cc: Michał Winiarski
Reviewed-by: Michał Winiarski
-Michał
> ---
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 51 +
> .../gt/uc/abi/guc_communication_ctb_abi.h | 106 +
> ...
Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: John Harrison
> Cc: Jon Ewins
Reviewed-by: Michał Winiarski
-Michał
> ---
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 55
> .../gt/uc/abi/guc_communication_ctb_abi.h | 106
> .../gt/uc/abi/g
trivial, I've preserved your
> v1/v2 Reviewd-by: except for patches with non-trivial changes, where I
> marked your R-b as v1/v2 applicable. Please have a look and confirm if
> you are still OK with them.
Feel free to add:
Reviewed-by: Michał Winiarski
For the whole series (with the except
it easier to review).
LGTM.
Reviewed-by: Michał Winiarski
-Michał
>
> Janusz Krzysztofik (15):
> tests/core_hotunplug: Use igt_assert_fd()
> tests/core_hotunplug: Constify dev_bus_addr string
> tests/core_hotunplug: Consolidate duplicated debug messages
> tests/co
From: Michał Winiarski
Firmware "Selected" state is a transient state - we don't expect to see
it after finishing driver probe, we even have asserts sprinkled over
i915 to confirm whether that's the case.
Unfortunately - we don't handle the transition out of "Selected" in cas
From: Michał Winiarski
It has been pointed out that information about HuC usage doesn't belong
in guc_info debugfs. Let's move "supported/used/wanted" matrix to a
separate debugfs file, keeping guc_info strictly about GuC.
Suggested-by: Daniele Ceraolo Spurio
Signed-off-by: Michał
From: Michał Winiarski
Firmware "Selected" state is a transient state - we don't expect to see
it after finishing driver probe, we even have asserts sprinkled over
i915 to confirm whether that's the case.
Unfortunately - we don't handle the transition out of "Selected" in cas
From: Michał Winiarski
It has been pointed out that information about HuC usage doesn't belong
in guc_info debugfs. Let's move "supported/used/wanted" matrix to a
separate debugfs file, keeping guc_info strictly about GuC.
Suggested-by: Daniele Ceraolo Spurio
Signed-off-by: Michał
From: Michał Winiarski
Getting wedged device on driver init is pretty much unrecoverable.
Since we're running various scenarios that may potentially hit this in
CI (module reload / selftests / hotunplug), and if it happens, it means
that we can't trust any subsequent CI results, we should just
From: Michał Winiarski
We can add taint from multiple places, printing the caller allows us to
have a better overview of what exactly caused us to do the tainting.
v2: Tweak format and print the device (Chris)
v3: Move things around (Chris)
Suggested-by: Michal Wajdeczko
Signed-off-by: Michał
From: Michał Winiarski
It is not really unexpected to hit wedge on init this way.
We're already downgrading error printk when running with fault injection,
let's use the same approach for CI tainting.
v2: Don't check fault inject in trace dump (Chris)
Signed-off-by: Michał Winiarski
Cc: Chris
Quoting Daniele Ceraolo Spurio (2020-07-01 18:45:52)
>
>
> On 7/1/2020 7:27 AM, Michał Winiarski wrote:
> > From: Michał Winiarski
> >
> > The information about platform/driver/user view of GuC firmware usage
> > currently requires user to eith
From: Michał Winiarski
We can add taint from multiple places, printing the caller allows us to
have a better overview of what exactly caused us to do the tainting.
v2: Tweak format and print the device (Chris)
Suggested-by: Michal Wajdeczko
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
From: Michał Winiarski
It is not really unexpected to hit wedge on init this way.
We're already downgrading error printk when running with fault injection,
let's use the same approach for CI tainting.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Petri Latvala
From: Michał Winiarski
Getting wedged device on driver init is pretty much unrecoverable.
Since we're running various scenarios that may potentially hit this in
CI (module reload / selftests / hotunplug), and if it happens, it means
that we can't trust any subsequent CI results, we should just
From: Michał Winiarski
Getting wedged device on driver init is pretty much unrecoverable.
Since we're running various scenarios that may potentially hit this in
CI (module reload / selftests / hotunplug), and if it happens, it means
that we can't trust any subsequent CI results, we should just
We can add taint from multiple places, printing the caller allows us to
have a better overview of what exactly caused us to do the tainting.
Suggested-by: Michal Wajdeczko
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Petri Latvala
---
drivers/gpu/drm/i915
From: Michał Winiarski
Getting wedged device on driver init is pretty much unrecoverable.
Since we're running verious scenarios that may potentially hit this in
CI (module reload / selftests / hotunplug), and if it happens, it means
that we can't trust any subsequent CI results, we should just
From: Michał Winiarski
The information about platform/driver/user view of GuC firmware usage
currently requires user to either go through kernel log or parse the
combination of "enable_guc" modparam and various debugfs entries.
Let's keep things simple and add a "supported/used
Quoting Janusz Krzysztofik (2020-06-22 18:44:15)
> Verify if a device with a GEM batch job still running on a GPU can be
> hot-unplugged cleanly and released, then recovered.
>
> v2: rebase on upstream
>
> Signed-off-by: Janusz Krzysztofik
> ---
> tests/core_hotunplug.c | 34
lateclose"
tests, since here we're closing the device FD before the unplug.
Maybe just "prime-hotunplug"? But that's up to you - either way:
Reviewed-by: Michał Winiarski
-Michał
>
> Signed-off-by: Janusz Krzysztofik
> ---
> tests/core_hotunplug.c | 36
+
> + local_debug("creating a GEM user object");
> + igt_ignore_warn(gem_create(priv.fd.drm, 4096));
Same as previous one.
(note - we could just check for proper error when we attempt to close this
handle after unplug, and the same thing a
quot;);
> + igt_ignore_warn(gem_vm_create(priv.fd.drm));
Why the "ignore_warn"?
This deserves a comment. And perhaps a word of information about why we picked
this partucular operation in the commit message (vm_create).
This is a regression test, right?
LGTM otherwise (but ag
ore adequate hotrebind/hotreplug-lateclose and add
> new variants focused on exercising the lateclose phase regardless of
> potential rebind/re-plug issues under old names.
>
> v2: rebase on upstream
>
> Signed-off-by: Janusz Krzysztofik
After addressing comments from preceding
driver code.
>
> v2: rebase on upstream
>
> Signed-off-by: Janusz Krzysztofik
After addressing comments from preceding patches:
Reviewed-by: Michał Winiarski
-Michał
> ---
> tests/core_hotunplug.c | 40 ++--
> 1 file chang
Quoting Janusz Krzysztofik (2020-06-22 18:44:09)
> Future subtests may want to access PCI attributes of the device after
> driver unbind. Refactor prepare() helper.
>
> v2: rebase on upstream
>
> Signed-off-by: Janusz Krzysztofik
> ---
> tests/core_hotunplug.c | 68
Quoting Janusz Krzysztofik (2020-06-22 18:44:08)
> The purpose of debug messages displayed by the test is to make
> identification of a subtest phase that fails more easy. Since issues
> exhibited by the test are mostly reported to dmesg, print those debug
> messages to /dev/kmsg as well.
I'm
39219] hardirqs last enabled at (204219): []
> console_unlock+0x4cd/0x5a0
> <4> [93.339250] hardirqs last disabled at (204220): []
> trace_hardirqs_off_thunk+0x1a/0x1c
> <4> [93.339277] softirqs last enabled at (204208): []
> __do_softirq+0x395/0x49e
> <4> [93.3
Quoting Janusz Krzysztofik (2020-05-18 20:17:19)
> GGTT including its scratch page is not cleaned up until driver release.
> Since DMA mappings still exist before scratch page cleanup, unmapping
> them on last device close after the driver has been already removed may
> be judged by intel-iommu
:( */
i915_vm_put(vm);
?
We're not fixing that... We're adding more :(
Unfortunately I don't have a clear answer on how to rework our init / cleanup to
be unplug friendly, and this fixes a bug, so...
Reviewed-by: Michał Winiarski
-Michał
>
> <4> [39.201062] -
Quoting Janusz Krzysztofik (2020-05-18 20:17:17)
> Contexts associated with open device file descriptors together with
> their assigned address spaces are now closed on device file close. On
> address space closure its associated DMA mappings are revoked. If the
> device is removed while being
tiple GPUs")
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_pmu.c | 41 ++---
drivers/gpu/drm/i915/i915_pmu.h | 4
2 files changed, 26 insertions(+), 19
tiple GPUs")
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_pmu.c | 18 +-
drivers/gpu/drm/i915/i915_pmu.h | 7 +--
2 files changed, 14 insertions(+), 11 deletions(-)
Attempting to bind / unbind module from devices where we have both
integrated and discreete GPU handed by i915 may lead to interesting
results where we're keeping per-device state in per-module globals.
Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
Signed-off-by: Michał
se subtests use GEM_MMAP_GTT IOCTL which may also fail,
> e.g. on hardware with no mappable aperture. Use GEM_MMAP_OFFSET
> instead and iterate MMAP_OFFSET coherent types to find one that works.
>
> Signed-off-by: Janusz Krzysztofik
> Cc: Michał Winiarski
> ---
> Hi Michał,
and their read.
>
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
Reviewed-by: Michał Winiarski
-Michał
> ---
> tests/i915/gem_ctx_isolation.c | 31 +++
> 1 file changed, 31 insertions(+)
___
We're no longer using it on execlists platforms. There's no point in
allocating it.
v2: Move scratch init to legacy ring submission backend. (Chris)
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 --
drivers/gpu/drm/i915/gt/intel_gt.c
We're no longer using it on execlists platforms. There's no point in
allocating it.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 --
drivers/gpu/drm/i915/gt/intel_gt.c| 6 ++
2 files changed, 6 insertions(+), 2 deletions
We can use it in i915 for updating parts of unmasked registers from
within a batch. We're also adding Gen8+ versions of CS_GPR registers
(aka MI_MATH_REG in the coprocessor).
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 24
of scratch, since we would use CS_GPR
anyways, let's just drop the constant values and do the bitops using
MI_MATH.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 53
drivers/gpu/drm/i915/gt
We're currently using scratch presence as a way of identifying that we
entered wedged state at driver initialization time.
Let's use a separate flag rather than rely on scratch.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_reset.c
that instead.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 45 +++-
drivers/gpu/drm/i915/gt/intel_lrc.h | 4 +++
3 files changed, 17 insertions
Default length value of MI_LOAD_REGISTER_REG is 1.
Also move it out of cmd-parser-only registers since we're going to use
it in i915.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +-
1 file changed, 1 insertion(+), 1
mplify guc client
^ Sentence case
Reviewed-by: Michał Winiarski
-Michał
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
> drivers/gpu/drm/i915/intel_guc_submission.c | 73 ++---
> drivers/gpu/drm/i915/intel_guc_submission.h | 2 -
> dri
; preempt_context as well
>
> Signed-off-by: Chris Wilson
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> Cc: Michal Wajdeczko
> Cc: Matthew Brost
> Cc: John Harrison
> Acked-by: Matthew Brost
Reviewed-by: Michał Winiarski
-Michał
> ---
> drive
-by: Michał Winiarski
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 2 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 279 +---
drivers/gpu/drm/i915/i915_gem_gtt.h | 36
3 files changed, 42 insertions(+), 275
We missed one place where we check PPGTT-only platform for PPGTT
presence. Let's remove it.
While I'm here let's assert that this particular code is never called on
pre-gen8 platforms.
References: 4bdafb9ddfa4 ("drm/i915: Remove i915.enable_ppgtt override")
Signed-off-by: Michał Win
Let's trust both the user (i915.reset modparam) and device caps instead
of attempting to reset unconditionally.
Signed-off-by: Michał Winiarski
Cc: Arkadiusz Hiler
Cc: Michal Wajdeczko
Cc: Stuart Summers
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uc.c | 5 +
1 file changed, 5
uc_events << 16;
#define the GuC enable/mask shift somewhere (also, adding a comment stating that
GuC is sharing this register with SG, and we currently don't care about
SG interrupts wouldn't hurt)
With that
Reviewed-by: Michał Winiarski
-Michał
> +
> + WARN
/mmap for intel/radeon (v3)")
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Janusz Krzysztofik
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i9
Since GEM_CREATE is trying to outsmart the user by rounding up unaligned
objects, we used to update the size returned to userspace.
This update seems to have been lost throughout the history.
References: ff72145badb8 ("drm: dumb scanout create/mmap for intel/radeon (v3)")
Signed-off-
ement")
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Zhi Wang
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 -
drivers/gpu/drm/i915/i915_gem_gtt.c | 279 +---
drivers/gpu/drm/i915/i915_gem_g
On Sun, Mar 24, 2019 at 01:47:08PM +, Chris Wilson wrote:
> Quoting Michał Winiarski (2019-03-22 16:20:37)
> > static int gen8_gmch_probe(struct i915_ggtt *ggtt)
> > @@ -3517,14 +3327,6 @@ void i915_gem_restore_gtt_mappings(struct
> > drm_i
This reverts commit 4395890a48551982549d222d1923e2833dac47cf.
It's been over a year since this was merged, and the actual users of
intel_ppat_get / intel_ppat_put never materialized.
Time to remove it!
Fixes: 4395890a4855 ("drm/i915: Introduce private PAT management")
Signed-off-
We're using pr_debug for things that we don't really want to see in the
CI log, but we may find useful during test development.
Let's upgrade the test name printer - we do want to see those in CI log.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/selftests
I'm here, let's also update the "workaround" naming.
Signed-off-by: Michał Winiarski
Cc: Anuj Phogat
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: Rafael Antognolli
Tested-by: Anuj Phogat
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_workarounds.c | 9 +++--
1 file
There are still some cases where userspace needs to change the
preemption granularity for compute workloads. Let's whitelist the
per-ctx granularity control register to allow it.
Signed-off-by: Michał Winiarski
Cc: Anuj Phogat
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: Rafael Antognolli
Cc
f-by: Chris Wilson
> Cc: Dale B Stimson
> Cc: Michał Winiarski
> ---
> .../drm/i915/selftests/intel_workarounds.c| 376 ++
> 1 file changed, 376 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/intel_workarounds.c
> b/drivers/gpu/drm/
I'm here, let's also update the "workaround" naming.
Signed-off-by: Michał Winiarski
Cc: Anuj Phogat
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: Rafael Antognolli
---
drivers/gpu/drm/i915/intel_workarounds.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/d
There are still some cases where userspace needs to change the
preemption granularity for compute workloads. Let's whitelist the
per-ctx granularity control register to allow it.
Signed-off-by: Michał Winiarski
Cc: Anuj Phogat
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: Rafael Antognolli
On Tue, Jan 08, 2019 at 03:13:02PM +, Tvrtko Ursulin wrote:
> From: Tony Ye
>
> Simple test which exercises the VME fixed function block.
>
> v2: (Tvrtko Ursulin)
> * Small cleanups like copyright date, tabs, remove unused bits.
>
> v3: (Tony Ye)
> * Added curbe data entry for dst
On Mon, Jan 07, 2019 at 11:19:31AM -0800, Matt Roper wrote:
> On Mon, Jan 07, 2019 at 01:23:50PM +0100, Michał Winiarski wrote:
> > On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> > > Quoting José Roberto de Souza (2019-01-04 19:37:00)
> > > > Ac
On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A set of subtests which exercises different paths to our shrinker code
> (including the OOM killer) in predictable and reasonable time budget.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> lib/igt_core.c
On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> Quoting José Roberto de Souza (2019-01-04 19:37:00)
> > According to Workaround database ICL also needs
> > WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> > fine-granularity preemptions per-context.
>
> I
an avoid breaking anything.
intel-vaapi-driver is doing !!(getparam) and media-driver is being optimistic
(i.e. assuming that HuC is present without any checks).
I don't know of any other components using this, and as you've mentioned in the
commit message - HuC is still under unsafe param, so:
: igt/drv_selftest/live_gem
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
> Cc: Michal Wajdeczko
Reviewed-by: Michał Winiarski
-Michał
> ---
> drivers/gpu/drm/i915/intel_guc_submission.c | 80 +++--
> 1
bb18f1b70 R08: 55fbb18f1bdc R09:
> 7ffda4e98d38
> [ 397.873802] R10: 7ffda4e97cf4 R11: 0206 R12:
> 55fbb0d32470
> [ 397.873808] R13: 7ffda4e992e0 R14: R15:
> 0000
>
> v2: It's use-after-free; not a NULL poi
> release function, making that central function more attractive to a
> couple of other callsites.
>
> The continual ulterior motive is to sweep over errors on module load
> aborting...
>
> Testcase: igt/drv_module_reload/basic-reload-inject
> Signed-off-by: Chris Wilson
>
the GuC WOPCM size.
>
> Signed-off-by: Jakub Bartmiński
> Cc: Chris Wilson
> Cc: Michał Winiarski
> Cc: Michal Wajdeczko
Cc: Jackie Li
Matches what I was able to read on GuC view of GGTT.
Reviewed-by: Michał Winiarski
-Michał
> ---
> drivers/gpu/drm/i915/intel_guc.c | 50 ++
; time being suppress the assertion to get the test re-enabled.
>
> Testcase: igt/drv_module_reload/basic-reload-inject
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
> Cc: Michal Wajdeczko
Reviewed-by: Michał Winiarski
-Michał
> ---
> drivers/gpu/drm/i915/i915_gem_gt
On Wed, Jul 18, 2018 at 11:56:27AM +0100, Chris Wilson wrote:
> Only pm_rpm still uses the igt_trash_aperture() and so we can remove it
> from the lib and in the process convert it over from the legacy
> libdrm_intel.
>
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
e
> will either restore guc submission or mark the driver as wedged, making
> the reset back to execlists pointless.
> v3: Move reset.prepare across
>
> Testcase: igt/drv_module_reload/basic-reload-inject
> Testcase: igt/gem_eio
> Signed-off-by: Chris Wilson
> Cc:
hich it does) or use small partials to avoid mmaping the whole object
> (which it does). Rather than assume, use the debugfs interface to force
> the eviction of the bound objects.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Michał Winiarski
-Michał
> ---
> tests/gem_ca
On Tue, Jul 17, 2018 at 03:52:41PM +0200, Michał Winiarski wrote:
> On Tue, Jul 17, 2018 at 03:53:19PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Most plattforms don't have a fixed 1MiB WOPCM so stop saying that they
> > do.
> >
> > Al
(wopcm);
> +
> + if (!HAS_GUC(i915))
> + return;
Single use dev_priv, drop the local?
> +
> + /* FIXME use the size we actually probed from the hardware */
> wopcm->size = GEN9_WOPCM_SIZE;
I don't think that's exposed to us in any way.
I'd drop
Causing kvmgt part to no longer build. Let's remove it.
Reported-by: Tomasz Lis
Signed-off-by: Michał Winiarski
Cc: Changbin Du
Cc: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i9
1 - 100 of 616 matches
Mail list logo
