| 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
| ||
|
Message-ID: <42e9a7d0-536f-bd15-0c4a-071d09195bc2@amd.com>
Date: Fri, 8 Oct 2021 10:57:44 -0500
From: "Limonciello, Mario" <mario.limonciello@....com>
To: Sachi King <nakato@...ato.io>, hdegoede@...hat.com,
mgross@...ux.intel.com, rafael@...nel.org, lenb@...nel.org,
Sanket.Goswami@....com, Shyam Sundar S K <Shyam-sundar.S-k@....com>
Cc: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 1/2] platform/x86: amd-pmc: Add alternative acpi id for
PMC controller
On 10/8/2021 07:19, Sachi King wrote:
> On Friday, 8 October 2021 21:27:15 AEDT Shyam Sundar S K wrote:
>>
>> On 10/8/2021 1:30 AM, Limonciello, Mario wrote:
>>>
>>> On 10/5/2021 00:16, Shyam Sundar S K wrote:
>>>>
>>>> On 10/2/2021 9:48 AM, Sachi King wrote:
>>>>> The Surface Laptop 4 AMD has used the AMD0005 to identify this
>>>>> controller instead of using the appropriate ACPI ID AMDI0005. Include
>>>>> AMD0005 in the acpi id list.
>>>>
>>>> Can you provide an ACPI dump and output of 'cat /sys/power/mem_sleep'
>>>
>>> I had a look through the acpidump listed there and it seems like the PEP
>>> device is filled with a lot of NO-OP type of code. This means the LPS0
>>> patch really isn't "needed", but still may be a good idea to include for
>>> completeness in case there ends up being a design based upon this that
>>> does need it.
>>>
>>> As for this one (the amd-pmc patch) how are things working with it? Have
>>> you checked power consumption
>
> Using my rather limited plug-in power meter I measure 1w with this patch,
> and I've never seen the meter go below this reading, so this may be over
> reporting. Without this patch however the device bounces around 2.2-2.5w.
> The device consumes 6w with the display off.
>
> I have not left the device for long periods of time to see what the battery
> consumption is over a period of time, however this patch is being carried
> in linux-surface in advance and one users suspend power consumption is
> looking good. They have reported 2 hours of suspend without a noticable
> power drop from the battery indicator.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flinux-surface%2Flinux-surface%2Fissues%2F591%23issuecomment-936891479&data=04%7C01%7Cmario.limonciello%40amd.com%7Cb95422d699a2496a56f608d98a55e888%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692923846585025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MND10b0iIblTgywFsxoLNx7D1bZuLZOmbqbhQJiezxM%3D&reserved=0
>
Thanks, in that case this is certainly part of what you'll need and it
sounds like you're on the right train as it pertains to the wakeup sources.
For both patches in this series:
Reviewed-by: Mario Limonciello <mario.limonciello@....com>
>
>>> and verified that the amd_pmc debugfs
>>> statistics are increasing?
>
> s0ix_stats included following smu_fw_info below.
>
>>> Is the system able to resume from s2idle?
>
> It does, however additional patches are required to do so without an external
> device such as a keyboard. The power button, lid, and power plug trigger
> events via pinctrl-amd. Keyboard and trackpad go via the Surface EC and
> require the surface_* drivers, which do not have wakeup support.
>
> 1. The AMDI0031 pinctrl-amd device is setup on Interrupt 7, however the APIC
> table does not define an interrupt source override. Right now I'm not sure
> how approach producing a quirk for this. linux-surface is carrying the hack
> described in
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F87lf8ddjqx.ffs%40nanos.tec.linutronix.de%2F&data=04%7C01%7Cmario.limonciello%40amd.com%7Cb95422d699a2496a56f608d98a55e888%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692923846585025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5dWwpgh%2FRIA%2F57UpY5h0l9Snzem%2BNpirgE6ujEHO7aY%3D&reserved=0
> Also available here:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flinux-surface%2Fkernel%2Fcommit%2F25baf27d6d76f068ab8e7cb7a5be33218ac9bd6b&data=04%7C01%7Cmario.limonciello%40amd.com%7Cb95422d699a2496a56f608d98a55e888%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692923846585025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HPZfqPoVUJT8w%2FRD7UaVjegT0iRLDlRkXfOwMx5HS8Q%3D&reserved=0
>
> 2. pinctrl: amd: Handle wake-up interrupt
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Ftorvalds%2Fc%2Facd47b9f28e5&data=04%7C01%7Cmario.limonciello%40amd.com%7Cb95422d699a2496a56f608d98a55e888%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692923846585025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gUtHcFKolVIZeHtIIJuT3BkruQbjq8NAOU5504%2F02Mg%3D&reserved=0
> Without this patch the device would suspend, but any interrupt via
> pinctrl-amd would result in a failed resume, which is every wakeup
> souce I know of on this device.
Yes that was the same experience a number of us had on other AMD based
platforms as well which led to this patch being submitted.
>
> 3. pinctrl: amd: disable and mask interrupts on probe
> Once I worked out that I needed the patch in 2 above the device gets a lot
> of spurious wakeups, largely because Surface devices have a second embedded
> controller that wants to wake the device on all sorts of events. We don't
> have support for that, and there were a number of interrupts not configured
> by linux that were set enabled, unmasked, and wake in s0i3 on boot.
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-gpio%2F20211001161714.2053597-1-nakato%40nakato.io%2FT%2F%23t&data=04%7C01%7Cmario.limonciello%40amd.com%7Cb95422d699a2496a56f608d98a55e888%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692923846585025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mwJgcXBY9zdlTG671KssViHdSwHfq6DCJ2fpeLbRbR4%3D&reserved=0
We'll have to take a look at this to make sure it's not causing a
regression for the other platforms the original patch helped. If it
does, then we'll need some sort of other messaging to accomplish this
for the surface devices.
>
> These three are enough to be able to wake the device via a lid event, or by
> changing the state of the power cable.
>
> 4. The power button requires another pair of patches. These are only in the
> linux-surface kernel as qzed would like to run them there for a couple of
> releases before we propose them upstream. These patches change the method
> used to determine if we should load surfacepro3-button or soc-button-array.
> The AMD variant Surface Laptops were loading surfacepro3-button instead
> soc-button-array. They can be seen:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flinux-surface%2Fkernel%2Fcommit%2F1927c0b30e5cd95a566a23b6926472bc2be54f42&data=04%7C01%7Cmario.limonciello%40amd.com%7Cb95422d699a2496a56f608d98a55e888%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692923846585025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PGWON0kCpByJtsO1rS9wrYr7oH86V%2F8M%2FYLmUoFjBhM%3D&reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flinux-surface%2Fkernel%2Fcommit%2Fac1a977392880456f61e830a95e368cad7a0fa3f&data=04%7C01%7Cmario.limonciello%40amd.com%7Cb95422d699a2496a56f608d98a55e888%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692923846585025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=B%2BBW3M4L5TLCq3Fc6oB0KHaC9A%2FQp3uwkB2Jby%2FdDo8%3D&reserved=0
>
>
>> Echo-ing to what Mario said, I am also equally interested in knowing the
>> the surface devices are able to reach S2Idle.
>>
>> Spefically can you check if your tree has this commit?
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fpdx86%2Fplatform-drivers-x86.git%2Fcommit%2F%3Fh%3Dfor-next%26id%3D9cfe02023cf67a36c2dfb05d1ea3eb79811a8720&data=04%7C01%7Cmario.limonciello%40amd.com%7Cb95422d699a2496a56f608d98a55e888%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692923846585025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XdRCk8klBuDRCk7UWL%2Ft5wiupVVgdCWBqFmaYgGK%2BFU%3D&reserved=0
>
> My tree currently does not have that one. I've applied it.
You should look through all the other amd-pmc patches that have happened
as well in linux-next, it's very likely some others will make sense too
for you to be using and testing with.
>
>> this would tell the last s0i3 status, whether it was successful or not.
>>
>> cat /sys/kernel/debug/amd_pmc/smu_fw_info
>
>
> === SMU Statistics ===
> Table Version: 3
> Hint Count: 1
> Last S0i3 Status: Success
> Time (in us) to S0i3: 102543
> Time (in us) in S0i3: 10790466
>
> === Active time (in us) ===
> DISPLAY : 0
> CPU : 39737
> GFX : 0
> VDD : 39732
> ACP : 0
> VCN : 0
> DF : 18854
> USB0 : 3790
> USB1 : 2647
>
>>> /sys/kernel/debug/amd_pmc/s0ix_stats
>
> After two seperate suspends:
>
> === S0ix statistics ===
> S0ix Entry Time: 19022953504
> S0ix Exit Time: 19485830941
> Residency Time: 9643279
>
> === S0ix statistics ===
> S0ix Entry Time: 21091709805
> S0ix Exit Time: 21586928064
> Residency Time: 10317047
>
>
Yeah these look good, thanks.
>>> Does pinctrl-amd load on this system? It seems to me that the power
>>> button GPIO doesn't get used like normally on "regular" UEFI based AMD
>>> systems. I do see MSHW0040 so this is probably supported by
>>> surfacepro3-button and that will probably service all the important events.
>
> We require the first patch listed above to get pinctrl-amd to load on this
> system, and the two patches mentioned in 4 so we correctly choose
> soc-button-array which is used by all recent Surface devices.
>
>
>
>
Powered by blists - more mailing lists