Názory k článku
Triviální oprava usínání notebooků s procesory AMD

Ze by konecne? Ach jo, jeste kdybych nebyl liny vybuildit si vlastni kernel.

Zajímalo by mne jestli/jak moc tahle změna zvýší spotřebu.

Nijak, ten polling probíhá jen uvnitř těch několika milisekund mezi odesláním requestu na suspend a jeho potvrzením z hardwaru (ve funkci amd_pmc_send_cmd).

Aha, toho jsem si nevšiml. Díky. :-)

Chápu to dobře, že to potvrzení přijetí nahodí nějaký bit v AMD_PMC_REGIS­TER_RESPONSE jen na méně než 100us? Jinak si nedovedu přestavit, jak by ten patch mohl fungovat- čtení každých 100us potvrzení nezachytí, zatímco každých 50us jo. To je běžné řešení potvrzení? Čekal bych, že to potvrzení v registru visí, dokud jej čtecí proces nesmaže (což se v té metodě amd_pmc_send_cmd následně provádí).

Nemělo by to tak být. V té odkazované gitlab diskuzi se to řeší ještě teď. Že ta změna spin rychlosti pomohla je symptomem něčeho složitějšího, např. race condition kdy ten bit resetuje něco rychlejšího.

Díky za hint, tu diskuzi jsem přehlédl. Očividně zatím netuší, co to může dělat. Dělá to prý i při inicializaci, takže vyloučili variantu, že než stihnout bit přečíst, interface usne (což by dávalo smysl). Prý vyloučili i variantu vícenásobného přístupu. Jsem opravdu zvědavý, co bude nakonec příčinou.

Klidně to může být i něco na straně firmwaru AMD, případně HP. Nějaká krysa v UEFI nebo PSP koprocesoru. Nebylo by to poprvé, kdy hardware nefunguje jak má, Windows driver obsahuje nezvěřejněný workaround a "my" na to musíme přijít sami :-)