[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games or after extended periods of time
https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #5 from Jean-Fran�ois Fortin Tam --- And it's not triggered by Chromium/Epiphany/Firefox, it happens with just a GNOME desktop sitting around in my case. Clearly, something is just FUBAR in the radeon driver or recent Linux kernels... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160305/9021d84e/attachment.html>
[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games or after extended periods of time
https://bugs.freedesktop.org/show_bug.cgi?id=93341 Jean-Fran�ois Fortin Tam changed: What|Removed |Added Summary|GPU lockups on RadeonHD |GPU lockups on RadeonHD |7770 (radeonsi driver) when |7770 (radeonsi driver) when |running OpenGL games|running OpenGL games or ||after extended periods of ||time --- Comment #4 from Jean-Fran�ois Fortin Tam --- Happened to me again today after 1 day and 22 hours of uptime, with the computer just sitting around, idle, with the screen turned of. It can sometimes happen after 6 days, sometimes 1-2 days... doesn't matter what you're doing or not. At least this time I've been able to eliminate "suspend/resume" from the list of potential causes, as the computer was set to never sleep. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160305/4395670b/attachment.html>
Oops (NULL pointer dereference) in radeon_fence_ref in 3.14.63
Hi Lutz, just an educated guess, but I think the problem is simply that kernel 3.14 doesn't yet contain the code so that radeon_fence_get() can safely called with a NULL pointer. So the backport of Nicolai's patch needs and extra check for the case when the fence is NULL. Regards, Christian. Am 05.03.2016 um 18:16 schrieb Lutz Euler: > Hi, > > after upgrading from kernel 3.14.62 to 3.14.63, while surfing, the > screen suddenly got black and the mouse cursor froze. I had to reset > the machine and found an oops followed by repeated messages > "BUG: scheduling while atomic: Xorg/3757/0x0002" in the logs. > I have copied the oops and the first of these messages below. > > This was repeatable: After the reboot, when the browser restored its > tabs, the oops occurred again. I then rebooted into 3.14.62 and the > problem didn't occur again. > > Just guessing: Of the commits regarding radeon between these two > kernel versions might the following be involved > > Nicolai Hähnle (1): >drm/radeon: hold reference to fences in radeon_sa_bo_new > > as it mentions fences and the stack trace starts with radeon_sa_bo_new? > > Thanks and Regards, > > Lutz > > From lspci -v: > > 05:00.0 VGA compatible controller: ATI Technologies Inc NI Caicos [AMD RADEON > HD 6450] (prog-if 00 [VGA controller]) > Subsystem: PC Partner Limited Device e164 > Flags: bus master, fast devsel, latency 0, IRQ 53 > Memory at d000 (64-bit, prefetchable) [size=256M] > Memory at fe9e (64-bit, non-prefetchable) [size=128K] > I/O ports at e000 [size=256] > Expansion ROM at fe9c [disabled] [size=128K] > Capabilities: [50] Power Management version 3 > Capabilities: [58] Express Legacy Endpoint, MSI 00 > Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 > > Capabilities: [150] Advanced Error Reporting > Kernel driver in use: radeon > Kernel modules: radeon > > X.Org version: 1.10.4 > > decodecode of the oops: > > Mar 5 15:04:58 lutz kernel: [ 6995.216776] Code: c7 c6 d8 3e 36 a0 31 c0 45 > 31 e4 e8 7b 70 15 e1 eb b5 66 0f 1f 84 00 00 00 00 00 55 48 89 f8 ba 01 00 00 > 00 48 89 e5 48 83 ec 10 0f c1 57 08 ff c2 ff ca 7e 02 c9 c3 80 3d 10 ae > 10 00 01 74 > All code > > 0:c7 c6 d8 3e 36 a0 mov$0xa0363ed8,%esi > 6:31 c0 xor%eax,%eax > 8:45 31 e4xor%r12d,%r12d > b:e8 7b 70 15 e1 callq 0xe115708b >10:eb b5 jmp0xffc7 >12:66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1) >19:00 00 >1b:55 push %rbp >1c:48 89 f8mov%rdi,%rax >1f:ba 01 00 00 00 mov$0x1,%edx >24:48 89 e5mov%rsp,%rbp >27:48 83 ec 10 sub$0x10,%rsp >2b:* f0 0f c1 57 08 lock xadd %edx,0x8(%rdi) > <-- trapping instruction >30:ff c2 inc%edx >32:ff ca dec%edx >34:7e 02 jle0x38 >36:c9 leaveq >37:c3 retq >38:80 3d 10 ae 10 00 01cmpb $0x1,0x10ae10(%rip)# > 0x10ae4f >3f:74 .byte 0x74 > > Code starting with the faulting instruction > === > 0:f0 0f c1 57 08 lock xadd %edx,0x8(%rdi) > 5:ff c2 inc%edx > 7:ff ca dec%edx > 9:7e 02 jle0xd > b:c9 leaveq > c:c3 retq > d:80 3d 10 ae 10 00 01cmpb $0x1,0x10ae10(%rip)# > 0x10ae24 >14:74 .byte 0x74 > > Mar 5 15:04:58 lutz kernel: [ 6995.192330] BUG: unable to handle kernel NULL > pointer dereference at 0008 > Mar 5 15:04:58 lutz kernel: [ 6995.192375] IP: [] > radeon_fence_ref+0x10/0x50 [radeon] > Mar 5 15:04:58 lutz kernel: [ 6995.192441] PGD 22a86a067 PUD 22d8e8067 PMD 0 > Mar 5 15:04:58 lutz kernel: [ 6995.192463] Oops: 0002 [#1] PREEMPT SMP > Mar 5 15:04:58 lutz kernel: [ 6995.192484] Modules linked in: binfmt_misc > parport_pc ppdev snd_hda_codec_hdmi snd_opl3_synth snd_seq_midi_emul > snd_hda_intel snd_hda_codec snd_es1938 gameport snd_pcm_oss snd_mixer_oss > snd_seq_dummy snd_pcm snd_seq_oss snd_opl3_lib snd_hwdep snd_mpu401_uart > snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq psmouse fbcon tileblit > edac_core font serio_raw i2c_piix4 bitblit softcursor radeon snd_seq_device > snd_timer hwmon_vid ttm drm_kms_helper asus_atk0110 drm i2c_algo_bit snd >
[pull] radeon and amdgpu drm-next-4.6
On 03.03.2016 15:15, Alex Deucher wrote: > > Some more radeon and amdgpu stuff for drm-next. Mostly just bug fixes > for new features and cleanups. Please also include Daniel Vetter's changes switching to drm_vblank_on/off: https://lists.freedesktop.org/archives/dri-devel/2016-January/099159.html https://lists.freedesktop.org/archives/dri-devel/2016-January/099160.html (with dce_v8_0.c added) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro
On Sat, 2016-03-05 at 15:16 +0100, Lukas Wunner wrote: > Hi Bastien, > > On Fri, Mar 04, 2016 at 04:12:27PM +, Bastien Nocera wrote: > > > > Lukas Wunner wunner.de> writes: > > > > > > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), > > > v5. > > I've tested your patchset on a MacBookPro8,1, with an integrated > > Intel and > > discrete AMD/ATI GPUs. > Hm, it must be either an 8,2 or 8,3. The 8,1 was a 13" machine and > only > had an integrated GPU. On the 8,2, still, and with the kernel from the COPR repo[1]. I tried running: echo DIGD > switch to (later) switch to the integrated GPU. Log out, get to gdm, log back in to a black screen with the cursor visible and nothing else. I'm wondering if it's the gdm X11 session running in the background that makes this fail. I'd like to try and get this working properly before bringing the runtime PM support into it. [1]: That's the list of patches in the kernel: http://copr-dist-git.fedorainfracloud.org/cgit/firstyear/kernel-mbp/kernel.git/tree/
Oops (NULL pointer dereference) in radeon_fence_ref in 3.14.63
Hi, after upgrading from kernel 3.14.62 to 3.14.63, while surfing, the screen suddenly got black and the mouse cursor froze. I had to reset the machine and found an oops followed by repeated messages "BUG: scheduling while atomic: Xorg/3757/0x0002" in the logs. I have copied the oops and the first of these messages below. This was repeatable: After the reboot, when the browser restored its tabs, the oops occurred again. I then rebooted into 3.14.62 and the problem didn't occur again. Just guessing: Of the commits regarding radeon between these two kernel versions might the following be involved Nicolai Hähnle (1): drm/radeon: hold reference to fences in radeon_sa_bo_new as it mentions fences and the stack trace starts with radeon_sa_bo_new? Thanks and Regards, Lutz >From lspci -v: 05:00.0 VGA compatible controller: ATI Technologies Inc NI Caicos [AMD RADEON HD 6450] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e164 Flags: bus master, fast devsel, latency 0, IRQ 53 Memory at d000 (64-bit, prefetchable) [size=256M] Memory at fe9e (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at fe9c [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon Kernel modules: radeon X.Org version: 1.10.4 decodecode of the oops: Mar 5 15:04:58 lutz kernel: [ 6995.216776] Code: c7 c6 d8 3e 36 a0 31 c0 45 31 e4 e8 7b 70 15 e1 eb b5 66 0f 1f 84 00 00 00 00 00 55 48 89 f8 ba 01 00 00 00 48 89 e5 48 83 ec 10 0f c1 57 08 ff c2 ff ca 7e 02 c9 c3 80 3d 10 ae 10 00 01 74 All code 0: c7 c6 d8 3e 36 a0 mov$0xa0363ed8,%esi 6: 31 c0 xor%eax,%eax 8: 45 31 e4xor%r12d,%r12d b: e8 7b 70 15 e1 callq 0xe115708b 10: eb b5 jmp0xffc7 12: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1) 19: 00 00 1b: 55 push %rbp 1c: 48 89 f8mov%rdi,%rax 1f: ba 01 00 00 00 mov$0x1,%edx 24: 48 89 e5mov%rsp,%rbp 27: 48 83 ec 10 sub$0x10,%rsp 2b:* f0 0f c1 57 08 lock xadd %edx,0x8(%rdi)<-- trapping instruction 30: ff c2 inc%edx 32: ff ca dec%edx 34: 7e 02 jle0x38 36: c9 leaveq 37: c3 retq 38: 80 3d 10 ae 10 00 01cmpb $0x1,0x10ae10(%rip)# 0x10ae4f 3f: 74 .byte 0x74 Code starting with the faulting instruction === 0: f0 0f c1 57 08 lock xadd %edx,0x8(%rdi) 5: ff c2 inc%edx 7: ff ca dec%edx 9: 7e 02 jle0xd b: c9 leaveq c: c3 retq d: 80 3d 10 ae 10 00 01cmpb $0x1,0x10ae10(%rip)# 0x10ae24 14: 74 .byte 0x74 Mar 5 15:04:58 lutz kernel: [ 6995.192330] BUG: unable to handle kernel NULL pointer dereference at 0008 Mar 5 15:04:58 lutz kernel: [ 6995.192375] IP: [] radeon_fence_ref+0x10/0x50 [radeon] Mar 5 15:04:58 lutz kernel: [ 6995.192441] PGD 22a86a067 PUD 22d8e8067 PMD 0 Mar 5 15:04:58 lutz kernel: [ 6995.192463] Oops: 0002 [#1] PREEMPT SMP Mar 5 15:04:58 lutz kernel: [ 6995.192484] Modules linked in: binfmt_misc parport_pc ppdev snd_hda_codec_hdmi snd_opl3_synth snd_seq_midi_emul snd_hda_intel snd_hda_codec snd_es1938 gameport snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_pcm snd_seq_oss snd_opl3_lib snd_hwdep snd_mpu401_uart snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq psmouse fbcon tileblit edac_core font serio_raw i2c_piix4 bitblit softcursor radeon snd_seq_device snd_timer hwmon_vid ttm drm_kms_helper asus_atk0110 drm i2c_algo_bit snd soundcore lp parport usbhid btrfs raid6_pq zlib_deflate xor r8169 mii xhci_hcd libcrc32c Mar 5 15:04:58 lutz kernel: [ 6995.192741] CPU: 5 PID: 3757 Comm: Xorg Not tainted 3.14.63 #1 Mar 5 15:04:58 lutz kernel: [ 6995.192765] Hardware name: System manufacturer System Product Name/M4A87TD/USB3, BIOS 120202/17/2011 Mar 5 15:04:58 lutz kernel: [ 6995.192803] task: 88022c1d5f80 ti: 8800c42a6000 task.ti: 8800c42a6000 Mar 5 15:04:58 lutz kernel: [ 6995.192833] RIP: 0010:[] [] radeon_fence_ref+0x10/0x50 [radeon] Mar 5 15:04:58 lutz kernel: [ 6995.192881] RSP: 0018:8800c42a7a68 EFLAGS: 00010282 Mar 5 15:04:58 lutz kernel: [ 6995.192903]
[Bug 94405] mesa hang GPU
https://bugs.freedesktop.org/show_bug.cgi?id=94405 --- Comment #1 from Lorenzo Bona --- Created attachment 122117 --> https://bugs.freedesktop.org/attachment.cgi?id=122117=edit mesa build script -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160305/be968421/attachment.html>
[Bug 94405] mesa hang GPU
https://bugs.freedesktop.org/show_bug.cgi?id=94405 Bug ID: 94405 Summary: mesa hang GPU Product: Mesa Version: 11.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: lorenz.bona at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 122116 --> https://bugs.freedesktop.org/attachment.cgi?id=122116=edit git bisect log Hi, mesa crash as soon as I start xorg with 'startx' from tty1. I can see the mouse coursor in the middle of a black screen. After a few seconds the tty1 appears back, the message tells me that my GPU hangs for seconds. I tried to bisect this and you can see the result attached. I've also attached my mesa build script. My GPU is a R7-265 pitcairn, running Debian sid, with mesa/xorg/drm/kernel from git. LLVM 3.8 is at revision: 257294. I'm usign LXqt+openbox from debian sid. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160305/1570ddbb/attachment-0001.html>
[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro
On Sat, 2016-03-05 at 15:16 +0100, Lukas Wunner wrote: > Hi Bastien, > > On Fri, Mar 04, 2016 at 04:12:27PM +, Bastien Nocera wrote: > > > > Lukas Wunner wunner.de> writes: > > > > > > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), > > > v5. > > I've tested your patchset on a MacBookPro8,1, with an integrated > > Intel and > > discrete AMD/ATI GPUs. > Hm, it must be either an 8,2 or 8,3. The 8,1 was a 13" machine and > only > had an integrated GPU. Sorry, it's an "8,2". That's what I get for having not having my mail on that machine. > > > > I've used the COPR repository here to cut down on my compilation > > time: > > https://copr.fedorainfracloud.org/coprs/firstyear/kernel-mbp/ > > > > I'm not certain how to test out your changes, or what the > > consequences should > > be on a stock Fedora 23/GNOME 3.18 installation. After booting > > (note that I > > did not change any command-line options in grub), a gnome-shell/gdm > > X11 > > session comes up (I disabled Wayland, to rule out behavioural > > changes), I'd > > log in to GNOME and gnome-shell (which starts another X11 session > > on > > another VT). > Switching and power control currently requires manual intervention > by echoing commands to /sys/kernel/debug/vgaswitcheroo/switch > as documented here: > https://01.org/linuxgraphics/gfx-docs/drm/modes_of_use.html Right, though I would intend on automating this. > As you've correctly observed, the machine is initially switched to > the discrete GPU and both GPUs are turned on. By echoing "IGD" to > the sysfs file, you'll switch to the integrated GPU and turn off > the discrete GPU. > > It's possible to let the EFI firmware switch to the integrated GPU > on boot by using this tool: https://github.com/0xbb/gpu-switch > However still both GPUs will be powered up, so you have to issue > the "OFF" command to sysfs to power the discrete GPU down. Also, > once you boot into OS X, the setting made by the gpu-switch tool > will be overwritten and the machine will be switched to the discrete > GPU again the next time you boot Linux. We could, on boot, force using the integrated GPU, turning off the discrete GPU that we're not interested in. So I'd push DIGD to the switch sysfs entry on boot. But I'm guessing that won't turn off the other output we're not interested in. > Note that switching is only possible from the text console, with > X11/Wayland shut down. Obviously this is not great in terms of UX. > A few years ago there was a GSoC proposal to get hot GPU switching > to work on Linux (akin to what OS X does) but nothing ever came of > it: > http://www.phoronix.com/scan.php?page=news_item=OTIyMQ > https://lists.x.org/archives/xorg/2011-March/052522.html > > Unfortunately this seems to be a low priority item for kernel > graphics > developers since nowadays most dual GPU notebooks no longer have a > mux > and cannot switch. The MacBook Pro seems to be the last one > supporting > this but I've witnessed a bit of an anti-Apple sentiment among kernel > graphics developers since everything is non-standard there. Which is > unfortunate because these machines have a large market share and > Apple > software quality is deteriorating rapidly so a lot of Mac users are > ripe for converting to Linux. DIGD and DDIS should help (you need to log out/log in again), and if the current GPU is the integrated one, you could force running, say, a game on the discrete GPU using DRI_PRIME=1, correct? FWIW, using OFF at runtime made my machine hang, and without any ways for me to get debug output. > Anyway, one short-term improvement will be to add runtime pm support > (called "Driver power control" in the vga_switcheroo documentation > linked above). That way it'll no longer be necessary to power the > discrete GPU up and down manually, this will happen automatically > as needed (when switching or using render offloading with DRI PRIME). Ok, so using GIGD or DDIS would just switch the output, but not turn off the unused GPU without runtime PM management. > I have patches to enable this for radeon but they're completely > untested: > > http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz       => gpu switching > for 4.5 That's the same patch that's already applied to the kernel above (the ones from this patchset thread), right? > http://wunner.de/mbp_switcheroo_v5-4.5-runpm.tar.gz => runtime pm for > radeon OK, will test those out. > I have an Nvidia based machine and runtime pm doesn't work there yet > because of bugs in nouveau that I haven't had the time to look into. > > > > > > I did not use any external screens to test this. > Since your machine has Thunderbolt, the external port is no longer > switchable between GPUs, it can only be driven by the discrete GPU. > So you need to power it up manually for this to work. You don't need > to switch to it, but it's probably recommendable to save energy. > (Otherwise both GPUs are on with the integrated GPU driving the panel > and
[PATCH 1/2] drm/amdgpu: Fix error handling in amdgpu_flip_work_func.
On 02.03.2016 05:31, Mario Kleiner wrote: > The patch e1d09dc0ccc6: "drm/amdgpu: Don't hang in > amdgpu_flip_work_func on disabled crtc." from Feb 19, 2016, leads to > the following static checker warning, as reported by Dan Carpenter in > https://lists.freedesktop.org/archives/dri-devel/2016-February/101987.html > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:127 amdgpu_flip_work_func() > warn: should this be 'repcnt == -1' > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() > error: double unlock 'spin_lock:>dev->event_lock' > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() > error: double unlock 'irqsave:flags' > > This patch fixes both reported problems: > > Change post-decrement of repcnt to pre-decrement, so > it can't underflow anymore, but still performs up to > three repetitions - three is the maximum one could > expect in practice. > > Move the spin_unlock_irqrestore to where it actually > belongs. > > Reported-by: Dan Carpenter > Signed-off-by: Mario Kleiner > Cc: # 4.4+ > Cc: Michel Dänzer > Cc: Alex Deucher Both patches are Reviewed-by: Michel Dänzer Alex, these should go into 4.5 if at all possible. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro
Hi Bastien, On Fri, Mar 04, 2016 at 04:12:27PM +, Bastien Nocera wrote: > Lukas Wunner wunner.de> writes: > > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. > > I've tested your patchset on a MacBookPro8,1, with an integrated Intel and > discrete AMD/ATI GPUs. Hm, it must be either an 8,2 or 8,3. The 8,1 was a 13" machine and only had an integrated GPU. > I've used the COPR repository here to cut down on my compilation time: > https://copr.fedorainfracloud.org/coprs/firstyear/kernel-mbp/ > > I'm not certain how to test out your changes, or what the consequences should > be on a stock Fedora 23/GNOME 3.18 installation. After booting (note that I > did not change any command-line options in grub), a gnome-shell/gdm X11 > session comes up (I disabled Wayland, to rule out behavioural changes), I'd > log in to GNOME and gnome-shell (which starts another X11 session on > another VT). Switching and power control currently requires manual intervention by echoing commands to /sys/kernel/debug/vgaswitcheroo/switch as documented here: https://01.org/linuxgraphics/gfx-docs/drm/modes_of_use.html As you've correctly observed, the machine is initially switched to the discrete GPU and both GPUs are turned on. By echoing "IGD" to the sysfs file, you'll switch to the integrated GPU and turn off the discrete GPU. It's possible to let the EFI firmware switch to the integrated GPU on boot by using this tool: https://github.com/0xbb/gpu-switch However still both GPUs will be powered up, so you have to issue the "OFF" command to sysfs to power the discrete GPU down. Also, once you boot into OS X, the setting made by the gpu-switch tool will be overwritten and the machine will be switched to the discrete GPU again the next time you boot Linux. Note that switching is only possible from the text console, with X11/Wayland shut down. Obviously this is not great in terms of UX. A few years ago there was a GSoC proposal to get hot GPU switching to work on Linux (akin to what OS X does) but nothing ever came of it: http://www.phoronix.com/scan.php?page=news_item=OTIyMQ https://lists.x.org/archives/xorg/2011-March/052522.html Unfortunately this seems to be a low priority item for kernel graphics developers since nowadays most dual GPU notebooks no longer have a mux and cannot switch. The MacBook Pro seems to be the last one supporting this but I've witnessed a bit of an anti-Apple sentiment among kernel graphics developers since everything is non-standard there. Which is unfortunate because these machines have a large market share and Apple software quality is deteriorating rapidly so a lot of Mac users are ripe for converting to Linux. Anyway, one short-term improvement will be to add runtime pm support (called "Driver power control" in the vga_switcheroo documentation linked above). That way it'll no longer be necessary to power the discrete GPU up and down manually, this will happen automatically as needed (when switching or using render offloading with DRI PRIME). I have patches to enable this for radeon but they're completely untested: http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz => gpu switching for 4.5 http://wunner.de/mbp_switcheroo_v5-4.5-runpm.tar.gz => runtime pm for radeon I have an Nvidia based machine and runtime pm doesn't work there yet because of bugs in nouveau that I haven't had the time to look into. > I did not use any external screens to test this. Since your machine has Thunderbolt, the external port is no longer switchable between GPUs, it can only be driven by the discrete GPU. So you need to power it up manually for this to work. You don't need to switch to it, but it's probably recommendable to save energy. (Otherwise both GPUs are on with the integrated GPU driving the panel and the discrete GPU driving the DP port.) The runpm tarball linked above contains a patch to automatically wake the discrete GPU on hotplug. I've heard that the AMD GPU is picky about external monitors and doesn't recognize them unless they're plugged in at exactly the right moment, so you may need to retry a couple of times until it works. Best regards, Lukas
[PATCH] drm/gma500: Make mdfld_dsi_connector_dpms() return a value
* Ingo Molnar wrote: > as we have this in Makefile: > > # enforce correct pointer usage > KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types) Sorry, never mind - this is a recent commit that is not upstream. So there's no upstream build regression. Thanks, Ingo
[PATCH] drm/gma500: Make mdfld_dsi_connector_dpms() return a value
* Patrik Jakobsson wrote: > Hi Daniel, > > A patch to fix this is already merged into drm-misc: > > commit db9b60400f9253c25ae639797df2d0ff7a35d9d8 > Author: Sudip Mukherjee > Date: Tue Feb 2 11:35:55 2016 +0530 > > drm/gma500: remove helper function > > We were getting build warning about: > drivers/gpu/drm/gma500/mdfld_dsi_output.c:407:2: warning: initialization > from incompatible pointer type This should really be in drm-fixes, as this bug is now triggering an upstream allyesconfig build failure: drivers/gpu/drm/gma500/mdfld_dsi_output.c:407:39: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] as we have this in Makefile: # enforce correct pointer usage KBUILD_CFLAGS += $(call cc-option,-Werror=incompatible-pointer-types) Thanks, Ingo
[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro
On Sat, Mar 5, 2016 at 9:16 AM, Lukas Wunner wrote: > Hi Bastien, > > On Fri, Mar 04, 2016 at 04:12:27PM +, Bastien Nocera wrote: >> Lukas Wunner wunner.de> writes: >> > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. >> >> I've tested your patchset on a MacBookPro8,1, with an integrated Intel and >> discrete AMD/ATI GPUs. > > Hm, it must be either an 8,2 or 8,3. The 8,1 was a 13" machine and only > had an integrated GPU. > > >> I've used the COPR repository here to cut down on my compilation time: >> https://copr.fedorainfracloud.org/coprs/firstyear/kernel-mbp/ >> >> I'm not certain how to test out your changes, or what the consequences should >> be on a stock Fedora 23/GNOME 3.18 installation. After booting (note that I >> did not change any command-line options in grub), a gnome-shell/gdm X11 >> session comes up (I disabled Wayland, to rule out behavioural changes), I'd >> log in to GNOME and gnome-shell (which starts another X11 session on >> another VT). > > Switching and power control currently requires manual intervention > by echoing commands to /sys/kernel/debug/vgaswitcheroo/switch > as documented here: > https://01.org/linuxgraphics/gfx-docs/drm/modes_of_use.html > > As you've correctly observed, the machine is initially switched to > the discrete GPU and both GPUs are turned on. By echoing "IGD" to > the sysfs file, you'll switch to the integrated GPU and turn off > the discrete GPU. > > It's possible to let the EFI firmware switch to the integrated GPU > on boot by using this tool: https://github.com/0xbb/gpu-switch > However still both GPUs will be powered up, so you have to issue > the "OFF" command to sysfs to power the discrete GPU down. Also, > once you boot into OS X, the setting made by the gpu-switch tool > will be overwritten and the machine will be switched to the discrete > GPU again the next time you boot Linux. > > Note that switching is only possible from the text console, with > X11/Wayland shut down. Obviously this is not great in terms of UX. > A few years ago there was a GSoC proposal to get hot GPU switching > to work on Linux (akin to what OS X does) but nothing ever came of it: > http://www.phoronix.com/scan.php?page=news_item=OTIyMQ > https://lists.x.org/archives/xorg/2011-March/052522.html > > Unfortunately this seems to be a low priority item for kernel graphics > developers since nowadays most dual GPU notebooks no longer have a mux > and cannot switch. The MacBook Pro seems to be the last one supporting > this but I've witnessed a bit of an anti-Apple sentiment among kernel > graphics developers since everything is non-standard there. Which is > unfortunate because these machines have a large market share and Apple > software quality is deteriorating rapidly so a lot of Mac users are > ripe for converting to Linux. Is there any reason to make use of the mux? The usage model and amount of stack work for non-mux systems is a lot easier to deal with and covers a lot more systems overall. runtime pm generally works pretty seemlessly for mux-less systems. Properly handling the mux is a lot of work for relatively little gain as there are very few systems that use them. > > Anyway, one short-term improvement will be to add runtime pm support > (called "Driver power control" in the vga_switcheroo documentation > linked above). That way it'll no longer be necessary to power the > discrete GPU up and down manually, this will happen automatically > as needed (when switching or using render offloading with DRI PRIME). > I have patches to enable this for radeon but they're completely untested: > > http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz => gpu switching for 4.5 > http://wunner.de/mbp_switcheroo_v5-4.5-runpm.tar.gz => runtime pm for radeon > > I have an Nvidia based machine and runtime pm doesn't work there yet > because of bugs in nouveau that I haven't had the time to look into. > > >> I did not use any external screens to test this. > > Since your machine has Thunderbolt, the external port is no longer > switchable between GPUs, it can only be driven by the discrete GPU. > So you need to power it up manually for this to work. You don't need > to switch to it, but it's probably recommendable to save energy. > (Otherwise both GPUs are on with the integrated GPU driving the panel > and the discrete GPU driving the DP port.) > > The runpm tarball linked above contains a patch to automatically > wake the discrete GPU on hotplug. > > I've heard that the AMD GPU is picky about external monitors and > doesn't recognize them unless they're plugged in at exactly the > right moment, so you may need to retry a couple of times until it > works. > Are talking about some issue specific to these muxed apple systems or in general? If you are having issues, please file a bug. Alex
[PATCH] staging/android: add flags member to sync ioctl structs
Hi Greg, Allow me to chip in as well. On 3 March 2016 at 16:17, Greg Kroah-Hartman wrote: > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote: >> From: Gustavo Padovan >> >> Play safe and add flags member to all structs. So we don't need to >> break API or create new IOCTL in the future if new features that requires >> flags arises. >> >> v2: check if flags are valid (zero, in this case) >> >> v3: return -EINVAL if flags are not zero'ed >> >> v4: add padding for 64-bit alignment >> >> v5: rebase to use only stacked sync_file_info > > Why are these vX things here in the changelog? > > And you just broke all existing userspace users of this code, why are > you allowed to do that? > In all honesty, isn't 'fluid ABI' one of the reasons behind staging ? That is how it was used by a few drivers in the past, at least. If the rules have changed and/or Android is special in that regard, we ought to make it perfectly clear so that people are aware from day 1. That aside, Android developers were clear that only internal, downstream components are using this code and they are OK with breaking the ABI [1]. Gustavo is in the process of rewriting their tests for upstream inclusion and he'll also update the Android side of things [2]. With those in mind, I think everything should be safe here. If you prefer to avoid the ABI break, which approach are you keen on - reassign new ioctl numbers (Rob suggestion) or use new header fence2.h (Daniel). Thank you Emil [1] https://lists.freedesktop.org/archives/dri-devel/2016-January/099592.html [2] https://lists.freedesktop.org/archives/dri-devel/2016-January/099726.html
[pull] radeon and amdgpu drm-next-4.6
On Sat, Mar 5, 2016 at 4:35 AM, Michel Dänzer wrote: > On 03.03.2016 15:15, Alex Deucher wrote: >> >> Some more radeon and amdgpu stuff for drm-next. Mostly just bug fixes >> for new features and cleanups. > > Please also include Daniel Vetter's changes switching to drm_vblank_on/off: > > > https://lists.freedesktop.org/archives/dri-devel/2016-January/099159.html > https://lists.freedesktop.org/archives/dri-devel/2016-January/099160.html > (with dce_v8_0.c added) > Applied. thanks! Alex
[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path
On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote: > On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote: > > The drm_encoder_cleanup() was missing both from the error path of > > dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was > > enabled and we ended up deferring probe of HDMI at boot. > > > > This call isn't needed from unbind() because if dw_hdmi_bind() returns > > no error then it takes over the job of freeing the encoder (in > > dw_hdmi_unbind). > > > > Signed-off-by: Douglas Anderson > > --- > > Does dw_hdmi-imx need a similar change? I wonder if it would be cleaner > to push this into dw_hdmi_bind() if it affects all of the platforms.. I don't think moving it there would make sense - keep the initialisation and cleanup together in the same file so that it's contained together. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH] drm/amdgpu: delete set-but-not-read member has_uvd from amdgpu_device
On Sat, Mar 5, 2016 at 12:59 AM, Nils Wallménius
wrote:
> Clean up leftover from radeon code.
>
> Signed-off-by: Nils Wallménius
Applied, thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
> drivers/gpu/drm/amd/amdgpu/cik.c| 2 --
> drivers/gpu/drm/amd/amdgpu/vi.c | 4
> 3 files changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 0c42a85..cfd35b0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -2053,7 +2053,6 @@ struct amdgpu_device {
> struct amdgpu_sdma sdma;
>
> /* uvd */
> - boolhas_uvd;
> struct amdgpu_uvd uvd;
>
> /* vce */
> diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c
> b/drivers/gpu/drm/amd/amdgpu/cik.c
> index 6b1f053..5da14a3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/cik.c
> +++ b/drivers/gpu/drm/amd/amdgpu/cik.c
> @@ -2025,8 +2025,6 @@ static int cik_common_early_init(void *handle)
>
> adev->asic_funcs = _asic_funcs;
>
> - adev->has_uvd = true;
> -
> adev->rev_id = cik_get_rev_id(adev);
> adev->external_rev_id = 0xFF;
> switch (adev->asic_type) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 1250035..9163f59 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1071,26 +1071,22 @@ static int vi_common_early_init(void *handle)
> adev->external_rev_id = 0xFF;
> switch (adev->asic_type) {
> case CHIP_TOPAZ:
> - adev->has_uvd = false;
> adev->cg_flags = 0;
> adev->pg_flags = 0;
> adev->external_rev_id = 0x1;
> break;
> case CHIP_FIJI:
> - adev->has_uvd = true;
> adev->cg_flags = 0;
> adev->pg_flags = 0;
> adev->external_rev_id = adev->rev_id + 0x3c;
> break;
> case CHIP_TONGA:
> - adev->has_uvd = true;
> adev->cg_flags = 0;
> adev->pg_flags = 0;
> adev->external_rev_id = adev->rev_id + 0x14;
> break;
> case CHIP_CARRIZO:
> case CHIP_STONEY:
> - adev->has_uvd = true;
> adev->cg_flags = 0;
> /* Disable UVD pg */
> adev->pg_flags = /* AMDGPU_PG_SUPPORT_UVD |
> */AMDGPU_PG_SUPPORT_VCE;
> --
> 2.7.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amdgpu: Fix error handling in amdgpu_flip_work_func.
On Sat, Mar 5, 2016 at 3:00 AM, Michel Dänzer wrote: > On 02.03.2016 05:31, Mario Kleiner wrote: >> The patch e1d09dc0ccc6: "drm/amdgpu: Don't hang in >> amdgpu_flip_work_func on disabled crtc." from Feb 19, 2016, leads to >> the following static checker warning, as reported by Dan Carpenter in >> https://lists.freedesktop.org/archives/dri-devel/2016-February/101987.html >> >> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:127 amdgpu_flip_work_func() >> warn: should this be 'repcnt == -1' >> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() >> error: double unlock 'spin_lock:>dev->event_lock' >> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() >> error: double unlock 'irqsave:flags' >> >> This patch fixes both reported problems: >> >> Change post-decrement of repcnt to pre-decrement, so >> it can't underflow anymore, but still performs up to >> three repetitions - three is the maximum one could >> expect in practice. >> >> Move the spin_unlock_irqrestore to where it actually >> belongs. >> >> Reported-by: Dan Carpenter >> Signed-off-by: Mario Kleiner >> Cc: # 4.4+ >> Cc: Michel Dänzer >> Cc: Alex Deucher > > Both patches are > > Reviewed-by: Michel Dänzer > > > Alex, these should go into 4.5 if at all possible. Yup, Added to my 4.5 fixes tree. Alex
[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path
On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote: > The drm_encoder_cleanup() was missing both from the error path of > dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was > enabled and we ended up deferring probe of HDMI at boot. > > This call isn't needed from unbind() because if dw_hdmi_bind() returns > no error then it takes over the job of freeing the encoder (in > dw_hdmi_unbind). > > Signed-off-by: Douglas Anderson > --- Does dw_hdmi-imx need a similar change? I wonder if it would be cleaner to push this into dw_hdmi_bind() if it affects all of the platforms.. > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > index 3d3cf2f8891e..88776aba984e 100644 > --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c > @@ -293,7 +293,16 @@ static int dw_hdmi_rockchip_bind(struct device *dev, > struct device *master, > drm_encoder_init(drm, encoder, _hdmi_rockchip_encoder_funcs, >DRM_MODE_ENCODER_TMDS, NULL); > > - return dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data); > + ret = dw_hdmi_bind(dev, master, data, encoder, iores, irq, plat_data); > + > + /* > + * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(), > + * which would have called the encoder cleanup. Do it manually. > + */ > + if (ret) > + drm_encoder_cleanup(encoder); > + > + return ret; > } > > static void dw_hdmi_rockchip_unbind(struct device *dev, struct device > *master, > -- > 2.7.0.rc3.207.g0ac5344
[Bug 113341] GPU Lockup on AMD Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=113341 --- Comment #5 from Bernd Steinhauser --- Created attachment 207721 --> https://bugzilla.kernel.org/attachment.cgi?id=207721=edit Xorg.0.log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 113341] GPU Lockup on AMD Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=113341 --- Comment #4 from Bernd Steinhauser --- Today I ran into this again and got the Xorg log, but there doesn't seem to be anything interesting in it. Kernel is now 4.4.4. When the freeze occurs, I can still ssh into the system. Applications continue to run (i.e. I had a music player running), I could even reboot the system, although that seemed to take longer because X didn't like to shutdown (was markt as DSsl+ in ps aux). -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v9] dma-buf: Add ioctls to allow userspace to flush
On Mon, Feb 29, 2016 at 03:02:09PM +, Chris Wilson wrote:
> On Mon, Feb 29, 2016 at 03:54:19PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 25, 2016 at 06:01:22PM +, Chris Wilson wrote:
> > > On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vignatti wrote:
> > > > +static long dma_buf_ioctl(struct file *file,
> > > > + unsigned int cmd, unsigned long arg)
> > > > +{
> > > > + struct dma_buf *dmabuf;
> > > > + struct dma_buf_sync sync;
> > > > + enum dma_data_direction direction;
> > > > +
> > > > + dmabuf = file->private_data;
> > > > +
> > > > + switch (cmd) {
> > > > + case DMA_BUF_IOCTL_SYNC:
> > > > + if (copy_from_user(, (void __user *) arg,
> > > > sizeof(sync)))
> > > > + return -EFAULT;
> > > > +
> > > > + if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
> > > > + return -EINVAL;
> > > > +
> > > > + switch (sync.flags & DMA_BUF_SYNC_RW) {
> > > > + case DMA_BUF_SYNC_READ:
> > > > + direction = DMA_FROM_DEVICE;
> > > > + break;
> > > > + case DMA_BUF_SYNC_WRITE:
> > > > + direction = DMA_TO_DEVICE;
> > > > + break;
> > > > + case DMA_BUF_SYNC_RW:
> > > > + direction = DMA_BIDIRECTIONAL;
> > > > + break;
> > > > + default:
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + if (sync.flags & DMA_BUF_SYNC_END)
> > > > + dma_buf_end_cpu_access(dmabuf, direction);
> > > > + else
> > > > + dma_buf_begin_cpu_access(dmabuf, direction);
> > >
> > > We forgot to report the error back to userspace. Might as well fixup the
> > > callchain to propagate error from end-cpu-access as well. Found after
> > > updating igt/gem_concurrent_blit to exercise dmabuf mmaps vs the GPU.
> >
> > EINTR? Do we need to make this ABI - I guess so? Tiago, do you have
> > patches? See drmIoctl() in libdrm for what's needed on the userspace side
> > if my guess is right.
>
> EINTR is the easiest, but conceivably we could also get EIO and
> currently EAGAIN.
>
> I am also seeing some strange timing dependent (i.e. valgrind doesn't
> show up anything client side and the tests then pass) failures (SIGSEGV,
> SIGBUS) with !llc.
Tiago, ping. Also probably a gap in igt coverage besides the kernel side.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCHv12 05/17] HID: add HDMI CEC specific keycodes
On Sat, Mar 05, 2016 at 09:44:24AM +0100, Hans Verkuil wrote: > Hi Dmitry, > > On 03/04/2016 08:58 PM, Dmitry Torokhov wrote: > > On Wed, Feb 10, 2016 at 01:51:39PM +0100, Hans Verkuil wrote: > >> +#define KEY_AUDIO_DESC0x26e > >> +#define KEY_3D_MODE 0x26f > >> +#define KEY_NEXT_FAVORITE 0x270 > >> +#define KEY_STOP_RECORD 0x271 > >> +#define KEY_PAUSE_RECORD 0x272 > >> +#define KEY_VOD 0x273 /* Video on Demand */ > >> +#define KEY_UNMUTE0x274 > >> +#define KEY_FASTREVERSE 0x275 > >> +#define KEY_SLOWREVERSE 0x276 > > > > KEY_FRAMEBACK maybe? > > FRAMEBACK suggests to me that it goes back a single frame and then pauses > at that frame. Whereas SLOWREVERSE is continual slow reverse playback. > > So I would prefer to keep it, unless you think otherwise. OK, fair enough. Thanks. -- Dmitry
[PATCHv12 05/17] HID: add HDMI CEC specific keycodes
Hi Dmitry,
On 03/04/2016 08:58 PM, Dmitry Torokhov wrote:
> On Wed, Feb 10, 2016 at 01:51:39PM +0100, Hans Verkuil wrote:
>> From: Kamil Debski
>>
>> Add HDMI CEC specific keycodes to the keycodes definition.
>>
>> Signed-off-by: Kamil Debski
>> Signed-off-by: Hans Verkuil
>> ---
>> include/uapi/linux/input-event-codes.h | 28
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/include/uapi/linux/input-event-codes.h
>> b/include/uapi/linux/input-event-codes.h
>> index 87cf351..2662500 100644
>> --- a/include/uapi/linux/input-event-codes.h
>> +++ b/include/uapi/linux/input-event-codes.h
>> @@ -611,6 +611,34 @@
>> #define KEY_KBDINPUTASSIST_ACCEPT 0x264
>> #define KEY_KBDINPUTASSIST_CANCEL 0x265
>>
>> +#define KEY_RIGHT_UP0x266
>> +#define KEY_RIGHT_DOWN 0x267
>> +#define KEY_LEFT_UP 0x268
>> +#define KEY_LEFT_DOWN 0x269
>
> Can you please add some comments to these and how they are different
> form normal KEY_UP/KEY_DOWN or KEY_DPAD* or BTN_A/B/X/Y.
These go in the diagonal direction (which is how they are different.)
I'll add a comment.
>
>> +#define KEY_ROOT_MENU 0x26a /* Show Device's Root
>> Menu */
>> +#define KEY_MEDIA_TOP_MENU 0x26b /* Show Top Menu of the Media
>> (e.g. DVD) */
>> +#define KEY_NUMERIC_11 0x26c
>> +#define KEY_NUMERIC_12 0x26d
>> +/*
>> + * Toggle Audio Description: refers to an audio service that helps blind and
>> + * visually impaired consumers understand the action in a program. Note: in
>> + * some countries this is referred to as "Video Description".
>> + */
>> +#define KEY_AUDIO_DESC 0x26e
>> +#define KEY_3D_MODE 0x26f
>> +#define KEY_NEXT_FAVORITE 0x270
>> +#define KEY_STOP_RECORD 0x271
>> +#define KEY_PAUSE_RECORD0x272
>> +#define KEY_VOD 0x273 /* Video on Demand */
>> +#define KEY_UNMUTE 0x274
>> +#define KEY_FASTREVERSE 0x275
>> +#define KEY_SLOWREVERSE 0x276
>
> KEY_FRAMEBACK maybe?
FRAMEBACK suggests to me that it goes back a single frame and then pauses
at that frame. Whereas SLOWREVERSE is continual slow reverse playback.
So I would prefer to keep it, unless you think otherwise.
BTW, the CEC spec actually has three variants for each of the slow/fast
forward/reverse
commands: min/medium/max speed.
As you can see in the rc-cec.c patch (06/17) I'm mapping all three to a single
key code:
{ 0x6005, KEY_FASTFORWARD },
{ 0x6006, KEY_FASTFORWARD },
{ 0x6007, KEY_FASTFORWARD },
{ 0x6015, KEY_SLOW },
{ 0x6016, KEY_SLOW },
{ 0x6017, KEY_SLOW },
{ 0x6009, KEY_FASTREVERSE },
{ 0x600a, KEY_FASTREVERSE },
{ 0x600b, KEY_FASTREVERSE },
{ 0x6019, KEY_SLOWREVERSE },
{ 0x601a, KEY_SLOWREVERSE },
{ 0x601b, KEY_SLOWREVERSE },
But in theory I might have to add e.g. KEY_FASTREVERSE_MIN/MAX in the future and
ditto for the other three speed keys. I don't want to do that now, though, as I
think that is overkill. But I might have to revisit this once I have a better
idea
of what I can expect from CEC devices.
Thank you for the review, I'm planning to post a v13 soon.
Regards,
Hans
>
>> +/*
>> + * Control a data application associated with the currently viewed channel,
>> + * e.g. teletext or data broadcast application (MHEG, MHP, HbbTV, etc.)
>> + */
>> +#define KEY_DATA0x275
>> +
>> #define BTN_TRIGGER_HAPPY 0x2c0
>> #define BTN_TRIGGER_HAPPY1 0x2c0
>> #define BTN_TRIGGER_HAPPY2 0x2c1
>> --
>> 2.7.0
>>
>
> Thanks.
>
[PATCH] drm/amdgpu: delete set-but-not-read member has_uvd from amdgpu_device
Clean up leftover from radeon code.
Signed-off-by: Nils Wallménius
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
drivers/gpu/drm/amd/amdgpu/cik.c| 2 --
drivers/gpu/drm/amd/amdgpu/vi.c | 4
3 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 0c42a85..cfd35b0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -2053,7 +2053,6 @@ struct amdgpu_device {
struct amdgpu_sdma sdma;
/* uvd */
- boolhas_uvd;
struct amdgpu_uvd uvd;
/* vce */
diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c
index 6b1f053..5da14a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik.c
@@ -2025,8 +2025,6 @@ static int cik_common_early_init(void *handle)
adev->asic_funcs = _asic_funcs;
- adev->has_uvd = true;
-
adev->rev_id = cik_get_rev_id(adev);
adev->external_rev_id = 0xFF;
switch (adev->asic_type) {
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 1250035..9163f59 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1071,26 +1071,22 @@ static int vi_common_early_init(void *handle)
adev->external_rev_id = 0xFF;
switch (adev->asic_type) {
case CHIP_TOPAZ:
- adev->has_uvd = false;
adev->cg_flags = 0;
adev->pg_flags = 0;
adev->external_rev_id = 0x1;
break;
case CHIP_FIJI:
- adev->has_uvd = true;
adev->cg_flags = 0;
adev->pg_flags = 0;
adev->external_rev_id = adev->rev_id + 0x3c;
break;
case CHIP_TONGA:
- adev->has_uvd = true;
adev->cg_flags = 0;
adev->pg_flags = 0;
adev->external_rev_id = adev->rev_id + 0x14;
break;
case CHIP_CARRIZO:
case CHIP_STONEY:
- adev->has_uvd = true;
adev->cg_flags = 0;
/* Disable UVD pg */
adev->pg_flags = /* AMDGPU_PG_SUPPORT_UVD |
*/AMDGPU_PG_SUPPORT_VCE;
--
2.7.0
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 Steven Haigh changed: What|Removed |Added CC||netwiz at crc.id.au --- Comment #74 from Steven Haigh --- I'm actually looking at this - and I wonder if this is the same problem as I filed here: https://bugs.freedesktop.org/show_bug.cgi?id=94387 It has all the hallmarks of it. I've love to help get this fixed as I'm sick of heating my room up beyond a comfortable level :P -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94387] Approx 35W more power usage in multi-screen
https://bugs.freedesktop.org/show_bug.cgi?id=94387 --- Comment #5 from Steve --- Further digging in this BZ seems to show this as a similar problem to: https://bugzilla.kernel.org/show_bug.cgi?id=60523 /sys/class/drm/card0/device $ cat power_dpm_force_performance_level auto /sys/class/drm/card0/device $ echo low > power_dpm_force_performance_level -bash: echo: write error: Invalid argument /sys/class/drm/card0/device $ cat power_dpm_force_performance_level auto /sys/class/drm/card0/device $ echo high > power_dpm_force_performance_level -bash: echo: write error: Invalid argument /sys/class/drm/card0/device $ echo auto > power_dpm_force_performance_level -bash: echo: write error: Invalid argument Video card is: $ lspci -v -s 03:00.0 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Barts XT [Radeon HD 6870] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device 00d0 Flags: bus master, fast devsel, latency 0, IRQ 37 Memory at d000 (64-bit, prefetchable) [size=256M] Memory at fbcc (64-bit, non-prefetchable) [size=128K] I/O ports at d000 [size=256] Expansion ROM at fbca [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon Kernel modules: radeon -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160305/5ee295b8/attachment.html>
[Bug 94387] Approx 35W more power usage in multi-screen
https://bugs.freedesktop.org/show_bug.cgi?id=94387 --- Comment #4 from Steve --- I've been digging more into this I have 3 x displays - 2 x DVI, 1 x DP. Looking into debugfs, I can see that the clocks never change from sclk 900MHz, mclk: 105000. ie: # cat /sys/kernel/debug/dri/64/radeon_pm_info uvdvclk: 0 dclk: 0 power level 2sclk: 9 mclk: 105000 vddc: 1175 vddci: 1150 My kernel options are: # for i in /sys/class/drm/card0/device/power_*; do echo "$i: `cat $i`"; done /sys/class/drm/card0/device/power_dpm_force_performance_level: auto /sys/class/drm/card0/device/power_dpm_state: balanced /sys/class/drm/card0/device/power_method: dpm /sys/class/drm/card0/device/power_profile: default # for i in /sys/module/radeon/parameters/*; do echo "$i: `cat $i`"; done /sys/module/radeon/parameters/agpmode: 0 /sys/module/radeon/parameters/aspm: -1 /sys/module/radeon/parameters/audio: 0 /sys/module/radeon/parameters/auxch: -1 /sys/module/radeon/parameters/backlight: -1 /sys/module/radeon/parameters/bapm: -1 /sys/module/radeon/parameters/benchmark: 0 /sys/module/radeon/parameters/connector_table: 0 /sys/module/radeon/parameters/deep_color: 0 /sys/module/radeon/parameters/disp_priority: 0 /sys/module/radeon/parameters/dpm: -1 /sys/module/radeon/parameters/dynclks: -1 /sys/module/radeon/parameters/fastfb: 0 /sys/module/radeon/parameters/gartsize: 1024 /sys/module/radeon/parameters/hard_reset: 0 /sys/module/radeon/parameters/hw_i2c: 0 /sys/module/radeon/parameters/lockup_timeout: 1 /sys/module/radeon/parameters/modeset: 1 /sys/module/radeon/parameters/msi: -1 /sys/module/radeon/parameters/mst: 0 /sys/module/radeon/parameters/no_wb: 0 /sys/module/radeon/parameters/pcie_gen2: -1 /sys/module/radeon/parameters/r4xx_atom: 0 /sys/module/radeon/parameters/runpm: -1 /sys/module/radeon/parameters/test: 0 /sys/module/radeon/parameters/tv: 0 /sys/module/radeon/parameters/use_pflipirq: 2 /sys/module/radeon/parameters/vm_block_size: 12 /sys/module/radeon/parameters/vm_size: 8 /sys/module/radeon/parameters/vramlimit: 0 # cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.4.3-300.fc23.x86_64 root=UUID=03ee98ed-d998-4518-b216-b77822a9319b ro quiet radeon.audio=0 radeon.tv=0 audit=0 selinux=0 # cat /proc/version Linux version 4.4.3-300.fc23.x86_64 (mockbuild at bkernel01.phx2.fedoraproject.org) (gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) ) #1 SMP Fri Feb 26 18:45:40 UTC 2016 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160305/3e91acc7/attachment.html>
