- 05 Dec, 2019 4 commits
-
-
Chris Wilson authored
Invalidate the ring TLB and increase the delay required for Baytrail. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191205113726.413351-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
It is not acceptable for context pinning to fail with -ENOSPC as we should always be able to make space in the GGTT. The only reason we may fail is that other "temporary" context pins are reserving their space and we need to wait for an available slot. Closes: https://gitlab.freedesktop.org/drm/intel/issues/676Signed-off-by:
-
Chris Wilson authored
Removing all vma from the VM is best effort -- we only remove all those ready to be removed, so forgive and VMA that becomes pinned. While forgiving those that become pinned, also take a second look for any that became unpinned as we waited. Signed-off-by:
-
Chris Wilson authored
The use GEM context itself was removed in commit cd30a503 ("drm/i915/gem: Excise the per-batch whitelist from the context"), but the locals were left in place as an oversight. Remove the parameters and clean up. References: cd30a503 ("drm/i915/gem: Excise the per-batch whitelist from the context") Signed-off-by:
-
- 04 Dec, 2019 12 commits
-
-
Chris Wilson authored
Call i915_user_extensions() to validate the arg->extensions pointer, and so return consistent error numbers for the future. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204162803.3841140-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Remember to take the lock before walking the obj->vma.list so that the nodes do not change beneath us! E.g., i915_gem_object_bump_inactive_ggtt:387 GEM_BUG_ON(vma->vm != &i915->ggtt.vm) Closes: https://gitlab.freedesktop.org/drm/intel/issues/691Signed-off-by:
-
Chris Wilson authored
If we cannot handle a vma within the unbind loop, try to flush the pending events (i915_vma_parked, i915_vm_release) and try again. This avoids a round trip to userspace that is not guaranteed to make forward progress, as the events we wait upon require being idle. References: cb6c3d45 ("drm/i915/gem: Avoid parking the vma as we unbind") Signed-off-by:
-
Abdiel Janulgue authored
This is really just an alias of mmap_gtt. The 'mmap offset' nomenclature comes from the value returned by this ioctl which is the offset into the device fd which userpace uses with mmap(2). mmap_gtt was our initial mmap_offset implementation, this extends our CPU mmap support to allow additional fault handlers that depends on the object's backing pages. Note that we multiplex mmap_gtt and mmap_offset through the same ioctl, and use the zero extending behaviour of drm to differentiate between them, when we inspect the flags. To support multiple mmap types on an object we need to support multiple mmap_offsets for an object (each offset in the global device address space corresponding to a unique instance of the object for a file + mmap type). As we drop the simplified drm core idea of a single mmap_offset, we need to provide replacement hooks for the dumb mmap interface as well. Link: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1675 Testcase: igt/gem_mmap_offset Signed-off-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by:
-
Mao Wenan authored
There is no need to have the 'T *v' variable static since new value always be assigned before use it. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Mao Wenan <maowenan@huawei.com> Signed-off-by:
-
Ville Syrjälä authored
Assuming intel_crtc_arm_fifo_underrun() only gets called when there's no pending plane updates we can utilize it on gen2 by checking the active_planes bitmask so that we only re-enable underrun reporting if some planes are active. i915_fifo_underrun_reset_write() seems to have the necessary hw_done/flip_done waits in place. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-8-ville.syrjala@linux.intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
Let's just inline intel_pre_disable_primary_noatomic() into intel_plane_disable_noatomic(). The CxSR disable we can do regardless of which plane we're disabling, and while at it we can make the gen2 underrun w/a accurate by consulting the active_planes bitmask. Signed-off-by:
-
Ville Syrjälä authored
We have the active_planes bitmask now so use it to properly determine when some planes are visible for the gen2 underrun workaround. This let's us almost eliminate intel_post_enable_primary(). The manual underrun checks we can simply move into intel_atomic_commit_tail() since they loop over all the pipes already. No point in repeating the checks multiple times when there are multiple pipes in the commit. Signed-off-by:
-
Ville Syrjälä authored
Change the calling convention to just pass the state+crtc and switch to intel_ types throughout. We'll also do a quick s/if (old_primary_state)/if (new_primary_state)/ so that we'll be able to eliminate old_primary_state later. This is fine since we always have either both old and new state or neither. Signed-off-by:
-
Ville Syrjälä authored
Replace the old world 'pipe_config' variable name with the new thing. Signed-off-by:
-
Ville Syrjälä authored
Get rid of another 'dev' usage by passing dev_priv instead. Signed-off-by:
-
Ville Syrjälä authored
Don't pass the redundant dev_priv to needs_nv12_wa() and needs_scalerclk_wa(). Signed-off-by:
-
- 03 Dec, 2019 11 commits
-
-
Chris Wilson authored
And Haswell still occasionally forgets it is meant to be using a new page directory, so repeat ourselves a little louder. <7> [509.919864] heartbeat rcs0 heartbeat {prio:-2147483645} not ticking <7> [509.919895] heartbeat Awake? 8 <7> [509.919903] heartbeat Barriers?: no <7> [509.919912] heartbeat Heartbeat: 3008 ms ago <7> [509.919930] heartbeat Reset count: 0 (global 0) <7> [509.919937] heartbeat Requests: <7> [509.921008] heartbeat active a7eb:56e1* @ 5847ms: <7> [509.921157] heartbeat ring->start: 0x00001000 <7> [509.921164] heartbeat ring->head: 0x00001610 <7> [509.921170] heartbeat ring->tail: 0x000023d8 <7> [509.921176] heartbeat ring->emit: 0x000023d8 <7> [509.921182] heartbeat ring->space: 0x00002570 <7> [509.921189] heartbeat ring->hwsp: 0x7fffe100 <7> [509.921197] heartbeat [head 1628, postfix 1738, tail 1750, batch 0xffffffff_ffffffff]: <7> [509.921289] heartbeat [0000] 7a000002 00100002 00000000 00000000 7a000002 01154c1e 7ffff080 00000000 <7> [509.921299] heartbeat [0020] 11000001 00002220 ffffffff 12400001 00002220 7ffff000 00000000 11000001 <7> [509.921308] heartbeat [0040] 00002228 6e900000 7a000002 00100002 00000000 00000000 7a000002 01154c1e <7> [509.921317] heartbeat [0060] 7ffff080 00000000 12400001 00002228 7ffff000 00000000 7a000002 00100002 <7> [509.921326] heartbeat [0080] 00000000 00000000 7a000002 01154c1e 7ffff080 00000000 7a000002 001010a1 <7> [509.921335] heartbeat [00a0] 7ffff080 00000000 04000000 11000005 00022050 00010001 00012050 00010001 <7> [509.921345] heartbeat [00c0] 0001a050 00010001 00000000 0c000000 459a110c 00000000 11000005 00022050 <7> [509.921354] heartbeat [00e0] 00010000 00012050 00010000 0001a050 00010000 12400001 0001a050 7ffff000 <7> [509.921363] heartbeat [0100] 00000000 04000001 18802100 00000000 7a000002 011050a1 7fffe100 000056e1 <7> [509.921370] heartbeat [0120] 01000000 00000000 <7> [509.921538] heartbeat MMIO base: 0x00002000 <7> [509.921682] heartbeat CCID: 0x3fa0110d <7> [509.922342] heartbeat RING_START: 0x00001000 <7> [509.922353] heartbeat RING_HEAD: 0x00001628 <7> [509.922366] heartbeat RING_TAIL: 0x000023d8 <7> [509.922381] heartbeat RING_CTL: 0x00003001 <7> [509.922396] heartbeat RING_MODE: 0x00004000 <7> [509.922408] heartbeat RING_IMR: ffffffde <7> [509.922421] heartbeat ACTHD: 0x00000000_30e01628 <7> [509.922434] heartbeat BBADDR: 0x00000000_00004004 <7> [509.922446] heartbeat DMA_FADDR: 0x00000000_00002800 <7> [509.922458] heartbeat IPEIR: 0x00000000 <7> [509.922470] heartbeat IPEHR: 0x780c0000 <7> [509.922642] heartbeat PP_DIR_BASE: 0x6e700000 <7> [509.922652] heartbeat PP_DIR_BASE_READ: 0x00000000 <7> [509.922662] heartbeat PP_DIR_DCLV: 0xffffffff <7> [509.922678] heartbeat E a7eb:56e1* @ 5849ms: <7> [509.922689] heartbeat E a7eb:56e2- @ 5849ms: <7> [509.922698] heartbeat E a7eb:56e3 @ 5848ms: <7> [509.922707] heartbeat E a7eb:56e4 @ 5848ms: <7> [509.922715] heartbeat E a7eb:56e5 @ 5847ms: <7> [509.922724] heartbeat E a7eb:56e6 @ 5846ms: <7> [509.922735] heartbeat E a7eb:56e7 @ 5846ms: <7> [509.922744] heartbeat ...skipping 4 executing requests... <7> [509.922754] heartbeat E a7eb:56ec @ 3010ms: <7> [509.922796] heartbeat HWSP: <7> [509.922807] heartbeat [0000] 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <7> [509.922817] heartbeat [0020] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <7> [509.922826] heartbeat * <7> [509.922836] heartbeat [0100] 000056e0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <7> [509.922845] heartbeat [0120] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <7> [509.922851] heartbeat * <7> [509.922870] heartbeat Idle? no <7> [509.922878] heartbeat Signals: <7> [509.923000] heartbeat [a7eb:56e2] @ 5850ms Here, we have a failed context restore after the PD switch, but note that the PP_DIR_BASE register does not match the LRI in the ring. Bump it to 8^W 4 loops, and with that Baytrail starts passing the sanity checks. Signed-off-by: -
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:
-
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:
-
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:
-
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 13 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:
-
