- 21 Nov, 2018 2 commits
-
-
Brajeswar Ghosh authored
Remove gca/gfx_8_0_d.h which is included more than once Reviewed-by:
Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by:
Brajeswar Ghosh <brajeswar.linux@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Philip Yang authored
Based SDMA fw version to enable has_page_queue support. Have to move sdma_v4_0_init_microcode from sw_init to early_init, to load firmware and init fw_version before set_ring/buffer/vm_pte_funcs use it. v2: don't enable on vega12, 20 until confirmed Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
- 20 Nov, 2018 8 commits
-
-
Philip Yang authored
Because increase SDMA_DOORBELL_RANGE to add new SDMA doorbell for paging queue will break SRIOV, instead we can reserve and map two doorbell pages for amdgpu, paging queues doorbell index use same index as SDMA gfx queues index but on second page. For Vega20, after we change doorbell layout to increase SDMA doorbell for 8 SDMA RLC queues later, we could use new doorbell index for paging queue. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
Philip Yang authored
This looks like copy paste typo Signed-off-by:
-
Rex Zhu authored
The static struct drm_driver *driver was not used because drm_pci_init was deprecated v2: Remove static pointer pdriver(Christian) Reviewed-by:
Rex Zhu <Rex.Zhu@amd.com> Signed-off-by:
-
Eric Huang authored
It is to improve system limit by: 1. replacing userptrlimit with a total memory limit that conunts TTM memory usage and userptr usage. 2. counting acc size for all BOs. Signed-off-by:
Eric Huang <JinHuiEric.Huang@amd.com> Reviewed-by:
-
Felix Kuehling authored
This change prepares for adding SG BOs that will be used for mapping doorbells into GPUVM address space. This type of BO would be mistaken for an invalid userptr BO. Improve that check to test that it's actually a userptr BO so that SG BOs that are still in the CPU domain can be validated and mapped correctly. Signed-off-by:
-
Felix Kuehling authored
The adev parameter in amdgpu_sync_fence and amdgpu_sync_resv is only needed for updating sync->last_vm_update. This breaks if different adevs are passed to calls for the same sync object. Always pass NULL for calls from KFD because sync objects used for KFD don't belong to any particular device, and KFD doesn't need the sync->last_vm_update fence. This fixes kernel log warnings on multi-GPU systems after recent changes in amdgpu_amdkfd_gpuvm_restore_process_bos. Signed-off-by:
-
Harish Kasiviswanathan authored
Instead of waiting for each KFD BO after validation just wait for the last BO moving fence. Signed-off-by:
Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by:
-
Harish Kasiviswanathan authored
PD or PT might have to be moved during validation and this move has to be completed before updating it. If page table updates are done using SDMA then this serializing is done by SDMA command submission. And if PD/PT updates are done by CPU, then explicit waiting for PD/PT updates are done in amdgpu VM amdgpu_vm_wait_pd function. Sync to PD BO moving fence to handle corner case where none of the PTs are updated but PD is evicted. Signed-off-by:
-
- 19 Nov, 2018 30 commits
-
-
Brajeswar Ghosh authored
Remove gca/gfx_8_0_enum.h which is included more than once Signed-off-by:
-
Alex Deucher authored
Use the define rather than hardcoded value. Acked-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Trigger Huang authored
A bad job is the one triggered TDR(In the current amdgpu's implementation, actually all the jobs in the current joq-queue will be treated as bad jobs). In the recovery process, its fence will be fake signaled and as a result, the work behind will be scheduled to delete it from the mirror list, but if the TDR process is invoked before the work's execution, then this bad job might be processed again and the call dma_fence_set_error to its fence in TDR process will lead to kernel warning trace: [ 143.033605] WARNING: CPU: 2 PID: 53 at ./include/linux/dma-fence.h:437 amddrm_sched_job_recovery+0x1af/0x1c0 [amd_sched] kernel: [ 143.033606] Modules linked in: amdgpu(OE) amdchash(OE) amdttm(OE) amd_sched(OE) amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 snd_hda_codec_generic crypto_simd glue_helper cryptd snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq joydev snd_seq_device snd_timer snd soundcore binfmt_misc input_leds mac_hid serio_raw nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 8139too floppy psmouse 8139cp mii i2c_piix4 pata_acpi [ 143.033649] CPU: 2 PID: 53 Comm: kworker/2:1 Tainted: G OE 4.15.0-20-generic #21-Ubuntu [ 143.033650] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 [ 143.033653] Workqueue: events drm_sched_job_timedout [amd_sched] [ 143.033656] RIP: 0010:amddrm_sched_job_recovery+0x1af/0x1c0 [amd_sched] [ 143.033657] RSP: 0018:ffffa9f880fe7d48 EFLAGS: 00010202 [ 143.033659] RAX: 0000000000000007 RBX: ffff9b98f2b24c00 RCX: ffff9b98efef4f08 [ 143.033660] RDX: ffff9b98f2b27400 RSI: ffff9b98f2b24c50 RDI: ffff9b98efef4f18 [ 143.033660] RBP: ffffa9f880fe7d98 R08: 0000000000000001 R09: 00000000000002b6 [ 143.033661] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9b98efef3430 [ 143.033662] R13: ffff9b98efef4d80 R14: ffff9b98efef4e98 R15: ffff9b98eaf91c00 [ 143.033663] FS: 0000000000000000(0000) GS:ffff9b98ffd00000(0000) knlGS:0000000000000000 [ 143.033664] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 143.033665] CR2: 00007fc49c96d470 CR3: 000000001400a005 CR4: 00000000003606e0 [ 143.033669] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 143.033669] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 143.033670] Call Trace: [ 143.033744] amdgpu_device_gpu_recover+0x144/0x820 [amdgpu] [ 143.033788] amdgpu_job_timedout+0x9b/0xa0 [amdgpu] [ 143.033791] drm_sched_job_timedout+0xcc/0x150 [amd_sched] [ 143.033795] process_one_work+0x1de/0x410 [ 143.033797] worker_thread+0x32/0x410 [ 143.033799] kthread+0x121/0x140 [ 143.033801] ? process_one_work+0x410/0x410 [ 143.033803] ? kthread_create_worker_on_cpu+0x70/0x70 [ 143.033806] ret_from_fork+0x35/0x40 So just delete the bad job from mirror list directly Changes in v3: - Add a helper function to delete the bad jobs from mirror list and call it directly *before* the job's fence is signaled Changes in v2: - delete the useless list node check - also delete bad jobs in drm_sched_main because: kthread_unpark(ring->sched.thread) will be invoked very early before amdgpu_device_gpu_recover's return, then drm_sched_main will have chance to pick up a new job from the job queue. This new job will be added into the mirror list and processed by amdgpu_job_run, but may not be deleted from the mirror list on time due to the same reason. And finally re-processed by drm_sched_job_recovery Signed-off-by:
Trigger Huang <Trigger.Huang@amd.com> Reviewed-by:
Christian König <chrstian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
Looks like a copy paste typo. Reviewed-by:
-
Yong Zhao authored
This is a known gfx9 HW issue, and this change can perfectly workaround the issue. Signed-off-by:
Yong Zhao <Yong.Zhao@amd.com> Reviewed-by:
-
Yong Zhao authored
This makes debug message get printed even when there is early return. Signed-off-by:
-
Gang Ba authored
Add Vega12 and Polaris12 device info and device IDs to KFD. Signed-off-by:
Gang Ba <gaba@amd.com> Reviewed-by:
-
Yong Zhao authored
This will make reading code much easier. This fixes a few spots missed in a previous commit with the same title. Signed-off-by:
-
Chengming Gui authored
With GFXOFF enabled, this patch will cause PCO amdgpu_test failed, but GFXOFF is necessary for PCO, so revert the patch. This reverts commit b83761bb. v2: add a comment for future reference (Alex) Reviewed-by:
Jack Gui <Jack.Gui@amd.com> Signed-off-by:
-
Joerg Roedel authored
Running kfdtest on an AMD Carizzo flooded the kernel log with thousands of these "was not implemented" messages, making it impossible to see other messages there. Ratelimit the messages to prevent user-space from flooding the kernel log. Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
David Francis authored
[Why] There was a full clock request struct of which only one value was being used. [How] Replace the struct with a uint32_t Signed-off-by:
David Francis <David.Francis@amd.com> Reviewed-by:
Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Reviewed-by:
Sun peng Li <Sunpeng.Li@amd.com> Acked-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Many panels support more than 8bpc but some modes are unavailable while running at greater than 8bpc due to DP/HDMI bandwidth constraints. Support for more than 8bpc was added recently in the driver but it defaults to the maximum supported bpc - locking out these modes. This should be a user configurable option such that the user can select what bpc configuration they would like. [How] This patch adds support for getting and setting the amdgpu driver specific "max bpc" property on the connector. It also adds support for limiting the output bpc based on the property value. The default limitation is the lowest value in the range, 8bpc. This was the old value before the range was uncapped. This patch should be updated/replaced later once common drm support for max bpc lands. Bugzilla: https://bugs.freedesktop.org/108542 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201585 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200645 Fixes: e03fd3f3 ("drm/amd/display: Do not limit color depth to 8bpc") v2: rebase on upstream (Alex) Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Nicholas Kazlauskas authored
[Why] Many panels support more than 8bpc but some modes are unavailable while running at greater than 8bpc due to DP/HDMI bandwidth constraints. Support for more than 8bpc was added recently in the driver but it defaults to the maximum supported bpc - locking out these modes. This should be a user configurable option such that the user can select what bpc configuration they would like. [How] This patch introduces the "max bpc" amdgpu driver specific connector property so the user can limit the maximum bpc. It ranges from 8 to 16. This doesn't directly set the preferred bpc for the panel since it follows Intel's existing driver conventions. This proprety should be removed once common drm support for max bpc lands. v2: rebase on upstream (Alex) Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/amd/amdgpu/psp_v10_0.c: In function 'psp_v10_0_ring_stop': drivers/gpu/drm/amd/amdgpu/psp_v10_0.c:230:19: warning: variable 'ring' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/psp_v3_1.c: In function 'psp_v3_1_ring_stop': drivers/gpu/drm/amd/amdgpu/psp_v3_1.c:359:19: warning: variable ‘ring’ set but not used [-Wunused-but-set-variable] It not used since commit 4ef72453 ("drm/amdgpu: added api for stopping psp ring (v2)") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
Emily Deng authored
Aligned the amd_sriov_msg_pf2vf_info_header and amd_sriov_msg_pf2vf_info_header's definition with libgv. Signed-off-by:
Emily Deng <Emily.Deng@amd.com> Reviewed-by:
Frank.Min <Frank.Min@amd.com> Signed-off-by:
-
David Francis authored
[Why] dc_link_set_backlight_level can be called from a context where the stream is unknown. In this case, we can still find which controller is driving this particular backlight [How] Compare links for equality instead of streams Signed-off-by:
-
Charlene Liu authored
expose dcn10_get_surface_visual_confirm_color() to be used in the future Signed-off-by:
Charlene Liu <charlene.liu@amd.com> Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
Dmytro Laktyushkin authored
A number of registers need to be updated for all active pipes wherever any pipe causes a change in watermarks. This change separates programming of these registers into a separate function call that is called for all active pipes during a bw update. Signed-off-by:
Tony Cheng <Tony.Cheng@amd.com> Acked-by:
-
Joshua Aberback authored
[Why] We observed an issue where a display would not accept programming of the ignore_MSA_timing_param bit if the stream was blanked. [How] move enable_stream_features from enable_link_dp to core_link_enable_stream, after unblank_stream Signed-off-by:
Joshua Aberback <joshua.aberback@amd.com> Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
Anthony Koo <Anthony.Koo@amd.com> Acked-by:
-
Eric Bernstein authored
[Why] For some complicated blending transition cases, the head pipe of the second stream may end up being a higher pipe index than the free pipe. In those cases dc_add_plane_to_context will incorrectly set the tail_pipe to the free pipe, which will cause the top_pipe and bottom_pipe to be the same [How] Move the call to resource_get_tail_pipe_for_stream() to be before call to acquire_free_pipe_for_stream(). Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Reviewed-by:
-
Xiaodong Yan authored
DPCD Extended Receiver Capability Field [Why] 1.dpcd extended receiver capability sometimes read fail, and corrupted data leads to sink caps is not correct. 2.sometimes sink reply ack with fewer data [How] check the return value of core_link_read_dpcd, try to read again when failure happens Signed-off-by:
Xiaodong Yan <Xiaodong.Yan@amd.com> Reviewed-by:
Wenjing Liu <Wenjing.Liu@amd.com> Acked-by:
-
Steven Chiu authored
Signed-off-by:
Steven Chiu <steven.chiu@amd.com> Reviewed-by:
-
Dmytro Laktyushkin authored
Change the math to work in viewport rotation when calculating viewport and viewport adjustment. This simplifies the math for viewport calculation and makes viewport adjustment easier to understand. Signed-off-by:
-
Jun Lei authored
[why] Underflow is asserted due to some timing condition which does not actually result in visible underflow (i.e. it occurs while blanked). [how] Force clear underflow occured bit whenver we unblank. Signed-off-by:
Aric Cyr <Aric.Cyr@amd.com> Acked-by:
-
Nikola Cornij authored
[why] The condition to check for two pixels per containter has become rather long and is used in number of places. [how] Move the check to a helper function. Signed-off-by:
Nikola Cornij <nikola.cornij@amd.com> Reviewed-by:
-
Yogesh Mohan Marimuthu authored
[why] phy_pix_clk is one of the variable used to check if one PLL can be shared with displays having common mode set configuration. As of now phy_pix_clock varialbe is calculated in function dc_validate_stream(). dc_validate_stream() function is called after clocks are assigned for the new display. Due to this during hotplug, when PLL sharing conditions are checked for new display phy_pix_clk variable will be 0 and for displays that are already enabled phy_pix_clk will have some value. Hence PLL will not be shared and if the display hardware doesn't have any more PLL to assign, mode set will fail due to resource unavailability. [how] Instead of only calculating the phy_pix_clk variable after the PLL is assigned for new display, this patch calculates phy_pix_clk also during the before assigning the PLL for new display. Signed-off-by:
Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com> Reviewed-by:
-
Yongqiang Sun authored
[Why] Typo for return check value. [How] Correct one should be "return enable ? true : false;" Signed-off-by:
Yongqiang Sun <yongqiang.sun@amd.com> Reviewed-by:
-
David Francis authored
[Why] Unused variable "refresh" and incorrect comment formatting [How] Remove variable, reindent comments Signed-off-by:
-
David Francis authored
[Why] DMCU firmware is not required - the system is expected to run fine without it. Therefore, wherever dmcu functions could be called, dmcu initialization shoudl be checked [How] Use the helpful hook dmcu_funcs->is_dmcu_initialized Signed-off-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
-
Murton Liu authored
[why] Gamma was always being set as identity on SDR monitor, leading to no changes in gamma. This caused nightlight to not apply correctly. [how] Added a default gamma structure to compare against in the sdr case. Signed-off-by:
Murton Liu <murton.liu@amd.com> Reviewed-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Acked-by:
-
