summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-10-10drm/amdgpu/powerplay: factor out some pptable helpersAlex Deucher
Move copy_array helpers to smu_helper.c and share between vega12 and vega20. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu/powerplay: endian fixes for vega20_processpptables.cAlex Deucher
Properly swap data from vbios. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu/powerplay: endian fixes for vega12_processpptables.cAlex Deucher
Properly swap data from vbios. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu/powerplay: endian fixes for vega10_processpptables.cAlex Deucher
Properly swap data from vbios. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: remove set but not used variable 'header'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c: In function 'amdgpu_ucode_init_bo': drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:431:39: warning: variable 'header' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: remove set but not used variable 'ring' in psp_v11_0_ring_stopYueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdgpu/psp_v11_0.c: In function 'psp_v11_0_ring_stop': drivers/gpu/drm/amd/amdgpu/psp_v11_0.c:309:19: warning: variable 'ring' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdkfd: Remove set but not used variable 'preempt_all_queues'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c: In function 'destroy_queue_cpsch': drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:1366:7: warning: variable 'preempt_all_queues' set but not used [-Wunused-but-set-variable] It never used since introduct in commit 992839ad64f2 ("drm/amdkfd: Add static user-mode queues support") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu/powerplay: fix missing break in switch statementsColin Ian King
There are several switch statements that are missing break statements. Add missing breaks to handle any fall-throughs corner cases. Detected by CoverityScan, CID#1457175 ("Missing break in switch") Fixes: 18aafc59b106 ("drm/amd/powerplay: implement fw related smu interface for iceland.") Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Suppress keypresses from ACPI_VIDEO eventsLyude Paul
Currently we return NOTIFY_DONE for any event which we don't think is ours. However, many laptops will send more then just an ATIF event and will also send an ACPI_VIDEO_NOTIFY_PROBE event as well. Since we don't check for this, we return NOTIFY_DONE which causes a keypress for the ACPI event to be propogated to userspace. This is the equivalent of someone pressing the display key on a laptop every time there's a hotplug event. So, check for ACPI_VIDEO_NOTIFY_PROBE events and suppress keypresses from them. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Remove the direct fw loading support for sdma2.4Rex Zhu
sdma2.4 is only for iceland. For Vi, we don't maintain the direct fw loading. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Remove wrong fw loading type warningRex Zhu
Remove the warning message: "-1 is not supported on VI" the -1 is the default fw load type, mean auto. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Load fw between hw_init/resume_phase1 and phase2Rex Zhu
Extract the function of fw loading out of powerplay. Do fw loading between hw_init/resuem_phase1 and phase2 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: split ip hw_init into 2 phasesRex Zhu
We need to do some IPs earlier to deal with ordering issues similar to how resume is split into two phases. Will do fw loading via smu/psp between the two phases. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Remove amdgpu_ucode_fini_boRex Zhu
The variable clean is unnecessary. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Split amdgpu_ucode_init/fini_bo into two functionsRex Zhu
1. one is for create/free bo when init/fini 2. one is for fill the bo before fw loading the ucode bo only need to be created when load driver and free when driver unload. when resume/reset, driver only need to re-fill the bo if the bo is allocated in vram. Suggested by Christian. v2: Return error when bo create failed. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Check late_init status before set cg/pg stateRex Zhu
Fix cg/pg unexpected set in hw init failed case. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Refine function amdgpu_device_ip_late_initRex Zhu
1. only call late_init when hw_init successful, so check status.hw instand of status.valid in late_init. 2. set status.late_initialized true if late_init was not implemented. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Change AI gfx/sdma/smu init sequenceRex Zhu
initialize gfx/sdma before dpm features enabled. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Change SI/CI gfx/sdma/smu init sequenceRex Zhu
initialize gfx/sdma before dpm features enabled. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: Limit the max mc address to hole startEmily Deng
For the vram_start is 0 case, the gart range will be from 0x0000FFFF00000000 to 0x0000FFFF1FFFFFFF, which will cause the engine hang. So to avoid the hole, limit the max mc address to AMDGPU_GMC_HOLE_START.:wq Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: fix CPDMA hang in PRT modeTao Zhou
Fix CPDMA hang in PRT mode, set CPF_INT_DMA in reg CP_MECx_F32_INT_DIS for Compute and set DISABLE_GFX_HALT_ON_UTCL1_ERROR in reg CP_DEBUG for GFX Affected ASICs: Vega10 Vega12 Raven Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Tested-by: Yukun.Li <yukun1.li@amd.com> Tested-by: Maciej.Jesionowski <maciej.jesionowski@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amdgpu: add CP_DEBUG register definition for GC9.0Tao Zhou
Add CP_DEBUG register definition. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amd/display: RV2 DP MST 2nd display within daisy chain not light upHersen Wu
RV2 resource is limit to 3 pipes. Limitation should apply to all HW blocks instead of front pipe. Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/amd/display: Fix warning storm on Raven2Roman Li
[Why] Wrong index for pstate debug test register [How] Add correct index value for dcn1_01 in hubbub1_construct() Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Signed-off-by: Roman Li <Roman.Li@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-10drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectorsLyude Paul
It appears when testing my previous fix for some of the legacy modesetting issues with MST, I misattributed some kernel splats that started appearing on my machine after a rebase as being from upstream. But it appears they actually came from my patch series: [ 2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1] [ 2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered [ 2.980516] ------------[ cut here ]------------ [ 2.980519] Could not determine valid watermarks for inherited state [ 2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd [ 2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O 4.19.0-rc7Lyude-Test+ #1 [ 2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016 [ 2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00 [ 2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282 [ 2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006 [ 2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0 [ 2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065 [ 2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000 [ 2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800 [ 2.980630] FS: 00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000 [ 2.980633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0 [ 2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.980645] Call Trace: [ 2.980675] i915_driver_load+0xb0e/0xdc0 [i915] [ 2.980681] ? kernfs_add_one+0xe7/0x130 [ 2.980709] i915_pci_probe+0x46/0x60 [i915] [ 2.980715] pci_device_probe+0xd4/0x150 [ 2.980719] really_probe+0x243/0x3b0 [ 2.980722] driver_probe_device+0xba/0x100 [ 2.980726] __driver_attach+0xe4/0x110 [ 2.980729] ? driver_probe_device+0x100/0x100 [ 2.980733] bus_for_each_dev+0x74/0xb0 [ 2.980736] driver_attach+0x1e/0x20 [ 2.980739] bus_add_driver+0x159/0x230 [ 2.980743] ? 0xffffffffa0393000 [ 2.980746] driver_register+0x70/0xc0 [ 2.980749] ? 0xffffffffa0393000 [ 2.980753] __pci_register_driver+0x57/0x60 [ 2.980780] i915_init+0x55/0x58 [i915] [ 2.980785] do_one_initcall+0x4a/0x1c4 [ 2.980789] ? do_init_module+0x27/0x210 [ 2.980793] ? kmem_cache_alloc_trace+0x131/0x190 [ 2.980797] do_init_module+0x60/0x210 [ 2.980800] load_module+0x2063/0x22e0 [ 2.980804] ? vfs_read+0x116/0x140 [ 2.980807] ? vfs_read+0x116/0x140 [ 2.980811] __do_sys_finit_module+0xbd/0x120 [ 2.980814] ? __do_sys_finit_module+0xbd/0x120 [ 2.980818] __x64_sys_finit_module+0x1a/0x20 [ 2.980821] do_syscall_64+0x5a/0x110 [ 2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2.980826] RIP: 0033:0x7f4754e32879 [ 2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48 [ 2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879 [ 2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018 [ 2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000 [ 2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 [ 2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000 [ 2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980884] ---[ end trace 5eb47a76277d4731 ]--- The cause of this appears to be due to the fact that if there's pre-existing display state that was set by the BIOS when i915 loads, it will attempt to perform a modeset before the driver is registered with userspace. Since this happens before the driver's registered with userspace, it's connectors are also unregistered and thus-states which would turn on DPMS on a connector end up getting rejected since the connector isn't registered. These bugs managed to get past Intel's CI partially due to the fact it never ran a full test on my patches for some reason, but also because all of the tests unload the GPU once before running. Since this bug is only really triggered when the drivers tries to perform a modeset before it's been fully registered with userspace when coming from whatever display configuration the firmware left us with, it likely would never have been picked up by CI in the first place. After some discussion with vsyrjala, we decided the best course of action would be to just move the unregistered connector checks out of update_connector_routing() and into drm_atomic_set_crtc_for_connector(). The reason for this being that legacy modesetting isn't going to be expecting failures anywhere (at least this is the case with X), so ideally we want to ensure that any DPMS changes will still work even on unregistered connectors. Instead, we now only reject new modesets which would change the current CRTC assigned to an unregistered connector unless no new CRTC is being assigned to replace the connector's previous one. Signed-off-by: Lyude Paul <lyude@redhat.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009204424.21462-1-lyude@redhat.com
2018-10-10drm/i915: Inject a failure point when registering a connectorChris Wilson
Check we can handle a late display load failure where the final act of registering the connector fails. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181010123833.16797-1-chris@chris-wilson.co.uk
2018-10-10drm/i915: move intel connector specific functions to intel_connector.cJani Nikula
Now that we have intel_connector.c, move the connector specific functions from intel_display.c there. Fix a few checkpatch complaints while at it. No functional changes. Reviewed-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/20181010075205.7713-2-jani.nikula@intel.com
2018-10-10drm/i915: rename intel_modes.c to intel_connector.cJani Nikula
The common denominator here seems to be connector more than modes. Prepare for moving more connector functions to the same place. No functional changes. Reviewed-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/20181010075205.7713-1-jani.nikula@intel.com
2018-10-10drm/i915: nuke the intel_lvds_connectorJani Nikula
For a while we carried lvds connector specific data in the lvds connector, but since commit 05c72e77ccda ("drm/i915: Nuke the LVDS lid notifier") we haven't needed it. Revert back to plain intel_connector. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-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/20181009210916.19578-1-jani.nikula@intel.com
2018-10-10drm/i915: Show the DPCD read error inlineChris Wilson
When reporting the DPCD dump through debugfs, show the errors inline where appropriate. If a read at one particular offset fails, report it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106371 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181010081706.29931-1-chris@chris-wilson.co.uk
2018-10-10Merge tag 'drm-msm-fixes-2018-10-09' of ↵Dave Airlie
git://people.freedesktop.org/~robclark/linux into drm-next Fix 32-bit arm build. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGt7s20e4aJmnOFM-uZHfYSsicy0E=ssse1D7LTXX4jnWQ@mail.gmail.com
2018-10-10Merge tag 'drm-msm-next-2018-10-07' of ↵Dave Airlie
git://people.freedesktop.org/~robclark/linux into drm-next This time mostly further refinement of dpu1+a6xx for sdm845 and beyond.. and hurray for more negative diffstat :-) - Misc cleanups and fixes - GPU preemption optimization - a6xx perf improvements and clock fixes (ie. lets actually not run at minimum clks) - a6xx devfreq/DCVS - Lots of code cleanup across dpu (Bruce, Jeykumar, Sean) - Fixed a few crashes on startup relating to dsi (Sean) - Add cursor support (Sravanthi, Sean) - Properly free mdss irq on destroy (Jordan) - Use correct encoder_type when initializing, fixes crash on boot (Stephen) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsNevCzMiLuNW1EVN6gtP3JZSir6PfnWvnCavSZM+bUFQ@mail.gmail.com
2018-10-09drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit ↵Manasi Navare
panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09drm/amdgpu: Change VI gfx/sdma/smu init sequenceRex Zhu
initialize gfx/sdma before dpm features enabled. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu: Add fw load in gfx_v8 and sdma_v3Rex Zhu
gfx and sdma can be initialized before smu. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amd/pp: Implement load_firmware interfaceRex Zhu
with this interface, gfx/sdma can be initialized before smu. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amd/pp: Allocate ucode bo in request_smu_load_fwRex Zhu
ucode bo is needed by request_smu_load_fw, the request_smu_load_fw maybe called by gfx/sdma before smu hw init. so move amdgpu_ucode_bo_init to request_smu_lowd_fw from smu hw init. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu: Don't reallocate ucode bo when suspendRex Zhu
driver don't release the ucode memory when suspend. so don't need to allocate bo when resume back. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu: Remove FW_LOAD_DIRECT type support on VIRex Zhu
AMDGPU_FW_LOAD_DIRECT is used for bring up. Now it don't work any more. so remove the support. v2: Add warning message if user select AMDGPU_FW_LOAD_DIRECT/AMDGPU_FW_LOAD_PSP on VI. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu/vcn:Correct VCN cache window definitionJames Zhu
Correct VCN cache window definition. The old one is reused from UVD, and it is not fully correct. Signed-off-by: James Zhu <James.Zhu@amd.com> Acked-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu/vcn:Replace value with defined macroJames Zhu
Replace value with defined macro to make code more readable Signed-off-by: James Zhu <James.Zhu@amd.com> Acked-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu/vcn:fix dpg pause mode hang issueJames Zhu
Use mmUVD_SCRATCH2 tracking decode write point. It will help avoid dpg pause mode hang issue. Signed-off-by: James Zhu <James.Zhu@amd.com> Acked-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu/vcn:Remove unused codeJames Zhu
The following WREG32_SOC15_DPG_MODE will overwrite register mmUVD_CGC_CTRL. This code can be removed. Signed-off-by: James Zhu <James.Zhu@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/radeon: ratelimit bo warningsNick Alcock
So a few days ago I started getting sprays of these warnings -- sorry, but because it was a few days ago I'm not sure what I was running at the time (but it was probably either Stellaris or Chromium). Sep 25 22:06:34 mutilate err: : [ 544.718905] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.718909] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate err: : [ 544.719710] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.719714] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate err: : [ 544.719862] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.719865] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate err: : [ 544.720772] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.720778] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate warning: : [ 544.721415] radeon 0000:01:00.0: vbo resource seems too big for the bo followed by a massive stream of "vbo resource seems too big for the bo". The most extreme flood ran from 23:01:58 to 23:02:47 and emitted 91,000 lines of log in that time. This... seems excessive, given that each log message after the first contains more or less no information. So ratelimit these messages. (We probably want to see at least *some* so that the underlying bug can be fixed -- always assuming the bug isn't in unfixable closed-source game code somewhere.) Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu: fix incorrect use of amdgpu_irq_add_id in si_dma.cChristian König
Adding a second irq source because of a different src_id is actually a bug. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu: fix AGP location with VRAM at 0x0Christian König
That also simplifies handling quite a bit. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu: remove the intterupt handling for the KIQ eventsShirish S
[Why] 1. we never submit IBs to the KIQ 2. there seems to be ~500ms delay during amdgpu resume spent in KIQ, hence pointing toward interrupts are not working correctly. [How] remove interrupt handling for KIQ. Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>i Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdkfd: Fix incorrect use of process->mmFelix Kuehling
This mm_struct pointer should never be dereferenced. If running in a user thread, just use current->mm. If running in a kernel worker use get_task_mm to get a safe reference to the mm_struct. Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/amdgpu: skip IB tests for KIQ in generalPratik Vishwakarma
[Why] 1. We never submit IBs to KIQ. 2. Ring test pass without KIQ's ring also. 3. By skipping we see an improvement of around 500ms in the amdgpu's resume time. [How] skip IB tests for KIQ ring type. Signed-off-by: Shirish S <shirish.s@amd.com> Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-10-09drm/scheduler: Simplify spsc_queue_count check in drm_sched_entity_select_rqNathan Chancellor
Clang generates a warning when it sees a logical not followed by a conditional operator like ==, >, or <. drivers/gpu/drm/scheduler/sched_entity.c:470:6: warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses] if (!spsc_queue_count(&entity->job_queue) == 0 || ^ ~~ drivers/gpu/drm/scheduler/sched_entity.c:470:6: note: add parentheses after the '!' to evaluate the comparison first if (!spsc_queue_count(&entity->job_queue) == 0 || ^ ( ) drivers/gpu/drm/scheduler/sched_entity.c:470:6: note: add parentheses around left hand side expression to silence this warning if (!spsc_queue_count(&entity->job_queue) == 0 || ^ ( ) 1 warning generated. It assumes the author might have made a mistake in their logic: if (!a == b) -> if (!(a == b)) Sometimes that is the case; other times, it's just a super convoluted way of saying 'if (a)' when b = 0: if (!1 == 0) -> if (0 == 0) -> if (true) Alternatively: if (!1 == 0) -> if (!!1) -> if (1) Simplify this comparison so that Clang doesn't complain. Fixes: 35e160e781a0 ("drm/scheduler: change entities rq even earlier") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-19 01:14:50 +0000