- 20 Feb, 2019 8 commits
-
-
Ramalingam C authored
All HDCP1.4 routines are gathered together, followed by the generic functions those can be extended for HDCP2.2 too. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1550338640-17470-2-git-send-email-ramalingam.c@intel.com
-
Chris Wilson authored
The idea of taking the reset lock around writing the fence register was to serialise the mmio write we also perform during the reset where those registers get clobbered. However, the lock is overkill as write tearing between reset and fence_update() is harmless; the final value of the fence register is the same. A race between revoke_fences() and fence_update() is also harmless at this point as on the fault path where this is necessary, we acquire the reset lock to coordinate ourselves in the upper layer. The danger of acquiring the reset lock again in fence_update() is that we may recurse from the shrinker along the i915_gem_fault() path. <4> [125.739646] ============================================ <4> [125.739652] WARNING: possible recursive locking detected <4> [125.739659] 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 Tainted: G U <4> [125.739666] -------------------------------------------- <4> [125.739672] gem_mmap_gtt/1017 is trying to acquire lock: <4> [125.739679] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x0/0x310 [i915] <4> [125.739848] but task is already holding lock: <4> [125.739854] 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915] <4> [125.739918] other info that might help us debug this: <4> [125.739925] Possible unsafe locking scenario: <4> [125.739930] CPU0 <4> [125.739934] ---- <4> [125.739937] lock(&dev_priv->gpu_error.reset_backoff_srcu); <4> [125.739944] lock(&dev_priv->gpu_error.reset_backoff_srcu); <4> [125.739950] *** DEADLOCK *** <4> [125.739958] May be due to missing lock nesting notation <4> [125.739966] 5 locks held by gem_mmap_gtt/1017: <4> [125.739972] #0: 00000000471f682c (&mm->mmap_sem){++++}, at: __do_page_fault+0x133/0x500 <4> [125.739987] #1: 0000000026542685 (&dev->struct_mutex){+.+.}, at: i915_gem_fault+0x1f6/0x860 [i915] <4> [125.740061] #2: 00000000a730190a (&dev_priv->gpu_error.reset_backoff_srcu){+.+.}, at: i915_reset_trylock+0x192/0x310 [i915] <4> [125.740126] #3: 00000000c828eb4f (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.25+0x0/0x30 <4> [125.740140] #4: 000000002d360d65 (shrinker_rwsem){++++}, at: shrink_slab+0x1cb/0x2c0 <4> [125.740151] stack backtrace: <4> [125.740159] CPU: 1 PID: 1017 Comm: gem_mmap_gtt Tainted: G U 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 <4> [125.740170] Hardware name: Dell Inc. OptiPlex 745 /0GW726, BIOS 2.3.1 05/21/2007 <4> [125.740180] Call Trace: <4> [125.740189] dump_stack+0x67/0x9b <4> [125.740199] __lock_acquire+0xc75/0x1b00 <4> [125.740209] ? arch_tlb_finish_mmu+0x2a/0xa0 <4> [125.740216] ? tlb_finish_mmu+0x1a/0x30 <4> [125.740222] ? zap_page_range_single+0xe2/0x130 <4> [125.740230] ? lock_acquire+0xa6/0x1c0 <4> [125.740237] lock_acquire+0xa6/0x1c0 <4> [125.740296] ? i915_clear_error_registers+0x280/0x280 [i915] <4> [125.740357] i915_reset_trylock+0x44/0x310 [i915] <4> [125.740417] ? i915_clear_error_registers+0x280/0x280 [i915] <4> [125.740426] ? lockdep_hardirqs_on+0xe0/0x1b0 <4> [125.740434] ? _raw_spin_unlock_irqrestore+0x39/0x60 <4> [125.740499] fence_update+0x218/0x470 [i915] <4> [125.740571] i915_vma_unbind+0xa6/0x550 [i915] <4> [125.740640] i915_gem_object_unbind+0xfa/0x190 [i915] <4> [125.740711] i915_gem_shrink+0x2dc/0x590 [i915] <4> [125.740722] ? ___preempt_schedule+0x16/0x18 <4> [125.740792] ? i915_gem_shrinker_scan+0xc9/0x130 [i915] <4> [125.740861] i915_gem_shrinker_scan+0xc9/0x130 [i915] <4> [125.740870] do_shrink_slab+0x143/0x3f0 <4> [125.740878] shrink_slab+0x228/0x2c0 <4> [125.740886] shrink_node+0x167/0x450 <4> [125.740894] do_try_to_free_pages+0xc4/0x340 <4> [125.740902] try_to_free_pages+0xdc/0x2e0 <4> [125.740911] __alloc_pages_nodemask+0x662/0x1110 <4> [125.740921] ? reacquire_held_locks+0xb5/0x1b0 <4> [125.740928] ? reacquire_held_locks+0xb5/0x1b0 <4> [125.740986] ? i915_reset_trylock+0x192/0x310 [i915] <4> [125.741045] ? i915_memcpy_init_early+0x30/0x30 [i915] <4> [125.741054] pte_alloc_one+0x12/0x70 <4> [125.741060] __pte_alloc+0x11/0xf0 <4> [125.741067] apply_to_page_range+0x37e/0x440 <4> [125.741127] remap_io_mapping+0x6c/0x100 [i915] <4> [125.741196] i915_gem_fault+0x5a9/0x860 [i915] <4> [125.741204] ? ptlock_alloc+0x15/0x30 <4> [125.741212] __do_fault+0x2c/0xb0 <4> [125.741218] __handle_mm_fault+0x8ee/0xfa0 <4> [125.741227] handle_mm_fault+0x196/0x3a0 <4> [125.741235] __do_page_fault+0x246/0x500 <4> [125.741243] ? page_fault+0x8/0x30 <4> [125.741250] page_fault+0x1e/0x30 <4> [125.741256] RIP: 0033:0x55d0cc456e12 <4> [125.741264] Code: b0 df ff ff 89 c2 8b 85 70 df ff ff 01 c2 8b 85 70 df ff ff 48 98 48 8d 0c 85 00 00 00 00 48 8b 85 e0 df ff ff 48 01 c8 f7 d2 <89> 10 83 85 70 df ff ff 01 81 bd 70 df ff ff ff 03 00 00 7e be 48 <4> [125.741280] RSP: 002b:00007ffc1bab7ab0 EFLAGS: 00010206 <4> [125.741287] RAX: 00007fc787cb6000 RBX: 0000000000000000 RCX: 0000000000000000 <4> [125.741295] RDX: 00000000ffffffff RSI: 0000000000005401 RDI: 0000000000000002 <4> [125.741303] RBP: 00007ffc1bab9b70 R08: 00007ffc1bab7920 R09: 000000000000001b <4> [125.741310] R10: 7165722074736554 R11: 0000000000000246 R12: 000055d0cc454a80 <4> [125.741318] R13: 00007ffc1bab9f60 R14: 0000000000000000 R15: 0000000000000000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109665Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
At a few points in our uABI, we check to see if the driver is wedged and report -EIO back to the user in that case. However, as we perform the check and reset asynchronously (where once before they were both serialised by the struct_mutex), we may instead see the temporary wedging used to cancel inflight rendering to avoid a deadlock during reset (caused by either us timing out in our reset handler, i915_wedge_on_timeout or with malice aforethought in intel_reset_prepare for a stuck modeset). If we suspect this is the case, that is we see a wedged driver *and* reset in progress, then wait until the reset is resolved before reporting upon the wedged status. v2: might_sleep() (Mika) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109580Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190220145637.23503-1-chris@chris-wilson.co.uk
-
Joonas Lahtinen authored
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Joonas Lahtinen authored
Merge tag 'topic/mei-hdcp-2019-02-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next-queued Prep patches + headers for the mei-hdcp/i915 component interfaces Also contains the prep work in the component helpers plus adjustements for the snd-hda/i915 component interface. Plus one small static inline in the drm_hdcp.h header that both i915 and mei_hdcp will need. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190219071619.GA11016@phenom.ffwll.local
-
Joonas Lahtinen authored
Doing a backmerge to be able to merge topic/mei-hdcp-2019-02-19 PR. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
On the display side, cleanups and fixes to enabled modifiers (QCOM_COMPRESSED). And otherwise mostly misc fixes all around. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGuZ5uBKpf=fHvKpTiD10nychuEY8rnE+HeRz0QMvtY5_A@mail.gmail.com
-
git://github.com/skeggsb/linuxDave Airlie authored
Various fixes/cleanups, along with initial support for SVM features utilising HMM address-space mirroring and device memory migration. There's a lot more work to do in these areas, both in terms of features and efficiency, but these can slowly trickle in later down the track. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv5bsB4rRY1Gqa_Bp_KAd-v_q1rGZ4nYmOAQhceL0Nr-Xg@mail.gmail.com
-
- 19 Feb, 2019 32 commits
-
-
Ben Skeggs authored
Removes the need for temporary VMM mappings. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Removes the need for temporary VMM mappings. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Jérôme Glisse authored
This add an ioctl to migrate a range of process address space to the device memory. On platform without cache coherent bus (x86, ARM, ...) this means that CPU can not access that range directly, instead CPU will fault which will migrate the memory back to system memory. This is behind a staging flag so that we can evolve the API. Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
-
Jérôme Glisse authored
Device memory can be use in SVM, in which case we do not have any of the existing buffer object. This commit add infrastructure to allow use of device memory without nouveau_bo. Again this is a temporary solution until a rework of GPU memory management. Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
-
Ben Skeggs authored
This uses HMM to mirror a process' CPU page tables into a channel's page tables, and keep them synchronised so that both the CPU and GPU are able to access the same memory at the same virtual address. While this code also supports Volta/Turing, it's only enabled for Pascal GPUs currently due to channel recovery being unreliable right now on the later GPUs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
For a channel to make use of SVM features, it requires a different GPU MMU configuration than we would normally use, which is not desirable to switch to unless a client is actively going to use SVM. In order to supporting SVM without more extensive changes to the userspace interfaces, the SVM_INIT ioctl needs to replace the previous configuration safely. The only way we can currently do this safely, accounting for some unlikely failure conditions, is to allocate the new VMM without destroying the last one, and prioritising the SVM-enabled configuration in the code that cares. This will get cleaned up again further down the track. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This nvclass exposes the replayable fault buffer, which will be used by SVM to manage GPU page faults. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This nvclass exposes the replayable fault buffer, which will be used by SVM to manage GPU page faults. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Some GPU units are capable of supporting "replayable" page faults, where the execution unit will wait for SW to fixup GPU page tables rather than triggering a channel-fatal fault. This feature isn't useful (it's harmful, even) unless something like HMM is being used to manage events appearing in the replayable fault buffer, so, it's disabled by default. This commit allows a client to request it be enabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Host methods exist to do at least some of what we need, but we are not currently pushing replay/cancels through a channel like UVM does as it's not clear whether it's necessary in our case (UVM also updates PTEs with the GPU). UVM also pushes a software method for fault cancels on Pascal, seemingly because the host methods don't appear to be sufficient. If/when we want to push the replay/cancel on the GPU, we can re-purpose the cancellation code here to implement that swmthd. Keep it simple for now, until we figure out exactly what we need here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This provides a somewhat more direct method of manipulating the GPU page tables, which will be required to support SVM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This will be used to support a privileged client providing PTEs directly, without a memory object to use as a reference. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
NVKM is currently responsible for managing the allocation of a client's GPU address-space, but there's various use-cases (ie. HMM address-space mirroring) where giving a client more direct control is desirable. This commit allows for a VMM to be created where the area allocated for NVKM is limited to a client-specified window, the remainder of address- space is controlled directly by the client. Leaving a window is necessary to support various internal requirements, but also to support existing allocation interfaces as not all of the HW is capable of working with a HMM allocation. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
MMU will need access to this info. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
MMU will need access to these. v2. Apply fix from Rhys Kidd to send correct FECS method for STOP_CTXSW. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Colin Ian King authored
There are a few statements that are indented incorrectly. Fix these. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
It appears that Pascal and newer need something different. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Will want to reuse this for fault replay/cancellation swmthds. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Future changes will want to add some additional things here, keep them grouped together. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This is already done during golden context creation. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Makes the code somewhat less magic. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
There's no need to avoid using copy engines if gr init fails for some reason (usually missing FW, or incomplete bring-up). It's not terribly useful for an end-user, but it'll slightly speed up suspend/resume when saving fb contents, and allow for host/ce code to be validated. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
It has no relevance to the atomic path used by newer GPUs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
It has no relevance to the atomic path used by newer GPUs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Swapped order of functions in dispnv04 to allow this, but no code changes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-