AMD Zen 3 APU Temperature Monitoring Narrowly Misses Linux 5.14

[phoronix]

Phoronix: AMD Zen 3 APU Temperature Monitoring Narrowly Misses Linux 5.14

Landing into "hwmon-next" just after the Linux 5.14-rc1 tagging that marks the formal end to feature work for the current cycle was the k10temp driver adding support for AMD Zen 3 APU temperature monitoring under Linux...

https://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-3-APU-Temp-hwmon

[avem]

Anyone knows whether AMD is going to allow to set arbitrary CPU frequencies for its Zen CPUs in Linux? This has been an issue for over four years now. In Linux for e.g. Zen 3 CPUs only three frequencies are allowed 3800, 2800 and 2200Mhz while in Windows you can set anything from the base frequency to the maximum boost frequency. And no CPU drivers are required in Windows to achieve that, so somehow the CPU driver which probably works via ACPI is able to achieve that.

[Teggs]

The patch is small enough that it could be submitted as a "fix" so early in the Linux 5.14 cycle...

I am not familiar with the protocol, but could you not submit this as a fix, Michael? I know that you submitted at least one patch in this area before, and it is of legitimate interest to you in your work. Or would that be considered messing around in someone else's back yard?

[Mario Junior]

Anyone knows whether AMD is going to allow to set arbitrary CPU frequencies for its Zen CPUs in Linux? This has been an issue for over four years now. In Linux for e.g. Zen 3 CPUs only three frequencies are allowed 3800, 2800 and 2200Mhz while in Windows you can set anything from the base frequency to the maximum boost frequency. And no CPU drivers are required in Windows to achieve that, so somehow the CPU driver which probably works via ACPI is able to achieve that.

Same problem here when I tested Fedora with a 3700x.

Installed Windows and problem solved.

[middy]

"Left up to the community"

Basically AMD providing shit Linux support as usual, and wanting free labour instead of paying people to do that work.

AMD "We're a poor company that only earns billions of dollars in revenue per annum, there's no way we can hire engineers to add basic support like temperature sensors. Poor us."

what really annoys me is AMD works with people behind closed doors, like martin from hwinfo, giving him specs and everything he needs to get full hardware monitoring in his closed source application, but linux gets stuff either late, or nothing. hwinfo has so much support we can only dream of having here on linux. like the ability to see the current clock rate of infinity fabric (by default, it does downclock at idle), ppt limits, tdc limits, edc limits, edc and tdc values, cpu and soc reported voltages (not from the motherboard sensors but the cpu's own internal sensors), svi2 current, soc svi2 current, cpu reporting thermal throttling or not, cpu package power, etc.

if amd can some how easily hand some literal who documents and answer his emails to get this stuff to put into his little program for windows, why can't amd do the same with linux? we struggle just to get the ability to report power status and have that removed because amd some how can't manage to send the linux dev's documentation they can send to martin over at hwinfo: https://www.hwinfo.com

but on the gpu sides of things, amd seems to be a lot more open and forthcoming (which is what we want). cpu side of things just release the bare minimum. i love my 5800x i just wish amd loved linux as much as they love windows with it.

[agd5f]

Anyone knows whether AMD is going to allow to set arbitrary CPU frequencies for its Zen CPUs in Linux? This has been an issue for over four years now. In Linux for e.g. Zen 3 CPUs only three frequencies are allowed 3800, 2800 and 2200Mhz while in Windows you can set anything from the base frequency to the maximum boost frequency. And no CPU drivers are required in Windows to achieve that, so somehow the CPU driver which probably works via ACPI is able to achieve that.

This is due to the fact the Linux uses the older ACPI P-state interface for managing CPU frequencies. Windows uses the newer ACPI CPPC interface for managing CPU power states. AMD was working on this a while ago, but got a lot of push back from the community while trying to upstream it:

https://lkml.org/lkml/2019/7/10/682

[agd5f]

what really annoys me is AMD works with people behind closed doors, like martin from hwinfo, giving him specs and everything he needs to get full hardware monitoring in his closed source application, but linux gets stuff either late, or nothing. hwinfo has so much support we can only dream of having here on linux. like the ability to see the current clock rate of infinity fabric (by default, it does downclock at idle), ppt limits, tdc limits, edc limits, edc and tdc values, cpu and soc reported voltages (not from the motherboard sensors but the cpu's own internal sensors), svi2 current, soc svi2 current, cpu reporting thermal throttling or not, cpu package power, etc.

if amd can some how easily hand some literal who documents and answer his emails to get this stuff to put into his little program for windows, why can't amd do the same with linux? we struggle just to get the ability to report power status and have that removed because amd some how can't manage to send the linux dev's documentation they can send to martin over at hwinfo: https://www.hwinfo.com

My understanding is that tools like this use an API provided by Ryzen Master on CPUs and the GPU driver on APUs to get this information on windows. For APUs the information is already available in the GPU driver for Linux, it would just need to be exposed somehow for the CPU/SoC side.

[middy]

My understanding is that tools like this use an API provided by Ryzen Master on CPUs and the GPU driver on APUs to get this information on windows. For APUs the information is already available in the GPU driver for Linux, it would just need to be exposed somehow for the CPU/SoC side.

some might, but hwinfo doesn't. martin has stated he personally gets documentation and support from amd for his monitoring in hwinfo and his stuff doesn't use things provided by stuff like ryzen master. some of the way he goes about reporting sensor data is similar to how ryzen master does it, but he does not use ryzen master api's or anything like that. he gets stuff (hardware, documentation) from them before their new stuff even comes out. its how he adds support for stuff before its even released. its not just amd that does this, but intel, nvidia, and others too.

though programs like gpu-z does do what you describe. this is why gpu-z reports far less stuff than hwinfo does when it comes to gpu stuff. hwinfo will show A LOT more sensors than gpu-z. like my 6900xt with gpu-z doesn't show my vrm temps, current, etc like hwinfo does. amd drivers don't even provide that stuff but hwinfo shows it and of course, linux doesn't show the vrm temps on my gpu.

[mppix]

This is due to the fact the Linux uses the older ACPI P-state interface for managing CPU frequencies. Windows uses the newer ACPI CPPC interface for managing CPU power states. AMD was working on this a while ago, but got a lot of push back from the community while trying to upstream it:

https://lkml.org/lkml/2019/7/10/682

Quotes from the discussion to not misrepresent it:

"So in general I think it is a huge mistake to expose all that [CPPC registers] to userspace. Before you know it, there's tools that actually rely on it, and then inhibit the kernel from doing anything sane with it."

"We're trying to move all cpufreq into the scheduler and have only a single governor, namely schedutil -- yes, we're still stuck with legacy, and we're still working on performance parity in some cases, but I really hope to get rid of all other cpufreq governors eventually."

"And if you look at schedutil (schedutil_cpu_util in specific) then you'll see it is already prepared for CPPC and currently only held back by the generic cpufreq interface. It currently only sets desired freq, it has information for min/guaranteed, and once we get thermal intergrated we might have sensible data for max freq too."

[stalkerg]

https://lkml.org/lkml/2019/7/15/1454 - nobody answers on it. It's sad.
Kernel developers want to do everything magically in the kernel it's too opposite mainstream Windows behavior.