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 at vodafone.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
