linux-kernel - Re: [PATCH] radeon: Allow disabling UVD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 8 May 2013 17:39:46 -0400 (EDT)
From:	Parag Warudkar <parag.lkml@...il.com>
To:	Christian König <deathsimple@...afone.de>
cc:	Parag Warudkar <parag.lkml@...il.com>,
	Michel Dänzer <michel@...nzer.net>,
	LKML <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] radeon: Allow disabling UVD



On Wed, 8 May 2013, Christian König wrote:

> Am 07.05.2013 23:13, schrieb Parag Warudkar:
> > On Tue, May 7, 2013 at 4:44 AM, Christian König <deathsimple@...afone.de>
> > wrote:
> > Without SUMO_uvd.bin - suspends fine and only wakes up when I want it to.
> 
> Hui? Wait a second, the firmware doesn't work but still causes an instant
> resume on suspend? Very strange.

Yes, I tested this multiple times - if firmware loads and the init bails 
out, machine resume instantly, like this -

[ 3631.441257] PM: Entering mem sleep
[ 3631.441274] Suspending console(s) (use no_console_suspend to debug)
[ 3631.441825] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 3631.442003] sd 0:0:0:0: [sda] Stopping disk
[ 3631.755076] PM: suspend of devices complete after 313.257 msecs
[ 3631.755219] PM: late suspend of devices complete after 0.134 msecs
[ 3631.795185] PM: noirq suspend of devices complete after 39.904 msecs
[ 3631.821922] pcieport 0000:00:1c.1: power state changed by ACPI to D0
[ 3631.915378] PM: noirq resume of devices complete after 119.999 msecs
[ 3631.915459] PM: early resume of devices complete after 0.062 msecs
[ 3631.915525] ahci 0000:00:1f.2: setting latency timer to 64
[ 3631.915609] ehci-pci 0000:00:1a.7: setting latency timer to 64
[ 3631.915654] uhci_hcd 0000:00:1a.0: setting latency timer to 64
[ 3631.915690] usb usb1: root hub lost power or was reset
[ 3631.915709] snd_hda_intel 0000:00:1b.0: irq 46 for MSI/MSI-X
[ 3631.915770] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[ 3631.915792] usb usb2: root hub lost power or was reset
[ 3631.915804] ehci-pci 0000:00:1d.7: setting latency timer to 64
[ 3631.915821] snd_hda_intel 0000:01:00.1: irq 48 for MSI/MSI-X
[ 3631.918662] [drm] probing gen 2 caps for device 8086:101 = 2212d02/0
[ 3631.918665] [drm] PCIE gen 2 link speeds already enabled
[ 3631.921479] [drm] PCIE GART of 512M enabled (table at 
0x0000000000040000).
[ 3631.921584] radeon 0000:01:00.0: WB enabled

Right now, I have removed SUMO_uvd.bin and suspend resume is working 
without fail. Strange indeed, and I only noticed it when the machine did 
not instant resume when running with the UVD disable patch and no_uvd=1 
which skips uvd init just like firmware lodaing failure does I suppose.

> 
> My best guess is that it has something todo with a different clock routing on
> Macs, but without access to the hardware (or precise documentation from Apple
> what the heck they did different) I don't really see a chance to solve that
> problem.

Hopefully it is not that hard and we'll find a way! I will experiment the 
clocks and see how that goes.

> If you want to hack a bit on it you could try commenting out the calls to
> "radeon_set_uvd_clocks" in radeon_uvd.c. That should give you the default
> clocks of 100Mhz, not enough for usable decoding, but on SUMO based UVD blocks
> a very failsafe default.
> 
> Whatever it is, please send me an output of lspci, so I can blacklist the
> offending chip.
> 
Here is the lspci -nn output :

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee 
ATI Whistler [Radeon HD 6600M/6700M/7600M Series] [1002:6741]

Parag