Am 07.05.2013 23:13, schrieb Parag Warudkar:
On Tue, May 7, 2013 at 4:44 AM, Christian König deathsimple@vodafone.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