aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-12-15drm/msm/dpu: make danger_status/safe_status readableDmitry Baryshkov1-1/+1
Change \t to \n in the print format to stop putting all SSPP status in a single line. Splitting it to one SSPP per line is much more readable. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-12-15drm/msm/dpu: fix safe status debugfs fileDmitry Baryshkov1-2/+2
Make safe_status debugfs fs file actually return safe status rather than danger status data. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-12-15drm/msm/dpu: move disable_danger out of plane subdirDmitry Baryshkov3-73/+77
The disable_danger debugfs file is not related to a single plane. Instead it is used by all registered planes. Move it from plane subtree to the global subtree next to danger_status and safe_status files, so that the new file supplements them. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-12-15drm/vc4: kms: Wait for the commit before increasing our clock rateMaxime Ripard1-8/+7
Several DRM/KMS atomic commits can run in parallel if they affect different CRTC. These commits share the global HVS state, so we have some code to make sure we run commits in sequence. This synchronization code is one of the first thing that runs in vc4_atomic_commit_tail(). Another constraints we have is that we need to make sure the HVS clock gets a boost during the commit. That code relies on clk_set_min_rate and will remove the old minimum and set a new one. We also need another, temporary, minimum for the duration of the commit. The algorithm is thus to set a temporary minimum, drop the previous one, do the commit, and finally set the minimum for the current mode. However, the part that sets the temporary minimum and drops the older one runs before the commit synchronization code. Thus, under the proper conditions, we can end up mixing up the minimums and ending up with the wrong one for our current step. To avoid it, let's move the clock setup in the protected section. Fixes: d7d96c00e585 ("drm/vc4: hvs: Boost the core clock during modeset") Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Tested-by: Jian-Hong Pan <[email protected]> [danvet: re-apply this from 0c980a006d3f ("drm/vc4: kms: Wait for the commit before increasing our clock rate") because I lost that part in my merge resolution in 99b03ca651f1 ("Merge v5.16-rc5 into drm-next")] Fixes: 99b03ca651f1 ("Merge v5.16-rc5 into drm-next") Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-12-14drm/i915: replace X86_FEATURE_PAT with pat_enabled()Lucas De Marchi2-6/+5
PAT can be disabled on boot with "nopat" in the command line. Replace one x86-ism with another, which is slightly more correct to prepare for supporting other architectures. Cc: Matt Roper <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-12-14drm/radeon: Fix syntax errors in commentsXiang wangx1-1/+1
Delete the redundant word 'we'. Reviewed-by: Christian König <[email protected]> Signed-off-by: Xiang wangx <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14amdgpu: fix some comment typosYann Dirson3-3/+3
Signed-off-by: Yann Dirson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14amdgpu: fix some kernel-doc markupYann Dirson3-6/+6
Those are not today pulled by the sphinx doc, but better be ready. Signed-off-by: Yann Dirson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14Documentation/gpu: include description of some of the GC microcontrollersYann Dirson1-0/+35
This is Alex' description from the "Looking for clarifications around gfx/kcq/kiq" thread, edited to fit as ReST. Original text: https://www.spinics.net/lists/amd-gfx/msg71383.html Originally-by: Alex Deucher <[email protected]> Signed-off-by: Yann Dirson <[email protected]> Acked-by: Harry Wentland <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14Documentation/gpu: include description of AMDGPU hardware structureYann Dirson2-0/+84
This describes in broad lines the how an AMD GPU is organized, in terms of hardware blocks. This is Alex' description from the "gpu block diagram" thread, edited to fit as ReST. Original text: https://www.spinics.net/lists/amd-gfx/msg71543.html Originally-by: Alex Deucher <[email protected]> Signed-off-by: Yann Dirson <[email protected]> Acked-by: Harry Wentland <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/pm: fix a potential gpu_metrics_table memory leakLang Yu1-0/+3
Memory is allocated for gpu_metrics_table in renoir_init_smc_tables(), but not freed in int smu_v12_0_fini_smc_tables(). Free it! Fixes: 95868b85764a ("drm/amd/powerplay: add Renoir support for gpu metrics export") Signed-off-by: Lang Yu <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/amdgpu: fix gmc bo pin count leak in SRIOVJingwen Chen2-0/+8
[Why] gmc bo will be pinned during loading amdgpu and reset in SRIOV while only unpinned in unload amdgpu [How] add amdgpu_in_reset and sriov judgement to skip pin bo v2: fix wrong judgement Signed-off-by: Jingwen Chen <[email protected]> Reviewed-by: Horace Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/amdgpu: fix psp tmr bo pin count leak in SRIOVJingwen Chen1-0/+4
[Why] psp tmr bo will be pinned during loading amdgpu and reset in SRIOV while only unpinned in unload amdgpu [How] add amdgpu_in_reset and sriov judgement to skip pin bo v2: fix wrong judgement Signed-off-by: Jingwen Chen <[email protected]> Reviewed-by: Horace Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/pm: Skip power state allocationLijo Lazar2-20/+0
Power states are not valid for arcturus and aldebaran, no need to allocate memory. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Yang Wang <[email protected]> Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amdgpu: correct the wrong cached state for GMC on PICASSOEvan Quan3-5/+18
Pair the operations did in GMC ->hw_init and ->hw_fini. That can help to maintain correct cached state for GMC and avoid unintention gate operation dropping due to wrong cached state. BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1828 Signed-off-by: Evan Quan <[email protected]> Acked-by: Guchun Chen <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amdgpu: use adev_to_drm to get drm_device pointerGuchun Chen1-1/+1
Updated for consistency when accessing drm_device from amdgpu driver. Signed-off-by: Guchun Chen <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amdgpu: move smu_debug_mask to a more proper placeEvan Quan4-16/+18
As the smu_context will be invisible from outside(of power). Also, the smu_debug_mask can be shared around all power code instead of some specific framework(swSMU) only. Signed-off-by: Evan Quan <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Reviewed-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amdgpu: SRIOV flr_work should use down_writeVictor Skvortsov2-4/+6
Host initiated VF FLR may fail if someone else is already holding a read_lock. Change from down_write_trylock to down_write to guarantee the reset goes through. Signed-off-by: Victor Skvortsov <[email protected]> Reviewed by: Shaoyun.liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: 3.2.166Aric Cyr1-1/+1
Tested-by: Daniel Wheeler <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Signed-off-by: Aric Cyr <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: implement dc_mode_memclkMartin Leung14-7/+188
why: Need interface to lower clocks when in dc (power save) mode. Must be able to work with p_state unsupported cases Can cause flicker when OS notifies us of dc state change how: added dal3 interface for KMD added pathway to query smu for this softmax added blank before clock change to override underflow added logic to change clk based on pstatesupport and softmax added logic in prepare/optimize_bw to conform while changing clocks Reviewed-by: Aric Cyr <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Martin Leung <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: ODM + MPO window on only one half of ODMEric Bernstein2-21/+71
[Why] For ODM + MPO window on one half of ODM, only 3 pipes should be allocated and scaling parameters adjusted to handle this case [How] Fix pipe allocation when MPO viewport is only on one side of ODM split, and modify scaling paramters. Added diags test cases for ODM + windows MPO, where MPO window is on right half, left half, and both halves or ODM. Reviewed-by: Dmytro Laktyushkin <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Eric Bernstein <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: Reset DMCUB before HW initNicholas Kazlauskas1-0/+5
[Why] If the firmware wasn't reset by PSP or HW and is currently running then the firmware will hang or perform underfined behavior when we modify its firmware state underneath it. [How] Reset DMCUB before setting up cache windows and performing HW init. Reviewed-by: Aurabindo Jayamohanan Pillai <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: [FW Promotion] Release 0.0.97Anthony Koo1-2/+2
Reviewed-by: Aric Cyr <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Anthony Koo <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: Force det buf size to 192KB with 3+ streams and upscalingMichael Strauss1-0/+8
[WHY] This workaround resolves underflow caused by incorrect DST_Y_PREFETCH. Overriding to 192KB DET buf size until the DST_Y_PREFETCH calc is fixed. Reviewed-by: Eric Yang <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Michael Strauss <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: parse and check PSR SU capsMikita Lipski3-13/+98
[why] Adding a function to read PSR capabilities and ALPM capabilities. Also adding a helper function to validate if the sink and the driver support PSR SU. [how] - isolated all PSR and ALPM reading calls to a separate funciton - set all required PSR caps - added a helper function to check if PSR SU is supported by sink and the driver Reviewed-by: Roman Li <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Mikita Lipski <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: Add src/ext ID info for dummy serviceSolomon Chiu1-4/+6
[Why] Current error log of dummy irq service doesn't have src/ext ID info in the log. [How] Add src/ext ID in ack/set of dummy irq service. Reviewed-by: Wayne Lin <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Solomon Chiu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: Add debugfs entry for ILRWayne Lin1-0/+134
[Why & How] In order to know the intermediate link rates supported by the eDP panel and test to select the optimized link rate to save power, create a new debugfs entry "ilr_setting" for setting ILR. Reviewed-by: Aurabindo Jayamohanan Pillai <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Wayne Lin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/amd/display: Set exit_optimized_pwr_state for DCN31Nicholas Kazlauskas1-0/+1
[Why] SMU now respects the PHY refclk disable request from driver. This causes a hang during hotplug when PHY refclk was disabled because it's not being re-enabled and the transmitter control starts on dc_link_detect. [How] We normally would re-enable the clk with exit_optimized_pwr_state but this is only set on DCN21 and DCN301. Set it for dcn31 as well. This fixes DMCUB timeouts in the PHY. Fixes: 64b1d0e8d500 ("drm/amd/display: Add DCN3.1 HWSEQ") Reviewed-by: Eric Yang <[email protected]> Acked-by: Pavle Kotarac <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-14drm/i915/debugfs: add noreclaim annotationsMatthew Auld1-0/+3
We have a debugfs hook to directly call into i915_gem_shrink() with the fs_reclaim acquire annotations to simulate hitting direct reclaim. However we should also annotate this with memalloc_noreclaim, which will set PF_MEMALLOC for us on the current context, to ensure we can't re-enter direct reclaim(just like "real" direct reclaim does). This is an issue now that ttm_bo_validate could potentially be called here, which might try to allocate a tiny amount of memory to hold the new ttm_resource struct, as per the below splat: [ 2507.913844] WARNING: possible recursive locking detected [ 2507.913848] 5.16.0-rc4+ #5 Tainted: G U [ 2507.913853] -------------------------------------------- [ 2507.913856] gem_exec_captur/1825 is trying to acquire lock: [ 2507.913861] ffffffffb9df2500 (fs_reclaim){..}-{0:0}, at: kmem_cache_alloc_trace+0x30/0x390 [ 2507.913875] but task is already holding lock: [ 2507.913879] ffffffffb9df2500 (fs_reclaim){..}-{0:0}, at: i915_drop_caches_set+0x1c9/0x2c0 [i915] [ 2507.913962] other info that might help us debug this: [ 2507.913966] Possible unsafe locking scenario: [ 2507.913970] CPU0 [ 2507.913973] ---- [ 2507.913975] lock(fs_reclaim); [ 2507.913979] lock(fs_reclaim); [ 2507.913983] DEADLOCK *** [ 2507.913988] May be due to missing lock nesting notation [ 2507.913992] 4 locks held by gem_exec_captur/1825: [ 2507.913997] #0: ffff888101f6e460 (sb_writers#17){..}-{0:0}, at: ksys_write+0xe9/0x1b0 [ 2507.914009] #1: ffff88812d99e2b8 (&attr->mutex){..}-{3:3}, at: simple_attr_write+0xbb/0x220 [ 2507.914019] #2: ffffffffb9df2500 (fs_reclaim){..}-{0:0}, at: i915_drop_caches_set+0x1c9/0x2c0 [i915] [ 2507.914085] #3: ffff8881b4a11b20 (reservation_ww_class_mutex){..}-{3:3}, at: ww_mutex_trylock+0x43f/0xcb0 [ 2507.914097] stack backtrace: [ 2507.914102] CPU: 0 PID: 1825 Comm: gem_exec_captur Tainted: G U 5.16.0-rc4+ #5 [ 2507.914109] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 0403 01/26/2021 [ 2507.914115] Call Trace: [ 2507.914118] <TASK> [ 2507.914121] dump_stack_lvl+0x59/0x73 [ 2507.914128] __lock_acquire.cold+0x227/0x3b0 [ 2507.914135] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 2507.914141] ? __lock_acquire+0x23ca/0x5000 [ 2507.914147] lock_acquire+0x19c/0x4b0 [ 2507.914152] ? kmem_cache_alloc_trace+0x30/0x390 [ 2507.914157] ? lock_release+0x690/0x690 [ 2507.914163] ? lock_is_held_type+0xe4/0x140 [ 2507.914170] ? ttm_sys_man_alloc+0x47/0xb0 [ttm] [ 2507.914178] fs_reclaim_acquire+0x11a/0x160 [ 2507.914183] ? kmem_cache_alloc_trace+0x30/0x390 [ 2507.914188] kmem_cache_alloc_trace+0x30/0x390 [ 2507.914192] ? lock_release+0x37f/0x690 [ 2507.914198] ttm_sys_man_alloc+0x47/0xb0 [ttm] [ 2507.914206] ttm_bo_pipeline_gutting+0x70/0x440 [ttm] [ 2507.914214] ? ttm_mem_io_free+0x150/0x150 [ttm] [ 2507.914221] ? lock_is_held_type+0xe4/0x140 [ 2507.914227] ttm_bo_validate+0x2fb/0x370 [ttm] [ 2507.914234] ? lock_acquire+0x19c/0x4b0 [ 2507.914239] ? ttm_bo_bounce_temp_buffer.constprop.0+0xf0/0xf0 [ttm] [ 2507.914246] ? lock_acquire+0x131/0x4b0 [ 2507.914251] ? lock_is_held_type+0xe4/0x140 [ 2507.914257] i915_ttm_shrinker_release_pages+0x2bc/0x490 [i915] [ 2507.914339] ? i915_ttm_swap_notify+0x130/0x130 [i915] [ 2507.914429] ? i915_gem_object_release_mmap_offset+0x32/0x250 [i915] [ 2507.914529] i915_gem_shrink+0xb14/0x1290 [i915] [ 2507.914616] ? ___i915_gem_object_make_shrinkable+0x3e0/0x3e0 [i915] [ 2507.914698] ? _raw_spin_unlock_irqrestore+0x2d/0x60 [ 2507.914705] ? track_intel_runtime_pm_wakeref+0x180/0x230 [i915] [ 2507.914777] i915_gem_shrink_all+0x4b/0x70 [i915] [ 2507.914857] i915_drop_caches_set+0x227/0x2c0 [i915] Reported-by: Thomas Hellström <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-12-14drm/i915/ttm: fix large buffer population trucationRobert Beckett1-1/+1
ttm->num_pages is uint32_t which was causing very large buffers to only populate a truncated size. This fixes gem_create@create-clear igt test on large memory systems. Fixes: 7ae034590cea ("drm/i915/ttm: add tt shmem backend") Signed-off-by: Robert Beckett <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-12-14drm: document DRM_IOCTL_MODE_GETFB2Simon Ser1-0/+18
There are a few details specific to the GETFB2 IOCTL. It's not immediately clear how user-space should check for the number of planes. Suggest using the handles field or the pitches field. The modifier array is filled with zeroes, ie. DRM_FORMAT_MOD_LINEAR. So explicitly tell user-space to not look at it unless the flag is set. Changes in v2 (Daniel): - Mention that handles should be used to compute the number of planes, and only refer to pitches as a fallback. - Reword bit about undefined modifier. Signed-off-by: Simon Ser <[email protected]> Acked-by: Daniel Vetter <[email protected]> Acked-by: Pekka Paalanen <[email protected]> Acked-by: Daniel Stone <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-12-14drm/i915: Test all device memory on probingChris Wilson3-12/+28
This extends the previous sanitychecking of device memory to read/write all the memory on the device during the device probe, ala memtest86, as an optional module parameter: i915.memtest=1. This is not expected to be fast, but a reasonably thorough verfification that the device memory is accessible and doesn't return bit errors. v2: Rebased. Suggested-by: Matthew Auld <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Signed-off-by: Ramalingam C <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-12-14drm/i915: Sanitycheck device iomem on probeChris Wilson1-0/+116
As we setup the memory regions for the device, give each a quick test to verify that we can read and write to the full iomem range. This ensures that our physical addressing for the device's memory is correct, and some reassurance that the memory is functional. v2: wrapper for memtest [Chris] v3: Removed the unused ptr i915 [Chris] v4: used the %pa for the resource_size_t. Signed-off-by: Chris Wilson <[email protected]> Cc: Matthew Auld <[email protected]> Signed-off-by: Ramalingam C <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-12-14drm/i915: Exclude reserved stolen from driver useChris Wilson1-0/+3
Remove the portion of stolen memory reserved for private use from driver access. Signed-off-by: Chris Wilson <[email protected]> cc: Matthew Auld <[email protected]> Signed-off-by: Ramalingam C <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-12-14Merge v5.16-rc5 into drm-nextDaniel Vetter929-7121/+10985
Thomas Zimmermann requested a fixes backmerge, specifically also for 96c5f82ef0a1 ("drm/vc4: fix error code in vc4_create_object()") Just a bunch of adjacent changes conflicts, even the big pile of them in vc4. Signed-off-by: Daniel Vetter <[email protected]>
2021-12-14drm/i915: Fix implicit use of struct pci_devMark Brown1-0/+1
intel_device_info.h references struct pci_dev but does not ensure that the struct has been declared, causing build failures if something in other headers changes so that the implicit dependency it is relying on is no longer satisfied: In file included from drivers/gpu/drm/i915/intel_device_info.h:32, from drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:11, from drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:11: drivers/gpu/drm/i915/display/intel_display.h:643:39: error: 'struct pci_dev' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 643 | bool intel_modeset_probe_defer(struct pci_dev *pdev); | ^~~~~~~ cc1: all warnings being treated as errors Add a declaration of the struct to fix this. Signed-off-by: Mark Brown <[email protected]> Fixes: 94b541f53db1 ("drm/i915: Add intel_modeset_probe_defer() helper") Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-12-14drm/mediatek: Set the default value of rotation to DRM_MODE_ROTATE_0Mark Yacoub1-1/+2
At the reset hook, call __drm_atomic_helper_plane_reset which is called at the initialization of the plane and sets the default value of rotation on all planes to DRM_MODE_ROTATE_0 which is equal to 1. Tested on Jacuzzi (MTK). Resolves IGT@kms_properties@plane-properties-{legacy,atomic} Signed-off-by: Mark Yacoub <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]>
2021-12-13drm/msm/a6xx: Skip crashdumper state if GPU needs_hw_initRob Clark2-2/+8
I am seeing some crash logs which imply that we are trying to use crashdumper hw to read back GPU state when the GPU isn't initialized. This doesn't go well (for example, GPU could be in 32b address mode and ignoring the upper bits of buffer that it is trying to dump state to). I'm not *quite* sure how we get into this state in the first place, but lets not make a bad situation worse by triggering iova fault crashes. While we're at it, also add the information about whether the GPU is initialized to the devcore dump to make this easier to see in the logs (which makes the WARN_ON() redundant and even harmful because it fills up the small bit of dmesg we get with the crash report). Signed-off-by: Rob Clark <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-12-13drm:amdgpu:remove unneeded variablechiminghao2-8/+3
return value form directly instead of taking this in another redundant variable. Reported-by: Zeal Robot <[email protected]> Signed-off-by: chiminghao <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13Documentation/gpu: split amdgpu/index for readabilityYann Dirson7-334/+324
This starts to make the formated index much more manageable to the reader. Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Yann Dirson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drivers/amd/pm: drop statement to print FW version for smu_v13Mario Limonciello1-3/+0
Update smu_v13 to match smu_v12 and smu_v11 behavior where this is fetched from debugfs rather than in kernel logs on every boot. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drm/amd/pm: fix reading SMU FW version from amdgpu_firmware_info on YCMario Limonciello1-0/+3
This value does not get cached into adev->pm.fw_version during startup for smu13 like it does for other SMU like smu12. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drm/amd/display: fix function scopesIsabella Basso48-517/+179
This turns previously global functions into static, thus removing compile-time warnings such as: warning: no previous prototype for 'get_highest_allowed_voltage_level' [-Wmissing-prototypes] 742 | unsigned int get_highest_allowed_voltage_level(uint32_t chip_family, uint32_t hw_internal_rev, uint32_t pci_revision_id) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ warning: no previous prototype for 'rv1_vbios_smu_send_msg_with_param' [-Wmissing-prototypes] 102 | int rv1_vbios_smu_send_msg_with_param(struct clk_mgr_internal *clk_mgr, unsigned int msg_id, unsigned int param) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Changes since v1: - As suggested by Rodrigo Siqueira: 1. Rewrite function signatures to make them more readable. 2. Get rid of unused functions in order to remove 'defined but not used' warnings. Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Isabella Basso <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drm/amd/display: Reduce stack size for dml31 UseMinimumDCFCLKMichel Dänzer1-235/+69
Use the struct display_mode_lib pointer instead of passing lots of large arrays as parameters by value. Addresses this warning (resulting in failure to build a RHEL debug kernel with Werror enabled): ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c: In function ‘UseMinimumDCFCLK’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:7478:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=] NOTE: AFAICT this function previously had no observable effect, since it only modified parameters passed by value and doesn't return anything. Now it may modify some values in struct display_mode_lib passed in by reference. Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drm/amd/display: Reduce stack size for ↵Michel Dänzer1-86/+99
dml31_ModeSupportAndSystemConfigurationFull Move code using the Pipe struct to a new helper function. Works around[0] this warning (resulting in failure to build a RHEL debug kernel with Werror enabled): ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c: In function ‘dml31_ModeSupportAndSystemConfigurationFull’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:5740:1: warning: the frame size of 2144 bytes is larger than 2048 bytes [-Wframe-larger-than=] The culprit seems to be the Pipe struct, so pull the relevant block out into its own sub-function. (This is porting commit a62427ef9b55 ("drm/amd/display: Reduce stack size for dml21_ModeSupportAndSystemConfigurationFull") from dml31 to dml21) [0] AFAICT this doesn't actually reduce the total amount of stack which can be used, just moves some of it from dml31_ModeSupportAndSystemConfigurationFull to the new helper function, so the former happens to no longer exceed the limit for a single function. Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drm/amdgpu: re-format file header commentsIsabella Basso1-1/+1
Fix the warning below: warning: Cannot understand * \file amdgpu_ioc32.c on line 2 - I thought it was a doc line Changes since v1: - As suggested by Alexander Deucher: 1. Reduce diff to minimum as this DOC section doesn't provide much value. Signed-off-by: Isabella Basso <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drm/amdgpu: remove unnecessary variablesIsabella Basso2-10/+1
This fixes the warnings below, and also drops the display_count variable, as it's unused. In function 'svm_range_map_to_gpu': warning: variable 'bo_va' set but not used [-Wunused-but-set-variable] 1172 | struct amdgpu_bo_va bo_va; | ^~~~~ ... In function 'dcn201_update_clocks': warning: variable 'enter_display_off' set but not used [-Wunused-but-set-variable] 132 | bool enter_display_off = false; | ^~~~~~~~~~~~~~~~~ Changes since v1: - As suggested by Rodrigo Siqueira: 1. Drop display_count variable. - As suggested by Felix Kuehling: 1. Remove block surrounding amdgpu_xgmi_same_hive. Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Isabella Basso <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drm/amdgpu: fix amdgpu_ras_mca_query_error_status scopeIsabella Basso1-3/+3
This commit fixes the compile-time warning below: warning: no previous prototype for ‘amdgpu_ras_mca_query_error_status’ [-Wmissing-prototypes] Changes since v1: - As suggested by Alexander Deucher: 1. Make function static instead of adding prototype. Signed-off-by: Isabella Basso <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drm/amd: move variable to local scopeMario Limonciello1-2/+2
`edp_stream` is only used when backend is enabled on eDP, don't declare the variable outside that scope. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2021-12-13drm/amd: add some extra checks that is_dig_enabled is definedMario Limonciello2-12/+12
There are a few places that this isn't checked that could potentially be a NULL pointer access. Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.