aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2019-10-04drm/i915/dp: remove static variable for aux last statusJani Nikula2-3/+3
Add aux_busy_last_status to intel_dp. Don't bother with initializing to all ones; the only difference is potentially missing logging for one error case if the readout is all zeros. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-04drm/i915/execlists: Skip redundant resubmissionChris Wilson1-1/+16
If we unwind the active requests, and on resubmission discover that we intend to preempt the active contexts with themselves, simply skip the ELSP submission. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-04drm/i915/tgl: Add the Thunderbolt PLL divider valuesImre Deak1-2/+40
The Thunderbolt PLL divider values on TGL differ from the ICL ones, update the PLL parameter calculation function accordingly. Bspec: 49204 v2: - Remove unused refclk config. (José) Cc: Jose Souza <[email protected]> Cc: Clinton A Taylor <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Mika Westerberg <[email protected]> Tested-by: Mika Westerberg <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jose Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-03Revert "drm/i915: Fix DP-MST crtc_mask"Ville Syrjälä1-1/+1
This reverts commit 4eaceea3a00f8e936a7f48dcd0c975a57f88930f. Several userspace clients (modesetting ddx and mutter+wayland at least) handle encoder.possible_crtcs incorrectly. What they essentially do is the following: possible_crtcs = ~0; for_each_possible_encoder(connector) possible_crtcs &= encoder->possible_crtcs; Ie. they calculate the intersection of the possible_crtcs for the connector when they really should be calculating the union instead. In our case each MST encoder now has just one unique bit set, and so the intersection is always zero. The end result is that MST connectors can't be lit up because no crtc can be found to drive them. I've submitted a fix for the modesetting ddx [1], and complained on #wayland about mutter, so hopefully the situation will improve in the future. In the meantime we have regression, and so must go back to the old way of misconfiguring possible_crtcs in the kernel. [1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 Cc: Jonas Ådahl <[email protected]> Cc: Stanislav Lisovskiy <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Dhinakaran Pandiyan <[email protected]> Cc: Lucas De Marchi <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111507 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]> (cherry picked from commit e838bfa8e170415fa3cc8e83ecb171e809c0c422) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-03Merge drm/drm-next into drm-misc-nextMaxime Ripard362-17247/+24109
We haven't done any backmerge for a while due to the merge window, and it starts to become an issue for komeda. Let's bring 5.4-rc1 in. Signed-off-by: Maxime Ripard <[email protected]>
2019-10-03drm/i915: use DRM_DEBUG_KMS() instead of drm_dbg(DRM_UT_KMS, ...)Jani Nikula1-4/+4
Unify on current common usage to allow repurposing drm_dbg() later. Fix newlines while at it. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-03drm/i915: use DRM_ERROR() instead of drm_err()Jani Nikula1-4/+4
Unify on current common usage to allow repurposing drm_err() later. Fix newlines while at it. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-02drm/i915: Fix g4x sprite scaling stride check with GTT remappingVille Syrjälä1-2/+3
I forgot to update the g4x sprite scaling stride check when GTT remapping was introduced. The stride of the original framebuffer is irrelevant when remapping is used and instead we want to check the stride of the remapped view. Also drop the duplicate width_bytes check. We already check that a few lines earlier. Fixes: df79cf441910 ("drm/i915: Store the final plane stride in plane_state") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> (cherry picked from commit 006e570128f413759b9df64b51bae79903679c9b) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-02drm/i915/dp: Fix dsc bpp calculations, v5.Maarten Lankhorst5-99/+107
There was a integer wraparound when mode_clock became too high, and we didn't correct for the FEC overhead factor when dividing, with the calculations breaking at HBR3. As a result our calculated bpp was way too high, and the link width limitation never came into effect. Print out the resulting bpp calcululations as a sanity check, just in case we ever have to debug it later on again. We also used the wrong factor for FEC. While bspec mentions 2.4%, all the calculations use 1/0.972261, and the same ratio should be applied to data M/N as well, so use it there when FEC is enabled. This fixes the FIFO underrun we are seeing with FEC enabled. Changes since v2: - Handle fec_enable in intel_link_compute_m_n, so only data M/N is adjusted. (Ville) - Fix initial hardware readout for FEC. (Ville) Changes since v3: - Remove bogus fec_to_mode_clock. (Ville) Changes since v4: - Use the correct register for icl. (Ville) - Split hw readout to a separate patch. Signed-off-by: Maarten Lankhorst <[email protected]> Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC") Cc: <[email protected]> # v5.0+ Cc: Manasi Navare <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]> (cherry picked from commit ed06efb801bd291e935238d3fba46fa03d098f0e) Signed-off-by: Rodrigo Vivi <[email protected]>
2019-10-03drm/i915/selftests: Exercise potential false lite-restoreChris Wilson2-4/+194
If execlists's lite-restore is based on the common GEM context tag rather than the per-intel_context LRCA, then a context switch between two intel_contexts on the same engine derived from the same GEM context will perform a lite-restore instead of a full context switch. We can exploit this by poisoning the ringbuffer of the first context and trying to trick a simple RING_TAIL update (i.e. lite-restore) v2: Also check what happens if preempt ce[0] with ce[1] (both instances on the same engine from the same parent context) [Tvrtko] Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-02drm/i915/mg: Use tc_port instead of port parameter to MG registersJosé Roberto de Souza2-83/+81
All the MG registers is based on the tc_port not port, so MG_PHY_PORT_LN() was subtracting port and PORT_C what is very fragile. So replacing port to tc_port in all MG register macros and users like we have for DKL. Cc: Lucas De Marchi <[email protected]> Cc: Imre Deak <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-02drm/i915: Clean up encoder->crtc_mask setupVille Syrjälä7-15/+14
Use BIT(pipe) for better legibility when populating the crtc_mask for encoders. Also remove the redundant possible_crtcs setup for the TV encoder. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-02drm/i915: Populate possible_crtcs correctlyVille Syrjälä1-1/+16
Don't advertize non-exisiting crtcs in the encoder possible_crtcs bitmask. Reviewed-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-02drm/i915/gem: Refactor tests on obj->ops->flagsChris Wilson1-5/+12
We repeat obj->ops->flags in our object checks, so pull that into its own little helper for clarity. Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-02drm/i915/selftests: Extract random_offset() for use with a prngChris Wilson3-5/+33
For selftests, we desire repeatability and so prefer using a prng with known seed over true randomness. Extract random_offset() as a selftest utility that can take the prng state. Suggested-by: Matthew Auld <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-02drm/i915: Fix g4x sprite scaling stride check with GTT remappingVille Syrjälä1-2/+3
I forgot to update the g4x sprite scaling stride check when GTT remapping was introduced. The stride of the original framebuffer is irrelevant when remapping is used and instead we want to check the stride of the remapped view. Also drop the duplicate width_bytes check. We already check that a few lines earlier. Fixes: df79cf441910 ("drm/i915: Store the final plane stride in plane_state") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]>
2019-10-02drm/i915: Polish intel_tv_mode_valid()Ville Syrjälä1-4/+3
Drop the tv_mode NULL check since intel_tv_mode_find() never actually returns NULL, and flip the condition around so that the MODE_OK case is at the end, which is customary to all the other .mode_valid() implementations. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2019-10-02drm/i915: Limit MST modes based on plane size tooVille Syrjälä1-1/+2
When adding the max plane size checks to the .mode_valid() hooks I naturally forgot about MST. Take care of that one as well. Cc: Manasi Navare <[email protected]> Cc: Sean Paul <[email protected]> Cc: José Roberto de Souza <[email protected]> Cc: Maarten Lankhorst <[email protected]> Fixes: 2d20411e25a3 ("drm/i915: Don't advertise modes that exceed the max plane size") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: José Roberto de Souza <[email protected]>
2019-10-02drm/i915/display: abstract all vgaarb access to intel_vga.[ch]Jani Nikula10-146/+194
Split out the code related to vga client and vgaarb all over the place into new intel_vga.[ch]. No functional changes. Cc: Ville Syrjälä <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-02drm/i915/userptr: Never allow userptr into the mappable GGTTChris Wilson5-1/+19
Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to invalidate userptr objects which also happen to be pulled into GGTT mmaps. That is when we unbind the userptr object (on mmu invalidation), we revoke all CPU mmaps, which may then recurse into mmu invalidation. We looked for ways of breaking the cycle, but the revocation on invalidation is required and cannot be avoided. The only solution we could see was to not allow such GGTT bindings of userptr objects in the first place. In practice, no one really wants to use a GGTT mmapping of a CPU pointer... Just before Daniel's explosive lockdep patches land in v5.4-rc1, we got a genuine blip from CI: <4>[ 246.793958] ====================================================== <4>[ 246.793972] WARNING: possible circular locking dependency detected <4>[ 246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G U <4>[ 246.794003] ------------------------------------------------------ <4>[ 246.794017] kswapd0/145 is trying to acquire lock: <4>[ 246.794030] 000000003f565be6 (&dev->struct_mutex/1){+.+.}, at: userptr_mn_invalidate_range_start+0x18f/0x220 [i915] <4>[ 246.794250] but task is already holding lock: <4>[ 246.794263] 000000001799cef9 (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe6/0x2a0 <4>[ 246.794291] which lock already depends on the new lock. <4>[ 246.794307] the existing dependency chain (in reverse order) is: <4>[ 246.794322] -> #3 (&anon_vma->rwsem){++++}: <4>[ 246.794344] down_write+0x33/0x70 <4>[ 246.794357] __vma_adjust+0x3d9/0x7b0 <4>[ 246.794370] __split_vma+0x16a/0x180 <4>[ 246.794385] mprotect_fixup+0x2a5/0x320 <4>[ 246.794399] do_mprotect_pkey+0x208/0x2e0 <4>[ 246.794413] __x64_sys_mprotect+0x16/0x20 <4>[ 246.794429] do_syscall_64+0x55/0x1c0 <4>[ 246.794443] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 246.794456] -> #2 (&mapping->i_mmap_rwsem){++++}: <4>[ 246.794478] down_write+0x33/0x70 <4>[ 246.794493] unmap_mapping_pages+0x48/0x130 <4>[ 246.794519] i915_vma_revoke_mmap+0x81/0x1b0 [i915] <4>[ 246.794519] i915_vma_unbind+0x11d/0x4a0 [i915] <4>[ 246.794519] i915_vma_destroy+0x31/0x300 [i915] <4>[ 246.794519] __i915_gem_free_objects+0xb8/0x4b0 [i915] <4>[ 246.794519] drm_file_free.part.0+0x1e6/0x290 <4>[ 246.794519] drm_release+0xa6/0xe0 <4>[ 246.794519] __fput+0xc2/0x250 <4>[ 246.794519] task_work_run+0x82/0xb0 <4>[ 246.794519] do_exit+0x35b/0xdb0 <4>[ 246.794519] do_group_exit+0x34/0xb0 <4>[ 246.794519] __x64_sys_exit_group+0xf/0x10 <4>[ 246.794519] do_syscall_64+0x55/0x1c0 <4>[ 246.794519] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 246.794519] -> #1 (&vm->mutex){+.+.}: <4>[ 246.794519] i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915] <4>[ 246.794519] i915_address_space_init+0x9f/0x160 [i915] <4>[ 246.794519] i915_ggtt_init_hw+0x55/0x170 [i915] <4>[ 246.794519] i915_driver_probe+0xc9f/0x1620 [i915] <4>[ 246.794519] i915_pci_probe+0x43/0x1b0 [i915] <4>[ 246.794519] pci_device_probe+0x9e/0x120 <4>[ 246.794519] really_probe+0xea/0x3d0 <4>[ 246.794519] driver_probe_device+0x10b/0x120 <4>[ 246.794519] device_driver_attach+0x4a/0x50 <4>[ 246.794519] __driver_attach+0x97/0x130 <4>[ 246.794519] bus_for_each_dev+0x74/0xc0 <4>[ 246.794519] bus_add_driver+0x13f/0x210 <4>[ 246.794519] driver_register+0x56/0xe0 <4>[ 246.794519] do_one_initcall+0x58/0x300 <4>[ 246.794519] do_init_module+0x56/0x1f6 <4>[ 246.794519] load_module+0x25bd/0x2a40 <4>[ 246.794519] __se_sys_finit_module+0xd3/0xf0 <4>[ 246.794519] do_syscall_64+0x55/0x1c0 <4>[ 246.794519] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 246.794519] -> #0 (&dev->struct_mutex/1){+.+.}: <4>[ 246.794519] __lock_acquire+0x15d8/0x1e90 <4>[ 246.794519] lock_acquire+0xa6/0x1c0 <4>[ 246.794519] __mutex_lock+0x9d/0x9b0 <4>[ 246.794519] userptr_mn_invalidate_range_start+0x18f/0x220 [i915] <4>[ 246.794519] __mmu_notifier_invalidate_range_start+0x85/0x110 <4>[ 246.794519] try_to_unmap_one+0x76b/0x860 <4>[ 246.794519] rmap_walk_anon+0x104/0x280 <4>[ 246.794519] try_to_unmap+0xc0/0xf0 <4>[ 246.794519] shrink_page_list+0x561/0xc10 <4>[ 246.794519] shrink_inactive_list+0x220/0x440 <4>[ 246.794519] shrink_node_memcg+0x36e/0x740 <4>[ 246.794519] shrink_node+0xcb/0x490 <4>[ 246.794519] balance_pgdat+0x241/0x580 <4>[ 246.794519] kswapd+0x16c/0x530 <4>[ 246.794519] kthread+0x119/0x130 <4>[ 246.794519] ret_from_fork+0x24/0x50 <4>[ 246.794519] other info that might help us debug this: <4>[ 246.794519] Chain exists of: &dev->struct_mutex/1 --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem <4>[ 246.794519] Possible unsafe locking scenario: <4>[ 246.794519] CPU0 CPU1 <4>[ 246.794519] ---- ---- <4>[ 246.794519] lock(&anon_vma->rwsem); <4>[ 246.794519] lock(&mapping->i_mmap_rwsem); <4>[ 246.794519] lock(&anon_vma->rwsem); <4>[ 246.794519] lock(&dev->struct_mutex/1); <4>[ 246.794519] *** DEADLOCK *** v2: Say no to mmap_ioctl Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111744 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111870 Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-01drm/i915/dp: Fix DP MST error after unplugging TypeC cableSrinivasan S1-1/+1
This patch avoids DP MST payload error message in dmesg, as it is trying to update the payload to the disconnected DP MST device. After DP MST device is disconnected we should not be updating the payload and hence remove the error. v2: Removed the connector status check and converted from error to debug. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111632 Signed-off-by: Srinivasan S <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-10-01drm/i915: Initialise breadcrumb lists on the virtual engineChris Wilson1-0/+1
With deferring the breadcrumb signalling to the virtual engine (thanks preempt-to-busy) we need to make sure the lists and irq-worker are ready to send a signal. [41958.710544] BUG: kernel NULL pointer dereference, address: 0000000000000000 [41958.710553] #PF: supervisor write access in kernel mode [41958.710556] #PF: error_code(0x0002) - not-present page [41958.710558] PGD 0 P4D 0 [41958.710562] Oops: 0002 [#1] SMP [41958.710565] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U 5.3.0+ #207 [41958.710568] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [41958.710602] RIP: 0010:i915_request_enable_breadcrumb+0xe1/0x130 [i915] [41958.710605] Code: 8b 44 24 30 48 89 41 08 48 89 08 48 8b 85 98 01 00 00 48 8d 8d 90 01 00 00 48 89 95 98 01 00 00 49 89 4c 24 28 49 89 44 24 30 <48> 89 10 f0 80 4b 30 10 c6 85 88 01 00 00 00 e9 1a ff ff ff 48 83 [41958.710609] RSP: 0018:ffffc90000003de0 EFLAGS: 00010046 [41958.710612] RAX: 0000000000000000 RBX: ffff888735424480 RCX: ffff8887cddb2190 [41958.710614] RDX: ffff8887cddb3570 RSI: ffff888850362190 RDI: ffff8887cddb2188 [41958.710617] RBP: ffff8887cddb2000 R08: ffff8888503624a8 R09: 0000000000000100 [41958.710619] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8887cddb3548 [41958.710622] R13: 0000000000000000 R14: 0000000000000046 R15: ffff888850362070 [41958.710625] FS: 0000000000000000(0000) GS:ffff88885ea00000(0000) knlGS:0000000000000000 [41958.710628] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [41958.710630] CR2: 0000000000000000 CR3: 0000000002c09002 CR4: 00000000001606f0 [41958.710633] Call Trace: [41958.710636] <IRQ> [41958.710668] __i915_request_submit+0x12b/0x160 [i915] [41958.710693] virtual_submit_request+0x67/0x120 [i915] [41958.710720] __unwind_incomplete_requests+0x131/0x170 [i915] [41958.710744] execlists_dequeue+0xb40/0xe00 [i915] [41958.710771] execlists_submission_tasklet+0x10f/0x150 [i915] [41958.710776] tasklet_action_common.isra.17+0x41/0xa0 [41958.710781] __do_softirq+0xc8/0x221 [41958.710785] irq_exit+0xa6/0xb0 [41958.710788] smp_apic_timer_interrupt+0x4d/0x80 [41958.710791] apic_timer_interrupt+0xf/0x20 [41958.710794] </IRQ> Fixes: cb2377a919bb ("drm/i915: Fixup preempt-to-busy vs reset of a virtual request") Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-30drm/i915/gt: Only unwedge if we can reset firstChris Wilson1-1/+7
Unwedging the GPU requires a successful GPU reset before we restore the default submission, or else we may see residual context switch events that we were not expecting. v2: Pull in the special-case reset_clobbers_display, and explain why it should be safe in the context of unwedging. v3: Just forget all about resets before unwedging if it will clobber the display; risk it all. Reported-by: Janusz Krzysztofik <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Janusz Krzysztofik <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-30drm/i915/selftests: Exercise context switching in parallelChris Wilson1-0/+225
We currently test context switching on each engine as a basic stress test (just verifying that nothing explodes if we execute 2 requests from different contexts sequentially). What we have not tested is what happens if we try and do so on all available engines simultaneously, putting our SW and the HW under the maximal stress. v2: Clone the set of engines from the first context into the secondary contexts. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/selftests: Provide a mock GPU reset routineChris Wilson1-1/+10
For those mock tests that may wish to pretend triggering a GPU reset and processing the cleanup. Signed-off-by: Chris Wilson <[email protected]> Cc: Andi Shyti <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/selftests: Distinguish mock device from no wakerefChris Wilson2-3/+2
On systems that have no runtime-pm, we mark the wakeref as being -1. We therefore cannot use that value for the mock-gt indicator, so opt for -ENODEV instead. The wakeref should never be an error value -- one hopes! Signed-off-by: Chris Wilson <[email protected]> Cc: Andi Shyti <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915: Pass intel_gt to has-reset?Chris Wilson8-27/+31
As we execute GPU resets on a gt/ basis, and use the intel_gt as the primary for all other reset functions, also use it for the has-reset? predicates. Gradually simplifying the churn of pointers. Signed-off-by: Chris Wilson <[email protected]> Cc: Andi Shyti <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/selftests: Do not try to sanitize mock HWChris Wilson1-1/+2
If we are mocking the device, skip trying to sanitize the pm HW state. Signed-off-by: Chris Wilson <[email protected]> Cc: Andi Shyti <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915: simplify i915_gem_init_earlyMatthew Auld3-8/+3
i915_gem_init_early doesn't need to return anything. Signed-off-by: Matthew Auld <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915: check for kernel_contextMatthew Auld1-2/+4
Explosions during early driver init on the error path. Make sure we fail gracefully. [ 9547.672258] BUG: kernel NULL pointer dereference, address: 000000000000007c [ 9547.672288] #PF: supervisor read access in kernel mode [ 9547.672292] #PF: error_code(0x0000) - not-present page [ 9547.672296] PGD 8000000846b41067 P4D 8000000846b41067 PUD 797034067 PMD 0 [ 9547.672303] Oops: 0000 [#1] SMP PTI [ 9547.672307] CPU: 1 PID: 25634 Comm: i915_selftest Tainted: G U 5.3.0-rc8+ #73 [ 9547.672313] Hardware name: /NUC6i7KYB, BIOS KYSKLi70.86A.0050.2017.0831.1924 08/31/2017 [ 9547.672395] RIP: 0010:intel_context_unpin+0x9/0x100 [i915] [ 9547.672400] Code: 6b 60 00 e9 17 ff ff ff bd fc ff ff ff e9 7c ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 41 54 55 53 <8b> 47 7c 83 f8 01 74 26 8d 48 ff f0 0f b1 4f 7c 48 8d 57 7c 75 05 [ 9547.672413] RSP: 0018:ffffae8ac24ff878 EFLAGS: 00010246 [ 9547.672417] RAX: ffff944a1b7842d0 RBX: ffff944a1b784000 RCX: ffff944a12dd6fa8 [ 9547.672422] RDX: ffff944a1b7842c0 RSI: ffff944a12dd5328 RDI: 0000000000000000 [ 9547.672428] RBP: 0000000000000000 R08: ffff944a11e5d840 R09: 0000000000000000 [ 9547.672433] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 9547.672438] R13: ffffffffc11aaf00 R14: 00000000ffffffe4 R15: ffff944a0e29bf38 [ 9547.672443] FS: 00007fc259b88ac0(0000) GS:ffff944a1f880000(0000) knlGS:0000000000000000 [ 9547.672449] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9547.672454] CR2: 000000000000007c CR3: 0000000853346003 CR4: 00000000003606e0 [ 9547.672459] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 9547.672464] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 9547.672469] Call Trace: [ 9547.672518] intel_engine_cleanup_common+0xe3/0x270 [i915] [ 9547.672567] execlists_destroy+0xe/0x30 [i915] [ 9547.672669] intel_engines_init+0x94/0xf0 [i915] [ 9547.672749] i915_gem_init+0x191/0x950 [i915] Signed-off-by: Matthew Auld <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/tgl: initialize TC and TBT portsLucas De Marchi1-1/+6
Now that TC support was added, initialize DDIs. Reviewed-by: José Roberto de Souza <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/tgl: Fix dkl link trainingJosé Roberto de Souza1-7/+7
Link training is failling when running link at 2.7GHz and 1.62GHz and following BSpec pll algorithm. Comparing the values calculated and the ones from the reference table it looks like MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO should not always set to 5. For DP ports ICL mg pll algorithm sets it to 10 or 5 based on div2 value, that matches with dkl hardcoded table. So implementing this way as it proved to work in HW and leaving a comment so we know why it do not match BSpec. v4: Using the same is_dp check as ICL, need testing on HDMI over tc port Issue reported on BSpec 49204. Reviewed-by: Imre Deak <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/tgl: Add dkl phy programming sequencesClinton A Taylor2-28/+154
Added DKL Phy sequences and helpers functions to program voltage swing, clock gating and dp mode. It is not written in DP enabling sequence but "PHY Clockgating programming" states that clock gating should be enabled after the link training but doing so causes all the following trainings to fail so not enabling it for. v2: Setting the right HIP_INDEX_REG bits (José) v3: Adding the meaning of each column of tgl_dkl_phy_ddi_translations Adding if gen >= 12 on intel_ddi_hdmi_level() and intel_ddi_pre_enable_hdmi() instead of reuse part of gen >= 11 if v4: Moved the DP_MODE lane programing to another patch as ICL also needed it Sharing icl_phy_set_clock_gating() and icl_program_mg_dp_mode() with TGL as bits and programing as now it almost identical to ICL BSpec: 49292 BSpec: 49190 Cc: Imre Deak <[email protected]> Cc: Lucas De Marchi <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Signed-off-by: Clinton A Taylor <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/tc: Update DP_MODE programmingClinton A Taylor4-41/+72
BSpec was updated(r146548) with a new MG_DP_MODE Programming table, now taking in consideration the pin assignment and allowing us to optimize power by shutting down available but not needed lanes. It was tested on ICL and TGL, with adaptors that used pin assignment C and B, reversing the connector and going to different modes testing the not needed lane shutdown. v5: Using crtc_state->lane_count instead of dp.lane_count BSpec: 21735 BSpec: 49292 Cc: Imre Deak <[email protected]> Cc: Lucas De Marchi <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Clinton A Taylor <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/dmc: Update ICL DMC version to v1.09Anusha Srivatsa1-2/+2
We have a new version of DMC for ICL - v1.09. This version adds the Half Refresh Rate capability into DMC. Cc: José Roberto de Souza <[email protected]> Signed-off-by: Anusha Srivatsa <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/huc: fix version parsing from CSS headerDaniele Ceraolo Spurio2-24/+7
The HuC FW has silently switched to encoding the version the same way as the GuC FW does, i.e. major.minor.patch instead of just major.minor. All the current blobs follow the new scheme, but since minor and patch are both zero there is no difference in the end results and we happily load them. New binaries, however, will have non-zero values in there, so we need to make sure to parse them correctly. Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Anusha Srivatsa <[email protected]> Cc: Michal Wajdeczko <[email protected]> Reviewed-by: Stuart Summers <[email protected]> Acked-by: Michal Wajdeczko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915: Update DRIVER_DATE to 20190927Joonas Lahtinen1-2/+2
Signed-off-by: Joonas Lahtinen <[email protected]>
2019-09-27drm/i915: Extract GT render sleep (rc6) managementAndi Shyti18-843/+916
Continuing the theme of breaking intel_pm.c up in a reasonable chunk of powermanagement utilities, pull out the rc6 setup into its GT handler. Based on a patch by Chris Wilson. Signed-off-by: Andi Shyti <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-27drm/i915/selftests: Exercise concurrent submission to all enginesChris Wilson1-0/+125
The simplest and most maximal submission we can do, a thread to submit requests unto each engine. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-26drm/i915: Add definitions for MI_MATH commandMichał Winiarski2-0/+27
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 <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-26drm/i915/perf: Fix use of kernel-doc format in structure membersAnna Karas1-7/+7
Insert structure members names into their descriptions to follow kernel-doc format. Cc: Chris Wilson <[email protected]> Signed-off-by: Anna Karas <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-26drm/i915: Don't disable interrupts for intel_engine_breadcrumbs_irq()Sebastian Andrzej Siewior4-14/+7
The function intel_engine_breadcrumbs_irq() is always invoked from an interrupt handler and for that reason it invokes (as an optimisation) only spin_lock() for locking assuming that the interrupts are already disabled. The function intel_engine_signal_breadcrumbs() is provided to disable interrupts while the former function is invoked so that assumption is also true for callers from preemptible context. On PREEMPT_RT local_irq_disable() really disables interrupts and this forbids to invoke spin_lock() which becomes a sleeping spinlock. This is also problematic with `threadirqs' in conjunction with irq_work. With force threading the interrupt handler, the handler is invoked with disabled BH but with interrupts enabled. This is okay and the lock itself is never acquired in IRQ context. This changes with irq_work (signal_irq_work()) which _still_ invokes intel_engine_breadcrumbs_irq() from IRQ context. Lockdep should see this and complain. Acquire the locks in intel_engine_breadcrumbs_irq() with _irqsave() suffix and let all callers invoke intel_engine_breadcrumbs_irq() directly instead using intel_engine_signal_breadcrumbs(). Reported-by: Clark Williams <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-26drm/i915: Drop the IRQ-off assertsSebastian Andrzej Siewior1-3/+0
The lockdep_assert_irqs_disabled() check is needless. The previous lockdep_assert_held() check ensures that the lock is acquired and while the lock is acquired lockdep also prints a warning if the interrupts are not disabled if they have to be. These IRQ-off asserts trigger on PREEMPT_RT because the locks become sleeping locks and do not really disable interrupts. Remove lockdep_assert_irqs_disabled(). Reported-by: Clark Williams <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-26drm/i915: Adjust length of MI_LOAD_REGISTER_REGMichał Winiarski1-1/+1
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 <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-26drm/i915/execlists: Use per-process HWSP as scratchMichał Winiarski3-35/+17
Some of our commands (MI_FLUSH_DW / PIPE_CONTROL) require a post-sync write operation to be performed. Currently we're using dedicated VMA for PIPE_CONTROL and global HWSP for MI_FLUSH_DW. On execlists platforms, each of our contexts has an area that can be used as scratch space. Let's use that instead. Signed-off-by: Michał Winiarski <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-26drm/i915: Define explicit wedged on init reset stateMichał Winiarski4-2/+26
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 <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-26drm/i915: Small joiner RAM buffer size is platform-specificMatt Roper1-7/+17
According to the bspec, GLK/CNL have a smaller small joiner RAM buffer than ICL+. This feels like something that could easily change again on future platforms, so let's just add a function to return the proper per-platform buffer size. That may also slightly simplify the upcoming bigjoiner enabling. Since we have to change intel_dp_dsc_get_output_bpp()'s signature to pass the dev_priv down for the platform check, let's take the opportunity to also make that function static since it isn't used outside the intel_dp file. v2: Minor rebase on top of Maarten's changes. Bspec: 20388 Bspec: 49259 Cc: Manasi Navare <[email protected]> Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Manasi Navare <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-25drm/i915/tgl: Add memory type decoding for bandwidth checkingJames Ausmus1-16/+39
The memory type values have changed in TGL, so we need to translate them differently than ICL. While we're moving it, fix up the ICL translation for LPDDR4. BSpec: 53998 v2: Fix up ICL LPDDR4 entry (Ville); Drop unused values from TGL (Ville) Cc: Ville Syrjälä <[email protected]> Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: James Ausmus <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Stuart Summers <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-25drm/i915/tgl: Return the mg/dkl pll as DDI clock for new TC portsJosé Roberto de Souza1-0/+2
TGL added 2 more TC ports that currently are not being handled by icl_pll_to_ddi_clk_sel(), so adding those. Reviewed-by: Lucas De Marchi <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Imre Deak <[email protected]> Reported-by: Imre Deak <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2019-09-25drm/i915/tgl: Add dkl phy pll calculationsJosé Roberto de Souza2-12/+62
Extending ICL mg calculations to also support dkl calculations. v3: Fixing iref_trim calculation for 38400 refclock BSpec: 49204 Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Vandita Kulkarni <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.