aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2019-06-18drm/vmwgfx: Implement an infrastructure for read-coherent resourcesThomas Hellstrom5-11/+177
Similar to write-coherent resources, make sure that from the user-space point of view, GPU rendered contents is automatically available for reading by the CPU. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-06-18drm/vmwgfx: Use an RBtree instead of linked list for MOB resourcesThomas Hellstrom3-16/+32
With emulated coherent memory we need to be able to quickly look up a resource from the MOB offset. Instead of traversing a linked list with O(n) worst case, use an RBtree with O(log n) worst case complexity. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-06-18drm/vmwgfx: Implement an infrastructure for write-coherent resourcesThomas Hellstrom11-20/+584
This infrastructure will, for coherent resources, make sure that from the user-space point of view, data written by the CPU is immediately automatically available to the GPU at resource validation time. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-06-18drm/ttm: TTM fault handler helpersThomas Hellstrom1-62/+101
With the vmwgfx dirty tracking, the default TTM fault handler is not completely sufficient (vmwgfx need to modify the vma->vm_flags member, and also needs to restrict the number of prefaults). We also want to replicate the new ttm_bo_vm_reserve() functionality So start turning the TTM vm code into helpers: ttm_bo_vm_fault_reserved() and ttm_bo_vm_reserve(), and provide a default TTM fault handler for other drivers to use. Cc: "Christian König" <christian.koenig@amd.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: "Christian König" <christian.koenig@amd.com> #v1
2019-06-18drm/ttm: Allow the driver to provide the ttm struct vm_operations_structThomas Hellstrom2-3/+4
Add a pointer to the struct vm_operations_struct in the bo_device, and assign that pointer to the default value currently used. The driver can then optionally modify that pointer and the new value can be used for each new vma created. Cc: "Christian König" <christian.koenig@amd.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2019-06-18drm/vmwgfx: Assign eviction priorities to resourcesThomas Hellstrom8-20/+141
TTM provides a means to assign eviction priorities to buffer object. This means that all buffer objects with a lower priority will be evicted first on memory pressure. Use this to make sure surfaces and in particular non-dirty surfaces are evicted first. Evicting in particular shaders, cotables and contexts imply a significant performance hit on vmwgfx, so make sure these resources are evicted last. Some buffer objects are sub-allocated in user-space which means we can have many resources attached to a single buffer object or resource. In that case the buffer object is given the highest priority of the attached resources. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
2019-06-18drm/i915/guc: Reduce verbosity on log overflowsChris Wilson1-1/+3
If the user is clearing the log buffer too slowly, we overflow. As this is an expected condition, and the driver tries to handle it, reduce the error message down to a notice. Michal mentioned that another cause would be incorrect reset handling, so we don't want to lose the notification entirely. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110817 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190617100917.13110-1-chris@chris-wilson.co.uk
2019-06-17drm/i915/ehl: Introduce Mule Creek Canyon PCHMatt Roper7-10/+74
Although EHL introduces a new PCH, the South Display part of the PCH that we care about is nearly identical to ICP, just with some pins remapped. Most notably, Port C is mapped to the pins that ICP uses for TC Port 1. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190615004210.16656-1-matthew.d.roper@intel.com
2019-06-17drm/i915/gtt: Serialise both updates to PDE and our shadowChris Wilson1-60/+73
Currently, we perform a locked update of the shadow entry when allocating a page directory entry such that if two clients are concurrently allocating neighbouring ranges we only insert one new entry for the pair of them. However, we also need to serialise both clients wrt to the actual entry in the HW table, or else we may allow one client or even a third client to proceed ahead of the HW write. My handwave before was that under the _pathological_ condition we would see the scratch entry instead of the expected entry, causing a temporary glitch. That starvation condition will eventually show up in practice, so fix it. The reason for the previous cheat was to avoid having to free the extra allocation while under the spinlock. Now, we keep the extra entry allocated until the end instead. v2: Fix error paths for gen6 Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for allocation") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190617140426.7203-1-chris@chris-wilson.co.uk
2019-06-17drm/i915/dmc: protect against loading wrong firmwareLucas De Marchi1-3/+11
In intel_package_header version 2 there's a new field in the fw_info table that must be 0, otherwise it's not the correct DMC firmware. Add a check for version 2 or later. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-10-lucas.demarchi@intel.com
2019-06-17drm/i915/dmc: remove redundant return in parse_csr_fw()Lucas De Marchi1-11/+6
parse_csr_fw() is responsible to set up several fields in struct intel_csr, including the payload. We don't need to assign it again. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-9-lucas.demarchi@intel.com
2019-06-17drm/i915/dmc: add support to load dmc_header version 3Lucas De Marchi2-30/+95
Main difference is that now there are up to 20 MMIOs that can be set and a lot of noise due to the struct changing the fields in the middle. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-8-lucas.demarchi@intel.com
2019-06-17drm/i915/dmc: extract function to parse dmc_headerLucas De Marchi1-56/+74
Complete the extraction of functions to parse specific parts of the firmware. The return of the function parse_csr_fw() is now redundant since it already sets the dmc_payload field. Changing it is left for later to avoid noise in the commit. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-7-lucas.demarchi@intel.com
2019-06-17drm/i915/dmc: extract function to parse package_headerLucas De Marchi1-51/+66
Like parse_csr_fw_css() this parses the package_header from firmware and saves the relevant fields in the csr struct. In this function we also lookup the fw_info we are interested in. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-6-lucas.demarchi@intel.com
2019-06-17drm/i915/dmc: extract function to parse css headerLucas De Marchi1-25/+41
Let's start splitting the parse function, making all of them return the number of bytes parsed - different versions of the firmware header may require different sizes for the structures. v2: rework remaining bytes calculation on new protection for amount of bytes read Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-5-lucas.demarchi@intel.com
2019-06-17drm/i915/dmc: add support for package_header with version 2Lucas De Marchi1-12/+26
The only meaninful change is that it supports up to 32 fw_info entries rather than the previous max=20. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-4-lucas.demarchi@intel.com
2019-06-17drm/i915/dmc: extract fw_info and table walk from intel_package_headerLucas De Marchi1-17/+55
Move fw_info out of struct intel_package_header to allow it to grow more easily in future. To make a cleaner move, let's also extract a function to search the header for the dmc_offset. While reviewing this code I wondered why we continued the search even after finding a suitable firmware. Add a comment to explain we will continue to try to find a more specific firmware version, even if this is not required by the spec. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-3-lucas.demarchi@intel.com
2019-06-17drm/i915/dmc: use kernel typesLucas De Marchi1-5/+5
Change all fields in intel_package_header and intel_dmc_header whose meaning are 1-byte numbers to use u8. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-2-lucas.demarchi@intel.com
2019-06-17drm/amdgpu: wait to fetch the vbios until after common initAlex Deucher1-11/+13
We need the asic_funcs set for the get rom callbacks in some cases. Tested-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17drm/amd/powerplay: Delete a redundant memory setting in vega20_set_default_od8_setttings()Markus Elfring1-1/+0
The memory was set to zero already by a call of the function “kzalloc”. Thus remove an extra call of the function “memset” for this purpose. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17drm/amd/display: Delete a redundant memory setting in amdgpu_dm_irq_register_interrupt()Markus Elfring1-2/+0
The memory was set to zero already by a call of the function “kzalloc”. Thus remove an extra call of the function “memset” for this purpose. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17drm/amdgpu: fix error handling in df_v3_6_pmc_startArnd Bergmann1-4/+9
When df_v3_6_pmc_get_ctrl_settings() fails for some reason, we store uninitialized data in a register, as gcc points out: drivers/gpu/drm/amd/amdgpu/df_v3_6.c: In function 'df_v3_6_pmc_start': drivers/gpu/drm/amd/amdgpu/amdgpu.h:1012:29: error: 'lo_val' may be used uninitialized in this function [-Werror=maybe-uninitialized] #define WREG32_PCIE(reg, v) adev->pcie_wreg(adev, (reg), (v)) ^~~~ drivers/gpu/drm/amd/amdgpu/df_v3_6.c:334:39: note: 'lo_val' was declared here uint32_t lo_base_addr, hi_base_addr, lo_val, hi_val; ^~~~~~ Make it return a proper error code that we can catch in the caller. Fixes: 992af942a6cf ("drm/amdgpu: add df perfmon regs and funcs for xgmi") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17drm/amd/display: Add missing newline at end of fileGeert Uytterhoeven1-1/+1
"git diff" says: \ No newline at end of file after modifying the file. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17drm/amd/powerplay: detect version of smu backend (v2)Prike Liang13-0/+13
Print the backend type. v2: whitespace fixes (Alex) Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17drm/amdkfd: Fix sdma queue allocate race conditionOak Zeng1-1/+6
SDMA queue allocation requires the dqm lock as it modify the global dqm members. Enclose it in the dqm_lock. Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17drm/amdkfd: Fix a circular lock dependencyOak Zeng1-0/+4
The idea to break the circular lock dependency is to temporarily drop dqm lock before calling allocate_mqd. See callstack #1 below. [ 59.510149] [drm] Initialized amdgpu 3.30.0 20150101 for 0000:04:00.0 on minor 0 [ 513.604034] ====================================================== [ 513.604205] WARNING: possible circular locking dependency detected [ 513.604375] 4.18.0-kfd-root #2 Tainted: G W [ 513.604530] ------------------------------------------------------ [ 513.604699] kswapd0/611 is trying to acquire lock: [ 513.604840] 00000000d254022e (&dqm->lock_hidden){+.+.}, at: evict_process_queues_nocpsch+0x26/0x140 [amdgpu] [ 513.605150] but task is already holding lock: [ 513.605307] 00000000961547fc (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe4/0x250 [ 513.605540] which lock already depends on the new lock. [ 513.605747] the existing dependency chain (in reverse order) is: [ 513.605944] -> #4 (&anon_vma->rwsem){++++}: [ 513.606106] __vma_adjust+0x147/0x7f0 [ 513.606231] __split_vma+0x179/0x190 [ 513.606353] mprotect_fixup+0x217/0x260 [ 513.606553] do_mprotect_pkey+0x211/0x380 [ 513.606752] __x64_sys_mprotect+0x1b/0x20 [ 513.606954] do_syscall_64+0x50/0x1a0 [ 513.607149] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 513.607380] -> #3 (&mapping->i_mmap_rwsem){++++}: [ 513.607678] rmap_walk_file+0x1f0/0x280 [ 513.607887] page_referenced+0xdd/0x180 [ 513.608081] shrink_page_list+0x853/0xcb0 [ 513.608279] shrink_inactive_list+0x33b/0x700 [ 513.608483] shrink_node_memcg+0x37a/0x7f0 [ 513.608682] shrink_node+0xd8/0x490 [ 513.608869] balance_pgdat+0x18b/0x3b0 [ 513.609062] kswapd+0x203/0x5c0 [ 513.609241] kthread+0x100/0x140 [ 513.609420] ret_from_fork+0x24/0x30 [ 513.609607] -> #2 (fs_reclaim){+.+.}: [ 513.609883] kmem_cache_alloc_trace+0x34/0x2e0 [ 513.610093] reservation_object_reserve_shared+0x139/0x300 [ 513.610326] ttm_bo_init_reserved+0x291/0x480 [ttm] [ 513.610567] amdgpu_bo_do_create+0x1d2/0x650 [amdgpu] [ 513.610811] amdgpu_bo_create+0x40/0x1f0 [amdgpu] [ 513.611041] amdgpu_bo_create_reserved+0x249/0x2d0 [amdgpu] [ 513.611290] amdgpu_bo_create_kernel+0x12/0x70 [amdgpu] [ 513.611584] amdgpu_ttm_init+0x2cb/0x560 [amdgpu] [ 513.611823] gmc_v9_0_sw_init+0x400/0x750 [amdgpu] [ 513.612491] amdgpu_device_init+0x14eb/0x1990 [amdgpu] [ 513.612730] amdgpu_driver_load_kms+0x78/0x290 [amdgpu] [ 513.612958] drm_dev_register+0x111/0x1a0 [ 513.613171] amdgpu_pci_probe+0x11c/0x1e0 [amdgpu] [ 513.613389] local_pci_probe+0x3f/0x90 [ 513.613581] pci_device_probe+0x102/0x1c0 [ 513.613779] driver_probe_device+0x2a7/0x480 [ 513.613984] __driver_attach+0x10a/0x110 [ 513.614179] bus_for_each_dev+0x67/0xc0 [ 513.614372] bus_add_driver+0x1eb/0x260 [ 513.614565] driver_register+0x5b/0xe0 [ 513.614756] do_one_initcall+0xac/0x357 [ 513.614952] do_init_module+0x5b/0x213 [ 513.615145] load_module+0x2542/0x2d30 [ 513.615337] __do_sys_finit_module+0xd2/0x100 [ 513.615541] do_syscall_64+0x50/0x1a0 [ 513.615731] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 513.615963] -> #1 (reservation_ww_class_mutex){+.+.}: [ 513.616293] amdgpu_amdkfd_alloc_gtt_mem+0xcf/0x2c0 [amdgpu] [ 513.616554] init_mqd+0x223/0x260 [amdgpu] [ 513.616779] create_queue_nocpsch+0x4d9/0x600 [amdgpu] [ 513.617031] pqm_create_queue+0x37c/0x520 [amdgpu] [ 513.617270] kfd_ioctl_create_queue+0x2f9/0x650 [amdgpu] [ 513.617522] kfd_ioctl+0x202/0x350 [amdgpu] [ 513.617724] do_vfs_ioctl+0x9f/0x6c0 [ 513.617914] ksys_ioctl+0x66/0x70 [ 513.618095] __x64_sys_ioctl+0x16/0x20 [ 513.618286] do_syscall_64+0x50/0x1a0 [ 513.618476] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 513.618695] -> #0 (&dqm->lock_hidden){+.+.}: [ 513.618984] __mutex_lock+0x98/0x970 [ 513.619197] evict_process_queues_nocpsch+0x26/0x140 [amdgpu] [ 513.619459] kfd_process_evict_queues+0x3b/0xb0 [amdgpu] [ 513.619710] kgd2kfd_quiesce_mm+0x1c/0x40 [amdgpu] [ 513.620103] amdgpu_amdkfd_evict_userptr+0x38/0x70 [amdgpu] [ 513.620363] amdgpu_mn_invalidate_range_start_hsa+0xa6/0xc0 [amdgpu] [ 513.620614] __mmu_notifier_invalidate_range_start+0x70/0xb0 [ 513.620851] try_to_unmap_one+0x7fc/0x8f0 [ 513.621049] rmap_walk_anon+0x121/0x290 [ 513.621242] try_to_unmap+0x93/0xf0 [ 513.621428] shrink_page_list+0x606/0xcb0 [ 513.621625] shrink_inactive_list+0x33b/0x700 [ 513.621835] shrink_node_memcg+0x37a/0x7f0 [ 513.622034] shrink_node+0xd8/0x490 [ 513.622219] balance_pgdat+0x18b/0x3b0 [ 513.622410] kswapd+0x203/0x5c0 [ 513.622589] kthread+0x100/0x140 [ 513.622769] ret_from_fork+0x24/0x30 [ 513.622957] other info that might help us debug this: [ 513.623354] Chain exists of: &dqm->lock_hidden --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem [ 513.623900] Possible unsafe locking scenario: [ 513.624189] CPU0 CPU1 [ 513.624397] ---- ---- [ 513.624594] lock(&anon_vma->rwsem); [ 513.624771] lock(&mapping->i_mmap_rwsem); [ 513.625020] lock(&anon_vma->rwsem); [ 513.625253] lock(&dqm->lock_hidden); [ 513.625433] *** DEADLOCK *** [ 513.625783] 3 locks held by kswapd0/611: [ 513.625967] #0: 00000000f14edf84 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30 [ 513.626309] #1: 00000000961547fc (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe4/0x250 [ 513.626671] #2: 0000000067b5cd12 (srcu){....}, at: __mmu_notifier_invalidate_range_start+0x5/0xb0 [ 513.627037] stack backtrace: [ 513.627292] CPU: 0 PID: 611 Comm: kswapd0 Tainted: G W 4.18.0-kfd-root #2 [ 513.627632] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 513.627990] Call Trace: [ 513.628143] dump_stack+0x7c/0xbb [ 513.628315] print_circular_bug.isra.37+0x21b/0x228 [ 513.628581] __lock_acquire+0xf7d/0x1470 [ 513.628782] ? unwind_next_frame+0x6c/0x4f0 [ 513.628974] ? lock_acquire+0xec/0x1e0 [ 513.629154] lock_acquire+0xec/0x1e0 [ 513.629357] ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu] [ 513.629587] __mutex_lock+0x98/0x970 [ 513.629790] ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu] [ 513.630047] ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu] [ 513.630309] ? evict_process_queues_nocpsch+0x26/0x140 [amdgpu] [ 513.630562] evict_process_queues_nocpsch+0x26/0x140 [amdgpu] [ 513.630816] kfd_process_evict_queues+0x3b/0xb0 [amdgpu] [ 513.631057] kgd2kfd_quiesce_mm+0x1c/0x40 [amdgpu] [ 513.631288] amdgpu_amdkfd_evict_userptr+0x38/0x70 [amdgpu] [ 513.631536] amdgpu_mn_invalidate_range_start_hsa+0xa6/0xc0 [amdgpu] [ 513.632076] __mmu_notifier_invalidate_range_start+0x70/0xb0 [ 513.632299] try_to_unmap_one+0x7fc/0x8f0 [ 513.632487] ? page_lock_anon_vma_read+0x68/0x250 [ 513.632690] rmap_walk_anon+0x121/0x290 [ 513.632875] try_to_unmap+0x93/0xf0 [ 513.633050] ? page_remove_rmap+0x330/0x330 [ 513.633239] ? rcu_read_unlock+0x60/0x60 [ 513.633422] ? page_get_anon_vma+0x160/0x160 [ 513.633613] shrink_page_list+0x606/0xcb0 [ 513.633800] shrink_inactive_list+0x33b/0x700 [ 513.633997] shrink_node_memcg+0x37a/0x7f0 [ 513.634186] ? shrink_node+0xd8/0x490 [ 513.634363] shrink_node+0xd8/0x490 [ 513.634537] balance_pgdat+0x18b/0x3b0 [ 513.634718] kswapd+0x203/0x5c0 [ 513.634887] ? wait_woken+0xb0/0xb0 [ 513.635062] kthread+0x100/0x140 [ 513.635231] ? balance_pgdat+0x3b0/0x3b0 [ 513.635414] ? kthread_delayed_work_timer_fn+0x80/0x80 [ 513.635626] ret_from_fork+0x24/0x30 [ 513.636042] Evicting PASID 32768 queues [ 513.936236] Restoring PASID 32768 queues [ 524.708912] Evicting PASID 32768 queues [ 524.999875] Restoring PASID 32768 queues Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17Revert "drm/amdkfd: Fix a circular lock dependency"Oak Zeng1-10/+11
This reverts commit 06b89b38f3cc518a761164f9f958a9607bbb3587. This fix is not proper. allocate_mqd can't be moved before allocate_sdma_queue as it depends on q->properties->sdma_id set in later. Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17Revert "drm/amdkfd: Fix sdma queue allocate race condition"Oak Zeng1-12/+14
This reverts commit f77dac6cd62e5d4bcadd740620af1218bfb54cc6. This fix is not proper. allocate_mqd can't be moved before allocate_sdma_queue as it depends on q->properties->sdma_id set in later. Signed-off-by: Oak Zeng <Oak.Zeng@amd.com> Reviewed-by: Philip Yang <philip.yang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17drm/amdgpu: explicitly set mmGDS_VMID0_BASE to 0James Zhu1-18/+17
Explicitly set mmGDS_VMID0_BASE to 0. Also update GDS_VMID0_BASE/_SIZE with direct register writes. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-17drm/gem: Unexport drm_gem_(un)pin/v(un)mapDaniel Vetter2-32/+5
They're purely for internal use, not for drivers. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-3-daniel.vetter@ffwll.ch
2019-06-17drm/i915/gtt: Generalize alloc_pdMika Kuoppala1-52/+36
Allocate all page directory variants with alloc_pd. As the lvl3 and lvl4 variants differ in manipulation, we need to check for existence of backing phys page before accessing it. v2: use err in returns Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190614164350.30415-5-mika.kuoppala@linux.intel.com
2019-06-17drm/i915/gtt: Introduce init_pdMika Kuoppala1-23/+14
All page directories, excluding last level, are initialized with pointer to next level page directories. Make common function for it. Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190614164350.30415-4-mika.kuoppala@linux.intel.com
2019-06-17drm/i915/gtt: Introduce init_pd_with_pageMika Kuoppala1-8/+8
We set the page directory entries to point into a page table. There is no gen specifics in here so make it simple and obvious. Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190614164350.30415-3-mika.kuoppala@linux.intel.com
2019-06-17drm/i915/gtt: Use a common type for page directoriesMika Kuoppala6-215/+236
All page directories are identical in function, only the position in the hierarchy differ. Use same base type for directory functionality. v2: cleanup, size always 512, init to null Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190614164350.30415-2-mika.kuoppala@linux.intel.com
2019-06-17drm/i915/gtt: No need to zero the table for page dirsMika Kuoppala1-2/+2
We set them to scratch right after allocation so prevent useless zeroing before. v2: atomic_t v3: allow pdp alloc fail Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190614164350.30415-1-mika.kuoppala@linux.intel.com
2019-06-17drm/i915: no need to check return value of debugfs_create functionsGreg Kroah-Hartman1-13/+7
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613145229.21389-1-jani.nikula@intel.com
2019-06-17drm/i915: move modesetting core code under display/Jani Nikula77-103/+94
Now that we have a new subdirectory for display code, continue by moving modesetting core code. display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this is, again, a surprisingly clean operation. v2: - don't move intel_sideband.[ch] (Ville) - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-3-jani.nikula@intel.com
2019-06-17drm/i915/icl: Add Multi-segmented gamma supportShashank Sharma2-5/+123
ICL introduces a new gamma correction mode in display engine, called multi-segmented-gamma mode. This mode allows users to program the darker region of the gamma curve with sueprfine precision. An example use case for this is HDR curves (like PQ ST-2084). If we plot a gamma correction curve from value range between 0.0 to 1.0, ICL's multi-segment has 3 different sections: - superfine segment: 9 values, ranges between 0 - 1/(128 * 256) - fine segment: 257 values, ranges between 0 - 1/(128) - corase segment: 257 values, ranges between 0 - 1 This patch: - Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256), so that userspace can program with highest precision supported. - Changes default gamma mode (non-legacy) to multi-segmented-gamma mode. - Adds functions to program/detect multi-segment gamma. V2: Addressed review comments from Ville - separate function for superfine and fine segments. - remove enum for segments. - reuse last entry of the LUT as gc_max value. - replace if() ....cond with switch...case in icl_load_luts. - add an entry variable, instead of 'word' V3: Addressed review comments from Ville - extra newline - s/entry/color/ - remove LUT size checks - program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw - Change the comments in description of fine and coarse segments, and try to make more sense. - use 8 * 128 instead of 1024 - add 1 entry in LUT for GCMAX V4: Addressed review comments from Ville - Remove unused macro - missing shift entry in blue - pick correct entry for GCMAX - Added Ville's R-B Note: Tested and confirmed the programming sequence of odd/even registers in the HW. The correct sequence should be: ilk_lut_12p4_udw ilk_lut_12p4_ldw v5: Addressed Ville's review comments and renamed odd/even register helpers to be more consistent with the values. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1560321900-18318-5-git-send-email-uma.shankar@intel.com
2019-06-17drm/i915: Rename ivb_load_lut_10_maxShashank Sharma1-7/+7
This patch renames function ivb_load_lut_10_max to ivb_load_lut_ext_max. V3: Added Vill'es r-b. Cc: Uma Shankar <uma.shankar@intel.com> Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1560321900-18318-4-git-send-email-uma.shankar@intel.com
2019-06-17drm/i915/icl: Add register definitions for Multi Segmented gammaUma Shankar1-1/+18
Add macros to define multi segmented gamma registers V2: Addressed Ville's comments: Add gen-lable before bit definition Addressed Jani's comment - Use REG_GENMASK() and REG_BIT() V3: Addressed Ville's comments: - Put comments at the end of line. - Change the comment at start of ICL multisegmented gamma registers. Added Ville's r-b Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1560321900-18318-3-git-send-email-uma.shankar@intel.com
2019-06-17drm/i915: Change gamma/degamma_lut_size data type to u32Shashank Sharma1-2/+2
Currently, data type of gamma_lut_size & degamma_lut_size elements in intel_device_info is u16, which means it can accommodate maximum 64k values. In case of ICL multisegmented gamma, the size of gamma LUT is 256K. This patch changes the data type of both of these elements to u32. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> V4: Added Uma's r-b. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1560321900-18318-2-git-send-email-uma.shankar@intel.com
2019-06-17drm/i915: Nuke atomic set/get prop plane stubsMaarten Lankhorst4-67/+0
They have been unused since rotation was added to drm core in 2015, time to get rid of them. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190611132820.31981-1-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2019-06-17drm/i915: move modesetting output/encoder code under display/Jani Nikula61-70/+82
Add a new subdirectory for display code, and start off by moving modesetting output/encoder code. Judging by the include changes, this is a surprisingly clean operation. v2: - move intel_sdvo_regs.h too - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-2-jani.nikula@intel.com
2019-06-17drm/i915: make intel_sdvo_regs.h self-containedJani Nikula2-0/+9
Ensure intel_sdvo_regs.h is self-contained and remains that way. v2: - include <linux/compiler.h> for __packed (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190613100818.24800-1-jani.nikula@intel.com
2019-06-17Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst260-3301/+9531
Pick up rc3 and rc4 and the merges from the other branches, we're a bit out of date. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2019-06-17drm/i915/gvt: ignore unexpected pvinfo writeWeinan Li1-6/+9
There is pvinfo writing come from vgpu might be unexpected, like writing to one unknown address, GVT-g should do as reserved register to discard any invalid write. Now GVT-g lets it write to the vreg without prompt error message, should ignore the unexpected pvinfo write access and leave the vreg as the default value. For possible guest query GVT-g host feature, this returned proper value instead of wrong guest setting. v2: ignore unexpected pvinfo write instead of return predefined value Fixes: e39c5add3221 ("drm/i915/gvt: vGPU MMIO virtualization") Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Weinan Li <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2019-06-16drm/rockchip: Base adjustments of the mode based on prev adjustmentsDouglas Anderson1-2/+2
In vop_crtc_mode_fixup() we fixup the mode to show what we actually will be able to achieve. However we should base our adjustments on any previous adjustments that were made. As an example, the dw_hdmi driver may wish to make some small adjustments to clock rates in its atomic_check() function. If it does, it will update the adjusted_mode. We shouldn't throw away those adjustments. NOTE: the version of the dw_hdmi driver upstream doesn't _actually_ make such adjustments, but downstream in Chrome OS it does. It is plausible that one day we'll figure out how to cleanly make that happen in an upstream-friendly way, so we should prepare by using the right mode. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-2-dianders@chromium.org
2019-06-16drm/rockchip: Properly adjust to a true clock in adjusted_modeDouglas Anderson1-1/+2
When fixing up the clock in vop_crtc_mode_fixup() we're not doing it quite correctly. Specifically if we've got the true clock 266666667 Hz, we'll perform this calculation: 266666667 / 1000 => 266666 Later when we try to set the clock we'll do clk_set_rate(266666 * 1000). The common clock framework won't actually pick the proper clock in this case since it always wants clocks <= the specified one. Let's solve this by using DIV_ROUND_UP. Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-1-dianders@chromium.org
2019-06-15drm/i915/ehl: Update MOCS table for EHLMatt Roper1-0/+8
EHL defines two new MOCS table entries but is otherwise compatible with the ICL MOCS table. These table entries (16 and 17) should still be considered unused for ICL and as such their behavior remains undefined for that platform. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190530234014.22340-1-matthew.d.roper@intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2019-06-15kbuild: add support for ensuring headers are self-containedJani Nikula2-12/+1
Sometimes it's useful to be able to explicitly ensure certain headers remain self-contained, i.e. that they are compilable as standalone units, by including and/or forward declaring everything they depend on. Add special target header-test-y where individual Makefiles can add headers to be tested if CONFIG_HEADER_TEST is enabled. This will generate a dummy C file per header that gets built as part of extra-y. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.