- 31 May, 2019 6 commits
-
-
Chris Wilson authored
Currently the purgeable objects, I915_MADV_DONTNEED, are mixed in the normal bound/unbound lists. Every shrinker pass starts with an attempt to purge from this set of unneeded objects, which entails us doing a walk over both lists looking for any candidates. If there are none, and since we are shrinking we can reasonably assume that the lists are full!, this becomes a very slow futile walk. If we separate out the purgeable objects into own list, this search then becomes its own phase that is preferentially handled during shrinking. Instead the cost becomes that we then need to filter the purgeable list if we want to distinguish between bound and unbound objects. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190530203500.26272-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
The i915.alpha_support module parameter has caused some confusion along the way. Add new i915.force_probe parameter to specify PCI IDs of devices to probe, when the devices are recognized but not automatically probed by the driver. The name is intended to reflect what the parameter effectively does, avoiding any overloaded semantics of "alpha" and "support". The parameter supports "" to disable, "<pci-id>,[<pci-id>,...]" to enable force probe for one or more devices, and "*" to enable force probe for all known devices. Also add new CONFIG_DRM_I915_FORCE_PROBE config option to replace the DRM_I915_ALPHA_SUPPORT option. This defaults to "*" if DRM_I915_ALPHA_SUPPORT=y. Instead of replacing i915.alpha_support immediately, let the two coexist for a while, with a deprecation message, for a transition period. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190506134801.28751-1-jani.nikula@intel.com
-
Colin Ian King authored
The assignment of err is using the incorrect pointer vaddr that has not been initialized. Fix this by using the correct pointer obj instead. Addresses-Coverity: ("Uninitialized pointer read") Fixes: 6501aa4e ("drm/i915: add in-kernel blitter client") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Chris Wilson authored
The normal behaviour is to periodically check for a mmio access error, and once detected enable mmio access checking. However this is useless if the error only occurs once during module load, and so we may miss such errors in CI. To allow ourselves to catch them, allow CI to opt into always enabling mmio debugging. Signed-off-by:
-
Chris Wilson authored
Since the next entry is an offset from a pointer, it can not be NULL. For simplicity, drop the extra conditional before calling cond_resched() Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Janusz Krzysztofik authored
In order to support driver hot unbind, some cleanup operations, now performed on PCI driver remove, must be called later, after all device file descriptors are closed. Split out those operations from the tail of pci_driver.remove() callback and put them into drm_driver.release() which is called as soon as all references to the driver are put. As a result, those cleanups will be now run on last drm_dev_put(), either still called from pci_driver.remove() if all device file descriptors are already closed, or on last drm_release() file operation. Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by:
-
- 30 May, 2019 2 commits
-
-
Matthew Auld authored
The plan is to use the blitter engine for async object clearing when using local memory, but before we can move the worker to get_pages() we have to first tame some more of our struct_mutex usage. With this in mind we should be able to upstream the object clearing as some selftests, which should serve as a guinea pig for the ongoing locking rework and upcoming async get_pages() framework. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: CQ Tang <cq.tang@intel.com> Reviewed-by:
-
Matthew Auld authored
Some steps in gen6_alloc_va_range require the HW to be awake, so ideally we should be grabbing the wakeref ourselves and not relying on the caller already holding it for us. Suggested-by:
-
- 29 May, 2019 5 commits
-
-
Chris Wilson authored
An interesting issue cropped with making the pagetables be allocated and freed concurrently (i.e. removing their grandeous struct_mutex guard) was that we would overflow the page stash. This happens when we have multiple allocators grabbing WC pages such that we fill the vm's local page stash and then when we free another page, the page stash is already full and we overflow. The fix is quite simple: to check for a full page stash before adding another. This results in us keeping a vm local page stash around for much longer, which is both a blessing and a curse. Signed-off-by:
-
Jani Nikula authored
This reverts commit 1ac159e2 ("drm/i915: Expand subslice mask"), which kills ICL due to GEM_BUG_ON() sanity checks before CI even gets a chance to do anything. The commit exposes an issue in commit 1e40d4ae ("drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads"), which will also need to be addressed. There's a proposed fix [1], but considering the seeming uncertainty with the fix as well as the size of the regressing commit (in this context, the one that actually brings down ICL), this warrants a revert to get ICL working, and gives us time to get all of this right without rushing. Even if this means shooting the messenger. <3>[ 9.426327] intel_sseu_get_subslices:46 GEM_BUG_ON(slice >= sseu->max_slices) <4>[ 9.426355] ------------[ cut here ]------------ <2>[ 9.426357] kernel BUG at drivers/gpu/drm/i915/gt/intel_sseu.c:46! <4>[ 9.426371] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 9.426377] CPU: 1 PID: 364 Comm: systemd-udevd Not tainted 5.2.0-rc2-CI-CI_DRM_6159+ #1 <4>[ 9.426385] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411 05/02/2019 <4>[ 9.426444] RIP: 0010:intel_sseu_get_subslices+0x8a/0xe0 [i915] <4>[ 9.426452] Code: d5 76 b7 e0 48 8b 35 9d 24 21 00 49 c7 c0 07 f0 72 a0 b9 2e 00 00 00 48 c7 c2 00 8e 6d a0 48 c7 c7 a5 14 5b a0 e8 36 3c be e0 <0f> 0b 48 c7 c1 80 d5 6f a0 ba 30 00 00 00 48 c7 c6 00 8e 6d a0 48 <4>[ 9.426468] RSP: 0018:ffffc9000037b9c8 EFLAGS: 00010282 <4>[ 9.426475] RAX: 000000000000000f RBX: 0000000000000000 RCX: 0000000000000000 <4>[ 9.426482] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88849e346f98 <4>[ 9.426490] RBP: ffff88848a200000 R08: 0000000000000004 R09: ffff88849d50b000 <4>[ 9.426497] R10: 0000000000000000 R11: ffff88849e346f98 R12: ffff88848a209e78 <4>[ 9.426505] R13: 0000000003000000 R14: ffff88848a20b1a8 R15: 0000000000000000 <4>[ 9.426513] FS: 00007f73d5ae8680(0000) GS:ffff88849fc80000(0000) knlGS:0000000000000000 <4>[ 9.426521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 9.426527] CR2: 0000561417b01260 CR3: 0000000494764003 CR4: 0000000000760ee0 <4>[ 9.426535] PKRU: 55555554 <4>[ 9.426538] Call Trace: <4>[ 9.426585] wa_init_mcr+0xd5/0x110 [i915] <4>[ 9.426597] ? lock_acquire+0xa6/0x1c0 <4>[ 9.426645] icl_gt_workarounds_init+0x21/0x1a0 [i915] <4>[ 9.426694] ? i915_driver_load+0xfcf/0x18a0 [i915] <4>[ 9.426739] gt_init_workarounds+0x14c/0x230 [i915] <4>[ 9.426748] ? _raw_spin_unlock_irq+0x24/0x50 <4>[ 9.426789] intel_gt_init_workarounds+0x1b/0x30 [i915] <4>[ 9.426835] i915_driver_load+0xfd7/0x18a0 [i915] <4>[ 9.426843] ? lock_acquire+0xa6/0x1c0 <4>[ 9.426850] ? __pm_runtime_resume+0x4f/0x80 <4>[ 9.426857] ? _raw_spin_unlock_irqrestore+0x4c/0x60 <4>[ 9.426863] ? _raw_spin_unlock_irqrestore+0x4c/0x60 <4>[ 9.426870] ? lockdep_hardirqs_on+0xe3/0x1b0 <4>[ 9.426915] i915_pci_probe+0x29/0xa0 [i915] <4>[ 9.426923] pci_device_probe+0x9e/0x120 <4>[ 9.426930] really_probe+0xea/0x3c0 <4>[ 9.426936] driver_probe_device+0x10b/0x120 <4>[ 9.426942] device_driver_attach+0x4a/0x50 <4>[ 9.426948] __driver_attach+0x97/0x130 <4>[ 9.426954] ? device_driver_attach+0x50/0x50 <4>[ 9.426960] bus_for_each_dev+0x74/0xc0 <4>[ 9.426966] bus_add_driver+0x13f/0x210 <4>[ 9.426971] ? 0xffffffffa083b000 <4>[ 9.426976] driver_register+0x56/0xe0 <4>[ 9.426982] ? 0xffffffffa083b000 <4>[ 9.426987] do_one_initcall+0x58/0x300 <4>[ 9.426994] ? do_init_module+0x1d/0x1f6 <4>[ 9.427001] ? rcu_read_lock_sched_held+0x6f/0x80 <4>[ 9.427007] ? kmem_cache_alloc_trace+0x261/0x290 <4>[ 9.427014] do_init_module+0x56/0x1f6 <4>[ 9.427020] load_module+0x24d1/0x2990 <4>[ 9.427032] ? __se_sys_finit_module+0xd3/0xf0 <4>[ 9.427037] __se_sys_finit_module+0xd3/0xf0 <4>[ 9.427047] do_syscall_64+0x55/0x1c0 <4>[ 9.427053] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 9.427059] RIP: 0033:0x7f73d5609839 <4>[ 9.427064] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48 <4>[ 9.427082] RSP: 002b:00007ffdf34477b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 <4>[ 9.427091] RAX: ffffffffffffffda RBX: 00005559fd5d7b40 RCX: 00007f73d5609839 <4>[ 9.427099] RDX: 0000000000000000 RSI: 00007f73d52e8145 RDI: 000000000000000f <4>[ 9.427106] RBP: 00007f73d52e8145 R08: 0000000000000000 R09: 00007ffdf34478d0 <4>[ 9.427114] R10: 000000000000000f R11: 0000000000000246 R12: 0000000000000000 <4>[ 9.427121] R13: 00005559fd5c90f0 R14: 0000000000020000 R15: 00005559fd5d7b40 <4>[ 9.427131] Modules linked in: i915(+) mei_hdcp x86_pkg_temp_thermal coretemp snd_hda_intel crct10dif_pclmul crc32_pclmul snd_hda_codec snd_hwdep e1000e snd_hda_core ghash_clmulni_intel ptp snd_pcm cdc_ether usbnet mii pps_core mei_me mei prime_numbers btusb btrtl btbcm btintel bluetooth ecdh_generic ecc <4>[ 9.427254] ---[ end trace af3eeb543bd66e66 ]--- [1] http://patchwork.freedesktop.org/patch/msgid/20190528200655.11605-1-chris@chris-wilson.co.uk References: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6159/fi-icl-u2/pstore0-1517155098_Oops_1.log References: 1e40d4ae ("drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads") Fixes: 1ac159e2 ("drm/i915: Expand subslice mask") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Yunwei Zhang <yunwei.zhang@intel.com> Acked-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
In intel_wakeref_auto, we use refcount_inc_not_zero to detect the first use and initialise the timer. On doing so, we have to avoid using refcount_inc on that zero count as the debug code flags that as an error: refcount_t: increment on 0; use-after-free. Rearrange the code so that if we know the count is 0 and we are initialising, we explicitly set it to 1. Fixes: b27e35ae ("drm/i915: Keep user GGTT alive for a minimum of 250ms") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528154053.22004-1-chris@chris-wilson.co.uk
-
Dan Carpenter authored
We should check "request[n]" instead of just "request". Fixes: 78e41ddd ("drm/i915: Apply an execution_mask to the virtual_engine") Signed-off-by:
-
Chris Wilson authored
Before we start prepping the system for an atomic modeset, wake the device up. We then keep track of this wakeref until we complete the atomic commit, so we hold keep the device awake for all potential HW access, and do not allow the device to sleep with a pending modeset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110771Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528075354.22341-1-chris@chris-wilson.co.uk
-
- 28 May, 2019 27 commits
-
-
Stuart Summers authored
Currently, the subslice_mask runtime parameter is stored as an array of subslices per slice. Expand the subslice mask array to better match what is presented to userspace through the I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is then calculated: slice * subslice stride + subslice index / 8 v2: fix spacing in set_sseu_info args use set_sseu_info to initialize sseu data when building device status in debugfs rename variables in intel_engine_types.h to avoid checkpatch warnings v3: update headers in intel_sseu.h v4: add const to some sseu_dev_info variables use sseu->eu_stride for EU stride calculations v5: address review comments from Tvrtko and Daniele v6: remove extra space in intel_sseu_get_subslices return the correct subslice enable in for_each_instdone add GEM_BUG_ON to ensure user doesn't pass invalid ss_mask size use printk formatted string for subslice mask v7: remove string.h header and rebase Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by:Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190524154022.13575-6-stuart.summers@intel.com
-
Stuart Summers authored
Move functions to intel_sseu.h and remove inline qualifier. Additionally, ensure these are all prefixed with intel_sseu_* to match the convention of other functions in i915. v2: fix spacing from checkpatch warning v3: squash helper function changes into a single patch break 80 character line to fix checkpatch warning move get/set_eus helpers to intel_device_info.c v4: Remove intel_ prefix from static functions in intel_device_info.c and correctly copy changes to stride calculation in those functions. Acked-by: -
Stuart Summers authored
Add a new function to return the number of subslices per slice to consolidate code usage. v2: rebase on changes to move sseu struct to intel_sseu.h v3: add intel_* prefix to sseu_subslices_per_slice Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Stuart Summers authored
Subslice stride and EU stride are calculated multiple times in i915_query. Move this calculation to a macro to reduce code duplication. v2: update headers in intel_sseu.h v3: use GEN_SSEU_STRIDE for stride calculations in intel_sseu.h apply s/bits/max_entries/ to GEN_SSEU_STRIDE parameter Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: -
Stuart Summers authored
In the GETPARAM ioctl handler, use a local variable to consolidate usage of SSEU runtime info. v2: add const to sseu_dev_info variable Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Leave a hint in dmesg when we reject a configuration attempting to use C8 planes without the legacy LUT loaded. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
When the first C8 plane gets enabled, or the last one gets disabled we may need to enable/disable the pipe gamma for the other active planes. Check for that and run through the normal intel_color_check() path. Signed-off-by:
-
Chris Wilson authored
An old optimisation to reduce the number of atomics per batch sadly relies on struct_mutex for coordination. In order to remove struct_mutex from serialising object/context closing, always taking and releasing an active reference on first use / last use greatly simplifies the locking. Signed-off-by:
-
Chris Wilson authored
Rename the engine this HW context is currently active upon (that we are flying upon) to disambiguate between the mixture of different active terms (and prevent conflict in future patches). Signed-off-by:
-
Chris Wilson authored
Continuing the decluttering of i915_gem.c by moving the client self throttling into its own file. Signed-off-by:
-
Chris Wilson authored
Continuing the decluttering of i915_gem.c by moving the object busy checking into its own file. Signed-off-by:
-
Chris Wilson authored
Continuing the decluttering of i915_gem.c by moving the object wait decomposition into its own file. Signed-off-by:
-
Chris Wilson authored
Use the per-object local lock to control the cache domain of the individual GEM objects, not struct_mutex. This is a huge leap forward for us in terms of object-level synchronisation; execbuffers are coordinated using the ww_mutex and pread/pwrite is finally fully serialised again. Signed-off-by:
-
Chris Wilson authored
Out scatterlist utility routines can be pulled out of i915_gem.h for a bit more decluttering. v2: Push I915_GTT_PAGE_SIZE out of i915_scatterlist itself and into the caller. Signed-off-by:
-
Chris Wilson authored
Continuing the theme of separating out the GEM clutter. Signed-off-by:
-
Chris Wilson authored
Continuing the decluttering of i915_gem.c, that of the read/write domains, perhaps the biggest of GEM's follies? Signed-off-by:
-
Chris Wilson authored
Continuing the decluttering of i915_gem.c, now the turn of do_mmap and the faulthandlers Signed-off-by:
-
Chris Wilson authored
Continuing the decluttering of i915_gem.c, this time the legacy physical object. Signed-off-by:
-
Chris Wilson authored
Split the plain old shmem object into its own file to start decluttering i915_gem.c v2: Lose the confusing, hysterical raisins, suffix of _gtt. Signed-off-by:
-
Chris Wilson authored
Currently the code for manipulating the pages on an object is still residing in i915_gem.c, move it to i915_gem_object.c Signed-off-by:
-
Chris Wilson authored
Declutter i915_drv/gem.h by moving the ioctl API into its own header. Signed-off-by:
-
Chris Wilson authored
For convenience in avoiding inline spaghetti, keep the type definition as a separate header. Signed-off-by:
-
Chris Wilson authored
It was moved over to gt/ but the backmerge brought it back from the dead. Signed-off-by:
-
Uma Shankar authored
Attach HDR metadata property to connector object. v2: Rebase v3: Updated the property name as per updated name while creating hdr metadata property v4: Added platform check as suggested by Ville. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
-
Uma Shankar authored
Added state readout for DRM infoframe and enabled state validation for DRM infoframe. v2: Addressed Ville's review comments and dropped the unused drm infoframe read at intel_hdmi_init. v3: Removed a redundant platform check as per Ville's comment. Signed-off-by:
-
Uma Shankar authored
Enable writing of HDR metadata infoframe to panel. The data will be provid by usersapace compositors, based on blending policies and passsed to driver through a blob property. v2: Rebase v3: Fixed a warning message v4: Addressed Shashank's review comments v5: Rebase. Added infoframe calculation in compute config. v6: Addressed Shashank's review comment. Added HDR metadata support from GEN10 onwards as per Shashank's recommendation. v7: Addressed Shashank's review comments v8: Added Shashank's RB. v9: Addressed Ville's review comments. v10: Removed a redundant check as core already handles it, as per Ville's comment. v11: Added the metadata available check to avoid failure in compute_config. Signed-off-by:
-
Ville Syrjälä authored
This patch enables infoframes on GLK+ to be used to send HDR metadata to HDMI sink. v2: Addressed Shashank's review comment. v3: Addressed Shashank's review comment. v4: Added Shashank's RB. v5: Dropped hdr_metadata_change check while modeset, as per Ville's suggestion. v6: Removed an unused and duplicate bit defintion, as per Ville's comment. Signed-off-by:
-
