[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #34 from MasterCATZ (masterc...@hotmail.com) ---
success
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
hwmgr->fan_ctrl_is_in_default_mode = false;
it will now boot up in manual mode
finally I have fan control "AMD_DPM_FORCED_LEVEL_AUTO"
I am wondering just how "FORCED" that "AUTO" is meant to be
how ever once you put it back to "2" "AUTO" it takes control again ... and will
overwrite your "0" card control and "1" manual
echo 2 > /sys/class/drm/card1/device/hwmon/hwmon1/pwm1_enable
don't do it unless you want to reboot with a hot GPU :P
also the crit temp for "Sea Island" cards like my R9 290 is defiantly being
retrieved from
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
thermal_temp_setting.temperature_shutdown
if (hwmgr->chip_id == CHIP_HAWAII) {
data->thermal_temp_setting.temperature_low = 74500;
data->thermal_temp_setting.temperature_high = 8;
data->thermal_temp_setting.temperature_shutdown = 98000;
and the fans still spin slow regardless how low I set it .. sooo .. somethings
broken ... so looks like I will be doing a custom kernel on every update for a
while now to disable AUTO fan control
and for some reason AMD devs feel 120 deg is NORMAL for a GPU and users want
quite fans ... I give up ...
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout causes system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 --- Comment #10 from saadnaj...@gmail.com --- Comment on attachment 145981 --> https://bugs.freedesktop.org/attachment.cgi?id=145981 additional-journalctl-logs-during-game-play >Nov 17 01:02:31 archlinux audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 >ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' >Nov 17 01:02:31 archlinux kernel: audit: type=1131 audit(1573970551.160:173): >pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed >comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? >res=success' >Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: GPU fault detected: 146 >0x066e480c >Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: >VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00100DB3 >Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: >VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E04800C >Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: VM fault (0x0c, vmid 7) >at page 1052083, read from '' (0x) (72) >Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: GPU fault detected: 146 >0x06ae880c >Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: >VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x >Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: >VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F008010 >Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: VM fault (0x10, vmid 7) >at page 0, write from '' (0x) (8) >Nov 17 01:02:45 archlinux kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* >ring gfx timeout, signaled seq=23, emitted seq=24 >Nov 17 01:02:45 archlinux kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* >Process information: process hl2_linux pid 2252 thread hl2_linux:cs0 pid 2254 >Nov 17 01:02:45 archlinux kernel: amdgpu :01:00.0: GPU reset begin! >Nov 17 01:02:45 archlinux kernel: amdgpu :01:00.0: GPU reset succeeded, >trying to resume >Nov 17 01:02:45 archlinux kernel: [drm] PCIE gen 3 link speeds already enabled >Nov 17 01:02:45 archlinux kernel: amdgpu :01:00.0: PCIE GART of 1024M >enabled (table at 0x00F4). >Nov 17 01:02:46 archlinux kernel: amdgpu :01:00.0: >[drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring gfx test failed (-110) >Nov 17 01:02:46 archlinux kernel: [drm:amdgpu_device_ip_resume_phase2 >[amdgpu]] *ERROR* resume of IP block failed -110 >Nov 17 01:02:46 archlinux kernel: [drm:si_dpm_set_power_state [amdgpu]] >*ERROR* si_restrict_performance_levels_before_switch failed >Nov 17 01:02:46 archlinux kernel: amdgpu :01:00.0: GPU reset(1) failed >Nov 17 01:02:46 archlinux kernel: amdgpu :01:00.0: GPU reset end with ret >= -110 >Nov 17 01:02:49 archlinux kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* >ring gfx timeout, signaled seq=24, emitted seq=24 >Nov 17 01:02:49 archlinux kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* >Process information: process hl2_linux pid 2252 thread hl2_linux:cs0 pid 2254 >Nov 17 01:02:49 archlinux kernel: amdgpu :01:00.0: GPU reset begin! >Nov 17 01:03:49 archlinux kernel: [drm] schedsdma0 is not ready, skipping >Nov 17 01:03:49 archlinux kernel: [drm] schedsdma1 is not ready, skipping >Nov 17 01:03:49 archlinux kernel: amdgpu :01:00.0: failed to clear page >tables on GEM object close (-2) >Nov 17 01:03:49 archlinux kernel: BUG: kernel NULL pointer dereference, >address: 0008 >Nov 17 01:03:49 archlinux kernel: #PF: supervisor read access in kernel mode >Nov 17 01:03:49 archlinux kernel: #PF: error_code(0x) - not-present page >Nov 17 01:03:49 archlinux kernel: PGD 0 P4D 0 >Nov 17 01:03:49 archlinux kernel: Oops: [#1] SMP PTI >Nov 17 01:03:49 archlinux kernel: CPU: 1 PID: 2262 Comm: hl2_linu:shlo0 Not >tainted 5.3.11-2-clear #1 >Nov 17 01:03:49 archlinux kernel: Hardware name: CLEVO >P150EM/P150EM, BIOS 1.02.17PM v2 07/01/2013 >Nov 17 01:03:49 archlinux kernel: RIP: 0010:amdgpu_vm_sdma_commit+0x34/0x100 >[amdgpu] >Nov 17 01:03:49 archlinux kernel: Code: 49 89 f5 41 54 53 48 89 fb 48 83 ec 10 >48 8b 47 08 48 8b 57 18 4c 8b b0 80 00 00 00 4c 8b a2 88 01 00 00 48 8b 80 c8 >00 00 00 <4c> 8b 78 08 41 8b 44 24 08 4d 8d 47 88 85 c0 0f 84 49 ae 1e 00 49 >Nov 17 01:03:49 archlinux kernel: RSP: 0018:b9290250b9a0 EFLAGS: 00010286 >Nov 17 01:03:49 archlinux kernel: RAX: RBX: b9290250b9e8 >RCX: 00100400 >Nov 17 01:03:49 archlinux kernel: RDX: 9d2c19ba1c00 RSI: b9290250ba60 >RDI: b9290250b9e8 >Nov 17 01:03:49 archlinux kernel: RBP: b9290250b9d8 R08: 1000 >R09: 0020 >Nov 17 01:03:49 archlinux kernel: R10: b929004c5600 R11: 0012 >R12: 9d2c19ba1df8 >Nov 17 01:03:49 archlinux kernel: R13: b9290250ba60 R14: 9d2b3a472000 >R15: 9d2bbc2f12a0 >Nov 17 01:03:49 archlinux kernel: FS: () >GS:9d2c1f04(
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout causes system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 --- Comment #9 from saadnaj...@gmail.com --- Comment on attachment 145980 --> https://bugs.freedesktop.org/attachment.cgi?id=145980 journalctl-logs-after-hardware-reboot >-- Logs begin at Sun 2019-06-30 23:10:01 EDT, end at Sat 2019-11-16 23:43:27 >EST. -- >Nov 16 23:41:09 archlinux kscreen_backend_launcher[1450]: kscreen.xrandr: >Actions to perform: > Primary > Output: false >Nov 16 23:41:09 archlinux kscreen_backend_launcher[1450]: kscreen.xrandr: > Change Screen Size: false >Nov 16 23:41:09 archlinux kscreen_backend_launcher[1450]: kscreen.xrandr: > Disable outputs: false >Nov 16 23:41:09 archlinux kscreen_backend_launcher[1450]: kscreen.xrandr: > Change outputs: false >Nov 16 23:41:09 archlinux kscreen_backend_launcher[1450]: kscreen.xrandr: > Enable outputs: false >Nov 16 23:41:09 archlinux kscreen_backend_launcher[1450]: kscreen.xrandr: >XRandR::setConfig done! >Nov 16 23:41:39 archlinux kernel: lxqt-powermanag: Corrupted page table at >address 7fd643ec8080 >Nov 16 23:41:39 archlinux kernel: PGD 8003921e4067 P4D 8003921e4067 >PUD 392157067 PMD 392168067 PTE >Nov 16 23:41:39 archlinux kernel: Bad pagetable: 000d [#1] SMP PTI >Nov 16 23:41:39 archlinux kernel: CPU: 2 PID: 1623 Comm: lxqt-powermanag Not >tainted 5.3.11-2-clear #1 >Nov 16 23:41:39 archlinux kernel: Hardware name: CLEVO >P150EM/P150EM, BIOS 1.02.17PM v2 07/01/2013 >Nov 16 23:41:39 archlinux kernel: RIP: 0033:0x7fd64d347128 >Nov 16 23:41:39 archlinux kernel: Code: 8b 47 08 8d 78 01 41 89 7f 08 89 f7 29 >cf 85 ff 7e 48 31 db 66 0f 1f 44 00 00 48 63 c1 48 01 d8 48 8b 7c c2 10 48 85 >ff 74 1d <48> 8b 07 4c 89 e9 4c 89 e2 48 89 ee ff 50 10 84 c0 75 4d 49 8b 56 >Nov 16 23:41:39 archlinux kernel: RSP: 002b:7fffc622cfa0 EFLAGS: 00010202 >Nov 16 23:41:39 archlinux kernel: RAX: RBX: >RCX: >Nov 16 23:41:39 archlinux kernel: RDX: 556223eec720 RSI: 0001 >RDI: 7fd643ec8080 >Nov 16 23:41:39 archlinux kernel: RBP: 556223e115e0 R08: 7fd64994b6d0 >R09: 7fd64994b6d0 >Nov 16 23:41:39 archlinux kernel: R10: 556223f42090 R11: >R12: 7fd644005cc0 >Nov 16 23:41:39 archlinux kernel: R13: 7fffc622cfe8 R14: 556223e56cd0 >R15: 556223dff780 >Nov 16 23:41:39 archlinux kernel: FS: 7fd64994ad80 GS: >Nov 16 23:41:39 archlinux kernel: Modules linked in: veth xt_nat xt_conntrack >xt_MASQUERADE nf_conntrack_netlink xt_addrtype iptable_filter iptable_nat >nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter overlay ath9k >ath9k_common ath9k_hw mac80211 uvcvideo ath mei_hdcp videobuf2_vmalloc >videobuf2_memops snd_hda_codec_hdmi videobuf2_v4l2 wmi_bmof videobuf2_common >videodev snd_hda_codec_realtek mc snd_hda_codec_generic ledtrig_audio cfg80211 >snd_hda_intel joydev snd_hda_codec snd_hda_core psmouse r8169 snd_hwdep >rtsx_pci_ms i2c_i801 mei_me snd_pcm realtek memstick mei libphy rfkill lpc_ich >snd_timer snd wmi thermal soundcore battery ac ip_tables atkbd libps2 >serio_raw i8042 hid_logitech_hidpp amdgpu amd_iommu_v2 hid_logitech_dj >gpu_sched >Nov 16 23:41:39 archlinux kernel: ---[ end trace 0bfef23d2a61f6da ]--- >Nov 16 23:41:39 archlinux kernel: RIP: 0033:0x7fd64d347128 >Nov 16 23:41:39 archlinux kernel: Code: 8b 47 08 8d 78 01 41 89 7f 08 89 f7 29 >cf 85 ff 7e 48 31 db 66 0f 1f 44 00 00 48 63 c1 48 01 d8 48 8b 7c c2 10 48 85 >ff 74 1d <48> 8b 07 4c 89 e9 4c 89 e2 48 89 ee ff 50 10 84 c0 75 4d 49 8b 56 >Nov 16 23:41:39 archlinux kernel: RSP: 002b:7fffc622cfa0 EFLAGS: 00010202 >Nov 16 23:41:39 archlinux kernel: RAX: RBX: >RCX: >Nov 16 23:41:39 archlinux kernel: RDX: 556223eec720 RSI: 0001 >RDI: 7fd643ec8080 >Nov 16 23:41:39 archlinux kernel: RBP: 556223e115e0 R08: 7fd64994b6d0 >R09: 7fd64994b6d0 >Nov 16 23:41:39 archlinux kernel: R10: 556223f42090 R11: >R12: 7fd644005cc0 >Nov 16 23:41:39 archlinux kernel: R13: 7fffc622cfe8 R14: 556223e56cd0 >R15: 556223dff780 >Nov 16 23:41:39 archlinux kernel: FS: 7fd64994ad80() >GS:9d5f9f08() knlGS: >Nov 16 23:41:39 archlinux kernel: CS: 0033 DS: ES: CR0: >80050033 >Nov 16 23:41:39 archlinux kernel: CR2: 7fd643ec8080 CR3: 00039221c004 >CR4: 001606e0 >Nov 16 23:41:39 archlinux kernel: Chrome_ChildIOT: Corrupted page table at >address 1689e6ba5e10 >Nov 16 23:41:39 archlinux kernel: PGD 800418dca067 P4D 800418dca067 >PUD 40c0c9067 PMD 419432067 PTE >Nov 16 23:41:39 archlinux kernel: Bad pagetable: 000f [#2] SMP PTI >Nov 16 23:41:39 archlinux kernel: CPU: 3 PID: 1843 Comm: Chrome_ChildIOT >Tainted: G D 5.3.11-2-clear
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout causes system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 --- Comment #8 from saadnaj...@gmail.com --- Comment on attachment 145976 --> https://bugs.freedesktop.org/attachment.cgi?id=145976 dmesg >[ 14.586198] wlp4s0: associated >[ 14.601321] IPv6: ADDRCONF(NETDEV_CHANGE): wlp4s0: link becomes ready >[ 17.005228] audit: type=1131 audit(1573694773.878:186): pid=1 uid=0 >auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher >comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? >res=success' >[ 21.287598] audit: type=1131 audit(1573694778.161:187): pid=1 uid=0 >auid=4294967295 ses=4294967295 msg='unit=user@620 comm="systemd" >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' >[ 21.295899] audit: type=1131 audit(1573694778.169:188): pid=1 uid=0 >auid=4294967295 ses=4294967295 msg='unit=user-runtime-dir@620 comm="systemd" >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' >[ 36.722300] audit: type=1131 audit(1573694789.782:189): pid=1 uid=0 >auid=4294967295 ses=4294967295 msg='unit=systemd-hostnamed comm="systemd" >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' >[ 388.740535] sysrq: Emergency Sync >[ 388.746854] Emergency Sync complete >[ 435.364668] [drm:intel_check_cpu_fifo_underruns] *ERROR* fifo underrun on >pipe B >[ 435.364674] [drm:intel_check_pch_fifo_underruns] *ERROR* pch fifo underrun >on pch transcoder B >[ 736.150037] logitech-hidpp-device 0003:046D:4041.0007: multiplier = 8 >[ 746.084734] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, >signaled seq=36264, emitted seq=36266 >[ 746.084796] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, >signaled seq=328, emitted seq=329 >[ 746.084854] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: >process hl2_linux pid 2921 thread hl2_linux:cs0 pid 2924 >[ 746.084856] [drm] GPU recovery disabled. >[ 746.084913] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: >process hl2_linux pid 2921 thread hl2_linux:cs0 pid 2924 >[ 746.084914] [drm] GPU recovery disabled. >[ 747.108578] Asynchronous wait on fence drm_sched:gfx:8ccf timed out >(hint:submit_notify+0x0/0xa4) >[ 747.108590] Asynchronous wait on fence i915:compton[1533]:bdd5 timed out >(hint:intel_atomic_commit_ready+0x0/0x58) >[ 747.108611] Asynchronous wait on fence i915:compton[1533]:bdd5 timed out >(hint:intel_atomic_commit_ready+0x0/0x58) >[ 890.857127] logitech-hidpp-device 0003:046D:4041.0007: multiplier = 8 >[ 922.726439] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, >signaled seq=36264, emitted seq=36266 >[ 922.726493] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: >process pid 0 thread pid 0 >[ 922.726495] [drm] GPU recovery disabled. >[ 922.749522] audit: type=1130 audit(1573695675.801:190): pid=1 uid=0 >auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' >[ 922.749525] audit: type=1131 audit(1573695675.801:191): pid=1 uid=0 >auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" >exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' >[ 1364.073259] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, >signaled seq=37448, emitted seq=37450 >[ 1364.073323] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, >signaled seq=328, emitted seq=330 >[ 1364.073384] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: >process pid 0 thread pid 0 >[ 1364.073385] [drm] GPU recovery disabled. >[ 1364.073443] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: >process pid 0 thread pid 0 >[ 1364.073444] [drm] GPU recovery disabled. >[ 1484.394300] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, >signaled seq=328, emitted seq=330 >[ 1484.394353] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: >process pid 0 thread pid 0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout causes system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 --- Comment #7 from saadnaj...@gmail.com --- Created attachment 145981 --> https://bugs.freedesktop.org/attachment.cgi?id=145981&action=edit additional-journalctl-logs-during-game-play I have enabled GPU reset with the following options mdgpu.gpu_recovery=1 amdgpu.lockup_timeout=3000. Then I have launch Counter Strike Source in attempts to capture logs as much as I can before system freeze. I have added the new logs, additional-journalctl-logs-during-game-play. Here is the snippet when error begins from logs Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: GPU fault detected: 146 0x066e480c Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00100DB3 Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E04800C Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: VM fault (0x0c, vmid 7) at page 1052083, read from '' (0x) (72) Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: GPU fault detected: 146 0x06ae880c Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F008010 Nov 17 01:02:36 archlinux kernel: amdgpu :01:00.0: VM fault (0x10, vmid 7) at page 0, write from '' (0x) (8) ... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105819] Window system hang due to GPU Fault
https://bugs.freedesktop.org/show_bug.cgi?id=105819 saadnaj...@gmail.com changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=112304 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout causes system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 saadnaj...@gmail.com changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=105819 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout causes system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 --- Comment #6 from saadnaj...@gmail.com --- Created attachment 145980 --> https://bugs.freedesktop.org/attachment.cgi?id=145980&action=edit journalctl-logs-after-hardware-reboot I believe this important clue. Here is the journalctl logs right after hardware powering off when my system froze during gameplay. You can see the logs there repetitive. There a lot of page tables and includes GPU failure e.g chrome_ChildIOT: Corrupted page table at address 1689e6ba5e10 drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 Nov 16 23:41:49 archlinux kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=112, emitted seq=11 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout causes system freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 saadnaj...@gmail.com changed: What|Removed |Added Summary|[drm:amdgpu_job_timedout|[drm:amdgpu_job_timedout |[amdgpu]] *ERROR* ring gfx |[amdgpu]] *ERROR* ring gfx |timeout Causes System |timeout causes system |Freeze |freeze --- Comment #5 from saadnaj...@gmail.com --- Forgot to add I am running 5.3.10-1-clear -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout Causes System Freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 --- Comment #4 from saadnaj...@gmail.com --- Created attachment 145979 --> https://bugs.freedesktop.org/attachment.cgi?id=145979&action=edit GLX_INFO_AMD_7970M -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout Causes System Freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 --- Comment #3 from saadnaj...@gmail.com --- Created attachment 145978 --> https://bugs.freedesktop.org/attachment.cgi?id=145978&action=edit xorg.conf -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout Causes System Freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 --- Comment #2 from saadnaj...@gmail.com --- Created attachment 145977 --> https://bugs.freedesktop.org/attachment.cgi?id=145977&action=edit journalctl I caught the output of journal when the freeze occured -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout Causes System Freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 --- Comment #1 from saadnaj...@gmail.com --- Created attachment 145976 --> https://bugs.freedesktop.org/attachment.cgi?id=145976&action=edit dmesg Dmesg output I caught when other monitor -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112304] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout Causes System Freeze
https://bugs.freedesktop.org/show_bug.cgi?id=112304 Bug ID: 112304 Summary: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout Causes System Freeze Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: saadnaj...@gmail.com Created attachment 145975 --> https://bugs.freedesktop.org/attachment.cgi?id=145975&action=edit Xorg.log Description: System go to freeze completely whenever during game play e.g Counter Strike global offensive ( Max setting). The hardware power reset is required. usually the system will freeze after 15~20 minutes of play. I noticed the frequency of my system freezing when playing games increases after my laptop goes to suspend mode and play after waking up. Also I noticed that the fan will keep spinning even after hardware power off cycling until I have unplug the laptop and remove the battery. Here my laptop configuration when running games: 1. DRI_PRIME =1 is set to all steam games 2. echo high > /sys/class/drm/card1/device/power_dpm_force_performance_level 3. echo performance > /sys/class/drm/card1/device/power_dpm_state 4. Performance governor is set Steps to reproduce -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112303] [LENOVO E595] Black screen on resume!
https://bugs.freedesktop.org/show_bug.cgi?id=112303 Bug ID: 112303 Summary: [LENOVO E595] Black screen on resume! Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: dracaphal...@gmail.com Suspending the laptop is not the issue I am experiencing but waking the laptop after suspension is what breaks. The laptop wakes up to a black screen without a functioning system, not even CTRL+ALT+BACKSPACE works. The issue is similar to https://bbs.archlinux.org/viewtopic.php?id=249510 and therefore I have tried all the solutions mentioned in that thread (before knowing of its existence). I also tried the Early KMS solution suggested by the owner of that thread, which I did not think of and the result remained the same. Solutions mentioned in https://wiki.archlinux.org/index.php/Laptop/Lenovo#E_series has also been tried but the problem remains unsolved. Something worth mentioning is that the laptop has to go through suspension and waking up twice for the system to return to normal, but this solution works 20% of the times and has unfortunately caused me loss of important data. Logs: 1. https://git.io/Jer5J (lshw -short) 2. https://git.io/Jer7H (Journalctl --since="1 hour ago", note that this journalctl includes several boots because I was trying to include the functional two suspends for the system to work again) 3. https://git.io/Jer7S (dmesg) 4. https://git.io/Jer79 (Xorg.0.log) >From the above log files, V1del (https://bbs.archlinux.org/viewtopic.php?pid=1873276#p1873276), was able to identify crashes in my AMDGPU driver thus leading me to create this bug hoping for a fix! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: ignore NULL clocks
Quoting Rob Clark (2019-11-14 10:51:50) > From: Rob Clark > > This isn't an error. Also the clk APIs handle the NULL case, so we can > just delete the check. > > Signed-off-by: Rob Clark > Tested-by: Matthias Kaehlcke > --- Acked-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #33 from MasterCATZ (masterc...@hotmail.com) --- another plan drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c hwmgr->dpm_level = AMD_DPM_FORCED_LEVEL_AUTO; hwmgr_init_default_caps(hwmgr); hwmgr_init_default_caps(hwmgr); hwmgr_set_user_specify_caps(hwmgr); hwmgr_set_user_specify_caps(hwmgr); hwmgr->fan_ctrl_is_in_default_mode = true; change to false to disable auto .. not like its going to be any worse for us then GPU's thermal system will run and you can actually manually run the fans but unsure if this will stop auto core speed power save features as well -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #32 from MasterCATZ (masterc...@hotmail.com) --- apparently I was looking through kernel 4.7 code on my pc and not master linux/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c looks like the new file name as they relocated ci_dpm.c to /home/aio/Programs/linux/drivers/gpu/drm/radeon/ci_dpm.c -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 15/17] drm/amd/display: MST DSC compute fair share
From: David Francis
If there is limited link bandwidth on a MST network,
it must be divided fairly between the streams on that network
Implement an algorithm to determine the correct DSC config
for each stream
The algorithm:
This
[ ] ( )
represents the range of bandwidths possible for a given stream.
The [] area represents the range of DSC configs, and the ()
represents no DSC. The bandwidth used increases from left to right.
First, try disabling DSC on all streams
[ ] (|)
[ ](|)
Check this against the bandwidth limits of the link and each branch
(including each endpoint). If it passes, the job is done
Second, try maximum DSC compression on all streams
that support DSC
[| ]( )
[|] ( )
If this does not pass, then enabling this combination of streams
is impossible
Otherwise, divide the remaining bandwidth evenly amongst the streams
[| ] ( )
[| ]( )
If one or more of the streams reach minimum compression, evenly
divide the reamining bandwidth amongst the remaining streams
[|] ( )
[ |] ( )
[ | ] ( )
[ | ] ( )
If all streams can reach minimum compression, disable compression
greedily
[ |] ( )
[|]( )
[ ](|)
Perform this algorithm on each full update, on each MST link
with at least one DSC stream on it
After the configs are computed, call
dcn20_add_dsc_to_stream_resource on each stream with DSC enabled.
It is only after all streams are created that we can know which
of them will need DSC.
Do all of this at the end of amdgpu atomic check. If it fails,
fail check; This combination of timings cannot be supported.
v2: Use drm_dp_mst_atomic_check to validate bw for certain dsc
configurations
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 362 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.h | 3 +
.../drm/amd/display/dc/dcn20/dcn20_resource.c | 7 +-
.../drm/amd/display/dc/dcn20/dcn20_resource.h | 1 +
5 files changed, 372 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3657a26ce1d1..7d8e244e5210 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8090,6 +8090,9 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
+ if (!compute_mst_dsc_configs_for_state(state,
dm_state->context))
+ goto fail;
+
if (dc_validate_global_state(dc, dm_state->context, false) !=
DC_OK) {
ret = -EINVAL;
goto fail;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index e8a0ef883434..70ed7f3d9814 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -40,6 +40,10 @@
#if defined(CONFIG_DEBUG_FS)
#include "amdgpu_dm_debugfs.h"
#endif
+
+
+#include "dc/dcn20/dcn20_resource.h"
+
/* #define TRACE_DPCD */
#ifdef TRACE_DPCD
@@ -263,11 +267,9 @@ static int dm_dp_mst_get_modes(struct drm_connector
*connector)
amdgpu_dm_update_freesync_caps(
connector, aconnector->edid);
-#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
if (!validate_dsc_caps_on_connector(aconnector))
memset(&aconnector->dc_sink->sink_dsc_caps,
0,
sizeof(aconnector->dc_sink->sink_dsc_caps));
-#endif
}
}
@@ -505,3 +507,359 @@ int dm_mst_get_pbn_divider(struct dc_link *link)
return dc_link_bandwidth_kbps(link,
dc_link_get_link_cap(link)) / (8 * 1000 * 54);
}
+
+struct dsc_mst_fairness_params {
+ struct dc_crtc_timing *timing;
+ struct dc_sink *sink;
+ struct dc_dsc_bw_range bw_range;
+ bool compression_possible;
+ struct drm_dp_mst_port *port;
+};
+
+struct dsc_mst_fairness_vars {
+ int pbn;
+ bool dsc_enabled;
+ int bpp_x16;
+};
+
+static int kbps_to_peak_pbn(int kbps)
+{
+ u64 peak_kbps = kbps;
+
+ peak_kbps *= 1006;
+ peak_kbps /= 1000;
+ return (int) DIV_ROUND_UP(peak_kbps * 64, (54 * 8 * 1000));
+}
+
+static void set_dsc_configs_from_fairness_vars(struct dsc_mst_fairness_params
*params,
+ struct dsc_mst_fairness_vars *v
[PATCH v7 10/17] drm/dp_mst: Manually overwrite PBN divider for calculating timeslots
From: Mikita Lipski
[why]
For DSC case we cannot always use topology manager's PBN divider
variable. The default divider does not take FEC into account.
Therefore we should allow driver to calculate its own divider based
on the link rate and count its handling, as it is hw specific.
[how]
Pass pbn_div as an argument, which will be used if its more than
zero, otherwise default topology manager's pbn_div will be used.
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
drivers/gpu/drm/drm_dp_mst_topology.c | 9 +++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
include/drm/drm_dp_mst_helper.h | 3 ++-
5 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6c32b73c5197..3657a26ce1d1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4972,7 +4972,8 @@ static int dm_encoder_helper_atomic_check(struct
drm_encoder *encoder,
dm_new_connector_state->vcpi_slots =
drm_dp_atomic_find_vcpi_slots(state,
mst_mgr,
mst_port,
-
dm_new_connector_state->pbn);
+
dm_new_connector_state->pbn,
+ 0);
if (dm_new_connector_state->vcpi_slots < 0) {
DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n",
(int)dm_new_connector_state->vcpi_slots);
return dm_new_connector_state->vcpi_slots;
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index d5df02315e14..94bb259ab73e 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3211,6 +3211,7 @@ static int drm_dp_init_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
* @mgr: MST topology manager for the port
* @port: port to find vcpi slots for
* @pbn: bandwidth required for the mode in PBN
+ * @pbn_div: divider for DSC mode that takes FEC into account
*
* Allocates VCPI slots to @port, replacing any previous VCPI allocations it
* may have had. Any atomic drivers which support MST must call this function
@@ -3237,7 +3238,8 @@ static int drm_dp_init_vcpi(struct
drm_dp_mst_topology_mgr *mgr,
*/
int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr,
- struct drm_dp_mst_port *port, int pbn)
+ struct drm_dp_mst_port *port, int pbn,
+ int pbn_div)
{
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
@@ -3270,7 +3272,10 @@ int drm_dp_atomic_find_vcpi_slots(struct
drm_atomic_state *state,
if (!vcpi)
prev_slots = 0;
- req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
+ if (pbn_div <= 0)
+ pbn_div = mgr->pbn_div;
+
+ req_slots = DIV_ROUND_UP(pbn, pbn_div);
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] [MST PORT:%p] VCPI %d -> %d\n",
port->connector->base.id, port->connector->name,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index dfac450841df..2123ac2939f0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -65,7 +65,7 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
false);
slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
- port, crtc_state->pbn);
+ port, crtc_state->pbn, 0);
if (slots == -EDEADLK)
return slots;
if (slots >= 0)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c45832230ccc..27c5ff99f77e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -784,7 +784,8 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
if (crtc_state->mode_changed) {
slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr,
mstc->port,
- asyh->dp.pbn);
+ asyh->dp.pbn,
+
[PATCH v7 11/17] drm/dp_mst: Add DSC enablement helpers to DRM
From: Mikita Lipski
Adding a helper function to be called by
drivers outside of DRM to enable DSC on
the MST ports.
Function is called to recalculate VCPI allocation
if DSC is enabled and raise the DSC flag to enable.
In case of disabling DSC the flag is set to false
and recalculation of VCPI slots is expected to be done
in encoder's atomic_check.
v2: squash separate functions into one and call it per
port
Cc: Harry Wentland
Cc: Lyude Paul
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/drm_dp_mst_topology.c | 61 +++
include/drm/drm_dp_mst_helper.h | 5 +++
2 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 94bb259ab73e..98cc93d5ddd7 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3876,6 +3876,67 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
return 0;
}
+/**
+ * drm_dp_mst_atomic_enable_dsc - Set DSC Enable Flag to On/Off
+ * @state: Pointer to the new drm_atomic_state
+ * @pointer: Pointer to the affected MST Port
+ * @pbn: Newly recalculated bw required for link with DSC enabled
+ * @pbn_div: Divider to calculate correct number of pbn per slot
+ * @enable: Boolean flag enabling or disabling DSC on the port
+ *
+ * This function enables DSC on the given Port
+ * by recalculating its vcpi from pbn provided
+ * and sets dsc_enable flag to keep track of which
+ * ports have DSC enabled
+ *
+ */
+int drm_dp_mst_atomic_enable_dsc(struct drm_atomic_state *state,
+struct drm_dp_mst_port *port,
+int pbn, int pbn_div,
+bool enable)
+{
+ struct drm_dp_mst_topology_state *mst_state;
+ struct drm_dp_vcpi_allocation *pos;
+ bool found = false;
+ int vcpi = 0;
+
+ mst_state = drm_atomic_get_mst_topology_state(state, port->mgr);
+
+ if (IS_ERR(mst_state))
+ return PTR_ERR(mst_state);
+
+ list_for_each_entry(pos, &mst_state->vcpis, next) {
+ if (pos->port == port) {
+ found = true;
+ break;
+ }
+ }
+
+ if (!found) {
+ DRM_DEBUG_ATOMIC("[MST PORT:%p] Couldn't find VCPI allocation
in mst state %p\n",
+port, mst_state);
+ return -EINVAL;
+ }
+
+ if (pos->dsc_enabled == enable) {
+ DRM_DEBUG_ATOMIC("[MST PORT:%p] DSC flag is already set to %d,
returning %d VCPI slots\n",
+port, enable, pos->vcpi);
+ vcpi = pos->vcpi;
+ }
+
+ if (enable) {
+ vcpi = drm_dp_atomic_find_vcpi_slots(state, port->mgr, port,
pbn, pbn_div);
+ DRM_DEBUG_ATOMIC("[MST PORT:%p] Enabling DSC flag, reallocating
%d VCPI slots on the port\n",
+port, vcpi);
+ if (vcpi < 0)
+ return -EINVAL;
+ }
+
+ pos->dsc_enabled = enable;
+
+ return vcpi;
+}
+EXPORT_SYMBOL(drm_dp_mst_atomic_enable_dsc);
/**
* drm_dp_mst_atomic_check - Check that the new state of an MST topology in an
* atomic update is valid
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index fc19094b06c3..b1b00de3083b 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -431,6 +431,7 @@ struct drm_dp_payload {
struct drm_dp_vcpi_allocation {
struct drm_dp_mst_port *port;
int vcpi;
+ bool dsc_enabled;
struct list_head next;
};
@@ -663,6 +664,10 @@ drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port, int pbn,
int pbn_div);
+int drm_dp_mst_atomic_enable_dsc(struct drm_atomic_state *state,
+struct drm_dp_mst_port *port,
+int pbn, int pbn_div,
+bool enable);
int __must_check
drm_dp_atomic_release_vcpi_slots(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 16/17] drm/amd/display: Recalculate VCPI slots for new DSC connectors
From: Mikita Lipski
[why]
Since for DSC MST connector's PBN is claculated differently
due to compression, we have to recalculate both PBN and
VCPI slots for that connector.
[how]
The function iterates through all the active streams to
find, which have DSC enabled, then recalculates PBN for
it and calls drm_dp_helper_update_vcpi_slots_for_dsc to
update connector's VCPI slots.
v2: - use drm_dp_mst_atomic_enable_dsc per port to
enable/disable DSC
v3: - Iterate through connector states from the state passed
- On each connector state get stream from dc_state,
instead CRTC state
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Lyude Paul
Signed-off-by: Mikita Lipski
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +--
1 file changed, 71 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 7d8e244e5210..4be6621088d2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4986,6 +4986,69 @@ const struct drm_encoder_helper_funcs
amdgpu_dm_encoder_helper_funcs = {
.atomic_check = dm_encoder_helper_atomic_check
};
+static int dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
+ struct dc_state *dc_state)
+{
+ struct dc_stream_state *stream = NULL;
+ struct drm_connector *connector;
+ struct drm_connector_state *new_con_state, *old_con_state;
+ struct amdgpu_dm_connector *aconnector;
+ struct dm_connector_state *dm_conn_state;
+ int i, j, clock, bpp;
+ int vcpi, pbn_div, pbn = 0;
+
+ for_each_oldnew_connector_in_state(state, connector, old_con_state,
new_con_state, i) {
+
+ aconnector = to_amdgpu_dm_connector(connector);
+
+ if (!aconnector->port)
+ continue;
+
+ if (!new_con_state || !new_con_state->crtc)
+ continue;
+
+ dm_conn_state = to_dm_connector_state(new_con_state);
+
+ for (j = 0; j < dc_state->stream_count; j++) {
+ stream = dc_state->streams[j];
+ if (!stream)
+ continue;
+
+ if ((struct
amdgpu_dm_connector*)stream->dm_stream_context == aconnector)
+ break;
+
+ stream = NULL;
+ }
+
+ if (!stream)
+ continue;
+
+ if (stream->timing.flags.DSC != 1) {
+ drm_dp_mst_atomic_enable_dsc(state,
+aconnector->port,
+dm_conn_state->pbn,
+0,
+false);
+ continue;
+ }
+
+ pbn_div = dm_mst_get_pbn_divider(stream->link);
+ bpp = stream->timing.dsc_cfg.bits_per_pixel;
+ clock = stream->timing.pix_clk_100hz / 10;
+ pbn = drm_dp_calc_pbn_mode(clock, bpp, true);
+ vcpi = drm_dp_mst_atomic_enable_dsc(state,
+ aconnector->port,
+ pbn, pbn_div,
+ true);
+ if (vcpi < 0)
+ return vcpi;
+
+ dm_conn_state->pbn = pbn;
+ dm_conn_state->vcpi_slots = vcpi;
+ }
+ return 0;
+}
+
static void dm_drm_plane_reset(struct drm_plane *plane)
{
struct dm_plane_state *amdgpu_state = NULL;
@@ -8017,11 +8080,6 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
- /* Perform validation of MST topology in the state*/
- ret = drm_dp_mst_atomic_check(state);
- if (ret)
- goto fail;
-
if (state->legacy_cursor_update) {
/*
* This is a fast cursor update coming from the plane update
@@ -8093,6 +8151,10 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
if (!compute_mst_dsc_configs_for_state(state,
dm_state->context))
goto fail;
+ ret = dm_update_mst_vcpi_slots_for_dsc(state,
dm_state->context);
+ if (ret)
+ goto fail;
+
if (dc_validate_global_state(dc, dm_state->context, false) !=
DC_OK) {
ret = -EINVAL;
goto fail;
@@ -8121,6 +8183,10 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
dc_retain_state(old_dm_state->context);
}
}
+ /* Perform validation of MST topology in the state*/
+ ret = drm_dp_mst_atom
[PATCH v7 12/17] drm/dp_mst: Add branch bandwidth validation to MST atomic check
From: Mikita Lipski
Adding PBN attribute to drm_dp_vcpi_allocation structure to
keep track of how much bandwidth each Port requires.
Adding drm_dp_mst_atomic_check_bw_limit to verify that
state's bandwidth needs doesn't exceed available bandwidth.
The funtion is called in drm_dp_mst_atomic_check after
drm_dp_mst_atomic_check_topology_state to fully verify that
the proposed topology is supported.
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Lyude Paul
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/drm_dp_mst_topology.c | 67 ++-
include/drm/drm_dp_mst_helper.h | 1 +
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 98cc93d5ddd7..5072c1e3dcfe 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3243,7 +3243,7 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
{
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
- int prev_slots, req_slots, ret;
+ int prev_slots, prev_bw, req_slots, ret;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
@@ -3254,6 +3254,7 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
if (pos->port == port) {
vcpi = pos;
prev_slots = vcpi->vcpi;
+ prev_bw = vcpi->pbn;
/*
* This should never happen, unless the driver tries
@@ -3269,8 +3270,10 @@ int drm_dp_atomic_find_vcpi_slots(struct
drm_atomic_state *state,
break;
}
}
- if (!vcpi)
+ if (!vcpi) {
prev_slots = 0;
+ prev_bw = 0;
+ }
if (pbn_div <= 0)
pbn_div = mgr->pbn_div;
@@ -3280,6 +3283,9 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] [MST PORT:%p] VCPI %d -> %d\n",
port->connector->base.id, port->connector->name,
port, prev_slots, req_slots);
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] [MST PORT:%p] PBN %d -> %d\n",
+port->connector->base.id, port->connector->name,
+port, prev_bw, pbn);
/* Add the new allocation to the state */
if (!vcpi) {
@@ -3292,6 +3298,7 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
list_add(&vcpi->next, &topology_state->vcpis);
}
vcpi->vcpi = req_slots;
+ vcpi->pbn = pbn;
ret = req_slots;
return ret;
@@ -3837,6 +3844,59 @@ static void drm_dp_mst_destroy_state(struct
drm_private_obj *obj,
kfree(mst_state);
}
+static bool drm_dp_mst_port_downstream_of_branch(struct drm_dp_mst_port *port,
+struct drm_dp_mst_branch
*branch)
+{
+ while (port->parent) {
+ if (port->parent == branch)
+ return true;
+
+ if (port->parent->port_parent)
+ port = port->parent->port_parent;
+ else
+ break;
+ }
+ return false;
+}
+
+static inline
+int drm_dp_mst_atomic_check_bw_limit(struct drm_dp_mst_branch *branch,
+struct drm_dp_mst_topology_state
*mst_state)
+{
+ struct drm_dp_mst_port *port;
+ struct drm_dp_vcpi_allocation *vcpi;
+ int pbn_limit = 0, pbn_used = 0;
+
+ list_for_each_entry(port, &branch->ports, next) {
+ if (port->mstb) {
+ if (drm_dp_mst_atomic_check_bw_limit(port->mstb,
mst_state))
+ return -EINVAL;
+ }
+ if (port->available_pbn > 0)
+ pbn_limit = port->available_pbn;
+ }
+ DRM_DEBUG_ATOMIC("[MST BRANCH:%p] branch has %d PBN available\n",
+branch,
+pbn_limit);
+
+ list_for_each_entry(vcpi, &mst_state->vcpis, next) {
+ if (!vcpi->pbn)
+ continue;
+
+ if (drm_dp_mst_port_downstream_of_branch(vcpi->port, branch))
+ pbn_used += vcpi->pbn;
+ }
+ DRM_DEBUG_ATOMIC("[MST BRANCH:%p] branch used %d PBN\n",
+branch,
+pbn_used);
+ if (pbn_used > pbn_limit) {
+ DRM_DEBUG_ATOMIC("[MST BRANCH:%p] No available bandwidth\n",
+branch);
+ return -EINVAL;
+ }
+ return 0;
+}
+
static inline int
drm_dp_mst_atomic_check_topology_state(struct drm_dp_mst_topology_mgr *mgr,
struct drm_
[PATCH v7 00/17] DSC MST support for DRM and AMDGPU
From: Mikita Lipski Patches are based of amd-staging-drm-next, the follow up set of patches will be sent for drm-tip This set of patches is a continuation of DSC enablement patches for AMDGPU. This set enables DSC on MST. It also contains implementation of both encoder and connector atomic check routines. These patches have been introduced in multiple iterations to the mailing list before. These patches were developed by David Francis as part of his work on DSC. v2: squashed previously 3 separate atomic check patches, separate atomic check for dsc connectors, track vcpi and pbn on connectors. v3: Moved modeset trigger on affected MST displays to DRM v4: Fix warnings, use current mode's bpc rather than display's maximum capable one v5: Moving branch's bandwidth validation to DRM, Added function to enable DSC per port in DRM v6: Compute fair share uses DRM helper for BW validation v7: Add helper to overwrite PBN divider per slot, Add helper function to trigger modeset on affected DSC connectors in DRM David Francis (9): drm/dp_mst: Add PBN calculation for DSC modes drm/dp_mst: Parse FEC capability on MST ports drm/dp_mst: Add MST support to DP DPCD R/W functions drm/dp_mst: Fill branch->num_ports drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux drm/amd/display: Initialize DSC PPS variables to 0 drm/amd/display: Validate DSC caps on MST endpoints drm/amd/display: Write DSC enable to MST DPCD drm/amd/display: MST DSC compute fair share drm/dp_mst: Add new quirk for Synaptics MST hubs Mikita Lipski (8): drm/dp_mst: Manually overwrite PBN divider for calculating timeslots drm/dp_mst: Add DSC enablement helpers to DRM drm/dp_mst: Add branch bandwidth validation to MST atomic check drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs drm/amd/display: Add PBN per slot calculation for DSC drm/amd/display: Recalculate VCPI slots for new DSC connectors drm/amd/display: Trigger modesets on MST DSC connectors .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 117 - .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 + .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 395 - .../display/amdgpu_dm/amdgpu_dm_mst_types.h | 5 + .../drm/amd/display/dc/core/dc_link_hwss.c| 3 + .../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 3 + .../drm/amd/display/dc/dcn20/dcn20_resource.c | 7 +- .../drm/amd/display/dc/dcn20/dcn20_resource.h | 1 + drivers/gpu/drm/drm_dp_aux_dev.c | 12 +- drivers/gpu/drm/drm_dp_helper.c | 33 +- drivers/gpu/drm/drm_dp_mst_topology.c | 401 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 +- drivers/gpu/drm/radeon/radeon_dp_mst.c| 2 +- include/drm/drm_dp_helper.h | 7 + include/drm/drm_dp_mst_helper.h | 19 +- 17 files changed, 989 insertions(+), 47 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 09/17] drm/amd/display: Write DSC enable to MST DPCD
From: David Francis
Rework the dm_helpers_write_dsc_enable callback to
handle the MST case.
Use the cached dsc_aux field.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 66f266a5e10b..069b7a6f5597 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -37,6 +37,7 @@
#include "dc.h"
#include "amdgpu_dm.h"
#include "amdgpu_dm_irq.h"
+#include "amdgpu_dm_mst_types.h"
#include "dm_helpers.h"
@@ -516,8 +517,24 @@ bool dm_helpers_dp_write_dsc_enable(
)
{
uint8_t enable_dsc = enable ? 1 : 0;
+ struct amdgpu_dm_connector *aconnector;
+
+ if (!stream)
+ return false;
+
+ if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST) {
+ aconnector = (struct amdgpu_dm_connector
*)stream->dm_stream_context;
+
+ if (!aconnector->dsc_aux)
+ return false;
+
+ return (drm_dp_dpcd_write(aconnector->dsc_aux, DP_DSC_ENABLE,
&enable_dsc, 1) >= 0);
+ }
+
+ if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT)
+ return dm_helpers_dp_write_dpcd(ctx, stream->link,
DP_DSC_ENABLE, &enable_dsc, 1);
- return dm_helpers_dp_write_dpcd(ctx, stream->sink->link, DP_DSC_ENABLE,
&enable_dsc, 1);
+ return false;
}
bool dm_helpers_is_dp_sink_present(struct dc_link *link)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 02/17] drm/dp_mst: Parse FEC capability on MST ports
From: David Francis
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for FEC and DSC support
Store it on drm_dp_mst_port
Reviewed-by: Lyude Paul
Reviewed-by: Harry Wentland
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
include/drm/drm_dp_mst_helper.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 3e7b7553cf4d..9f3604355705 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -553,6 +553,7 @@ static bool
drm_dp_sideband_parse_enum_path_resources_ack(struct drm_dp_sideband
{
int idx = 1;
repmsg->u.path_resources.port_number = (raw->msg[idx] >> 4) & 0xf;
+ repmsg->u.path_resources.fec_capable = raw->msg[idx] & 0x1;
idx++;
if (idx > raw->curlen)
goto fail_len;
@@ -2183,6 +2184,7 @@ static int drm_dp_send_enum_path_resources(struct
drm_dp_mst_topology_mgr *mgr,
DRM_DEBUG_KMS("enum path resources %d: %d %d\n",
txmsg->reply.u.path_resources.port_number,
txmsg->reply.u.path_resources.full_payload_bw_number,
txmsg->reply.u.path_resources.avail_payload_bw_number);
port->available_pbn =
txmsg->reply.u.path_resources.avail_payload_bw_number;
+ port->fec_capable =
txmsg->reply.u.path_resources.fec_capable;
}
}
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 9116b2c95239..f113ae04fa88 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -108,6 +108,8 @@ struct drm_dp_mst_port {
* audio-capable.
*/
bool has_audio;
+
+ bool fec_capable;
};
/**
@@ -312,6 +314,7 @@ struct drm_dp_port_number_req {
struct drm_dp_enum_path_resources_ack_reply {
u8 port_number;
+ bool fec_capable;
u16 full_payload_bw_number;
u16 avail_payload_bw_number;
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 01/17] drm/dp_mst: Add PBN calculation for DSC modes
From: David Francis
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate function for this
Reviewed-by: Manasi Navare
Reviewed-by: Lyude Paul
Reviewed-by: Harry Wentland
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c| 16
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 ++-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
drivers/gpu/drm/radeon/radeon_dp_mst.c | 2 +-
include/drm/drm_dp_mst_helper.h | 3 +--
6 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 93fa3f1d2e7e..6c32b73c5197 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4967,7 +4967,7 @@ static int dm_encoder_helper_atomic_check(struct
drm_encoder *encoder,
is_y420);
bpp = convert_dc_color_depth_into_bpc(color_depth) * 3;
clock = adjusted_mode->clock;
- dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp);
+ dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp,
false);
}
dm_new_connector_state->vcpi_slots =
drm_dp_atomic_find_vcpi_slots(state,
mst_mgr,
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 82add736e17d..3e7b7553cf4d 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3534,10 +3534,11 @@ EXPORT_SYMBOL(drm_dp_check_act_status);
* drm_dp_calc_pbn_mode() - Calculate the PBN for a mode.
* @clock: dot clock for the mode
* @bpp: bpp for the mode.
+ * @dsc: DSC mode. If true, bpp has units of 1/16 of a bit per pixel
*
* This uses the formula in the spec to calculate the PBN value for a mode.
*/
-int drm_dp_calc_pbn_mode(int clock, int bpp)
+int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc)
{
u64 kbps;
s64 peak_kbps;
@@ -3555,11 +3556,18 @@ int drm_dp_calc_pbn_mode(int clock, int bpp)
* peak_kbps *= (1006/1000)
* peak_kbps *= (64/54)
* peak_kbps *= 8convert to bytes
+*
+* If the bpp is in units of 1/16, further divide by 16. Put this
+* factor in the numerator rather than the denominator to avoid
+* integer overflow
*/
numerator = 64 * 1006;
denominator = 54 * 8 * 1000 * 1000;
+ if (dsc)
+ numerator /= 16;
+
kbps *= numerator;
peak_kbps = drm_fixp_from_fraction(kbps, denominator);
@@ -3570,19 +3578,19 @@ EXPORT_SYMBOL(drm_dp_calc_pbn_mode);
static int test_calc_pbn_mode(void)
{
int ret;
- ret = drm_dp_calc_pbn_mode(154000, 30);
+ ret = drm_dp_calc_pbn_mode(154000, 30, false);
if (ret != 689) {
DRM_ERROR("PBN calculation test failed - clock %d, bpp %d,
expected PBN %d, actual PBN %d.\n",
154000, 30, 689, ret);
return -EINVAL;
}
- ret = drm_dp_calc_pbn_mode(234000, 30);
+ ret = drm_dp_calc_pbn_mode(234000, 30, false);
if (ret != 1047) {
DRM_ERROR("PBN calculation test failed - clock %d, bpp %d,
expected PBN %d, actual PBN %d.\n",
234000, 30, 1047, ret);
return -EINVAL;
}
- ret = drm_dp_calc_pbn_mode(297000, 24);
+ ret = drm_dp_calc_pbn_mode(297000, 24, false);
if (ret != 1063) {
DRM_ERROR("PBN calculation test failed - clock %d, bpp %d,
expected PBN %d, actual PBN %d.\n",
297000, 24, 1063, ret);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 2c5ac3dd647f..dfac450841df 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -61,7 +61,8 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
crtc_state->pipe_bpp = bpp;
crtc_state->pbn =
drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock,
- crtc_state->pipe_bpp);
+ crtc_state->pipe_bpp,
+ false);
slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
[PATCH v7 14/17] drm/amd/display: Add PBN per slot calculation for DSC
From: Mikita Lipski
[why]
Need to calculate VCPI slots differently for DSC
to take in account current link rate, link count
and FEC.
[how]
Add helper to get pbn_div from dc_link
Signed-off-by: Mikita Lipski
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 8
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 02f30742d1ee..e8a0ef883434 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -497,3 +497,11 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
aconnector->connector_id);
}
+int dm_mst_get_pbn_divider(struct dc_link *link)
+{
+ if (!link)
+ return 0;
+
+ return dc_link_bandwidth_kbps(link,
+ dc_link_get_link_cap(link)) / (8 * 1000 * 54);
+}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
index 2da851b40042..a553ea046185 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.h
@@ -29,6 +29,8 @@
struct amdgpu_display_manager;
struct amdgpu_dm_connector;
+int dm_mst_get_pbn_divider(struct dc_link *link);
+
void amdgpu_dm_initialize_dp_connector(struct amdgpu_display_manager *dm,
struct amdgpu_dm_connector *aconnector);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 17/17] drm/amd/display: Trigger modesets on MST DSC connectors
From: Mikita Lipski
Whenever a connector on an MST network is attached, detached, or
undergoes a modeset, the DSC configs for each stream on that
topology will be recalculated. This can change their required
bandwidth, requiring a full reprogramming, as though a modeset
was performed, even if that stream did not change timing.
Therefore, whenever a crtc has drm_atomic_crtc_needs_modeset,
for each crtc that shares a MST topology with that stream and
supports DSC, add that crtc (and all affected connectors and
planes) to the atomic state and set mode_changed on its state
v2: Do this check only on Navi and before adding connectors
and planes on modesetting crtcs
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 4be6621088d2..2dc5c27ee4a1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7924,6 +7924,29 @@ dm_determine_update_type_for_commit(struct
amdgpu_display_manager *dm,
*out_type = update_type;
return ret;
}
+static int add_affected_mst_dsc_crtcs(struct drm_atomic_state *state, struct
drm_crtc *crtc)
+{
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct amdgpu_dm_connector *aconnector = NULL;
+ int i;
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->crtc != crtc)
+ continue;
+
+ aconnector = to_amdgpu_dm_connector(connector);
+ if (!aconnector->port)
+ aconnector = NULL;
+ else
+ break;
+ }
+
+ if (!aconnector)
+ return 0;
+
+ return drm_dp_mst_add_affected_dsc_crtcs(state, aconnector->port);
+
+}
/**
* amdgpu_dm_atomic_check() - Atomic check implementation for AMDgpu DM.
@@ -7976,6 +7999,16 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
ret = drm_atomic_helper_check_modeset(dev, state);
if (ret)
goto fail;
+
+ if (adev->asic_type >= CHIP_NAVI10) {
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
+ ret = add_affected_mst_dsc_crtcs(state, crtc);
+ if (ret)
+ goto fail;
+ }
+ }
+ }
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
if (!drm_atomic_crtc_needs_modeset(new_crtc_state) &&
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 04/17] drm/dp_mst: Fill branch->num_ports
From: David Francis This field on drm_dp_mst_branch was never filled It is initialized to zero when the port is kzallocced. When a port is added to the list, increment num_ports, and when a port is removed from the list, decrement num_ports. v2: remember to decrement on port removal v3: don't explicitly init to 0 Reviewed-by: Lyude Paul Reviewed-by: Harry Wentland Signed-off-by: David Francis Signed-off-by: Mikita Lipski --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 9f3604355705..502923c24450 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -1669,6 +1669,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch *mstb, mutex_lock(&mstb->mgr->lock); drm_dp_mst_topology_get_port(port); list_add(&port->next, &mstb->ports); + mstb->num_ports++; mutex_unlock(&mstb->mgr->lock); } @@ -1703,6 +1704,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch *mstb, /* remove it from the port list */ mutex_lock(&mstb->mgr->lock); list_del(&port->next); + mstb->num_ports--; mutex_unlock(&mstb->mgr->lock); /* drop port list reference */ drm_dp_mst_topology_put_port(port); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 08/17] drm/amd/display: Validate DSC caps on MST endpoints
From: David Francis
During MST mode enumeration, if a new dc_sink is created,
populate it with dsc caps as appropriate.
Use drm_dp_mst_dsc_aux_for_port to get the raw caps,
then parse them onto dc_sink with dc_dsc_parse_dsc_dpcd.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 29 ++-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index f6e18d8a9936..9b8f3d59fa30 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -323,6 +323,7 @@ struct amdgpu_dm_connector {
struct drm_dp_mst_port *port;
struct amdgpu_dm_connector *mst_port;
struct amdgpu_encoder *mst_encoder;
+ struct drm_dp_aux *dsc_aux;
/* TODO see if we can merge with ddc_bus or make a dm_connector */
struct amdgpu_i2c_adapter *i2c;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index e61eec15a3d0..02f30742d1ee 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include "dm_services.h"
#include "amdgpu.h"
#include "amdgpu_dm.h"
@@ -196,6 +197,26 @@ static const struct drm_connector_funcs
dm_dp_mst_connector_funcs = {
.early_unregister = amdgpu_dm_mst_connector_early_unregister,
};
+static bool validate_dsc_caps_on_connector(struct amdgpu_dm_connector
*aconnector)
+{
+ struct dc_sink *dc_sink = aconnector->dc_sink;
+ struct drm_dp_mst_port *port = aconnector->port;
+ u8 dsc_caps[16] = { 0 };
+
+ aconnector->dsc_aux = drm_dp_mst_dsc_aux_for_port(port);
+
+ if (!aconnector->dsc_aux)
+ return false;
+
+ if (drm_dp_dpcd_read(aconnector->dsc_aux, DP_DSC_SUPPORT, dsc_caps, 16)
< 0)
+ return false;
+
+ if (!dc_dsc_parse_dsc_dpcd(dsc_caps, NULL,
&dc_sink->sink_dsc_caps.dsc_dec_caps))
+ return false;
+
+ return true;
+}
+
static int dm_dp_mst_get_modes(struct drm_connector *connector)
{
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
@@ -238,10 +259,16 @@ static int dm_dp_mst_get_modes(struct drm_connector
*connector)
/* dc_link_add_remote_sink returns a new reference */
aconnector->dc_sink = dc_sink;
- if (aconnector->dc_sink)
+ if (aconnector->dc_sink) {
amdgpu_dm_update_freesync_caps(
connector, aconnector->edid);
+#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT
+ if (!validate_dsc_caps_on_connector(aconnector))
+ memset(&aconnector->dc_sink->sink_dsc_caps,
+ 0,
sizeof(aconnector->dc_sink->sink_dsc_caps));
+#endif
+ }
}
drm_connector_update_edid_property(
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 05/17] drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux
From: David Francis
Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
register might have to be written on the leaf port's DPCD,
its parent's DPCD, or the MST manager's DPCD. This function
finds the correct aux for the job.
As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual DPCD
is a DP feature new in DP v1.4, which exposes certain DPCD
registers on virtual ports.
v2: Remember to unlock mutex on all paths
v3: Refactor to match coding style and increase brevity
Reviewed-by: Lyude Paul
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/drm_dp_mst_topology.c | 127 ++
include/drm/drm_dp_mst_helper.h | 2 +
2 files changed, 129 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 502923c24450..d8f9ba27b559 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4150,3 +4150,130 @@ static void drm_dp_mst_unregister_i2c_bus(struct
drm_dp_aux *aux)
{
i2c_del_adapter(&aux->ddc);
}
+
+/**
+ * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DP Peer Device
+ * @port: The port to check
+ *
+ * A single physical MST hub object can be represented in the topology
+ * by multiple branches, with virtual ports between those branches.
+ *
+ * As of DP1.4, An MST hub with internal (virtual) ports must expose
+ * certain DPCD registers over those ports. See sections 2.6.1.1.1
+ * and 2.6.1.1.2 of Display Port specification v1.4 for details.
+ *
+ * May acquire mgr->lock
+ *
+ * Returns:
+ * true if the port is a virtual DP peer device, false otherwise
+ */
+static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
+{
+ struct drm_dp_mst_port *downstream_port;
+
+ if (!port || port->dpcd_rev < DP_DPCD_REV_14)
+ return false;
+
+ /* Virtual DP Sink (Internal Display Panel) */
+ if (port->port_num >= 8)
+ return true;
+
+ /* DP-to-HDMI Protocol Converter */
+ if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
+ !port->mcs &&
+ port->ldps)
+ return true;
+
+ /* DP-to-DP */
+ mutex_lock(&port->mgr->lock);
+ if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
+ port->mstb &&
+ port->mstb->num_ports == 2) {
+ list_for_each_entry(downstream_port, &port->mstb->ports, next) {
+ if (downstream_port->pdt == DP_PEER_DEVICE_SST_SINK &&
+ !downstream_port->input) {
+ mutex_unlock(&port->mgr->lock);
+ return true;
+ }
+ }
+ }
+ mutex_unlock(&port->mgr->lock);
+
+ return false;
+}
+
+/**
+ * drm_dp_mst_dsc_aux_for_port() - Find the correct aux for DSC
+ * @port: The port to check. A leaf of the MST tree with an attached display.
+ *
+ * Depending on the situation, DSC may be enabled via the endpoint aux,
+ * the immediately upstream aux, or the connector's physical aux.
+ *
+ * This is both the correct aux to read DSC_CAPABILITY and the
+ * correct aux to write DSC_ENABLED.
+ *
+ * This operation can be expensive (up to four aux reads), so
+ * the caller should cache the return.
+ *
+ * Returns:
+ * NULL if DSC cannot be enabled on this port, otherwise the aux device
+ */
+struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port)
+{
+ struct drm_dp_mst_port *immediate_upstream_port;
+ struct drm_dp_mst_port *fec_port;
+
+ if (!port)
+ return NULL;
+
+ if (port->parent)
+ immediate_upstream_port = port->parent->port_parent;
+ else
+ immediate_upstream_port = NULL;
+
+ fec_port = immediate_upstream_port;
+ while (fec_port) {
+ /*
+* Each physical link (i.e. not a virtual port) between the
+* output and the primary device must support FEC
+*/
+ if (!drm_dp_mst_is_virtual_dpcd(fec_port) &&
+ !fec_port->fec_capable)
+ return NULL;
+
+ fec_port = fec_port->parent->port_parent;
+ }
+
+ /* DP-to-DP peer device */
+ if (drm_dp_mst_is_virtual_dpcd(immediate_upstream_port)) {
+ u8 upstream_dsc;
+ u8 endpoint_dsc;
+ u8 endpoint_fec;
+
+ if (drm_dp_dpcd_read(&port->aux,
+DP_DSC_SUPPORT, &endpoint_dsc, 1) < 0)
+ return NULL;
+ if (drm_dp_dpcd_read(&port->aux,
+DP_FEC_CAPABILITY, &endpoint_fec, 1) < 0)
+ return NULL;
+ if (drm_dp_dpcd_read(&immediate_upstream_port->aux,
+DP_DSC_SUPPORT, &upstream_dsc, 1) < 0)
+
[PATCH v7 06/17] drm/dp_mst: Add new quirk for Synaptics MST hubs
From: Mikita Lipski
Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
support virtual DPCD registers, but do support DSC.
The DSC caps can be read from the physical aux,
like in SST DSC. These hubs have many different
DEVICE_IDs. Add a new quirk to detect this case.
Reviewed-by: Wenjing Liu
Reviewed-by: Lyude Paul
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
drivers/gpu/drm/drm_dp_mst_topology.c | 27 +++
include/drm/drm_dp_helper.h | 7 +++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index af1cd968adfd..02fa8c3d9a82 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1271,6 +1271,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
{ OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
BIT(DP_DPCD_QUIRK_NO_PSR) },
/* CH7511 seems to leave SINK_COUNT zeroed */
{ OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
+ /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
+ { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
};
#undef OUI
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index d8f9ba27b559..d5df02315e14 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4222,6 +4222,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
drm_dp_mst_port *port)
{
struct drm_dp_mst_port *immediate_upstream_port;
struct drm_dp_mst_port *fec_port;
+ struct drm_dp_desc desc = { 0 };
if (!port)
return NULL;
@@ -4274,6 +4275,32 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
drm_dp_mst_port *port)
if (drm_dp_mst_is_virtual_dpcd(port))
return &port->aux;
+ /*
+* Synaptics quirk
+* Applies to ports for which:
+* - Physical aux has Synaptics OUI
+* - DPv1.4 or higher
+* - Port is on primary branch device
+* - Not a VGA adapter (DP_DWN_STRM_PORT_TYPE_ANALOG)
+*/
+ if (!drm_dp_read_desc(port->mgr->aux, &desc, true))
+ return NULL;
+
+ if (drm_dp_has_quirk(&desc, DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) &&
+ port->mgr->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14 &&
+ port->parent == port->mgr->mst_primary) {
+ u8 downstreamport;
+
+ if (drm_dp_dpcd_read(&port->aux, DP_DOWNSTREAMPORT_PRESENT,
+&downstreamport, 1) < 0)
+ return NULL;
+
+ if ((downstreamport & DP_DWN_STRM_PORT_PRESENT) &&
+ ((downstreamport & DP_DWN_STRM_PORT_TYPE_MASK)
+!= DP_DWN_STRM_PORT_TYPE_ANALOG))
+ return port->mgr->aux;
+ }
+
return NULL;
}
EXPORT_SYMBOL(drm_dp_mst_dsc_aux_for_port);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 5a795075d5da..5ff59e91 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1464,6 +1464,13 @@ enum drm_dp_quirk {
* The driver should ignore SINK_COUNT during detection.
*/
DP_DPCD_QUIRK_NO_SINK_COUNT,
+ /**
+* @DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD:
+*
+* The device supports MST DSC despite not supporting Virtual DPCD.
+* The DSC caps can be read from the physical aux instead.
+*/
+ DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 13/17] drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs
From: Mikita Lipski
[why]
Whenever a connector on an MST network is changed or
undergoes a modeset, the DSC configs for each stream on that
topology will be recalculated. This can change their required
bandwidth, requiring a full reprogramming, as though a modeset
was performed, even if that stream did not change timing.
[how]
Adding helper to trigger modesets on MST DSC connectors
by setting mode_changed flag on CRTCs in the same topology
as affected connector
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/drm_dp_mst_topology.c | 90 +++
include/drm/drm_dp_mst_helper.h | 2 +
2 files changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5072c1e3dcfe..4d9089fe84c1 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -73,6 +73,7 @@ static bool drm_dp_validate_guid(struct
drm_dp_mst_topology_mgr *mgr,
static int drm_dp_mst_register_i2c_bus(struct drm_dp_aux *aux);
static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_aux *aux);
static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr);
+static bool drm_dp_mst_is_dsc_supported(struct drm_dp_mst_port *port);
#define DP_STR(x) [DP_ ## x] = #x
@@ -3936,6 +3937,66 @@ drm_dp_mst_atomic_check_topology_state(struct
drm_dp_mst_topology_mgr *mgr,
return 0;
}
+/**
+ * drm_dp_mst_add_affected_dsc_crtcs
+ * @state: Pointer to the new &struct drm_dp_mst_topology_state
+ * @port: Pointer tothe port of connector with new state
+ *
+ * Whenever there is a change in mst topology
+ * DSC configuration would have to be recalculated
+ * therefore we need to trigger modeset on all affected
+ * CRTCs in that topology
+ *
+ * See also:
+ * drm_dp_mst_atomic_enable_dsc()
+ */
+int drm_dp_mst_add_affected_dsc_crtcs(struct drm_atomic_state *state, struct
drm_dp_mst_port *port)
+{
+ struct drm_dp_mst_topology_state *mst_state;
+ struct drm_dp_vcpi_allocation *pos;
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+
+ if (!port)
+ return -EINVAL;
+
+ mst_state = drm_atomic_get_mst_topology_state(state, port->mgr);
+
+ list_for_each_entry(pos, &mst_state->vcpis, next) {
+
+ connector = pos->port->connector;
+
+ if (!connector)
+ return -EINVAL;
+
+ conn_state = drm_atomic_get_connector_state(state, connector);
+
+ if (IS_ERR(conn_state))
+ return PTR_ERR(conn_state);
+
+ crtc = conn_state->crtc;
+
+ if (!crtc)
+ return -EINVAL;
+
+ if (!drm_dp_mst_is_dsc_supported(pos->port))
+ continue;
+
+ crtc_state = drm_atomic_get_crtc_state(mst_state->base.state,
crtc);
+
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ DRM_DEBUG_ATOMIC("[MST PORT:%p] Setting mode_changed flag on
CRTC %p\n", port, crtc);
+
+ crtc_state->mode_changed = true;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_mst_add_affected_dsc_crtcs);
+
/**
* drm_dp_mst_atomic_enable_dsc - Set DSC Enable Flag to On/Off
* @state: Pointer to the new drm_atomic_state
@@ -4433,3 +4494,32 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
drm_dp_mst_port *port)
return NULL;
}
EXPORT_SYMBOL(drm_dp_mst_dsc_aux_for_port);
+
+/**
+ * drm_dp_mst_is_dsc_supported() - Verify DSC support on connector
+ * @port: The port to check. A leaf of the MST tree with an attached display.
+ *
+ * Acquiring correct aux from drm_dp_mst_dsc_aux_for_port
+ * and verifying DPCD flag that the aux is DSC capable
+ *
+ * Returns:
+ * True / False - if DSC is supported
+ */
+static bool drm_dp_mst_is_dsc_supported(struct drm_dp_mst_port *port)
+{
+ struct drm_dp_aux *dsc_aux;
+ u8 endpoint_dsc;
+
+ dsc_aux = drm_dp_mst_dsc_aux_for_port(port);
+
+ if (!dsc_aux)
+ return false;
+
+ if (drm_dp_dpcd_read(&port->aux, DP_DSC_SUPPORT, &endpoint_dsc, 1) < 0)
+ return false;
+
+ if (endpoint_dsc & DP_DSC_DECOMPRESSION_IS_SUPPORTED)
+ return true;
+
+ return false;
+}
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 5a119a40ed5a..7d1e5e42c9ac 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -669,6 +669,8 @@ int drm_dp_mst_atomic_enable_dsc(struct drm_atomic_state
*state,
struct drm_dp_mst_port *port,
int pbn, int pbn_div,
bool enable);
+int drm_dp_mst_add_affected_dsc_crtcs(struct drm_atomic_state *state,
+ struct drm_dp_mst_port *port);
int __must_
[PATCH v7 07/17] drm/amd/display: Initialize DSC PPS variables to 0
From: David Francis
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Reviewed-by: Nicholas Kazlauskas
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c | 3 +++
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
index bb1e8e5b5252..a7f3a9ecc626 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
@@ -526,6 +526,9 @@ bool dp_set_dsc_pps_sdp(struct pipe_ctx *pipe_ctx, bool
enable)
struct dsc_config dsc_cfg;
uint8_t dsc_packed_pps[128];
+ memset(&dsc_cfg, 0, sizeof(dsc_cfg));
+ memset(dsc_packed_pps, 0, 128);
+
/* Enable DSC hw block */
dsc_cfg.pic_width = stream->timing.h_addressable +
stream->timing.h_border_left + stream->timing.h_border_right;
dsc_cfg.pic_height = stream->timing.v_addressable +
stream->timing.v_border_top + stream->timing.v_border_bottom;
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
index 0111545dac75..6bdfee20b6a7 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
@@ -206,6 +206,9 @@ static bool dsc2_get_packed_pps(struct
display_stream_compressor *dsc, const str
struct dsc_reg_values dsc_reg_vals;
struct dsc_optc_config dsc_optc_cfg;
+ memset(&dsc_reg_vals, 0, sizeof(dsc_reg_vals));
+ memset(&dsc_optc_cfg, 0, sizeof(dsc_optc_cfg));
+
DC_LOG_DSC("Getting packed DSC PPS for DSC Config:");
dsc_config_log(dsc, dsc_cfg);
DC_LOG_DSC("DSC Picture Parameter Set (PPS):");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 03/17] drm/dp_mst: Add MST support to DP DPCD R/W functions
From: David Francis
Instead of having drm_dp_dpcd_read/write and
drm_dp_mst_dpcd_read/write as entry points into the
aux code, have drm_dp_dpcd_read/write handle both.
This means that DRM drivers can make MST DPCD read/writes.
v2: Fix spacing
v3: Dump dpcd access on MST read/writes
v4: Fix calling wrong function on DPCD write
Reviewed-by: Lyude Paul
Reviewed-by: Harry Wentland
Signed-off-by: David Francis
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/drm_dp_aux_dev.c | 12 ++--
drivers/gpu/drm/drm_dp_helper.c | 31 +--
2 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
index 0cfb386754c3..2510717d5a08 100644
--- a/drivers/gpu/drm/drm_dp_aux_dev.c
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -163,11 +163,7 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb, struct
iov_iter *to)
break;
}
- if (aux_dev->aux->is_remote)
- res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
- todo);
- else
- res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
+ res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
if (res <= 0)
break;
@@ -215,11 +211,7 @@ static ssize_t auxdev_write_iter(struct kiocb *iocb,
struct iov_iter *from)
break;
}
- if (aux_dev->aux->is_remote)
- res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf,
- todo);
- else
- res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
+ res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
if (res <= 0)
break;
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ffc68d305afe..af1cd968adfd 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+#include
#include "drm_crtc_helper_internal.h"
@@ -251,7 +253,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
/**
* drm_dp_dpcd_read() - read a series of bytes from the DPCD
- * @aux: DisplayPort AUX channel
+ * @aux: DisplayPort AUX channel (SST or MST)
* @offset: address of the (first) register to read
* @buffer: buffer to store the register values
* @size: number of bytes in @buffer
@@ -280,13 +282,18 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned
int offset,
* We just have to do it before any DPCD access and hope that the
* monitor doesn't power down exactly after the throw away read.
*/
- ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV, buffer,
-1);
- if (ret != 1)
- goto out;
+ if (!aux->is_remote) {
+ ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, DP_DPCD_REV,
+buffer, 1);
+ if (ret != 1)
+ goto out;
+ }
- ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset, buffer,
-size);
+ if (aux->is_remote)
+ ret = drm_dp_mst_dpcd_read(aux, offset, buffer, size);
+ else
+ ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_READ, offset,
+buffer, size);
out:
drm_dp_dump_access(aux, DP_AUX_NATIVE_READ, offset, buffer, ret);
@@ -296,7 +303,7 @@ EXPORT_SYMBOL(drm_dp_dpcd_read);
/**
* drm_dp_dpcd_write() - write a series of bytes to the DPCD
- * @aux: DisplayPort AUX channel
+ * @aux: DisplayPort AUX channel (SST or MST)
* @offset: address of the (first) register to write
* @buffer: buffer containing the values to write
* @size: number of bytes in @buffer
@@ -313,8 +320,12 @@ ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned
int offset,
{
int ret;
- ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer,
-size);
+ if (aux->is_remote)
+ ret = drm_dp_mst_dpcd_write(aux, offset, buffer, size);
+ else
+ ret = drm_dp_dpcd_access(aux, DP_AUX_NATIVE_WRITE, offset,
+buffer, size);
+
drm_dp_dump_access(aux, DP_AUX_NATIVE_WRITE, offset, buffer, ret);
return ret;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #18 from Luya Tshimbalanga (l...@fedoraproject.org) --- Reading another bug report on https://bugzilla.kernel.org/show_bug.cgi?id=204689 taken from amdgfx mailing list, could that issue related? Anyway, radeontop still runs with the patched kernel. No noticeable freeze and I tested with Blender rendering the old Ryzen CPU 3D model with GPU compute running on rocm-opencl (which needs optimization compared to amdgpu-pro-opencl). To Alex, will it possible to prepare the patch in the patchwork.kernel.org? Thanks. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #17 from Luya Tshimbalanga (l...@fedoraproject.org) --- Created attachment 285951 --> https://bugzilla.kernel.org/attachment.cgi?id=285951&action=edit Screenshot of radeontop running with patched kernel Running radeontop with the patched test kernel, I can confirm the patch fixed the freezing issue which no longer occurs as the card is correctly picked up. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #16 from Luya Tshimbalanga (l...@fedoraproject.org) --- Created attachment 285949 --> https://bugzilla.kernel.org/attachment.cgi?id=285949&action=edit amdgpu firmware info Firmware information of amdgpu installed in the testing system -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #15 from Luya Tshimbalanga (l...@fedoraproject.org) --- Created attachment 285947 --> https://bugzilla.kernel.org/attachment.cgi?id=285947&action=edit dmesg from amd raven ridege Ryzen 2500u dmesg showing latest kernel git snapshot -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #235 from Marko Popovic --- (In reply to Alex Deucher from comment #233) > Does attachment 145971 [details] [review] help? No, this is for flip hangs that only happen in some games, random SDMA hangs are still present, but SDMA is disabled in MESA20 so for the timebeing it should be more stable. (In reply to Timur Kristóf from comment #234) > (In reply to John H from comment #227) > > However, I have hard freezes when playing games. A > > specific one I can reproduce EVERY. SINGLE. TIME. was when playing Unreal > > Tournament 3 via Steam proton. > > Sounds like the same, or similar issue as this one: > https://gitlab.freedesktop.org/mesa/mesa/issues/868 > > In that case it was caused by an LLVM bug that has been fixed in LLVM 10 for > a while but haven't made it into LLVM 9 yet. > If you use mesa 19.3 can you try if the same issue occours with ACO? > Radv hangs are not related to SDMA hangs, but luckily at least those are fixed in LLVM10, so we can at least have decently stable experience with AMD_DEBUG=nodma, which is basically enabled by default in MESA 20. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #234 from Timur Kristóf --- (In reply to John H from comment #227) > However, I have hard freezes when playing games. A > specific one I can reproduce EVERY. SINGLE. TIME. was when playing Unreal > Tournament 3 via Steam proton. Sounds like the same, or similar issue as this one: https://gitlab.freedesktop.org/mesa/mesa/issues/868 In that case it was caused by an LLVM bug that has been fixed in LLVM 10 for a while but haven't made it into LLVM 9 yet. If you use mesa 19.3 can you try if the same issue occours with ACO? (In reply to John Smith from comment #225) > Is this seriously what AMD calls "support"? No offense but this is > ridiculous, this card has been out for four months and it still can't even > browse firefox reliably, even after these "workarounds" and "patches". I can symphatize with your frustration, but I don't think this attitude is helpful. Pierre-Eric and Alex are doing their best to solve this problem. Insulting each other in the bugzilla is not constructive and won't bring us closer to the solution. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #233 from Alex Deucher --- Does attachment 145971 help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #31 from MasterCATZ (masterc...@hotmail.com) --- oh I love it they know the drivers file is crap anyhow it looks like the real issue is in the GPU driver fan speeds temps everything is in their , ofcause this would not be an issue if pwm1_enable was NOT STUCK ON AUTO #if 0 /* XXX: need to figure out how to handle this properly */ tmp = RREG32_SMC(ixCG_THERMAL_CTRL); tmp &= DPM_EVENT_SRC_MASK; tmp |= DPM_EVENT_SRC(dpm_event_src); WREG32_SMC(ixCG_THERMAL_CTRL, tmp); #endif -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
Den 16.11.2019 12.57, skrev Emmanuel Vadot: > On Fri, 15 Nov 2019 15:33:46 +0100 > Noralf Trønnes wrote: > >> >> >> Den 15.11.2019 13.34, skrev Ville Syrjälä: >>> On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: Hi Daniel, I don't think we can make any complaints about GPL being more widely used in the DRM code. It's nice to have the code at all, the MIT license is a bonus. Thanks for writing it and bearing with us. Would rewrites done purely for licensing reasons be accepted upstream? >>> >>> Rewrite should be the last resort. I think a lot of the GPL only stuff >>> is quite recent so there's a good chance the author(s) are still around >>> to discuss relicensing. >>> >> >> If someone sends patches to MIT license the work I've done, I'll be >> happy to ack it. It's only recently that I've been aware of the fact >> that MIT licensed was a thing in the kernel. I was under the impression >> that all new code should be GPL and MIT were for code imported from >> elsewhere. I would love to see my work being used on the BSD's. > > And I would love to be able to use your work on FreeBSD :) > I don't really know the rules but shouldn't you send a patch to > relicence ? I don't know the rules either, but I don't think I have to be the author of the relicensing patch, I just have to put my stamp on it. Myself I haven't got the time to do the work, it's not just putting out a patch, everyone having made changes to the affected files would also have to be ok with the new license. Noralf. > Right now for me drm_client (and others) being GPL is a problem for my > update of DRM in FreeBSD so I'm not using it (which is bad and will > probably cause problems). > >> Noralf. >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #30 from MasterCATZ (masterc...@hotmail.com) ---
found them hard coded here for the R9 290 hawaii / Sea Islands chip sets
so that will be a dirty way to get it to go 100% throttle sooner I'll set mine
to 85000 and see how it goes , hopefully the rest follows
linux/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
if (adev->asic_type == CHIP_HAWAII) {
pi->thermal_temp_setting.temperature_low = 94500;
pi->thermal_temp_setting.temperature_high = 95000;
pi->thermal_temp_setting.temperature_shutdown = 104000;
} else {
pi->thermal_temp_setting.temperature_low = 99500;
pi->thermal_temp_setting.temperature_high = 10;
pi->thermal_temp_setting.temperature_shutdown = 104000;
}
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #69 from Jay Fitzpatrick --- Upgraded to 5.3.11-300.fc31.x86_64 this morning with linux-firmware-20191022-103.fc31.noarch and no evidence of regression Jay -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
Hi Daniel, On Tue, 12 Nov 2019 16:03:33 +0100 Daniel Vetter wrote: > Hi all, > > Dave and me chatted about this last week on irc. Essentially we have: > > $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c' > drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0 > drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT > drivers/gpu/drm/drm_dp_cec.c:// SPDX-License-Identifier: GPL-2.0 > drivers/gpu/drm/drm_edid_load.c:// SPDX-License-Identifier: GPL-2.0-or-later > drivers/gpu/drm/drm_fb_cma_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_format_helper.c:/* SPDX-License-Identifier: GPL-2.0 */ > drivers/gpu/drm/drm_gem_cma_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_gem_framebuffer_helper.c:// > SPDX-License-Identifier: GPL-2.0-or-later > drivers/gpu/drm/drm_gem_shmem_helper.c:// SPDX-License-Identifier: GPL-2.0 > drivers/gpu/drm/drm_gem_ttm_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_gem_vram_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_hdcp.c:// SPDX-License-Identifier: GPL-2.0 > drivers/gpu/drm/drm_lease.c:// SPDX-License-Identifier: GPL-2.0-or-later > drivers/gpu/drm/drm_mipi_dbi.c:// SPDX-License-Identifier: GPL-2.0-or-later > drivers/gpu/drm/drm_of.c:// SPDX-License-Identifier: GPL-2.0-only > drivers/gpu/drm/drm_simple_kms_helper.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_sysfs.c:// SPDX-License-Identifier: GPL-2.0-only > drivers/gpu/drm/drm_vma_manager.c:// SPDX-License-Identifier: GPL-2.0 OR MIT > drivers/gpu/drm/drm_vram_helper_common.c:// SPDX-License-Identifier: > GPL-2.0-or-later > drivers/gpu/drm/drm_writeback.c:// SPDX-License-Identifier: GPL-2.0 > > One is GPL+MIT, so ok, and one is a default GPL-only header from > Greg's infamous patch (so could probably be changed to MIT license > header). I only looked at .c sources, since headers are worse wrt > having questionable default headers. So about 18 files with clear GPL > licenses thus far in drm core/helpers. > > Looking at where that code came from, it is mostly from GPL-only > drivers (we have a lot of those nowadays), so seems legit non-MIT > licensed. Question is now what do we do: > > - Nothing, which means GPL will slowly encroach on drm core/helpers, > which is roughly the same as ... > > - Throw in the towel on MIT drm core officially. Same as above, except > lets just make it official. > > - Try to counter this, which means at least a) relicensing a bunch of > stuff b) rewriting a bunch of stuff c) making sure that's ok with > everyone, there's a lot of GPL-by-default for the kernel (that's how > we got most of the above code through merged drivers I think). I > suspect that whomever cares will need to put in the work to make this > happen (since it will need a pile of active resistance at least). > > Cc maintainers/driver teams who might care most about this. > > Also if people could cc *bsd, they probably care and I don't know best > contacts for graphics stuff (or anything else really at all). > > Cheers, Daniel First of all thanks for sending this mail. I'm of course not speaking for the whole FreeBSD project but being one of the persons that is currently trying to finish a clean update of DRM for it to finally have DRM drivers for arm/arm64 here is my view : I would love to have all the helper MIT or dual licence so I don't need to comment part of DRM code (which is ok on some part but wrong on most) or re-implement them. There is already too much code that really need a rewrite for FreeBSD (dma-bufs, syncobjs and a lot of others linux kernel subsystems) that adding drm helpers to the list makes it really hard for me. From the list you've send here are the most problematic files for me, for now I've simply not import them and hack around the code that calls functions from them : drivers/gpu/drm/drm_client.c It's now really tied into the drm subsystem so it's hard to ignore it, for now not merging the latest patches from 5.4 makes it ok-ish to ignore it. drivers/gpu/drm/drm_lease.c I can hack around it but I would prefer to include it and stop my hacks. drivers/gpu/drm/drm_format_helper.c a lot of helpers are here and needed, for now I'm using the old functions that were MIT licenced but it's kinda wrong to do it this way. For the gem_cma/gem_framebuffer/gem_etc ... we have our own implementation when we need one, those file are too close to the vm subsystem to be portable anyway so I don't really care if they stay GPLed. For the rest of the files either I don't want them (_sysfs and _of for example) because it don't make sense for us to have them (sysfs) or the subsystem is too different between FreeBSD-Linux (of) or I the current drivers that we have don't need them for now (writeback, hdcp etc ...) To finish this mail, I'd like to say that I would love to contribute to DRM and some drivers (lima/panfrost mostly)
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #29 from MasterCATZ (masterc...@hotmail.com) ---
from what I can work out the only difference between the kernel versions
was they added extra thermal readings to support the newer cards with thermal
junction sensors
{-273150, 99000},
{ 12, 12},
has been in their since Jan 2018 ...
looks like its reading the max temp settings from the bios
I will confirm this tomorrow I will flash a custom bios
/torvalds/linux/blob/master/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
/* The temperature, in 0.01 centigrades, below which we just run at a minimal
PWM. */
so maybe it is thinking it can do 1000C ?
anyhow as I don't want to run an altered bios as that would force fan 100% on
boot , what I decided to do was rip out all of AMD's new thermal code ...
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm core/helpers and MIT license
On Fri, 15 Nov 2019 15:33:46 +0100 Noralf Trønnes wrote: > > > Den 15.11.2019 13.34, skrev Ville Syrjälä: > > On Thu, Nov 14, 2019 at 08:01:32PM +, co...@sdf.org wrote: > >> Hi Daniel, > >> > >> I don't think we can make any complaints about GPL being more widely > >> used in the DRM code. It's nice to have the code at all, the MIT license > >> is a bonus. Thanks for writing it and bearing with us. > >> > >> Would rewrites done purely for licensing reasons be accepted upstream? > > > > Rewrite should be the last resort. I think a lot of the GPL only stuff > > is quite recent so there's a good chance the author(s) are still around > > to discuss relicensing. > > > > If someone sends patches to MIT license the work I've done, I'll be > happy to ack it. It's only recently that I've been aware of the fact > that MIT licensed was a thing in the kernel. I was under the impression > that all new code should be GPL and MIT were for code imported from > elsewhere. I would love to see my work being used on the BSD's. And I would love to be able to use your work on FreeBSD :) I don't really know the rules but shouldn't you send a patch to relicence ? Right now for me drm_client (and others) being GPL is a problem for my update of DRM in FreeBSD so I'm not using it (which is bad and will probably cause problems). > Noralf. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Emmanuel Vadot ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112266] [Navi] Pathfinder: Kingmaker is causing a GPU hang: flip_done timed out error
https://bugs.freedesktop.org/show_bug.cgi?id=112266 --- Comment #9 from Jan Kowalski <5lac7w...@protonmail.com> --- I had this bug on tested kernels: 5.3.8, 5.3.9, 5.4.0-rc6, 5.4.0-rc7. I can confirm hangs occurred, when the cursor was moved after some time of inactivity (10-60 sec, depending on kernel version. 5.4.0-rc6 was the worst) in Firefox when watching fullscreen video (excluding 5.4.0-rc7), or in games. This bug was accompanied by another one - sluggish cursor, in 5.3 line with screen flickering at the cursor position, in 5.4 line barely visible, occurring every few seconds but without screen flickering, and feels inaccurate. I added this patch https://bugs.freedesktop.org/attachment.cgi?id=145971 on top of 5.4.0-rc7 and hangs are gone (thanks), but laggy cursor is still there. Sapphire Pulse RX 5700 XT Dell U2311Hb, 1920x1080 60.00Hz Kernel: 5.4.0-rc7 Mesa: 19.3.0-rc2 llvm: 9.0.0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205309] kmemleak reports various leaks in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=205309 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Resolution|OBSOLETE|MOVED --- Comment #4 from Erhard F. (erhar...@mailbox.org) --- Ok, closing this bug was a bit too early... Just got some leaks in. Moved to https://bugs.freedesktop.org/show_bug.cgi?id=112302 (as I can select component DRM/AMDgpu here which seems more appropriate) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112302] [kernel 5.4-rc7][amdgpu] kmemleak reports various leaks
https://bugs.freedesktop.org/show_bug.cgi?id=112302 --- Comment #2 from erhar...@mailbox.org --- Created attachment 145974 --> https://bugs.freedesktop.org/attachment.cgi?id=145974&action=edit kernel .config (kernel 5.4-rc7) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112302] [kernel 5.4-rc7][amdgpu] kmemleak reports various leaks
https://bugs.freedesktop.org/show_bug.cgi?id=112302 Bug ID: 112302 Summary: [kernel 5.4-rc7][amdgpu] kmemleak reports various leaks Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: erhar...@mailbox.org Created attachment 145972 --> https://bugs.freedesktop.org/attachment.cgi?id=145972&action=edit cat /sys/kernel/debug/kmemleak [ 1306.389652] kmemleak: 28 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Running X I get various kmemleak dumps for amdgpu: [...] unreferenced object 0xa2501f3374c0 (size 208): comm "Xorg", pid 694, jiffies 4294885609 (age 1870.427s) hex dump (first 32 bytes): 50 75 33 1f 50 a2 ff ff a0 41 47 c0 ff ff ff ff Pu3.PAG. b6 d7 06 a0 06 00 00 00 48 fe aa 8c b5 b1 ff ff H... backtrace: [<502b8475>] drm_sched_fence_create+0x1d/0xc0 [gpu_sched] [<67f89939>] drm_sched_job_init+0x5b/0xa0 [gpu_sched] [<97e803db>] amdgpu_job_submit+0x1e/0x90 [amdgpu] [<8af66624>] amdgpu_copy_buffer+0x1ab/0x290 [amdgpu] [<5723dc17>] amdgpu_ttm_copy_mem_to_mem+0x25b/0x540 [amdgpu] [<9372cf45>] amdgpu_move_blit.constprop.0+0x85/0x1b0 [amdgpu] [] amdgpu_bo_move+0x168/0x2b0 [amdgpu] [<9f1ae718>] ttm_bo_handle_move_mem+0x126/0x5c0 [ttm] [ ] ttm_bo_validate+0x174/0x1b0 [ttm] [<812e63d8>] amdgpu_bo_fault_reserve_notify+0xe2/0x130 [amdgpu] [<340ebb51>] ttm_bo_vm_fault+0xa7/0x650 [ttm] [ ] __do_fault+0x31/0xf0 [<8cecfe93>] __handle_mm_fault+0xccc/0x1390 [<984b2f55>] handle_mm_fault+0x15b/0x2f0 [<53ca6a37>] __do_page_fault+0x1a2/0x420 [ ] page_fault+0x31/0x40 unreferenced object 0xa24c4471b040 (size 72): comm "sdma0", pid 402, jiffies 4294885609 (age 1870.427s) hex dump (first 32 bytes): a0 c7 36 59 4c a2 ff ff e0 95 fd c0 ff ff ff ff ..6YL... a4 2b 08 a0 06 00 00 00 58 e4 2a 61 50 a2 ff ff .+..X.*aP... backtrace: [<78aa5208>] amdgpu_fence_emit+0x2b/0x270 [amdgpu] [ ] amdgpu_ib_schedule+0x311/0x540 [amdgpu] [<4db3d964>] amdgpu_job_run+0xfc/0x1e0 [amdgpu] [ ] drm_sched_main+0xf7/0x2e0 [gpu_sched] [ ] kthread+0xf6/0x130 [<46d81882>] ret_from_fork+0x27/0x50 [...] -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112302] [kernel 5.4-rc7][amdgpu] kmemleak reports various leaks
https://bugs.freedesktop.org/show_bug.cgi?id=112302 --- Comment #1 from erhar...@mailbox.org --- Created attachment 145973 --> https://bugs.freedesktop.org/attachment.cgi?id=145973&action=edit dmesg (kernel 5.4-rc7) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205309] kmemleak reports various leaks in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=205309 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #3 from Erhard F. (erhar...@mailbox.org) --- Does not happen with 5.4-rc7. Seems fixed now. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
