For this stuff I’d just bypass that bit by overriding them using ryzenadj for now bfore opening another war front in the ec.
Setting prochot? That’s less “slow down” and more “emergency break just short of shutting down” XD
If by close you mean 0 distance then yeah XD. But when I looked at the power setup on the 16 is pretty messy, being the first ones to do >20V pd did come with it’s drawbacks. Looking forward to fully integrated solutions like we got for the regular pd stuff now.
I am generally very curious what you’ll find on the it limiting to about 80% of the advertised pd current front. Getting that bit closer to the limit may help a lot with lower wattage stuff and from my testing pretty much all pd power supplies that aren’t total garbage have a bit of overhead.
I think the 12A at 20V is one of the charge chips valiant effort to detect a failed mosfet that has shorted and not try to throw more power at it that might result in fried pcb traces. It is actually quite difficult to detect shorts on circuits that normally take high current anyway.
I saw one pcb that had burnt through part of the pcb due to a failed mosfet. The pcb itself was swolen and black in places. Edit: for clarity, that burnt PCB was not a FW one.
I would probably favour designs that distributed power around the board at 48V instead of 15-20V. There would be less current involved.
The next step would be blocking the signal from impacting the performance of the computer XD
In this case the FL 16 is mechanically incapable of sustaining 240W and since 180W drains the battery. This product is flawed unfortunately EDIT: previous post edited to clarify
No, I am not saying that. I don’t even wish imply it. I don’t think the FW16 is flawed. It might have some software bugs that need fixing. I have edited my previous post to clarify.
I was just giving an example of one of the cases where the charge chip can cause a throttle. There are about 20 of them and I have not looked at them all yet, and the EC firmware can enable/disable any of them it chooses. I suspect it has disabled the 12A 20V one for obvious reasons.
That might be why many other performance laptops choose 20V7A or higher current instead of higher voltage. The large voltage drop from 48V to 19.5V(or 17.8V) bus voltage is particularly hard on the small MOSFETs on DC-DC converter
Failed power stages on gpus also tend to produce pretty epic craters.
That is what I meant but that’ll require a whole lot of changes, most of the components used currently have max voltages a little over 20v which is porbably why the original pd standard maxed out there.
I’d guess more like getting 48v electronic components is a lot harder currently, the dc-dc converter doesn’t really care but it does need to be one capable of going up to 48V. The stressing part is the output current and that’s the same in both cases.
I have found some more information out about this now.
There is another reason people might not be getting the 240W from the PSU that they are expecting.
The EC uses the sb_rmi_mailbox_xfer() to set the PMF power profile.
This is set depending on:
The amount of power the PSU has.
Whether it is a SPR or EPR PSU.
Whether charger in “bypass” or not.
The power profile selected by the user.
A PMF looks like this:
PMF: SPL 45000mW, sPPT 54000mW, fPPT 60000mW, p3T 118000mW, ao_sppt 60000mW
So, when you see amdgpu_top Throttle Status saying SPPT, it means it is applying the SPPT limit.
So, if people are not getting the power they expect, it might mean that the EC has selected the wrong PMF profile.
There appears to be an order to apply things in.
Set the power profile, Performance, Balanced, Power Save.
Plug in the PSU. The power profile appears to get applied when the user plugs in the PSU.
I would be interested to see what the PMF values are when one uses a 240W charger.
On Linux:
To see these, run my “ec-syslog” daemon that grabs all the EC logs and puts them in the syslog.
The unplug and PSU. Wait 30 seconds and plug it back in again.
Then look for any PMF lines in the syslog and post them here.
SPL = SPL stands for Sustained Power Limit in AMD’s power management framework. It defines the maximum power level that a processor can maintain indefinitely under load, ensuring stable performance without exceeding thermal or electrical constraints.
sPPT = SPPT (Slow Package Power Tracking Limit), which governs short-term power boosts lasting up to 2 minutes
fPPT = fPPT (Fast Package Power Tracking Limit): This defines the short burst power limit, typically lasting a few seconds. It allows the CPU to briefly exceed its sustained power limit for quick computations, ensuring snappy performance
p3T = P3T stands for Peak Package Power Limit. This parameter represents the maximum instantaneous power that the SMU (System Management Unit) allows during transient workloads. In other words, it acts as a cap designed to prevent the processor package from drawing an excessive peak of power when under sudden or heavy load conditions, ensuring that the power delivery and thermal margins remain within safe limits.
ao_sppt = ao_sppt (APU Overdrive Slow Package Power Tracking Limit): This is a variation of sPPT (Slow Package Power Tracking Limit), which governs longer boost durations—typically up to a minute
@James3
I’ve started playing recently with ectool to be able to run it on Windows and I started to checking latest commit in FrameworkComputer/EmbeddedController repository. It looks like there is some work related to the GPU and power limit. It looks like that it in crease CPU power limit if GPU is powered.
There is one more commit which should prevent battery draining in balanced mode. it looks like it will impact how values which you have mentioned will be set. it looks like all these value depends on active_mpower which is read from cypd_get_ac_power(), maybe it will be worth to monitor it. I do not have GPU, so it is pure guess, based on the source code and recent changes.
If you get it running on windows, please let me know.
I would like to add any fixes to my ectool version, and then get github to automatically build the binary.
Also, I think this “ectool” has been trying to get it working on windows. It might already work:
I have ectool running in windows with secure mode enabled. It requires winring0 loaded by another app like “Universal x86 Tuning Utility” or " Libre Hardware Monitor".
I’m not an author of it. credits goes to Dustin L. Howett and Tomáš Iser who prepared PR. I’ve just forked the repo and build it. it is available on github and I used your github workflow action to build it. Here is the link to the built asset
@wojciech_migas
Would you be able to try my ectool repo, and then let me know which changesets need cherry picking from your one, to make my one work on windows?
Note: I don’t have windows to test on.
I will try to play with over the weekend. as I have mentioned earlier I’ve used Dustin L. Howett and merge PR prepared byt someone else.
It should be possible. I will try to fork you repo and then apply changes from my repo (combine all changes from Dustin and Tomáš).
We have made some progress.
There are three things that contribute to the power coming from the battery as well as the PSU.
Vsys dropping below Vbat.
PSU current limit. Set by the EC firmware to 85% of PSU, for a 180W PSU, it can draw 153W. for a 240W PSU, it can draw 205W.
The PMF settings, putting limits on the CPU side to what power it can draw.
I have a modified EC firmware that reports all the power being used, and whether it is coming from the PSU or the battery or both.
If anyone is willing to try it, we can do some measurements with the 240W charger.
