The ISL923x init function would initialize the charger's input current
to the board's defined default. For some boards like meowth and
zoombini, the default input current was set quite low, 128mA. When
sysjumping, all HOOK_INITs are called again and therefore the input
current limit would be reset even thought it would have been set
correctly prior to jumping. Setting the current limit so low, without a
battery, would cause a power failure and the PMIC would drop its power
OK signal and go into emergency shutdown.
This commit simply adds a check to whether the EC jumped to this image.
If it has, the charger input current limit is left unchanged. It will
be updated to the correct value by charge manager later on after
determine the attached charge supplier.
BUG=b:72129338
BRANCH=None
TEST=Flash meowth; Boot to S0 without a battery; Verify that PMIC_DPWROK
remains high.
TEST=Repeat above test for zoombini.
Change-Id: I7e5bbbbf3ec604c876cc4fa0163f8bb7feff4cc9
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/896960
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Caveh Jalali <caveh@google.com>
In the system, RT946x is always powered by the battery.
So even in battery cutoff mode, the reg values on RT946X are not reset.
We don't want RT946x to supply VBUS when DUT boots, which could mess up
PD state. So we need to disable VBUS output when RT946x initializes.
BUG=b:72228350
BRANCH=none
TEST=Confirm OPA_MODE (bit0 in reg 0x01) is clear after RT946x
finishes initialization
Change-Id: I32795b3bea64860b164c14b06aa1cd2551ebd8a0
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/890028
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
rt946x_block_read() is not implemented right.
It not only makes rt946x_init_irq() fail but also put
RT946x i2c module in an erroneous state temporarily.
BUG=b:72228350
BRANCH=none
TEST=manually on scarlet rev3:
1)Insert Plugable USB-C hub w/o AC
2)Run cutoff command on ec console
3)Hold Pwr button for a few seconds to wake up DUT
4)Repeat 2 - 3 for 10 times without seeing PD loops
Change-Id: I9304617f924e44288483afca5ab1b2923eb68ff0
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/890027
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
VSYS_PRIORITY in the register VIN_CTRL_SET is set during bd9995x
initialization to ensure VSYS remains up and stable during deeply
discharged battery conditions. However, outside of this case, this bit
should remain cleared.
If set, there the input current limit is disabled between the time
that the boost converter is enabled (USB_SUS = 0) and charging is
enabled (CHG_EN = 1). This can lead to too much current being drawn
which results in the connecting port shutting off VBUS due to its
overcurrent protection. This has been observed when attempting to
charge one DUT from another chromebook port, or with a Type C only
charger.
This CL adds a check in the bd99965x driver implementation of
charger_get_voltage() that compares the current battery voltage to
its minimum voltage. If it's higher, then it's not a deeply discharged
battery and VSYS_PRIORITY can be cleared.
BUG=chromium:69143827,71814128
BRANCH=coral,eve
TEST=Tested with 2 Coral DUTs. Verified that VSYS_PRIORITY gets
cleared when the charger state machine gets the charger
parameters. Also verified that I can repeatedly initated charging from
one Coral device to another. Without this fix, this would fail most of
the of the time. Also tested Eve with deeply discharged battery to
make sure the startup conditon still works.
Change-Id: I5230560fa98e5bf16921eb4f2c70802eb962e7f3
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/875178
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
After VBUS is up, there is a delay of ~500ms for rt946x to determine
'VBUS is ready'.
But we need charger_task to detect AC presence and then set a proper
sleep time immediately.
When using fusb302 to detect VBUS, I almost don't see any delay.
BUG=b:71520398
BRANCH=none
TEST=Confirm BATTERY LED turns on immediately when AC is
plugged in a Scarlet in G3.
Change-Id: If1d6d40081b5822eeb9e012115f8deef172def37
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/869420
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Without this, the battery will discharge if we disallow battery
charging (e.g. calling charge_request with either voltage == 0 or
current == 0, either by policy, or when the battery is full).
Also update config.h to set the option whenever isl923x is used.
BRANCH=none
BUG=b:66575472
BUG=b:35585464
TEST=make buildall -j
Change-Id: Id5515d5ea82a393a3693a3da44cbdc2778296a95
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/856538
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
On ISL923x, PSYS output is always enabled when the AP is on
(provided CONFIG_CHARGER_PSYS is enabled).
We add support for charger_get_system_power function, reading PSYS
value, when CONFIG_CHARGER_PSYS_READ is defined. This will be used
by the charging algorithm on lux.
We also rename CONFIG_CMD_CHARGER_PSYS to CONFIG_CHARGER_PSYS_READ
as CONFIG_CHARGER_PSYS_READ provides both "psys" console command
and the new function. We also cleanup unneeded undefs in board
files.
Note that this does not implement the function on bd9995x, but this
could be done without too much effort.
BRANCH=none
BUG=b:71520677
TEST=On lux, without AC connected, check that "psys" output roughly
matches the output current from the battery.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Change-Id: Ie1ce8e0ac103daacc5a08b8ccae604d1d83551b8
Reviewed-on: https://chromium-review.googlesource.com/848487
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
CONTROL1 bits can be modified from multiple tasks:
- charger_enable_otg_power (charger or pd task)
- charger_discharge_on_ac (host command or console)
- charger_enable/disable_psys (chipset task)
- print_amon_bmon (console)
Since we use I2C read, modify, then I2C write access pattern,
there is a small chance of races between these accesses:
let's protect them with a mutex.
Also, the current code sometimes uses charger_get_option/set_option
instead of manipulating CONTROL0 directly: fix those to regain
a bit of the extra code size caused by the mutex.
BRANCH=none
BUG=b:67029560
TEST=Flash lux, battery charges, amon works fine.
TEST=Flash elm, battery charges.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Change-Id: If375d9922db53dd582582bfa44d6218fe0b416ec
Reviewed-on: https://chromium-review.googlesource.com/848486
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This function sets up and enables "OTG" mode on the charger chip
(i.e. use the charger to provide power from the battery).
It also records the output current in curr.output_current, to
make sure that the charger loop is aware that current is provided
externally.
We also add a CONFIG_CHARGER_OTG to remove these functions on
boards that do not require it.
BRANCH=none
BUG=b:65697962
TEST=On wand, when discharging, battery status is updated every
5 seconds (and not every 60 seconds).
Change-Id: Ibf93933436f3eb24552a8e1eb9d97522fca2ce79
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/842743
Reviewed-by: Randall Spangler <rspangler@chromium.org>
rt946x_closest_reg_via_tbl() is buggy and doesn't
return the right reg value because of misuse of ARRAY_SIZE().
We should fix it.
Meanwhile, since rt946x_closest_reg_via_tbl() is only called in
rt946x_set_boost_current(), let's just delete rt946x_closest_reg_via_tbl()
and move its code to rt946x_set_boost_current().
BUG=b:70524967
BRANCH=none
TEST=Confirm reg 0x0a is set correctly
Change-Id: Ie9c90ebf63596a52f864ff5809488731edc41fff
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/830895
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The ISL9238 has a functionality where it will reload the adapter current
limit from a strap which is read from the PROG pin. This is problematic
when we decide to set the current limit prior to AC actually being
inserted. This commit disables this functionality from the charger.
It seems however that the charger will read the PROG pin and reload the
ILIM at least once before respecting the bits.
BUG=b:67120928, b:66017697
BRANCH=None
TEST=Plug and unplug and then plug again AC. Verify that the default
current limit is not set by the charger automatically.
Change-Id: Ia8e8742843f6ceb286635b31e0fe5c070a2b6dfe
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/759693
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Shamile Khan <shamile.khan@intel.corp-partner.google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The ISL9237/8 can both be powered by VSYS or AC, therefore, it's not
needed to reinitialize the charger after AC is present.
This commit moves the contents of charger_post_init() into a new init
function that will be run once at HOOK_INIT time.
BUG=b:67964166
BRANCH=None
TEST=make -j buildall
Change-Id: I637b1209f86f686013fee0783914fa1596076fa6
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/759692
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The ISL9238 has functionality for a input voltage regulation loop. By
default, the regulation reference voltage is set to 4096mV, however we
can be kinder to chargers by raising this regulation reference. In
testing, there appears to be insignificant change in current pulled at
the higher limit.
BUG=b:67964166
BRANCH=None
TEST=Flash a board with a ISL9238, verify that 0x4b reads as 0x0d00.
TEST=make -j buildall
Change-Id: I920c4b922106fca3001f2759cad0479a368f735b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/745527
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
In order for BC1.2 detection to succeed, USB data switches must be
open. Previously we performed BC1.2 detection whenever VBUS transitioned
up to 5V, including on power swap. In fact, there is no need to do BC1.2
detection on a PD-capable port, since we will always charge using the
USB-C or PD negotiated ILIM. Skip BC1.2 detection on power swap (and
more generally when a partner port is known to speak PD) by manually
triggering BC1.2 detection. In addition, manage USB switch state
differently, so that "auto mode" is only enabled during BC1.2 detection.
BUG=chromium:780905
BRANCH=gru
TEST=Attach USB-PD phone capable of role swap. Verify USB 2.0 device is
enumerated on plug, and not re-enumerated through a series of
"pd # swap power" commands on the EC console. Also verify BC1.2 charging
and PD charging are still functional on kevin.
Change-Id: I1d7d4dee3bc8d2e7885e7adb49ded84b4f515ad5
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755878
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The bd9995x driver was written to allow any PD port # to be VBUS or VCC,
but the mapping is broken in a few places. Since all boards use VBUS =
port 0, remove the conversion entirely.
BUG=chromium:781849
BRANCH=kevin
TEST=Verify PD and BC1.2 charging still works on kevin.
Change-Id: I3687866835d1684342d9f746d91b3a6079ab5cc4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755000
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
While introducing support for isl9238, I accidentally used an
incorrect config option (CONFIG_ISL9237), instead of
CONFIG_CHARGER_ISL9237.
BRANCH=none
BUG=b:35585464
TEST=make buildall -j
Fixes: b1101b8ed6 charger: isl923x: Add support for ISL9238
Change-Id: I2f62f3fbefbc60cc9d83726ef88a66c5c9f1b245
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/725121
Reviewed-by: Rong Chang <rongchang@chromium.org>
The decision on whether to ramp (and how high) depends on the quirks of
charger identification, so move the decision out of board, into the
drivers that implement usb_charger.
Also, rename CONFIG_CHARGE_RAMP to CONFIG_CHARGE_RAMP_SW, to better
contrast with the existing CONFIG_CHARGE_RAMP_HW.
BUG=None
TEST=Manual on kevin, verify ramp occurs when port plugged into Z840
workstation.
BRANCH=None
Change-Id: I5b395274133837a18a4f4ac34b59b623287be175
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/702681
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Zero ITERM_SET to keep the charger out of topoff mode, since it has
undesirable side-effects related to dead / low battery charging.
BUG=b:35575421
BRANCH=reef
TEST=Previous testing on kevin with same register setting.
Change-Id: Ic1dd280e1069d410895498c0f72989654a6b8c63
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/636152
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
When booting scarlet rev1, the initialization of rt9466
is not finished because CHIP REV < 0x05.
Actually, we shouldn't keep the latest CHIP REV in rt946x.h
because it's hard to maintain. And we should try to finish
rt946x_init() no matter what CHIP REV it is.
Also, let's clean up the logging message in rt946x_init()
a bit to make it clear that it's from RT946X.
BUG=chromium:736821, b:63739819
BRANCH=none
TEST=boot scarlet rev1 and confirm the
initialization of rt946x is finished
Change-Id: Ic0b1f837b801cc18744a1222794a055dfe8aa54c
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/612585
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
In the function bd9995x_battery_charging_profile_settings, the current
values for trickle, precharge, and fastcharge were being set. Fastcharge
current level was being set via
charger_set_current(PD_MAX_CURRENT_MA). By calling this function with
a non-zero parameter, charging will always be enabled. In addition,
PD_MAX_CURRENT_MA is an input current limit and doesn't neceassrily
apply to the fastcharge current level which would be read from the
fuel gauge. The other side effect is that by enabling charging, VSYS
is being set to battery->voltage_min which reverts VSYS being set to
battery->voltage_max in the init routine.
Per Rohm, all charging profile registers should be set prior to
enabling charging. On Coral, enabling charging at this point was
leading to VSYS collapse when no battery was connected or a fully
depleted battery case. I also believe that enabling charging here
exacerbates other issues we've been running into with low battery
startup cases.
BUG=b:64388515
BRANCH=eve
TEST=On Coral tested both no battery a fully depleted battery
cases. Verified that without the call to charger_set_current() that
VSYS consistently collapses and that after removing this call, the
start up was stable and the battery begins charging.
Change-Id: Ice20ed5d8147fe9ad8faa754286a2ec8a784f8d8
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/602493
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The initial value for input current limit is set to
CONFIG_CHARGER_INPUT_CURRENT which is typically 512 mA. In deeply
discharged battery cases (Vbat < 5.8V), the 512 mA input current limit
can cause VSYS to collapse which in turn causes the EC to
reset. Depending on how discharged the battery is, the EC may remain
off until the external charger is disconnected and reconnected again,
or it may undergo a number of reset cycles, each time charging the
battery just a little, until Vbat becomes > ~5.8V and the charger is
able to stabilize. When the charger type is determined, either from
BCD detection, or Type C/USB PD, the input current limit is set to the
appropriate level.
In order to avoid the issue described above, this CL sets a bit in the
VIN_CTRL_SET register which will disable the input current limit in cases
Where the VBAT is less than the VSYSREG_SET value.
BUG=b:35648317
BRANCH=none
TEST=Manually tested on Electro.
a. With Zinger attached DUT boots without the battery after
plugging in AC
b. DUT boots from cut-off battery
c. With Zinger attached DUT boots from cold-reset without the
battery
d. With no battery & DCP charger, anti-collapse occurs,
input current is limited to 512mA & the DUT is
power-up inhibited.
Tested also on Eve with signal wires attached to both PPVAR_VSYS,
PP3300_DSW, and Vbat. Verified that on certain boards (some board to
board variation) that PPVAT_VSYS would collapse when the input current
limit was set to CONFIG_CHARGER_INPUT_CURRENT. Then after adding this
CL, verifed on the scope that the collapse of PPVAR_VSYS no longer
occurred.
Change-Id: Ief9960550f988e69ab4637db85450e91c70d3b51
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/456049
Commit-Ready: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
With the change, compiler won't use 64-bit division for
bd9995x_psys_charger_adc() function.
BRANCH=none
BUG=none
TEST=To replace "reg" variable and checking the return value
if it is expected for both "bd9995x_psys_charger_adc()" and
"bd9995x_amon_bmon_chg_adc()" functions.
Change-Id: Ifc461e5a54ce583ff59281ad13421c640ec9e21e
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/485083
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The function bc12_detect was using a msleep(312) to allow for enough
time for the bd9995 to determine the charger type. Putting the USB_CHG
task to sleep for this period of time means that the USB_CHG task is
not able to process interrupts from the bd9995 during that time. This
is a particular problem when Try.SRC is enabled and a charger is
connected. VBUS will only remain present for ~40-50 msec, and
when it goes away, the discharge circuit should be engaged. However,
the USB_CHG task is still in the 312 mSec sleep from when VBUS was
detected. The result is that discharge circuit is not engaged. It was
observed that processing of charger interrupts could be delayed
upwards of 500 msec.
On Eve with the EVT charger, VBUS was not discharging without the
discharge circuit being enabled. This resulted in excessive connect
time as the Try.SRC cycle repeated many times until a case where the
discharge circuit was not disabled when VBUS detect occurred and this
finally allowed the charger to attach.
This CL modifies the USB_CHG task main loop so that a wait timer is
used when bc12_type needs to be read from the charger. There is a wait
timer mark per port. If the mark value is 0, then a wait timer is not
required and the task is put to sleep with -1. Each time the task is
woken, either from the interrupt or wait event timer, the current time
is checked against the timer mark for each port. The function that
reads the bc12_type will return a 1 if the type is still not available
and will return 0 if either VBUS is no longer present, or the
bc12_type was successfully determined.
With this change in place the discharge circuit is reliably
enabled/disabled within ~5-10 mSec of VBUS changes.
BUG=b:37292010
BRANCH=reef,gru
TEST=Manual
Added signal probe wires to VBUS, discharge control, and charger
interrupt signals. Connected eve EVT charger and verified that the
discharge circuit is consitently enabled when VBUS is removed
following the initial attach in Try.SRC. Verifed that the EVT charger
always connects on the first attempt.
Also tested with various different chargers on both Eve and Reef
platforms. In addition, temporarily changed the initial deferred time
to 100 mSec and validated the path where vbus_provided is not true and
that additional deferred calls were initiated until bc12_type is valid.
Change-Id: Idd066b5461ec4cbb77bb023519fed90c9e9f71db
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/487028
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If charging current is set to 0mA during charging, reference of
charge current feedback amp (VREF_CHG) is set to 0V. Hence the DCDC
stops switching (because of the EA offset). To eliminate this issue,
disable/enable charger depending on the charging current is zero
or non-zero respectively.
BUG=b:37413065
BRANCH=reef
TEST=test 'ectool chargecontrol normal/idle/discharge' are working
Change-Id: Id31876afe365a476fb906e059ab519b7a0c9a7c6
Signed-off-by: james_chao <james_chao@asus.com>
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/486101
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 6da9ed8786e90ee91b39934180fe84e01ac30260)
Reviewed-on: https://chromium-review.googlesource.com/489812
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
This patch disables IADP immediately after the EC boots. We
observed noise on IADP/RESET pin causing SEL_ILIM_VAL to
randomly change. This seems the cause of b:35648317.
We enabled IADP to fix b:35647661 initially and also followed
the vendor's recommendation. However, the issue is only
reproducible on the particular board which was used for power
measurement and we did not see the issue on other boards with
IADP disabled.
Also the vendor assumed our EC doesn't control IBUS_LIM_SET
and ICC_LIM_SET. (I think they assumed like other thier customers
our EC controls ILIM by DAC connected to IADP/RESET pin.) If ILIM
is not set by EC and IADP is disabled, the system would brownout
because ILIM stays at 128mA. Therefore, it was (mistakenly)
recommended that our EC should keep IADP enabled.
Cros EC configures IBUS_LIM_SET and ICC_LIM_SET dynamically thus
the above concern does not apply.
We also found that we have too much noise on IADP/RESET pin. The
noise is not big enough to cause the chip to reset but it's big
enough to cause ILIM to fall in 128mA zone. We think this is why
the boards fail to boot from battery cutoff or no battery.
(Contrary to the vendor's explanation, it seems IADP/RESET pin
continusouly affects ILIM not only in the early chip power-up
period.)
BUG=b:35648317
BRANCH=none
TEST=Booted two Electro and two Snappy from 1) dead battery 2) no
battery 3) battery cutoff.
Change-Id: Ic675f1354b9ef222ceec8ce112b19713812d2752
Reviewed-on: https://chromium-review.googlesource.com/458676
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If the charging current is less than the BD9995X's minimum charging current
it is overwritten to BD9995X's minimum charging current. However in idle
mode we write the charging current which is known to the charger during
that time, which can be less than the BD9995X's charging current. Hence,
do not overwrite the charging current in idle mode.
BUG=b:35984679
BRANCH=none
TEST=Manually tested on Electro. In idle mode charge current is 0mA.
Change-Id: I2e605b63c8519383c6a62d76718bc52660e7270e
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/453999
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
IADP monitoring bit was set to the default value for the devices
with an RO image which clears the bit (and causes the issue).
This patch removes the code so that we do not touch the IADP
monitoring bit since transitioning from 0->1 may cause other issues.
BUG=b:35647661
BRANCH=reef
TEST=none
Change-Id: I4413e0bd2de3f4e3912cbe6e73b8cad641ee9245
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/453400
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/453798
charge_ramp needs to make a decision based upon the VBUS level on one
specific port - the port that is ramping. The VBUS level on any other
charge ports (if present) is not relevant.
BUG=chrome-os-partner:54099
BRANCH=reef, gru
TEST=With subsequent patches, verify charge_ramp success with a variety
of BC1.2 chargers.
Change-Id: Ie0a51a577e2b7491222560cd08dd5321ff3b7975
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/435561
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Setting the VSYSREG_SET register as per Charge State Machine of
the BD9995X datasheet.
1. Set VSYSREG_SET <= VBAT so that the charger is in Fast-Charge
state when charging.
2. Set VSYSREG_SET > VBAT so that the charger is in Pre-Charge
state when not charging or discharging.
BUG=chrome-os-partner:55220
BRANCH=none
TEST=Manually tested on Reef. Observed 'Charger State Machine Status'
register value when charging it is in Fast-Charge state and
when not charging/discharging it is in Pre-Charge state.
Change-Id: I5cd5afa92384acb4fd9d69128a2a03ae6992dc5b
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/430880
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The nvdc voltage has a kind of deep, so that rarely observed
NVDC down at this point because of back-boosting.
Our sequence to enable charger bit and setting vsysreg
is correct but rohm introduce charger may need some more time
to be stable when between chg_en and vsys_set to start charge
BUG=chrome-os-partner:60380
BRANCH=gru
TEST=Manual on kevin, trigger battery disconnect, re-attach AC, verify
system boots cleanly. and see voltage probing on c54@60380
Change-Id: Ic05091379322ffaac16fe827a47345c76c85f3e5
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/434252
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
(From CL 431233)
Limit battery charge voltage to prevent battery over-charge, due to
regulation inaccuracy. Since RO FW may charge > 8656 mV, ensure the
battery is not full before charging.
BUG=chrome-os-partner:61906
BRANCH=none
TEST=Manual on Electro, sysjump with battery @ 99%, verify battery
discharges, then re-charges to 100%, before discharging once again.
Change-Id: I28212c83057a442fd75e39f8ad51927a7a1f2817
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/432857
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
ISL9238 is able to measure currents when battery is discharging
(like ISL9237), and charging (new feature).
Reverse AMON (OTG output current) is also supported by ISL9238,
but isn't very interesting on our boards.
BRANCH=none
BUG=chrome-os-partner:61166
TEST=Plug charger, "amon" in EC console, check that values match
current meter + "battery" information. Unplug charger,
values match "battery" information.
Change-Id: I9ecae6bec9e2049d17ef1a4596dbd4e3ff59919e
Reviewed-on: https://chromium-review.googlesource.com/430474
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
ISL9237 and ISL9238 are almost identical, with few register changes,
let's make the driver generic, to support both chargers.
BRANCH=none
BUG=chrome-os-partner:61166
TEST=make buildall -j
Change-Id: I029894dd62ab7e45897d877289707ee8c1ff1d09
Reviewed-on: https://chromium-review.googlesource.com/422197
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Charger Operation Control Setting 1 (CHGOP_SET1) has separate bits to
disable input current limitation for DCP, SDP, others. If it is not
disabled, input current is automatically selected, which results in
hard resets on weak chargers hence disable the input current
limitation for all types of chargers.
BUG=chrome-os-partner:60722
BRANCH=none
TEST=Tested on Reef. Input current is not automatically set to all
types of chargers.
Change-Id: Ideb16ac2a40b403c94c28e85f254043ead7415e0
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/417234
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
When the battery is fully charged or not charging, upon removal of
the AC, discharge takes long time. To overcome this issue suspend
the DC-DC converter when discharging on AC.
BUG=chrome-os-partner:58969
BRANCH=none
TEST=Manually tested on reef. Discharge is in the permissible range.
'chgstate' console command prints correct values.
Change-Id: I64afa992e50b6e18daf43edf237fde8cf658a8a2
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/413153
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
