- 03 Dec, 2019 10 commits
-
-
Chris Wilson authored
In order to avoid keeping a reference on the i915_vma (which is long overdue!) we have to coordinate all the possible lifetimes and only use the vma while we know it is alive. In this episode, we are reminded that while idle, the closed vma are destroyed. So if the GT idles while we are working with the vma, the vma itself becomes invalid. First class i915_vma here we come, but in the meantime keep piling on the straw. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191203155032.3137263-1-chris@chris-wilson.co.uk
-
José Roberto de Souza authored
Moving just to simplify handling as there is no change in behavior. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191202222513.337777-3-jose.souza@intel.com
-
José Roberto de Souza authored
Disabling pipe/transcoder clock before power down sink could cause sink lost signal, causing it to trigger a hotplug to notify source that link signal was lost. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
José Roberto de Souza authored
If the CRTC is going from enabled to disabled and it is a port sync slave, it needs to check to the old state to be disabled before the port sync master. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Matt Roper authored
Let's move handling and reset for gen11 display IRQs to their own functions, similar to how we deal with GT interrupts. This will make the top-level functions a bit easier to read and potentially make things easier to deal with in the future if new platforms wind up needing different display handling logic. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191202171608.3361125-1-matthew.d.roper@intel.comReviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com>
-
Chris Wilson authored
Rather than assume if and only if the engine->default_state is not set that the context is invalid, instead track when we know the context has valid state -- either because we have copied the default_state or we have completed a context switch to save the HW state. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191203124155.3019926-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Only along the submission path can we guarantee that the locked request is indeed from a foreign engine, and so the nesting of engine/rq is permissible. On the submission tasklet (process_csb()), we may find ourselves competing with the normal nesting of rq/engine, invalidating our nesting. As we only use the spinlock for debug purposes, skip the debug if we cannot acquire the spinlock for safe validation - catching 99% of the bugs is better than causing a hard lockup. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191203152631.3107653-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Check the pending request submission is valid: that it at least has a reference for the submission and that the request is on the active list. Signed-off-by:
-
Chris Wilson authored
Once inside a request, inside the timeline->mutex, pinning is verboten. <4> [896.032829] ====================================================== <4> [896.032831] WARNING: possible circular locking dependency detected <4> [896.032835] 5.4.0-rc8-CI-Patchwork_15533+ #1 Tainted: G U <4> [896.032838] ------------------------------------------------------ <4> [896.032841] gem_exec_parall/3720 is trying to acquire lock: <4> [896.032844] ffff888401863270 (&kernel#2){+.+.}, at: i915_request_create+0x16/0x1c0 [i915] <4> [896.032915] but task is already holding lock: <4> [896.032917] ffff8883ec1c93c0 (&vm->mutex){+.+.}, at: i915_vma_pin+0xf3/0x11c0 [i915] <4> [896.032952] which lock already depends on the new lock. <4> [896.032954] the existing dependency chain (in reverse order) is: <4> [896.032956] -> #1 (&vm->mutex){+.+.}: <4> [896.032961] __mutex_lock+0x9a/0x9d0 <4> [896.032995] i915_vma_pin+0xf3/0x11c0 [i915] <4> [896.033033] intel_renderstate_emit+0xb9/0x9e0 [i915] <4> [896.033081] i915_gem_init+0x5a9/0xa50 [i915] <4> [896.033112] i915_driver_probe+0xb00/0x15f0 [i915] <4> [896.033144] i915_pci_probe+0x43/0x1c0 [i915] <4> [896.033149] pci_device_probe+0x9e/0x120 <4> [896.033154] really_probe+0xea/0x420 <4> [896.033158] driver_probe_device+0x10b/0x120 <4> [896.033161] device_driver_attach+0x4a/0x50 <4> [896.033164] __driver_attach+0x97/0x130 <4> [896.033168] bus_for_each_dev+0x74/0xc0 <4> [896.033171] bus_add_driver+0x142/0x220 <4> [896.033174] driver_register+0x56/0xf0 <4> [896.033178] do_one_initcall+0x58/0x2ff <4> [896.033183] do_init_module+0x56/0x1f8 <4> [896.033187] load_module+0x243e/0x29f0 <4> [896.033190] __do_sys_finit_module+0xe9/0x110 <4> [896.033194] do_syscall_64+0x4f/0x210 <4> [896.033197] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [896.033200] -> #0 (&kernel#2){+.+.}: <4> [896.033206] __lock_acquire+0x1328/0x15d0 <4> [896.033209] lock_acquire+0xa7/0x1c0 <4> [896.033213] __mutex_lock+0x9a/0x9d0 <4> [896.033255] i915_request_create+0x16/0x1c0 [i915] <4> [896.033287] intel_engine_flush_barriers+0x4c/0x100 [i915] <4> [896.033327] ggtt_flush+0x37/0x60 [i915] <4> [896.033366] i915_gem_evict_something+0x46b/0x5a0 [i915] <4> [896.033407] i915_gem_gtt_insert+0x21d/0x6a0 [i915] <4> [896.033449] i915_vma_pin+0xb36/0x11c0 [i915] <4> [896.033488] gen6_ppgtt_pin+0xd5/0x170 [i915] <4> [896.033523] ring_context_pin+0x2e/0xc0 [i915] <4> [896.033554] __intel_context_do_pin+0x6b/0x190 [i915] <4> [896.033591] i915_gem_do_execbuffer+0x1814/0x26c0 [i915] <4> [896.033627] i915_gem_execbuffer2_ioctl+0x11b/0x460 [i915] <4> [896.033632] drm_ioctl_kernel+0xa7/0xf0 <4> [896.033635] drm_ioctl+0x2e1/0x390 <4> [896.033638] do_vfs_ioctl+0xa0/0x6f0 <4> [896.033641] ksys_ioctl+0x35/0x60 <4> [896.033644] __x64_sys_ioctl+0x11/0x20 <4> [896.033647] do_syscall_64+0x4f/0x210 <4> [896.033650] entry_SYSCALL_64_after_hwframe+0x49/0xbe Lift the object allocation and pin prior to the request construction. Signed-off-by: -
Chris Wilson authored
Some machines require ACPI for runtime resume, and ACPI is quite kmalloc happy. We cannot handle kmalloc from inside the vm->mutex, as they are used by the shrinker, and so we must ensure the global runtime-pm is awake prior to unbinding to avoid the potential inversion. <4> [57.121748] ====================================================== <4> [57.121750] WARNING: possible circular locking dependency detected <4> [57.121753] 5.4.0-rc8-CI-CI_DRM_7466+ #1 Tainted: G U <4> [57.121754] ------------------------------------------------------ <4> [57.121756] i915_pm_rpm/1105 is trying to acquire lock: <4> [57.121758] ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30 <4> [57.121766] but task is already holding lock: <4> [57.121768] ffff888475a593c0 (&vm->mutex){+.+.}, at: i915_vma_unbind+0x21/0x50 [i915] <4> [57.121868] which lock already depends on the new lock. <4> [57.121869] the existing dependency chain (in reverse order) is: <4> [57.121871] -> #1 (&vm->mutex){+.+.}: <4> [57.121951] i915_gem_shrinker_taints_mutex+0xa2/0xd0 [i915] <4> [57.122028] i915_address_space_init+0xa9/0x170 [i915] <4> [57.122104] i915_ggtt_init_hw+0x47/0x130 [i915] <4> [57.122150] i915_driver_probe+0xbb4/0x15f0 [i915] <4> [57.122197] i915_pci_probe+0x43/0x1c0 [i915] <4> [57.122202] pci_device_probe+0x9e/0x120 <4> [57.122206] really_probe+0xea/0x420 <4> [57.122209] driver_probe_device+0x10b/0x120 <4> [57.122212] device_driver_attach+0x4a/0x50 <4> [57.122214] __driver_attach+0x97/0x130 <4> [57.122217] bus_for_each_dev+0x74/0xc0 <4> [57.122220] bus_add_driver+0x142/0x220 <4> [57.122222] driver_register+0x56/0xf0 <4> [57.122226] do_one_initcall+0x58/0x2ff <4> [57.122230] do_init_module+0x56/0x1f8 <4> [57.122233] load_module+0x243e/0x29f0 <4> [57.122236] __do_sys_finit_module+0xe9/0x110 <4> [57.122239] do_syscall_64+0x4f/0x210 <4> [57.122242] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [57.122244] -> #0 (fs_reclaim){+.+.}: <4> [57.122249] __lock_acquire+0x1328/0x15d0 <4> [57.122251] lock_acquire+0xa7/0x1c0 <4> [57.122254] fs_reclaim_acquire.part.117+0x24/0x30 <4> [57.122257] __kmalloc+0x48/0x320 <4> [57.122261] acpi_ns_internalize_name+0x44/0x9b <4> [57.122264] acpi_ns_get_node_unlocked+0x6b/0xd3 <4> [57.122267] acpi_ns_get_node+0x3b/0x50 <4> [57.122271] acpi_get_handle+0x8a/0xb4 <4> [57.122274] acpi_has_method+0x1c/0x40 <4> [57.122278] acpi_pci_set_power_state+0x40/0xe0 <4> [57.122281] pci_platform_power_transition+0x3e/0x90 <4> [57.122284] pci_set_power_state+0x83/0xf0 <4> [57.122287] pci_restore_standard_config+0x22/0x40 <4> [57.122289] pci_pm_runtime_resume+0x23/0xc0 <4> [57.122293] __rpm_callback+0xb1/0x110 <4> [57.122296] rpm_callback+0x1a/0x70 <4> [57.122299] rpm_resume+0x50e/0x790 <4> [57.122302] __pm_runtime_resume+0x42/0x80 <4> [57.122357] __intel_runtime_pm_get+0x15/0x60 [i915] <4> [57.122435] ggtt_unbind_vma+0x24/0x60 [i915] <4> [57.122514] __i915_vma_unbind.part.39+0xb5/0x500 [i915] <4> [57.122593] i915_vma_unbind+0x2d/0x50 [i915] <4> [57.122668] i915_gem_object_unbind+0x11c/0x260 [i915] <4> [57.122740] i915_gem_object_set_cache_level+0x32/0x90 [i915] <4> [57.122810] i915_gem_set_caching_ioctl+0x1f7/0x2f0 [i915] <4> [57.122815] drm_ioctl_kernel+0xa7/0xf0 <4> [57.122818] drm_ioctl+0x2e1/0x390 <4> [57.122822] do_vfs_ioctl+0xa0/0x6f0 <4> [57.122825] ksys_ioctl+0x35/0x60 <4> [57.122828] __x64_sys_ioctl+0x11/0x20 <4> [57.122830] do_syscall_64+0x4f/0x210 <4> [57.122833] entry_SYSCALL_64_after_hwframe+0x49/0xbe Closes: https://gitlab.freedesktop.org/drm/intel/issues/711Signed-off-by:
-
- 02 Dec, 2019 29 commits
-
-
Chris Wilson authored
As the i915_active.retire() may be running on another CPU as we detect that the i915_active is idle, we may not wait for the retirement itself. Wait for the remote callback by waiting for the retirement worker. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112424Signed-off-by:
-
Chris Wilson authored
Similar to for i915_active.mutex, we require each class of i915_active to have distinct lockdep chains as some, but by no means all, i915_active are used within the shrinker and so have much more severe usage constraints. By using a lockclass local to i915_active_init() all i915_active workers have the same lock class, and we may generate false positives when waiting for the i915_active. If we push the lockclass into the caller, each class of i915_active will have distinct lockdep chains. Signed-off-by:
-
Chris Wilson authored
Avoid dangerous race handling of destroyed vma by unbinding all vma instead. Unfortunately, this stops us from trying to be clever and only doing the minimal change required, so on first use of scanout we may encounter an annoying stall as it transitions to a new cache level. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112413Signed-off-by:
-
Chris Wilson authored
Quite simply we only need to check for prior corruption on enabling rc6 on module load and resume, so by hooking into the common entry points. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191202110836.2342685-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Now that we have soft-rc6 in place, we can use that instead of the forcewake to disable rc6 while active; preferred by a few microbenchmarks. Signed-off-by:
-
Lucas De Marchi authored
The unaligned ioread32() will make us read byte by byte looking for the vbt. We could just as well have done a ioread8() + a shift and avoid the extra confusion on how we are looking for "$VBT". However when using ACPI it's guaranteed the VBT is 4-byte aligned per spec, so we can probably assume it here as well. v2: do not try to simplify the loop by eliminating the auxiliary counter (Jani and Ville) Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-4-lucas.demarchi@intel.com
-
Lucas De Marchi authored
We don't need to keep the pci rom mapped during the entire intel_bios_init() anymore. Move it to the previous copy_vbt() function and rename it to oprom_get_vbt() since now it's responsible to to all operations related to get the vbt from the oprom. v2: fix double __iomem attribute detected by sparse v3: fix missing unmap on success (Ville) Signed-off-by:
-
Lucas De Marchi authored
When we map the VBT through pci_map_rom() we may not be allowed to simply discard the address space and go on reading the memory. That doesn't work on my test system, but by dumping the rom via sysfs I can can get the correct vbt. So change our find_vbt() to do the same as done by pci_read_rom(), i.e. use memcpy_fromio(). v2: the just the minimal changes by not bothering with the unaligned io reads: this can be done on top (from Ville and Jani) v3: drop const in function return since now we are copying the vbt, rather than just finding it Signed-off-by:
-
José Roberto de Souza authored
MST topology needs to be suspended so we don't have any calls to fbdev after it's finalized. MST will be destroyed later as part of drm_mode_config_cleanup(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964Signed-off-by:
-
José Roberto de Souza authored
From VBT 228+ this is block that PSR and other power saving features configuration should be read from. v3: Using DRRS from this new block v4: Using BIT() Fixing DRRS comment in parse_power_conservation_features() Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
José Roberto de Souza authored
eDP specification states that sink can have its PSR capability changed, I have never found any panel doing that but lets add that for completeness. For now it is not reading back the PSR capabilities and if possible re-enabling PSR, this will be added if a panel is found using this feature. v4: Cleaning DP_PSR_CAPS_CHANGE Reviewed-by:
-
José Roberto de Souza authored
When this error happens sink link is not stable after the required FW_EXIT_LATENCY period so it will miss the selective update. As the other PSR errors, for now we are not trying to recover from it. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
José Roberto de Souza authored
eDP spec states that when sink enconters a problem that prevents it to keep PSR running it should set PSR status to internal error and set the reason why it happen to PSR_ERROR_STATUS but it is not how it was implemented. But also I don't want to change this behavior, who knows if there is a panel out there that only set the PSR_ERROR_STATUS. So here refactoring the code a bit to make more easy to read what was state above as more checks will be added to this function. v2: returning a int instead of a bool in psr_get_status_and_error_status() Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
José Roberto de Souza authored
PSR2 HW only support a limited number of bits per pixel, if mode has more than supported PSR2 should not be enabled. BSpec: 50422 BSpec: 7713 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Lucas De Marchi authored
The "err" label is not really "err", but rather "out" since the return path is shared between error condition and normal path. This broke when commit 03cea610 ("drm/i915/dsb: fix extra warning on error path handling") added a "dsb->cmd_buf = NULL;" there, making DSB to stop working since now all writes would pass-through via mmio. Remove the set to NULL since it's actually not needed: we only set it if all steps are successful. While at it, rename the label so this confusion doesn't happen again. Fixes: 03cea610 ("drm/i915/dsb: fix extra warning on error path handling") Resolves: https://gitlab.freedesktop.org/drm/intel/issues/8Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127221119.384754-1-lucas.demarchi@intel.com
-
Ville Syrjälä authored
Migrate away from the legacy encoder->crtc and connector->encoder links in the debugfs display_info code. Other users still remain so can't kill these off yet. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com>
-
Ville Syrjälä authored
Let's make the display info more useful by dumping both the uapi and hw states for each crtc/plane. Signed-off-by:
-
Ville Syrjälä authored
Use the canonical "[CRTC:%d:%s]" format for the obj id/name in the debugfs display_info dump. Everyone should already be familiar with the format since it's used in the debug logs extensively. Signed-off-by:
-
Ville Syrjälä authored
Make out life easier by just grabbing all modeset locks around the display_info dump. Signed-off-by:
-
Ville Syrjälä authored
No point in repeating the crtc mode for each cloned encoder. Just print it once, and avoid using multiple lines for it. And while at let's polish the fixed mode print to fit on one line as well. Signed-off-by:
-
Ville Syrjälä authored
Pull the crtc dumping stuff into a nice function so the loop over the crtcs doesn't look like crap. Signed-off-by:
-
Ville Syrjälä authored
Eliminate the special cases for the primary and cursor planes and just dump all the information consistently for all the planes. Signed-off-by:
-
Ville Syrjälä authored
Switch to using intel_ types in the debugfs display_info code. Should make it easier to handle bigjoiner etc. in the future. Signed-off-by:
-
Ville Syrjälä authored
Use DRM_RECT_FMT & co. to simpify the code. Signed-off-by:
-
Ville Syrjälä authored
It's hard to see what is going on when the function mixes drm_ and intel_ types. Switch to intel_ types. v2: Deal with another use of 'intel_crtc' being introduced Signed-off-by:
-
Matt Roper authored
The bspec tells us 'Program SHPD_FILTER_CNT with the "500 microseconds adjusted" value before enabling hotplug detection' on CNP+. We haven't been touching this register at all thus far, but we should probably follow the bspec's guidance. The register also exists on LPT and SPT, but there isn't any specific guidance I can find on how we should be programming it there so let's leave it be for now. Bspec: 4342 Bspec: 31297 Bspec: 8407 Bspec: 49305 Bspec: 50473 Signed-off-by:
-
Matt Roper authored
When looking at SDEISR to determine the connection status of combo outputs, we should use the phy index rather than the port index. Although they're usually the same thing, EHL's DDI-D (port D) is attached to PHY-A and SDEISR doesn't even have bits for a "D" output. It's also possible that future platforms may map DDIs (the internal display engine programming units) to PHYs (the output handling on the IO side) in ways where port!=phy, so let's look at the PHY index by default. v2: Rename to intel_combo_phy_connected. (Lucas) Fixes: 719d2400 ("drm/i915/ehl: Enable DDI-D") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
The South Display is part of the PCH so we should technically be basing our port detection logic off the PCH in use rather than the platform generation. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Ville Syrjälä authored
LPT/WPT only have PCH transcoder A. Make sure we poke at its chicken register instead of some non-existent register when FDI is being driven by pipe B or C. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com>
-
- 01 Dec, 2019 1 commit
-
-
Chris Wilson authored
As the gen6 page directory is written on binding and after every update, the code ended up duplicated. Refactor the code into a single routine to share the locking and serialisation. Signed-off-by:
-
