I have found what I think is the problem in the EC code.
Its the function:
sustain_switch_mode(enum ec_charge_control_mode mode)
It is broken logic in my opinion.
The problem is related to the decision points and state changes around the “sustain_soc.upper” point.
It seems to ignore the fact that “int soc = charge_get_display_charge() / 10;” does not return a constant value when the battery re-calibrates itself.
The value returned will shift up and down slightly over time, thus randomly pushing the value into the “DISCHARGING” part. Thus causing the DISCHARGE - IDLE loops.
I am going to just remove the whole “DISCHARGING” state from that part of the code if the AC is on.
I have compared the charge cycles of the FW laptop to that of my mobile phone, and the mobile phone does not have the forced “DISCHARGING” state even if the AC is on either.
Its a bogus and unwise state to have in my opinion.
Also, one line even uses an (sustain_soc.upper == soc) to change state. That is also not a great idea. Comparisons should be >=, <=, > or < when comparing charge levels, == should never be used. That ==, in itself, can cause the battery to happily charge on up to 100%, skipping the sustain_soc.upper limit.
Oh wait, there is a whole different section of code that deals with charge limits. I will look at that tomorrow.