aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2018-01-29Merge drm-next into drm-intel-next-queuedJoonas Lahtinen544-13854/+22478
Pull 4.15 into drm-intel-next-queued for next feature pull. Signed-off-by: Joonas Lahtinen <[email protected]>
2018-01-29Revert "drm/i915: mark all device info struct with __initconst"Lionel Landwerlin1-48/+48
This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e. Conflicts: drivers/gpu/drm/i915/i915_pci.c Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805 Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Fixes: 5b54eddd3920 ("drm/i915: mark all device info struct with __initconst") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-26drm/i915/lrc: Remove superfluous WARN_ONChris Wilson1-7/+7
Remove the WARN_ON(ce->state) inside the static function only called when ce->state == NULL and downgrade the w/a batch setup warning into a developer only mode (GEM_WARN_ON). v2: Move the deferred alloc guard into the callee, eliminating the need for the WARN_ON: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-1 (-1) Function old new delta execlists_context_pin 1819 1818 -1 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]
2018-01-26drm/dp: Add HBR3 support in existing DRM DP helpersManasi Navare2-0/+7
Existing helpers add support upto HBR2. This patch adds support for HBR3 rate (8.1 Gbps) introduced as part of DP 1.4 specification. Cc: Rodrigo Vivi <[email protected]> Cc: Jani Nikula <[email protected]> Cc: [email protected] Signed-off-by: Manasi Navare <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-26Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixesDave Airlie1-15/+31
Single irq regression fix * 'linux-4.15' of git://github.com/skeggsb/linux: drm/nouveau: Move irq setup/teardown to pci ctor/dtor
2018-01-26drm/nouveau: Move irq setup/teardown to pci ctor/dtorLyude Paul1-15/+31
For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline kernel that started introducing suspend/resume issues for nouveau: a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation) After this commit was introduced, we started getting interrupts from the GPU before we actually re-allocated our own IRQ (see references below) and assigned the IRQ handler. Investigating this turned out that the problem was not with the commit, but the fact that nouveau even free/allocates it's irqs before and after suspend/resume. For starters: drivers in the linux kernel haven't had to handle freeing/re-allocating their IRQs during suspend/resume cycles for quite a while now. Nouveau seems to be one of the few drivers left that still does this, despite the fact there's no reason we actually need to since disabling interrupts from the device side should be enough, as the kernel is already smart enough to know to disable host-side interrupts for us before going into suspend. Since we were tearing down our IRQs by hand however, that means there was a short period during resume where interrupts could be received before we re-allocated our IRQ which would lead to us getting an unhandled IRQ. Since we never handle said IRQ and re-arm the interrupt registers, this would cause us to miss all of the interrupts from the GPU and cause our init process to start timing out on anything requiring interrupts. So, since this whole setup/teardown every suspend/resume cycle is useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor functions instead so they're only called at driver load and driver unload. This should fix most of the issues with pending interrupts on resume, along with getting suspend/resume for nouveau to work again. As well, this probably means we can also just remove the msi rearm call inside nvkm_pci_init(). But since our main focus here is to fix suspend/resume before 4.15, we'll save that for a later patch. Signed-off-by: Lyude Paul <[email protected]> Cc: Karol Herbst <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Mike Galbraith <[email protected]> Cc: [email protected] Signed-off-by: Ben Skeggs <[email protected]>
2018-01-25drm/i915/lrc: Clear context restore/save inhibit flags for new contextsChris Wilson1-0/+8
CTX_CONTEXT_CONTROL (CTX_SR_CTL) operates as a masked register and so will only apply the bits that are selected by the upper half. In the case of selectively enabling sr inhibit, this may mean the context keeps the current setting (so forgetting to save the context later, eventually leading to a very upset GPU!). Fixes: 517aaffe0c1b ("drm/i915/execlists: Inhibit context save/restore for the fake preempt context") Signed-off-by: Chris Wilson <[email protected]> Cc: Michal Winiarski <[email protected]> Cc: Michel Thierry <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Joonas Lahtinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Michel Thierry <[email protected]>
2018-01-25Merge tag 'drm-misc-fixes-2018-01-24' of ↵Dave Airlie1-6/+27
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Two vc4 fixes that were applied in the last day. One fixes a NULL dereference, and the other fixes a flickering bug. Cc: Eric Anholt <[email protected]> Cc: Boris Brezillon <[email protected]> * tag 'drm-misc-fixes-2018-01-24' of git://anongit.freedesktop.org/drm/drm-misc: drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state() drm/vc4: Flush the caches before the bin jobs, as well.
2018-01-25Merge tag 'drm-misc-next-fixes-2018-01-18' of ↵Dave Airlie3-7/+14
git://anongit.freedesktop.org/drm/drm-misc into drm-next Fixes for 4.16: Fixes one Kconfig issue and a enable some panels to work properly. There is also a fix of error code return in sun4i. * tag 'drm-misc-next-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-misc: drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig drm/panel: lvds: Handle the optional regulator case properly drm/sun4i: Fix error code in sun4i_tcon_bind()
2018-01-25Merge branch 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie17-101/+138
into drm-next A few more fixes for 4.16, nothing major. A few more fixes for 4.16. This is on top of the pull request from last week. Most notable change here is a fix to the link order for the now separate from amdgpu GPU scheduler to fix crashes when the modules are build into the kernel rather than as modules. * 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux: drm: fix gpu scheduler link order drm/amd/display: Demote error print to debug print when ATOM impl missing drm/amdgpu: Avoid leaking PM domain on driver unbind (v2) drm/amd/amdgpu: Add Polaris version check drm/amdgpu: Reenable manual GPU reset from sysfs drm/amdgpu: disable MMHUB power gating on raven drm/ttm: Don't unreserve swapped BOs that were previously reserved drm/ttm: Don't add swapped BOs to swap-LRU list drm/amdgpu: only check for ECC on Vega10 drm/amd/powerplay: Fix smu_table_entry.handle type drm/ttm: add VADDR_FLAG_UPDATED_COUNT to correctly update dma_page global count drm/radeon: fill in rb backend map on evergreen/ni. drm/amdgpu/gfx9: fix ngg enablement to clear gds reserved memory (v2) drm/ttm: only free pages rather than update global memory count together drm/amdgpu: fix CPU based VM updates drm/amdgpu: fix typo in amdgpu_vce_validate_bo drm/amdgpu: fix amdgpu_vm_pasid_fault_credit drm/ttm: check the return value of register_shrinker drm/radeon: fix sparse warning: Should it be static?
2018-01-24drm: fix gpu scheduler link orderChristian König1-1/+1
It should initialize before the drivers using it. Signed-off-by: Christian König <[email protected]> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104736 Reviewed-by: Mike Lothian <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-01-24drm/amd/display: Demote error print to debug print when ATOM impl missingHarry Wentland2-19/+19
I assumed wrongfully that all relevant functions should be implemented. Apparently this isn't the case. Demote the print to debug level for now. Signed-off-by: Harry Wentland <[email protected]> Reviewed-by: Tony Cheng <[email protected]> Acked-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-01-24drm/i915/guc: Fix comments style in intel_guc_log.cSagar Arun Kamble1-15/+30
Use consistent multi-line comment style as per guideline. v2: Reverted comments prefix update to kernel-doc comment. (Chris) Suggested-by: Michal Wajdeczko <[email protected]> Signed-off-by: Sagar Arun Kamble <[email protected]> Cc: Michal Wajdeczko <[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]
2018-01-24drm/i915/guc: Update name and prototype of i915_guc_log_controlSagar Arun Kamble3-7/+7
i915_guc_log_control is GuC interface and GuC APIs that are not user facing should be named with "intel_guc" prefix hence we change name to intel_guc_log_control. Also changed the parameter to intel_guc struct. v2: Move log vma check to intel_guc_log_control (Michal) Return -ENODEV when log isn't initialized. (Chris) Suggested-by: Michal Wajdeczko <[email protected]> Signed-off-by: Sagar Arun Kamble <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Michal Wajdeczko <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-24drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutexSagar Arun Kamble8-66/+172
This patch fixes lockdep issue due to circular locking dependency of struct_mutex, i_mutex_key, mmap_sem, relay_channels_mutex. For GuC log relay channel we create debugfs file that requires i_mutex_key lock and we are doing that under struct_mutex. So we introduced newer dependency as: &dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem However, there is dependency from mmap_sem to struct_mutex. Hence we separate the relay create/destroy operation from under struct_mutex. Also added runtime check of relay buffer status. Reviewed-by: Chris Wilson <[email protected]> ====================================================== WARNING: possible circular locking dependency detected 4.15.0-rc6-CI-Patchwork_7614+ #1 Not tainted ------------------------------------------------------ debugfs_test/1388 is trying to acquire lock: (&dev->struct_mutex){+.+.}, at: [<00000000d5e1d915>] i915_mutex_lock_interruptible+0x47/0x130 [i915] but task is already holding lock: (&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&mm->mmap_sem){++++}: _copy_to_user+0x1e/0x70 filldir+0x8c/0xf0 dcache_readdir+0xeb/0x160 iterate_dir+0xdc/0x140 SyS_getdents+0xa0/0x130 entry_SYSCALL_64_fastpath+0x1c/0x89 -> #2 (&sb->s_type->i_mutex_key#3){++++}: start_creating+0x59/0x110 __debugfs_create_file+0x2e/0xe0 relay_create_buf_file+0x62/0x80 relay_late_setup_files+0x84/0x250 guc_log_late_setup+0x4f/0x110 [i915] i915_guc_log_register+0x32/0x40 [i915] i915_driver_load+0x7b6/0x1720 [i915] i915_pci_probe+0x2e/0x90 [i915] pci_device_probe+0x9c/0x120 driver_probe_device+0x2a3/0x480 __driver_attach+0xd9/0xe0 bus_for_each_dev+0x57/0x90 bus_add_driver+0x168/0x260 driver_register+0x52/0xc0 do_one_initcall+0x39/0x150 do_init_module+0x56/0x1ef load_module+0x231c/0x2d70 SyS_finit_module+0xa5/0xe0 entry_SYSCALL_64_fastpath+0x1c/0x89 -> #1 (relay_channels_mutex){+.+.}: relay_open+0x12c/0x2b0 intel_guc_log_runtime_create+0xab/0x230 [i915] intel_guc_init+0x81/0x120 [i915] intel_uc_init+0x29/0xa0 [i915] i915_gem_init+0x182/0x530 [i915] i915_driver_load+0xaa9/0x1720 [i915] i915_pci_probe+0x2e/0x90 [i915] pci_device_probe+0x9c/0x120 driver_probe_device+0x2a3/0x480 __driver_attach+0xd9/0xe0 bus_for_each_dev+0x57/0x90 bus_add_driver+0x168/0x260 driver_register+0x52/0xc0 do_one_initcall+0x39/0x150 do_init_module+0x56/0x1ef load_module+0x231c/0x2d70 SyS_finit_module+0xa5/0xe0 entry_SYSCALL_64_fastpath+0x1c/0x89 -> #0 (&dev->struct_mutex){+.+.}: __mutex_lock+0x81/0x9b0 i915_mutex_lock_interruptible+0x47/0x130 [i915] i915_gem_fault+0x201/0x790 [i915] __do_fault+0x15/0x70 __handle_mm_fault+0x677/0xdc0 handle_mm_fault+0x14f/0x2f0 __do_page_fault+0x2d1/0x560 page_fault+0x4c/0x60 other info that might help us debug this: Chain exists of: &dev->struct_mutex --> &sb->s_type->i_mutex_key#3 --> &mm->mmap_sem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(&sb->s_type->i_mutex_key#3); lock(&mm->mmap_sem); lock(&dev->struct_mutex); *** DEADLOCK *** 1 lock held by debugfs_test/1388: #0: (&mm->mmap_sem){++++}, at: [<0000000029a9c131>] __do_page_fault+0x106/0x560 stack backtrace: CPU: 2 PID: 1388 Comm: debugfs_test Not tainted 4.15.0-rc6-CI-Patchwork_7614+ #1 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.10 09/29/2016 Call Trace: dump_stack+0x5f/0x86 print_circular_bug.isra.18+0x1d0/0x2c0 __lock_acquire+0x14ae/0x1b60 ? lock_acquire+0xaf/0x200 lock_acquire+0xaf/0x200 ? i915_mutex_lock_interruptible+0x47/0x130 [i915] __mutex_lock+0x81/0x9b0 ? i915_mutex_lock_interruptible+0x47/0x130 [i915] ? i915_mutex_lock_interruptible+0x47/0x130 [i915] ? i915_mutex_lock_interruptible+0x47/0x130 [i915] i915_mutex_lock_interruptible+0x47/0x130 [i915] ? __pm_runtime_resume+0x4f/0x80 i915_gem_fault+0x201/0x790 [i915] __do_fault+0x15/0x70 ? _raw_spin_unlock+0x29/0x40 __handle_mm_fault+0x677/0xdc0 handle_mm_fault+0x14f/0x2f0 __do_page_fault+0x2d1/0x560 ? page_fault+0x36/0x60 page_fault+0x4c/0x60 v2: Added lock protection to guc->log.runtime.relay_chan (Chris) Fixed locking inside guc_flush_logs uncovered by new lockdep. v3: Locking guc_read_update_log_buffer entirely with relay_lock. (Chris) Prepared intel_guc_init_early. Moved relay_lock inside relay_create relay_destroy, relay_file_create, guc_read_update_log_buffer. (Michal) Removed struct_mutex lock around guc_log_flush and removed usage of guc_log_has_relay() from runtime_create path as it needs struct_mutex lock. v4: Handle NULL relay sub buffer pointer earlier in read_update_log_buffer (Chris). Fixed comment suffix **/. (Michal) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104693 Testcase: igt/debugfs_test/read_all_entries # with enable_guc=1 and guc_log_level=1 Signed-off-by: Sagar Arun Kamble <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Marta Lofstedt <[email protected]> Cc: Michal Winiarski <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-24drm/i915/guc: Enable interrupts before resuming GuC during runtime resumeSagar Arun Kamble1-4/+9
GuC log streaming needs interrupts enabled prior to GuC resume but runtime pm interrupt setup was happening post GuC resume. Fix it. While at it, fix the unwinding of steps in the runtime suspend path. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104695 Signed-off-by: Sagar Arun Kamble <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Michał Winiarski <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Marta Lofstedt <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-24drm/i915/guc: Grab RPM wakelock while disabling GuC interruptsSagar Arun Kamble2-0/+9
Disabling GuC interrupts involves access to GuC IRQ control registers hence ensure device is RPM awake. v1-v2: old changelog 1: Add comment about need to synchronize flush work and log runtime destroy 2: Moved patch earlier in the series and removed comment about future work. (Tvrtko) v3: Added assert_rpm_wakelock_held() to gen9_*_guc_interrupts. (Chris) Signed-off-by: Sagar Arun Kamble <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-24drm/i915: Add a comment exlaining CCS hsub/vsubVille Syrjälä1-0/+14
Let's document why we claim hsub==8,vsub==16 for CCS. v2: Replace my explanation with Jason's Cc: Daniel Vetter <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Jason Ekstrand <[email protected]> Cc: Daniel Stone <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jason Ekstrand <[email protected]>
2018-01-24drm/i915: Implement display w/a #1143Ville Syrjälä2-2/+48
Apparently SKL/KBL/CFL need some manual help to get the programmed HDMI vswing to stick. Implement the relevant workaround (display w/a #1143). Note that the relevant chicken bits live in a transcoder register even though the bits affect a specific DDI port rather than a specific transcoder. Hence we must pick the correct transcoder register instance based on the port rather than based on the cpu_transcoder. Also note that for completeness I included support for DDI A/E in the code even though we never have HDMI on those ports. v2: CFL needs the w/a as well (Rodrigo and Art) Cc: Rodrigo Vivi <[email protected]> Cc: Art Runyan <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2018-01-24drm/i915: Use enum plane_id for frontbuffer trackingVille Syrjälä4-12/+7
Replace the ad-hoc plane indexing scheme used by the frontbuffer tracking with enum plane_id. The old video overlay not being part of the plane_id namespace will just be given the high bit. v2: Drop the unintended whitespace change (Chris) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]>
2018-01-24drm/i915: Shrink the GEM kmem_caches upon idlingChris Wilson1-0/+79
When we finally decide the gpu is idle, that is a good time to shrink our kmem_caches. v3: Defer until an rcu grace period after we idle. v4: Think about epoch wraparound and how likely that is. v5: Use I915_EPOCH_INVALID magic. 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]
2018-01-24drm/i915: Track the number of times we have woken the GPU upChris Wilson3-3/+12
By counting the number of times we have woken up, we have a very simple means of defining an epoch, which will come in handy if we want to perform deferred tasks at the end of an epoch (i.e. while we are going to sleep) without imposing on the next activity cycle. v2: No reason to specify precise number of bits here. v3: Take Tvrtko's advice and reserve 0 as an invalid epoch. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-24drm/i915/execlists: Inhibit context save/restore for the fake preempt contextChris Wilson2-0/+5
We only use the preempt context to inject an idle point into execlists. We never need to reference its logical state, so tell the GPU never to load it or save it. v2: BIT(2) for save-inhibit. N.B. Daniele mentioned this bit mbz for ICL, and has been moved into the submission process rather than the context image. Suggested-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Michal Winiarski <[email protected]> Cc: Michel Thierry <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: Michel Thierry <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-24drm/i915: Move LRC register offsets to a header fileMichel Thierry2-54/+68
Newer platforms may have subtle offset changes, which will increase the number of defines, so it is probably better to start moving them to its own header file. Also move the macros used while setting the reg state. v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and intel_guc_reg.h (Chris) v3: License notice shenanigans. v4: Documentation/process/coding-style.rst is always right (Chris) v5: Rebase. Signed-off-by: Michel Thierry <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]>
2018-01-24drm/i915/lrc: Update reg_state macros to pass checkpatchMichel Thierry1-8/+13
The macros we use to init the reg_state had the following issues reported by checkpatch --strict. Macro argument reuse 'reg_state' - possible side-effects Macro argument reuse 'pos' - possible side-effects Macro argument reuse 'ppgtt' - possible side-effects spaces preferred around that '+' (ctx:VxV) So fix these issues before they are moved to a new header file. Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Michel Thierry <[email protected]> Cc: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]>
2018-01-24drm/i915/pmu: Fix sysfs exported counter configTvrtko Ursulin1-1/+1
We need to generate the event config value using the uAPI class and not the driver internal one. Signed-off-by: Tvrtko Ursulin <[email protected]> Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs") Cc: Tvrtko Ursulin <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-23drm/i915/cnl: Fix aux selection for WA 1178Rodrigo Vivi1-1/+1
Current code always select _CNL_AUX_ANAOVRD1_B register regardless the pw in use. CNL_DISP_PW_AUX_B = 9 CNL_DISP_PW_AUX_C = 10 CNL_DISP_PW_AUX_D = 11 And for pick we want B = 0 C = 1 D = 2 Fixes: ddd39e4b3f8f ("drm/i915/cnl: apply Display WA #1178 to fix type C dongles") Cc: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-23drm/i915/cnp: Ignore VBT request for know invalid DDC pin.Rodrigo Vivi1-3/+8
Let's ignore VBT request if the pin is clearly wrong. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104139 Cc: Kai Heng Feng <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Radhakrishna Sripada <[email protected]>
2018-01-23drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-10/+8
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Shawn Guo <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Shawn Guo <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-4/+3
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: VMware Graphics <[email protected]> Cc: Sinclair Yeh <[email protected]> Cc: Thomas Hellstrom <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Sinclair Yeh <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-5/+4
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). v2: Rebase due to tegra_plane_state_add() relocating to plane.c Cc: Laurent Pinchart <[email protected]> Cc: Thierry Reding <[email protected]> Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Acked-by: Thierry Reding <[email protected]> Reviewed-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-23drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-5/+4
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Mark Yao <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane clip ↵Ville Syrjälä1-8/+12
rectangle Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-10/+10
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Rob Clark <[email protected]> Cc: Archit Taneja <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Archit Taneja <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/meson: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-2/+3
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: [email protected] Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-2/+3
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes as the code already uses crtc_state->mode to populate the clip, which is also what drm_mode_get_hv_timing() uses. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: CK Hu <[email protected]> Cc: Philipp Zabel <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Philipp Zabel <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-5/+5
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Philipp Zabel <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Philipp Zabel <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane clip ↵Ville Syrjälä1-2/+3
rectangle Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Noralf Trønnes <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-2/+4
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Liviu Dudau <[email protected]> Cc: Brian Starkey <[email protected]> Cc: Mali DP Maintainers <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Liviu Dudau <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-2/+3
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Liviu Dudau <[email protected]> Cc: Brian Starkey <[email protected]> Cc: Mali DP Maintainers <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Liviu Dudau <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä4-13/+18
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes since pipe_src_w/h are already filled via drm_mode_get_hv_timing(). Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/i915: Reject odd pipe source width with double wide/dual linkVille Syrjälä1-3/+12
In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay we must not adjust pipe_src_w to accommodate double wide/dual link. Instead just reject the mode outright. This will allows us to rely on crtc_state->mode for plane clipping. Cc: Laurent Pinchart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Thierry Reding <[email protected]>
2018-01-23drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)Alex Deucher1-2/+0
We only support vga_switcheroo and runtime pm on PX/HG systems so forcing runpm to 1 doesn't do anything useful anyway. Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so that the cleanup path is correct as well. This mirrors what radeon does as well. v2: rework the patch originally sent by Lukas (Alex) Acked-by: Lukas Wunner <[email protected]> Reported-by: Lukas Wunner <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> (v1) Cc: [email protected]
2018-01-23drm/sun4i: Fix build warnings in sunxi_engine.hSean Paul1-0/+1
Fixes the following build warnings: In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0, from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.h:13, from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.c:12: ../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration struct drm_crtc_state *old_state); ^~~~~~~~~~~~~~ ../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration struct drm_crtc_state *state); ^~~~~~~~~~~~~~ In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0, from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.h:12, from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.c:12: ../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration struct drm_crtc_state *old_state); ^~~~~~~~~~~~~~ ../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct drm_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration struct drm_crtc_state *state); ^~~~~~~~~~~~~~ Fixes: 6b8562c86e24 ("drm/sun4i: engine: Create an atomic_begin callback") Fixes: 656e5f654903 ("drm/sun4i: engine: Add a custom crtc atomic_check") Cc: Chen-Yu Tsai <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Sean Paul <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-23drm/amd/amdgpu: Add Polaris version checkJames Zhu1-2/+15
Add Polaris version check if firmware support UVD encode Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: James Zhu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2018-01-23drm/amdgpu: Reenable manual GPU reset from sysfsAndrey Grodzovsky1-1/+1
Otherwise it keeps rejecting the reset. Signed-off-by: Andrey Grodzovsky <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2018-01-22drm/i915/execlists: Skip forcewake for ELSP submissionChris Wilson1-6/+12
Now that we can read the CSB from the HWSP, we may avoid having to perform mmio reads entirely and so forgo the rigmarole of the forcewake dance. v2: Include forcewake hint for GEM_TRACE readback of mmio. If we don't hold fw ourselves, the reads may return garbage. 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]
2018-01-22drm/i915: Increase render/media power gating hysteresis for gen9+Chris Wilson1-3/+23
On gen9+, after an idle period the HW will disable the entire power well to conserve power (by preventing current leakage). It takes around a 100 microseconds to bring the power well back online afterwards. With the current hysteresis value of 25us (really 25 * 1280ns), we do not have sufficient time to respond to an interrupt and schedule the next execution before the HW powers itself down. (At present, we prevent this by grabbing the forcewake for prolonged periods of time, but that overkill fixed in the next patch.) The minimum we want to set the power gating hysteresis to is the length of time it takes us to service the GPU, which across a broad spectrum of machines is about 250us. (Note this also brings guc latency into the same ballpark as execlists.) v2: Include some notes on where I plucked the numbers from. Testcase: igt/gem_exec_nop/sequential Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Michal Wajdeczko <[email protected]> Cc: Sagar Arun Kamble <[email protected]> Cc: Michel Thierry <[email protected]> Cc: Michal Winiarski <[email protected]> Reviewed-by: Sagar Arun Kamble <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-22drm/panel: panasonic-vvx10f034n00: More return value fixesSean Paul1-12/+5
A couple more return value fixes which Philippe brought up during our previous review. Suggested-by: Philippe CORNU <[email protected]> Reviewed-by: Philippe Cornu <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2018-01-22drm/i915: Per-engine scratch VMA is mandatoryTvrtko Ursulin1-1/+1
We fail engine initialization if the scratch VMA cannot be created so there is no point in error handle it later. If the initialization ordering gets messed up, we can explode during development just as well. Signed-off-by: Tvrtko Ursulin <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Michel Thierry <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.