With my FW16. I tried a 25W charger with it.
Normally it could pull only 20W from the charger due to the psu input current limits.
I tried ectool chargestate param 2 <value> to get it to draw up to 25W.
It worked, in the sense that it then draw 25W from the 25W charger.
I did not test any further, i.e. whether it resulted in EC prochot or anything like that.
I am only mentioning it so people know it is a setting we can change, and it keeps the setting and the EC does not immediately override it again.
This further confirms my hypothesis that PROCHOT (processor hot) is wildly overused. If the EC gets prochots when the input current is set to 3A, how could the FL13 use 100W charger? Or it could explain that the battery still gets momentarily discharged when 100W charger is used.
@Charlie_6
Maybe “PROCHOT” is not the right term.
It is just a tool the EC uses, when for whatever reason, it wishes the CPU to draw as little current as possible. It is not necessarily due to getting hot.
The current level that triggers a “PROCHOT” is configurable by the EC, and depending on which CPU is being used and which PSU size is connected, applies it or not and if applied, sets it based on the PSU size. So the “PROCHOT” level for a 60W psu is different from the level for a 100W psu.
I think it’s still overused regardless of wrong term or not. The EC should toughen up and stop losing its marbles when merely outside its comfort zone. For example a CPU strats to underclock at 95°C to 100°C PROCHOT only starts at 107°C~115°C(not 101°C) and reduce the clock speed to 400MHz.
The EC should remove the PROCHOT when both battery and AC are connected since if AC power ocp’d the computer can use battery power without interruption(BGATE has body diode), or at least set to 10% to 15% higher rather than 3001mA
Man, that is one crappy piece of EC code / behaviour that people / we are paying for?
The current code sets the input current prochot level to 100% of negotiated current so 5A when 5A and 3A when 3A and so on (with a bit of rounding as the prochot setting has 128mA resolution).
Kinda, this is probably a bit of collateral damage from standalone mode where you definitely want to prochot before you cause your only psu to turn off but when you have a battery it is not really needed there. We allready got low vsys and battery current prochot which are both a good thing with a battery and tangentially cover the same thing.
That is probably the first thing I am going to try when I got a development environment set up.
To be fair a lot of this is probably mostly because we can see it, closed source ecs also do a lot of dumb stuff we just can’t see or mess with it nearly as well. Plus framework does some non standard stuff that makes some of these things much harder. If they would have gone with just one or 2 pd capable ports there would have been off the shelve solutions. Not to mention pretty much the entire power sub-system of the 16.
But yeah there is room for improvement. Also if anyone from framework ever reads this, please comment why you are doing stuff in the ec (like “we had to de-rate the input current cause it had issues with charger x in y conditions” or something like this or even an "idk, was like this in the “reference implementation” would be very helpful)
I installed ryzenadj to get info on the Ryzen 7840U CPU power limits for each power mode I tested with on Fedora. To do this, I recorded the PPT outputs from sudo ryzenadj --info for each power mode I used.
Here are the CPU limits with the FW13 on battery power.
| Setting Name | Power Saver | Balanced | Performance |
|---|---|---|---|
| PPT LIMIT SLOW | 15W | 33W | 35W |
| PPT LIMIT FAST | 30W | 41W | 46W |
Here are the CPU limits with a charger plugged in. I verified the command outputs were the same with both my 60W and 100W charger.
| Setting Name | Power Saver | Balanced | Performance |
|---|---|---|---|
| PPT LIMIT SLOW | 25W | 33W | 35W |
| PPT LIMIT FAST | 30W | 51W | 53W |
My understanding is that the slow limit is an upper limit on average CPU power draw, and that the fast limit is an upper limit on boosted power draw.
Since battery flipping mostly occurred in the Balanced and Performance power modes, it would be interesting to test if dropping the charger fast limits to some value <50W reduces how often the FW13 dips into battery power. It would also be interesting to see what the default limits are for other CPU models.
The problem is probably what the code referes to as “P3T” which is a power limit I have not found in ryzenadj jet. It may actually need to be set from ec side or is called something else. Currently that is set to 90% of negotiated charger power + 89W (for the most part, they got some weird conditions where it does some different stuff at some combinations of charger and battery level) if I read the code correctly.
I’ll be able to do some experimenting pretty soon.
I think I found a bug about the input current PROCHOT. Currently
Battery and AC: Input current prochot
Battery only: Battery current prochot
AC only: Input current prochot
What it should be:
Battery and AC: Battery current prochot
Battery only: Battery current prochot
AC only: Input current prochot
I found it here
I used TLP for power management and I set PLATFORM_PROFILE_ON_AC=performance,
PLATFORM_PROFILE controls the PPT_FAST, PPT_SLOW and STAPM limits. I used $sudo tlp ac to force it on AC profile for testing.
When using performance profile, the burst power of CPU us 53W, which leads to 75+W of total system power usage. When on battery with out AC connection, the burst power of CPU is only 41W even if AC profile is forced, the total power usage is about 61W so it’s clearly limited by the 1C rating of the battery.
Since there’s no battery current prochot when AC is connected, when the chargecontrol is set to discharge you can draw the same 75+W totally on battery and 0W from AC. I think the BMS has an OCP curve or something like 130%/5s, 110%/1min, 100%sustained, so during the testing the battery didn’t disconnect, as the power draw reduced to 50~55W after 5 seconds where the CPU power reduced to 35W.
I think we should change the
prochot_ma = (DIV_ROUND_UP(charge_ma, 128) * 128);
charge_ma = charge_ma * 90 / 100;
into
prochot_ma = (DIV_ROUND_UP(charge_ma, 128) * 128) * 110 / 100;
charge_ma = charge_ma;
Because
You won’t be pulling the emergency brake when you are 0.1km/h above the speed limit
Sorry I should’ve re-word it more clearly. I think the “minimized power because of reasons” should be less restrictive and it should only be used in critical conditions when the temperature or power is way over the limit
I really hope that we have open sourced BMS. If so I would’ve troubleshot and provided a solution within a week after discovering the “17.6V on 61Wh and 17.4V on 55Wh causing sudden health drop” bug.
There isn’t? I could swear the bit was on when I checked the values from the youtube video.
I am going with set it to like 6000 or something inf we have a battery and keep the existing logic for standalone.
I could be wrong. I made the conclusion not based on values since my EC is not flashed, but based on 53W CPU (75W system) power on battery with AC connected and chargecontrol set to discharge but 41W CPU(61W system) on battery. Maybe the battery prochot is set to a value higher than 61W and the 41W is limited by other factor(s).
Last time I checked it was a bit over 7A, the limits on the charge controller are all current limits and not power limits but in power terms that would be way above what a fw 12 should be able to pull anyway, especially sustained.
Another thing to consider.
When the battery is 60% or less, it uses different PMF profiles, so for testing please keep the battery > 60%.
Those profiles are kind of a mess.
Also since I got a ccd now I noticed it keeps changing the vsys voltage a couple times a second, that can’t be the point. I think we need to take into account the charge limit in “calc_is_full” so it treats the charge limit as full and puts vsys to max and disables bfet.
Also also I narrowed down the issue with 5v charging a bit, the current limit does get set to 90% of 500mA but the input never gets selected so it’s probably on the pd controller side.
I found that the chg_voltage is set to max when chargecontrol is NORMAL. However when the chargecontrol is IDLE the chg_voltage is the battery currently voltage when the battery is high, but constant 15480mV when the battery is low.
Allright I got a development enviroment now some preliminary findings:
Setting the limit to 100% and disabling input current prochot didn’t blow up anything jet and also has not caused renegotiation.
Setting the p3t power limit to less than input power instead of input power + 89W seems to massively reduce battery dipping behavior even on a 30W psu, though at that point you are likely loosing a bit of performance.
I also am fairly sure the little single digit mA discharge currents are caused by that weird vsys logic that keeps moving all over the place. The implementation of charge limits looks quite messy and adding the whole battery extender thing only made it more complex.
@Charlie_6 You got an easy way to test the whole “inconsistent fps” thing you had?
Since the fps is inconsistent idk the exact way of testing quantitively. I just used $ sudo ectool chargestate param 2 3000 with unmodified EC firmware and played a video game.
You discovered the way:
Set input current prochot to input power+89W, change the input current limit from 90% to 100% and adjust the P3T power automatically to the PD charger rated power(with a minimum value to let it dip into battery when PD power is lower than a reasonable value)
Gotta see if I have anything interesting installed.
Currently testing input current prochot 6144mA (so pretty much impossible), 100% input current limit and 90% P3T with a hack that sets vsys to battery max when the mode is idle and I can’t see it dipping into battery even on a 30W charger. This may indeed be the way.
The vsys hack seems to have removed the single digit ma stuff but there is probably a nice way to implement it, currently I just added this:
Which is marginally nicer than just fully overriding the thing but I still don’t like it. Seems to do the trick though.
Setting P3T this high may have been a design decision and on lower power chargers it’s definitely going to cost performance but having the option to have it within the charger limit would be pretty nice I guess.
Settings P3T this high but input current prochot this low is like always using emergency brakes for normal everyday driving XD
The input prochot was irrelevant cause the input current limit was lower, that baby was never hit outside of standalone mode.