https://bugzilla.kernel.org/show_bug.cgi?id=216516 --- Comment #29 from Mario Limonciello (AMD) (mario.limonciello@xxxxxxx) --- > Is the usleep_range() patch about helping with the buggy interrupts? > Or is is about further lowering the power consumption below 2 % per hour? > (2 % per hour is the best I got until now, when the deepest state was active > all the time) It's for trying to keep it in deepest state for more of the kernel's suspend cycle when it has been interrupted. If you're already in the deepest state for most of the suspend cycle it won't do anything. > SMU Firmware, version 64.61.0 This is the BIOS component with the bug. The fix is in 64.66.0. > I got no Windows installed. But I'm wondering how Windows is handling this > firmware bug? Windows does Modern Standby a little bit differently. > Does "certified with Ubuntu" mean HP is officially supporting it? > Or does this mean, that just Ubuntu says it's working? I can't put words in their mouths on what it means for them. > Wouldn't it be better, if you - as official AMD employee - report this to > HP!? I'm not their customer; you are. > EC means "Embedded Controller"? > GPE means "General Purpose Event"? Yes > A little more than 1 % of battery was consumed. And I'm wondering if this > might contradicts your theory, about the EC trying to notify about a new > battery level. That amount of time in deep sleep matches how it should be behaving. If that *wasn't* with acpi.ec_no_wakeup=1 then the usleep_range() change is helping and I should clean up and send a patch for it too. But to your question, I don't have insight into the exact nature of what HP's EC does; so I hypothesize. I only know the AMD side of it. > So tomorrow morning I'll see how much power it has consumed using the > ec_no_wakeup workaround :-) OK. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
