[PATCH v7 3/3] drm: Expand max DRM device number to full MINORBITS

2024-08-23 Thread Michał Winiarski
numbering 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. Acked-by: James Zhu Signed-off-by: Michał Winiarski --- drivers/gpu/

[PATCH v7 2/3] accel: Use XArray instead of IDR for minors

2024-08-23 Thread Michał Winiarski
. Acked-by: James Zhu 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

[PATCH v7 1/3] drm: Use XArray instead of IDR for minors

2024-08-23 Thread Michał Winiarski
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. Suggested-by: Matthew Wilcox Acked-by: James Zhu Signed-off-by: M

[PATCH v7 0/3] drm: Use full allocated minor range for DRM

2024-08-23 Thread Michał Winiarski
) v4 -> v5: Fixup IDR to XArray conversion (Matthew Wilcox) v5 -> v6: Also convert Accel to XArray Rename skip_legacy_minors to force_extended_minors v6 -> v7: Drop the force_extended_minors patch intended for debug Rebase on latest drm-tip Update the cover letter, pointing out libd

Re: [PATCH v6 0/4] drm: Use full allocated minor range for DRM

2024-08-13 Thread Michał Winiarski
/ Acks. If you're interested to have a go at it - I can resend it. It should still apply on latest drm-tip. -Michał > > Alex > > On Mon, Jul 24, 2023 at 5:15 PM Michał Winiarski > wrote: > > > > 64 DRM device nodes is not enough for everyone. > > Upgrade

Re: Re: [PATCH v3 05/16] drm/i915: Disable the "binder"

2024-01-25 Thread Michał Winiarski
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: > > >

Re: [PATCH v3 05/16] drm/i915: Disable the "binder"

2024-01-17 Thread Michał Winiarski
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, di

Re: [Intel-gfx] [PATCH 0/3] drm/i915: nuke i915->gt0

2023-10-02 Thread Michał Winiarski
915/selftests/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ł

Re: [Intel-gfx] [PATCH v6 1/4] drm: Use XArray instead of IDR for minors

2023-08-28 Thread Michał Winiarski
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 us

[Intel-gfx] [PATCH v6 4/4] drm: Introduce force_extended_minors modparam

2023-07-24 Thread Michał Winiarski
rspace 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

[Intel-gfx] [PATCH v6 3/4] drm: Expand max DRM device number to full MINORBITS

2023-07-24 Thread Michał Winiarski
numbering 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 ++

[Intel-gfx] [PATCH v6 2/4] accel: Use XArray instead of IDR for minors

2023-07-24 Thread Michał Winiarski
. 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

[Intel-gfx] [PATCH v6 1/4] drm: Use XArray instead of IDR for minors

2023-07-24 Thread Michał Winiarski
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 W

[Intel-gfx] [PATCH v6 0/4] drm: Use full allocated minor range for DRM

2023-07-24 Thread Michał Winiarski
er) v3 -> 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 X

Re: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test

2023-03-26 Thread Michał Winiarski
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 + > dri

Re: [Intel-gfx] KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL

2022-11-07 Thread Michał Winiarski
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 no

Re: [Intel-gfx] [PATCH v5 1/3] drm: Use XArray instead of IDR for minors

2022-11-07 Thread Michał Winiarski
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

[Intel-gfx] [PATCH v3] drm: Use XArray instead of IDR for minors

2022-11-07 Thread Michał Winiarski
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 ---

Re: [Intel-gfx] [PATCH v5 07/22] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

2022-10-20 Thread Michał Winiarski
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

[Intel-gfx] [PATCH v5 2/3] drm: Expand max DRM device number to full MINORBITS

2022-09-11 Thread Michał Winiarski
numbering 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 +++

[Intel-gfx] [PATCH v5 3/3] drm: Introduce skip_legacy_minors modparam

2022-09-11 Thread Michał Winiarski
rspace 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

[Intel-gfx] [PATCH v5 1/3] drm: Use XArray instead of IDR for minors

2022-09-11 Thread Michał Winiarski
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 W

[Intel-gfx] [PATCH v5 0/3] drm: Use full allocated minor range for DRM

2022-09-11 Thread Michał Winiarski
er) v3 -> 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 dr

Re: [Intel-gfx] [PATCH v4 1/3] drm: Use XArray instead of IDR for minors

2022-09-11 Thread Michał Winiarski
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

[Intel-gfx] [PATCH v4 2/3] drm: Expand max DRM device number to full MINORBITS

2022-09-06 Thread Michał Winiarski
numbering 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 +

[Intel-gfx] [PATCH v4 3/3] drm: Introduce skip_legacy_minors modparam

2022-09-06 Thread Michał Winiarski
rspace 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

[Intel-gfx] [PATCH v4 1/3] drm: Use XArray instead of IDR for minors

2022-09-06 Thread Michał Winiarski
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 W

[Intel-gfx] [PATCH v4 0/3] drm: Use full allocated minor range for DRM

2022-09-06 Thread Michał Winiarski
er) v3 -> 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 +++---

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Mark GPU wedging on driver unregister unrecoverable

2021-09-10 Thread Michał Winiarski
, 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

Re: [Intel-gfx] [RFC PATCH 08/97] drm/i915/guc: Keep strict GuC ABI definitions

2021-05-24 Thread Michał Winiarski
; > 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 + > ...

Re: [Intel-gfx] [PATCH] drm/i915/guc: Keep strict GuC ABI definitions separate

2021-02-24 Thread Michał Winiarski
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

Re: [Intel-gfx] [PATCH i-g-t v6 00/24] tests/core_hotunplug: Fixes and enhancements

2020-09-14 Thread Michał Winiarski
s are 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 (

Re: [Intel-gfx] [RFC PATH i-g-t 00/15] tests/core_hotunplug: Fixes and enhancements

2020-07-22 Thread Michał Winiarski
grained split makes 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 mess

[Intel-gfx] [PATCH v2 2/2] drm/i915/huc: Adjust HuC state accordingly after GuC fetch error

2020-07-08 Thread Michał Winiarski
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 "Select

[Intel-gfx] [PATCH 1/2] drm/i915/uc: Extract uc usage details into separate debugfs

2020-07-08 Thread Michał Winiarski
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-

[Intel-gfx] [PATCH 2/2] drm/i915/huc: Adjust HuC state accordingly after GuC fetch error

2020-07-07 Thread Michał Winiarski
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 "Select

[Intel-gfx] [PATCH 1/2] drm/i915/uc: Extract uc usage details into separate debugfs

2020-07-07 Thread Michał Winiarski
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-

[Intel-gfx] [PATCH v3 1/3] drm/i915: Reboot CI if we get wedged during driver init

2020-07-06 Thread Michał Winiarski
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 s

[Intel-gfx] [PATCH v3 2/3] drm/i915: Print caller when tainting for CI

2020-07-06 Thread Michał Winiarski
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ł

[Intel-gfx] [PATCH v2 3/3] drm/i915: Don't taint when using fault injection

2020-07-06 Thread Michał Winiarski
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ł Winia

Re: [Intel-gfx] [PATCH] drm/i915/guc: Expand guc_info debugfs with more information

2020-07-06 Thread Michał Winiarski
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 either g

[Intel-gfx] [PATCH v2 2/3] drm/i915: Print caller when tainting for CI

2020-07-06 Thread Michał Winiarski
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

[Intel-gfx] [PATCH 3/3] drm/i915: Don't taint when using fault injection

2020-07-06 Thread Michał Winiarski
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: Pet

[Intel-gfx] [PATCH v3 1/3] drm/i915: Reboot CI if we get wedged during driver init

2020-07-06 Thread Michał Winiarski
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 s

[Intel-gfx] [PATCH v2 1/2] drm/i915: Reboot CI if we get wedged during driver init

2020-07-06 Thread Michał Winiarski
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 s

[Intel-gfx] [PATCH 2/2] drm/i915: Print caller when tainting for CI

2020-07-06 Thread 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. Suggested-by: Michal Wajdeczko Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Michal Wajdeczko Cc: Petri Latvala --- drivers/gpu/drm/i915

[Intel-gfx] [PATCH] drm/i915: Reboot CI if we get wedged during driver init

2020-07-01 Thread Michał Winiarski
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 s

[Intel-gfx] [PATCH] drm/i915/guc: Expand guc_info debugfs with more information

2020-07-01 Thread Michał Winiarski
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

Re: [Intel-gfx] [RFC PATCH i-g-t v2 8/8] tests/core_hotunplug: Add 'GEM batch' variant

2020-06-25 Thread Michał Winiarski
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 +++

Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v2 7/8] tests/core_hotunplug: Add 'PRIME handle' variant

2020-06-25 Thread Michał Winiarski
quot;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.

Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v2 6/8] tests/core_hotunplug: Add 'GEM object' variant

2020-06-25 Thread Michał Winiarski
gt_require_gem(priv.fd.drm); > + > + 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 thi

Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v2 5/8] tests/core_hotunplug: Add 'GEM address space' variant

2020-06-25 Thread Michał Winiarski
ress space"); > + 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 (bu

Re: [Intel-gfx] [RFC PATCH i-g-t v2 4/8] tests/core_hotunplug: Add 'lateclose before recover' variants

2020-06-25 Thread Michał Winiarski
to more 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 prec

Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v2 3/8] tests/core_hotunplug: Add unbind-unplug-rescan variant

2020-06-25 Thread Michał Winiarski
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

Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v2 2/8] tests/core_hotunplug: Use PCI device sysfs entry, not DRM

2020-06-25 Thread Michał Winiarski
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 +---

Re: [Intel-gfx] [RFC PATCH i-g-t v2 1/8] tests/core_hotunplug: Duplicate debug messages in dmesg

2020-06-25 Thread Michał Winiarski
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 not

Re: [Intel-gfx] [RFC PATCH 4/4] drm/i915: Move UC firmware cleanup from driver_release to _remove

2020-05-27 Thread Michał Winiarski
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

Re: [Intel-gfx] [RFC PATCH 3/4] drm/i915: Move GGTT cleanup from driver_release to _remove

2020-05-27 Thread Michał Winiarski
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 cod

Re: [Intel-gfx] [RFC PATCH 2/4] drm/i915: Release GT resources on driver remove

2020-05-27 Thread Michał Winiarski
:( */ 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> [3

Re: [Intel-gfx] [RFC PATCH 1/4] drm/i915: Drop user contexts on driver remove

2020-05-27 Thread Michał Winiarski
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 op

[Intel-gfx] [PATCH 2/2] drm/i915/pmu: Avoid using globals for PMU events

2020-02-19 Thread Michał Winiarski
t multiple 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(+

[Intel-gfx] [PATCH 1/2] drm/i915/pmu: Avoid using globals for CPU hotplug state

2020-02-19 Thread Michał Winiarski
t multiple 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(-

[Intel-gfx] [PATCH] drm/i915/pmu: Avoid using globals for per-device state

2020-02-19 Thread Michał Winiarski
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: M

Re: [Intel-gfx] [RFC PATCH i-g-t] tests/gem_userptr_blits: Refresh map-fixed-invalidate* subtests

2020-02-13 Thread Michał Winiarski
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ł,

Re: [Intel-gfx] [PATCH i-g-t v2] i915/gem_ctx_isolation: Check nonpriv values are kept across switch

2019-09-30 Thread Michał Winiarski
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(+) ___

[Intel-gfx] [PATCH v2 6/6] drm/i915/execlists: Don't allocate scratch

2019-09-26 Thread Michał Winiarski
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-gfx] [PATCH 6/6] drm/i915/execlists: Don't allocate scratch

2019-09-26 Thread Michał Winiarski
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

[Intel-gfx] [PATCH 4/6] drm/i915: Add definitions for MI_MATH command

2019-09-26 Thread Michał Winiarski
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

[Intel-gfx] [PATCH 5/6] drm/i915: Don't use scratch in WA batch.

2019-09-26 Thread Michał Winiarski
TER_REG instead 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 dri

[Intel-gfx] [PATCH 1/6] drm/i915: Define explicit wedged on init reset state

2019-09-26 Thread Michał Winiarski
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/int

[Intel-gfx] [PATCH 3/6] drm/i915: Adjust length of MI_LOAD_REGISTER_REG

2019-09-26 Thread Michał Winiarski
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(

[Intel-gfx] [PATCH 2/6] drm/i915/execlists: Use per-process HWSP as scratch

2019-09-26 Thread Michał Winiarski
s use 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

Re: [Intel-gfx] [PATCH 02/12] drm/i915/guc: simplify guc client

2019-07-10 Thread Michał Winiarski
simplify 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 - >

Re: [Intel-gfx] [PATCH 01/12] drm/i915/guc: Remove preemption support for current fw

2019-07-10 Thread Michał Winiarski
e > 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ł > --- >

[Intel-gfx] [PATCH 1/2] Revert "drm/i915: Introduce private PAT management"

2019-07-02 Thread Michał Winiarski
ff-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(+)

[Intel-gfx] [PATCH 2/2] drm/i915/gtt: Don't check PPGTT presence on PPGTT-only platforms

2019-07-02 Thread Michał Winiarski
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

[Intel-gfx] [PATCH] drm/i915/guc: Check if reset is supported before attempting to reset GuC

2019-06-14 Thread Michał Winiarski
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 chang

Re: [Intel-gfx] [PATCH v4 17/22] drm/i915/guc: Correctly handle GuC interrupts on Gen11

2019-05-27 Thread Michał Winiarski
uc_events = dev_priv->guc_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ł > + &

[Intel-gfx] [PATCH v2] drm/i915: Update size upon return from GEM_CREATE

2019-03-26 Thread Michał Winiarski
p 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

[Intel-gfx] [PATCH] drm/i915: Update size upon return from GEM_CREATE

2019-03-26 Thread Michał Winiarski
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-

[Intel-gfx] [PATCH v2] Revert "drm/i915: Introduce private PAT management"

2019-03-25 Thread Michał Winiarski
management") 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_

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Introduce private PAT management"

2019-03-25 Thread Michał Winiarski
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

[Intel-gfx] [PATCH] Revert "drm/i915: Introduce private PAT management"

2019-03-22 Thread Michał Winiarski
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

[Intel-gfx] [PATCH] drm/i915/selftests: Upgrade printing test/subtest name to pr_info

2019-03-05 Thread Michał Winiarski
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

[Intel-gfx] [PATCH 2/2] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

2019-03-05 Thread Michał Winiarski
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 Antognoll

[Intel-gfx] [PATCH 1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads

2019-03-05 Thread Michał Winiarski
GPU hang. While 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

Re: [Intel-gfx] [PATCH 06/38] drm/i915/selftests: Check that whitelisted registers are accessible

2019-03-01 Thread Michał Winiarski
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/

[Intel-gfx] [PATCH 1/2] drm/i915/icl: Default to Thread Group preemption for compute workloads

2019-02-27 Thread Michał Winiarski
GPU hang. While 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 del

[Intel-gfx] [PATCH 2/2] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

2019-02-27 Thread Michał Winiarski
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 Antog

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] tests/gem_media_vme: Simple test to exercise the VME block

2019-01-10 Thread Michał Winiarski
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 surface

Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

2019-01-09 Thread Michał Winiarski
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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/gem_shrink: Exercise OOM and other routes to shrinking in reasonable time

2019-01-07 Thread Michał Winiarski
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

Re: [Intel-gfx] [PATCH] drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD

2019-01-07 Thread Michał Winiarski
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 mus

Re: [Intel-gfx] [PATCH] drm/i915/huc: Normalize HuC status returned by I915_PARAM_HAS_HUC

2018-10-16 Thread Michał Winiarski
fully we can 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 unde

Re: [Intel-gfx] [PATCH] drm/i915/guc: Restore preempt-context across S3/S4

2018-09-20 Thread Michał Winiarski
: 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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Protect guc_fini_wq() against module load abort

2018-07-26 Thread Michał Winiarski
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 NUL

Re: [Intel-gfx] [PATCH] drm/i915: Pull unpin map into vma release

2018-07-24 Thread Michał Winiarski
> 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 >

Re: [Intel-gfx] [PATCH v4 1/5] drm/i915/guc: Avoid wasting memory on incorrect GuC pin bias

2018-07-20 Thread Michał Winiarski
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 ++

Re: [Intel-gfx] [PATCH] drm/i915: Suppress assertion for i915_ggtt_disable_guc

2018-07-20 Thread Michał Winiarski
e > 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_g

Re: [Intel-gfx] [PATCH i-g-t] lib: Move trash_bos to their only user

2018-07-19 Thread Michał Winiarski
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 I&#

  1   2   3   4   5   6   7   >