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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 08 May 2013 11:32:04 +0200
From:	Christian König <deathsimple@...afone.de>
To:	Parag Warudkar <parag.lkml@...il.com>
CC:	Michel Dänzer <michel@...nzer.net>,
	LKML <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] radeon: Allow disabling UVD

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:
>
>> The patch shouldn't be necessary because just removing the firmware should
>> have pretty much the same effect.
> Soon distros will ship the UVD firmware by default and then users will
> need to manually remove it and then do the same with every update.
> Besides, I just discovered that when UVD is enabled suspend resume
> breaks  - tried 3 times with SUMO_uvd loaded - machine suspends but
> resumes instantly.
> 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.

>> The only case where we indeed seems to have a problem are Macs with
>> integrated cards, and we can always just blacklist those if the problem
>> doesn't seems to be solvable.
> I happen to have the problematic card in my iMac - I'd be glad to
> provide any info or try any patches. Just let me know.
> For now I will remove the firmware - I reboot /suspend-resume often
> and it is a bit annoying to have to go through those mdelays only to
> fail.

Yeah, perfectly understandable.

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.

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.

Christian.

> Thanks,
> Parag
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/