[TRACKING] Battery flipping between charging and discharging / Draws from battery even on AC

I would guess it doesn’t care

Well the ec lied to it about the psu capacity XD.

Once we hit max current vsys is going down till we draw from the battery.

The charge controller also has the 2 stage power feature so we could theoretically pass through short spikes to the psu. I think I am also going to experiement with that.

The current limit math for the 16 is also pretty wacky mostly cause of the intermediary dc-dc converter.

I have a wild guess. It tries to tell the CPU that battery is -273.15°C when the battery is removed, so the system will draw way less power to risk a transient load wearing down the battery at below freezing. Could be the reason of

Since it’s a wild guess XD it’s mostly likely to be incorrect.

You sure that isn’t just regular annoying stapm throttling? I don’t think the cpu itself is aware of the actual battery draw (hence the need for prochot signals from the charge controller)

No, with battery removed the burst power is lower than sustained power with battery installed and the computer feels laggy when browsing the web or opening files/folders

Well without a battery it obviously can’t run the same settings as with, otherwise it would crash everytime we dip into battery with. It may be running into low vsys prochot or something though. I personally don’t particularly care about standalone mode but you could try playing with ryzenadj and keep an eye on the prochot signal. Setting the power limit lower may actually help snappyness as repeatedly running into prochot and pulling the emergency break is probably less good of an experience than just running a bit slower.

Regarding the problem of some people left being limited to 400Mhz.
There is something in the ISL9241 data sheets that talk about:
“Reduce system load below ACLIM”.
I have seen it also limit the AC to 5V, 500mA which is 2.5W. it seems to also slow the CPU down a lot when doing this. Its only at 500mA for about 1 second.
Maybe there is an edge case, where it does the slow down, but then hits an error case, and forgets to add power back again, thus leaving the CPU is slow mode.
It would be really interesting to see what amdgpu_top says when people are stuck in 400Mhz mode.

Do you know how it slows down the cpu? Manual prochot and then not unsetting it? That would explain the stuck bit cause the automatic ones should automatically release at least according to the reigsters in the videos.

also ryzenadj, though I don’t think that one shows prochot but it does show the currently set power and temp limits straight from the msrs.

This is meaningless as the computer won’t even take 5V3A input, it always draw 0.01A unless using workarounds such as kickstarting from 60W input

Looking at the EC source code, this is what slows the CPU down:
Generally called from here:
throttle_ap()

the bit of code that actually does the slowing is:
gpio_set_flags(GPIO_CPU_PROCHOT, gpio_get_default_flags(GPIO_CPU_PROCHOT));

and this:

gpio_set_level(GPIO_CPU_PROCHOT, throttle);

When it does that, everything slows down. In my FW16 case to 545 Mhz.
But, bizarrely, it does not have any relationship to amdgpu_top PROCHOT_CPU.
I.e. amdgpu_top does not show whether it is on or off.
There is a EC CCD command to view the current state:
apthrottle

It is not available from ectool.
When it is off:

apthrottle
AP throttling type 0 is off (0x00000000)
AP throttling type 1 is off (0x00000000)

When it is on:

apthrottle
AP throttling type 0 is off (0x00000000)
AP throttling type 1 is on (0x00000002)

The number “2” changes, depending on what part of the code requested the throttling.
In my EC firmware, I have added a EC CCD command to manually change it to on or off, so I could test it.
The “type 0” does not appear to do anything, but the “type 1” really slows things down.

So, if the people seeing 400 Mhz problems, if they got hold of an EC CCD, they might be able to use that apthrottle command to track down the problem.

Absolutely barbaric, does it do that with a battery or only standalone? If it’s also with a battery I’d argue for removing that (conditionally) on the 13, in standalone I guess needs must but with a battery that’s just pulling the emergency break for no reason.

Does that mean the system is pulling prochots by default?

I don’t know. I have not looked that far. The source code gets a little difficult at that point. A rabbit hole of various board specific includes. I have not had time to dig into. My guess is that it is just finding out if the prochot sends that gpio low active or high active, thus the default being which is the inactive level.

The throttle_ap thing seems to be a generic chromium ec thing, can you point me at where it is used between pd states?

The code is indeed somewhat hard to follow mostly because it is somewhat hard to tell what code is actually used with all the configurable stuff and overrides (and a whole bunch of code for other laptops). I stumbled over one that prochots if the lid is closed and the cpu gets a little warm XD.

If it is throttling with a battery present on the 13 that sounds unnecessary (on the 16 it could make sense since the system can probably draw more than the battery can handle). The reduce load to < new input current limit would only mean setting the new current limit and waiting till the input current got there right? If you got a battery it’ll just use that instead and if you don’t you are kinda boned.

You can tell when I throttles by looking at the EC logs.
The obvious one I have noticed is when you plug in a psu. It asserts prochot for about 1 second while it negotiates with the psu on the best volts level to use.
Another way to tell is simply to select “who calls function X” in a source code viewing tool.
E.g. scope or clink. (The really basic tools)
I have not yet found a tool that only displayed code based on CONFIG_* options.
One way I discover this is by putting in a #warning directive, and if the code fails to compile with that warning, I know that bit of code is included/needed.
If it compiles ok with the #warning, I know that bit of code is not needed/not used.

If it does that even on battery that seems excessive, then again probably not a huge deal.

That is actually pretty brilliant, much faster than putting in some log line and seeing if you can make it show up.

What’ll happen if you remove the prochot. At this moment I think PROCHOT is way overused

I don’t know what would happen if one removed the PROCHOT when a PSU is connected.
I can see why it might be useful when the PSU is disconnected, but when the PSU is connected, one could just not use the PSU until the volts had been negotiated. The CPU would have been running off battery up till then.
As it is, it is only doing PROCHOT for about 1 second when you insert/remove the PSU, so its not really impacting the user.
I think there might be a bug somewhere where is sets PROCHOT and then forgets to unset it.
Just to clarify, the EC initiated PROCHOT causes the CPU to run at 545Mhz, i.e. really slow. There are no half measures from the PROCHOT perspective.
For half measures (just going a bit slower than expected) there are PMF settings for controlling that.
and also, of course, the PSU input current limiting we have already mentioned.

Maybe the PROCHOT is to cover the step in the ISL9241 document relating to:
“Reduce system load below ACLIM”
PROCHOT would definitely reduce the system load.

If the load is reduced below aclim and the aclim is reduced to 2.5W you’ll get the worst performance ever in a computer, I think this situation must be avoided at all cost, like usin some kind of “if else” to make them mutually exclusive

I found it funny for FL13 that the best way to discharge the battery is to plug in and set charge control to discharge, rather than stress test solely on battery without ac connection

Well it is the officially recognized “reeeeeee something is wrong duck and cover” signal so there should not be half measures.

It might be but that is kind of a barbaric way to do it, though the only one you really got without a battery.

The charge controller actually does have a special battery calibration mode that lets the battery discharge while plugged in, really want to try that once I got my development setup running. The battery calibration you can do on thinkpads is real nice.