CONFIG_USB_PD_DISCHARGE is now defined automatically if you specify one of
the specified options such as CONFIG_USB_PD_DISCHARGE_TCPC
BRANCH=none
BUG=none
TEST=grunt still discharges using PPC
Change-Id: I94086cfc58bebce9c62ad6aa52b7740b25276d89
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/894676
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
It's no longer necessary to call board_tcpc_init() from PD tasks, since
HOOK_INIT completion is guaranteed before the task starts. Also, calling
board_tcpc_init() for each PD task without a port arg is a bad idea.
BUG=b:72229154
BRANCH=none
TEST=`make buildall -j`
Change-Id: I6fba07771693b8343568041960a263e02775a8fc
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/881538
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Edward Hill <ecgh@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>
Coral family has couple SKUs configured in clamshell form
factor, in order to avoid external magnetic field unexpectedly
switches clamshell device into tablet mode, this patch disables
tablet mode interrupt for SKUs in clamshell form factor.
BUG=b:67917181
TEST=emerge-coral chromeos-ec, image to clameshell device,
apply external magnetic field and examine no unexpected
switching to tablet mode through watching powerd logs;
alternately, watch the command 'ectool gpioget TABLET_MODE_L'
changes from 1 to 0 without interrupt, this requires some
hacking dump in board_set_tablet_mode() as reverse proof.
i.e.
tablet_mode_interrupt()
... (deferred hook)
enable_input_devices()
board_set_tablet_mode()
Change-Id: Iccf14cd5e2ea71ab3204aa386f476a9a0e1550c4
Signed-off-by: Harry Pan <harry.pan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/754148
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Coral family has couple SKUs configured in clamshell form
factor, in order to avoid external magnetic field unexpectedly
deasserts TABLET_MODE_L and switches device into tablet mode,
this patch ignores the TABLET_MODE_L pin status for those SKUs.
In other words, always set tablet_mode as 0 for clamshell SKUs.
BUG=b:67917181
TEST=emerge-coral chromeos-ec, image it to clamshell device,
apply external magnetic field and examine there is no unexpected
switching to tablet mode through watching powerd logs.
Change-Id: Ibbe08a00bb14144cad87fdd5a4a39cb3bfe2968e
Signed-off-by: Harry Pan <harry.pan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/748944
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are two different types of suspend states that are supported on
x86 platforms -- S3 and S0ix. When AP enters S3, the chipset state is
identified as CHIPSET_STATE_SUSPEND. On the other hand, when AP enters
S0ix, the chipset state is identified as CHIPSET_STATE_STANDBY. There
are several components within the EC e.g. charger state machine, usb
pd task, motion sense task that take actions based on the chipset
suspend state (and checked only for CHIPSET_STATE_SUSPEND until
now). In order to ensure that different EC components do not have to
worry about checking for all the different types of suspend states
that are supported, introduce a new combination
CHIPSET_STATE_ANY_SUSPEND which is a combination of
CHIPSET_STATE_SUSPEND(S3) and CHIPSET_STATE_STANDBY(S0ix).
BUG=b:69690699
BRANCH=None
TEST=make -j buildall. Ruben verified that with this change, EC power
consumption in S0ix drops from 7.85mW to 6.59mW on Soraka.
Change-Id: I599a0ea2fe2f39132764a6068fa77c3aea02affa
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/786919
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With the SMP and Celxpert batteries for Robo systems, following
battery cutoff, there is a race condition resulting from a failed
sb_read operation when the battery status is read. If this read fails,
then the flag battery_report_present is reset to 0. Since this flag
gets set in a hook task deferred callback, if the sb_read fails after
battery_report_present is set, but before batt_pres is set to BP_YES,
then the deferred call would not be restarted. This results in the
battery_is_present call returning BP_NO indefinitely.
To fix this condition, this CL ensures that
battery_report_present_timer_started is cleared for any case that
could result in BP_NO. This addressed both this corner case and makes
redundant a previous change that was put to handle the case where the
battery is disconnected and reconnected while the system remains
powered. The CL also adjusts the timer to 0.5 sec so that in the event
it has to be called twice, it doesn't exceed the previous 1 second
timer and delay boot time even longer.
BUG=b:69151530
BRANCH=coral
TEST=With the DUT powered, removed and reconnected the
battery. Ensured that the battery again reports present.
Bitland also verified that with this CL they can no longer reproduce
the issue.
For the corner case, had additional debug console prints.
(Note this is with 1 second timer)
The deferred call is started.
[0.156135 battery timer hook call]
This shows where the sb_read error happens in batt_init()
[1.085627 Battery FET: reg 0x0018 mask 0x0010 disc 0x0000]
[1.092251 battery: pres 0, prev_pres 0, cutoff 0, init 1, rep 0]
[1.160969 battery will now report present]
This shows where the batt_report present gets cleared
[1.184993 ******** batt_report_present 1 -> 0 *****]
[1.185840 Battery read status failed]
[1.186540 report = 0, batt_init 1->0: stat = 0x200c6bea 1 get 1]
[1.187544 battery: pres 0, prev_pres 0, cutoff 0, init 0, rep 0]
[1.193796 Battery read status failed]
[1.194886 battery: pres 0, prev_pres 0, cutoff 0, init 0, rep 0]
batt_init() no longer returns 0, so deferred call is restarted
[1.290559 Battery FET: reg 0x0018 mask 0x0010 disc 0x0000]
[1.292942 battery timer hook call]
battery reports present now
[2.293436 battery will now report present]
Change-Id: I89d69cf133365affc4cc538328daeaaf9ac05ed9
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/773623
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Scott Collyer <scollyer@chromium.org>
(cherry picked from commit 535080115d20dc223dab6288c5fea02da67c8e9c)
Reviewed-on: https://chromium-review.googlesource.com/782599
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Nearly every board had a buttons array defined in which its contents had
the standard volume buttons. This commit creates a single common
buttons array that can contain the standard volume buttons and recovery
buttons. If a board has volume up and down buttons, they can simply
define CONFIG_VOLUME_BUTTONS and it will populate the buttons array with
the standard definition. The buttons are active low and have a 30 ms
debounce period. Similiarly, if a board has a dedicated recovery
button, defining CONFIG_DEDICATED_RECOVERY_BUTTON will also populate the
buttons array with a recovery button.
BUG=chromium:783371
BRANCH=None
TEST=make -j buildall.
TEST=Flash a device with CONFIG_VOLUME_BUTTONS, verify pressing volume
buttons still work.
Change-Id: Ie5d63670ca4c6b146ec8ffb64d40ea9ce437b913
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/773794
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The reset line for the parade TCPC on port 1, has an external 1k pull
up resistor. However, the gpio.inc description for this line was set
to ODR_LOW which results in a short reset pulse. This can lead to an
external charger seeing an unattach event and dropping VBUS. On some
Coral systems with certain chargers this results in a continuous
reboot loop when no battery is connected.
Changing the default state of this line to ODR_HIGH prevents reset
from being pulled low until the EC is intializing the TCPC and fixes
the continous reboot loop issue when no battery is connected.
BUG=b:68226308
BRANCH=coral
TEST=Using Robo system tested with the Lenovo Type C charger and
verified that the system can boot up without a battery when connected
to port 1. Bitland also verified this change in their test setup and
found no failures.
Change-Id: Ia16fe8cf770dc91da479497d234a2b6f9679b878
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/762066
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Coral uses a 1 second delay to report battery being present to help
avoid VSYS glitches than can affect H1. On Eve, it was not expected to
remove and reconnect the battery while running. However, on Coral the
battery connector allows this action to take place.
Current if the battery is removed, when it's reconnected it can't
report as present because the timer_started flag is not being
reset. This CL checks for the case where the battery is not present
after being present and uses that as a trigger to reset the
battery_report_present_timer_started flag.
BUG=b:66923031
BRANCH=coral
TEST=While Coral unit has battery and ext AC connect, remove the
battery connector. Verifed the console log showed that this condition
was caught. Waited about 10 seconds, then reconnected battery and
verified that it reports as present.
[52.778818 Battery was present, but is now removed]
[60.211048 battery will now report present]
[60.217801 Battery FET: reg 0xe000 mask 0x4000 disc 0x0000]
[60.711195 battery woke up]
Change-Id: I41ae8c1b04a56697d20d3037b94189aff778fc4d
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/754025
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
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>
Charge port / current selection often needs to be significantly altered
when a battery cannot provide sufficient charge, so have charge_manager
initially enter safe mode. After a battery with sufficient capacity has
been identified, charge manager will leave safe mode, and port / current
selection will return to standard rules.
BUG=chromium:777596
BRANCH=None
TEST=Pass charge_manager unit tests. On kevin, remove battery, attach
Apple PD charger, verify safe mode is not exited and device does not
brown out. Hot-plug battery and verify safe mode is exited. Next,
remove battery, attach to Samus, verify safe mode is not exited and
device doesn't brown out. Hot-plug battery, verify that safe mode is
exited and no active charge port, due to dual-role exclusion.
Change-Id: I7784865750087a037aad8dbbac058b22c77ba6d4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/733954
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Most boards had an identical implementation for this function,
previously known as board_is_consuming_full_charge(). To reduce copy
paste, let's just move it to common code. Boards that charge ramp
without a battery will have to define their own implementation, but
there probably won't be any boards like that in the near future.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: Ic99a378ac26dfd35d7d718bf9376eacfa8609166
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/748919
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Robo's LED spec is Red <= 5%, Orange 6 < SOC < 97, Green >=
97%. However, the table had Orange and Green flipped. This CL corrects
that error.
BUG=b:64192049
BRANCH=coral
TEST=Used EC console battfake command to verify that charge LED color
is red until 5%, then orange until 94%, and green after that. Note the
94% limit is due to the define CONFIG_BATTERY_LEVEL_NEAR_FULL which is
set to 94 as that's when the battery will want charging again after
reaching 100%.
Change-Id: Ia8395d6ca28ab000e12fb7a43f13721c7959e35d
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/748971
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The default behavior for this state is the charge color for 1 second
and then off for 3 seconds. The existing table entry for this state
was incorrect.
BUG=b:67759004
BRANCH=none
TEST=Verfied that in S3 state the pattern is 1 second charging color
followed by 3 seconds off.
Change-Id: I838cdb34a23cd9224761bd7f16a3a1d9cb980fd6
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/741076
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Coral inherited from Reef a board.h modification of CC_DEFAULT which
disabled Events and the LPC channel. The LPC channel console prints
are required for the FAFT test firmware_ECBootTime
BUG=b:63488727
BRANCH=none
TEST=Tested with and without CC_LPC channel and verified that the FAFT
test firmware_ECBootTime pass/fail tracked accordingly.
Change-Id: I1e943978a4f23ee8f53e6951549f31c7231e463f
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/736679
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Tested-by: Peggy Chuang <peggychuang@ami.corp-partner.google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
According to the USB-C spec, when a debug accessory is identified, we may
optionally establish USB PD communication over CC. Some DTS partners
(eg. servo_v4) expect us to speak PD, so let's make it so. There is no
need for special ACCESSORY states, these do not exist in the PD spec.
BRANCH=servo
BUG=chromium:737755,b:65837068
TEST=On scarlet, attach servo_v4 and verify scarlet charges. Also verify
EC and cr50 consoles are available through servo_v4.
Change-Id: I59d1ca50b4766509eccf38562cdf926578138585
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/693294
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The GPIO lines for the charger LED are being used as simple on/off and
no PWM control is used. Removed them from the pwm channel list so that
it reflects more accurately what PWM is used for on Coral.
BUG=b:64192049
BRANCH=None
TEST=make -j BOARD=coral
Change-Id: I3546001f96cb01f81fa1c373de28e460b63012c1
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/717187
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Robo devices have a power button LED. For these devices the desried
power button LED behavior is:
S0 -> always on
S3 -> charging, then 500 mSec off, 3 seconds on
S3 -> not charging, always off
S5 -> always off
Because the hook tick runs at 200 msec, using 600 msec for the off
period when blinking in S3.
BUG=b:64015212
BRANCH=None
TEST=Manual
This LED is not connected on EVT, so added a wire on GPIO02 and used a
scope. Verifed that in S0 the signal level is low, and in S3 that it
control signal toggles 600 mSec high/3 sec low. Verifed than in S5
control signal is high.
Change-Id: I72438a009a507fcddaae5a673bf3bc83988f2dd5
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/717183
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
No Coral configurations will contain the ambient light sensor
(ALS). Therefore, no reason to have support for this in the board.c/.h
files.
BUG=b:38271876
BRANCH=eve
TEST=make -j BOARD=coral and verify no errors.
Change-Id: Ib8f6c546d5fb4d0bb8d37e84a62c4725e37be6f5
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/711196
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This CL adds the config option CONFIG_DYNAMIC_MOTION_SENSOR_COUNT and
SKU table which contains the form factor for all known SKUs. Once the
SKU ID is known, the variable motion_sensor_count is set based on
CLAMSHELL or CONVERTIBLE designation in the SKU table. If there isn't
a matching SKU ID in the table then motion_sensor_count will be
initialized to the ARRAY_LENGTH of motion_sensors.
BUG=b:38271876
BRANCH=None
TEST=Manual
Tested with Robo360 (SKU ID 71) and verified the motion sensor count
and that the motion senors were initialized in the EC console log.
[0.088188 Motion Sensor Init: count = 3]
[0.346097 Lid Accel: MS Done Init type:0x0 range:2]
[0.370386 Base Accel: MS Done Init type:0x0 range:2]
[0.386790 Base Gyro: MS Done Init type:0x1 range:1000]
Tested with Santa EVT (SKU ID 3) and verified motion_sensor_count is 0 and
no EC console messages showing sensor initialization failures.
Change-Id: Ia3d60f8c8dd4435dd7cfb80a860f809de2fb931e
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/711195
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The Nasher simplo battery uses the Reneas fuel gauge. The table entry
for this battery had TI fuel gauge assumption. This CL modifies the FET
info to use register 0x43 and bits 1|0.
In addition added console log entry for the FET register, mask, and
expected value. In normal cases this log message will appear only
once, but when recovering from battery cutoff, will have have one
entry per call until the battery is no reporting as disconnected.
BUG=b:64887361
BRANCH=None
TEST=Using nasher proto system connected the SMP-SDI3.72
battery. Tested normal start up and after doing a battery cutoff.
Normal caseL:
[0.038624 found batt:SMP-SDI3.72}
[0.046017 SW 0x01]
[0.068892 hash start 0x00040000 0x00020d08]
[0.075775 Battery FET: reg 0x001b mask 0x0003 disc 0x0000]
After battery cutoff:
[0.146889 Battery FET: reg 0x0008 mask 0x0003 disc 0x0000]
[0.161523 Battery FET: reg 0x0008 mask 0x0003 disc 0x0000]
.
.
[0.476275 Battery FET: reg 0x001b mask 0x0003 disc 0x0000]
Change-Id: Ie378e9a795f543763a02c6c062235b265be0f71c
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/705260
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Implemented an led state table based implementation for LED control of
the battery LED. The states are the same as previous Coral/Reef single
LED control with the exception of allowing for 3 charging states based
on the current battery state of charge level. Now the desired state
is determined and that's used to access the correct LED behavior based
on the current tick count.
Changed from a one second tick to the NPCX 200 msec tick so the Robo
power button pattern can be supported as well.
The are currently two tables implemented, one for Robo devices, and
the default table. At init time, after the SKU ID is determined, the
correct table is assigned.
BUG=b:64192049
BRANCH=None
TEST=Manual
Tested both Coral proto and Robo EVT systems. Verifed operation in the
different states. During tested used modified charging level tables
so the 3 different charging states could be exercised. Also removed
battery to verify the error state.
Change-Id: Ifc6935f73d4fed1eeec9c5aab13f6346f61857ff
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/693387
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@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>
Boards that use charge_manager have identical implementations of
typec_set_input_current_limit() and pd_set_input_current_limit(), so
move these functions to charge_manager.
BUG=b:67413505
TEST=`make buildall -j`, also verify that fizz continues to power-on and
boot AP, in both protected and unprotected mode, with barrel jack power
and with zinger.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I99a5314d02c4696db944c0f8ac689405f4f1f707
Reviewed-on: https://chromium-review.googlesource.com/701412
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Runtime S0ix results in SLP_S0 signal being toggled continuously
resulting in an interrupt storm on the EC. In order to avoid this,
enable SLP_S0 power signal only when host indicates intent to enter
S0ix and disable when host exits from S0ix.
BUG=b:65421825
BRANCH=None
TEST=Verified that runtime S0ix no longer results in interrupt storm
on EC. Normal S0ix works fine on soraka. Verified state of SLP_S0
using powerindebug.
Change-Id: I9ca62b8122afd8acedc2c353106407fdcc284925
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/679982
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When the battery gets to returns the FULL flag, bd99956 charging is
disabled and battery learning is enabled. This state will remain until
the FULL flag is cleared by the battery. The original fix had this
level at 97%, but on the various batteries tested this appears to
happen at 95%. The CONFIG_BATTERY_LEVEL_NEAR_FULL allows an adjustment
for this level and is only used for LED states.
BUG=b:64192049
BRANCH=None
TEST=Manual Let system charge to 100% when FULL flag is set in the
battery, verified the LED was in correct state. Then let battery drain
until the FULL flag is clear and observe that the battery requests
charge current. The LED stays in the expected full charge state.
Change-Id: I74d26abd5d8021bcfacdc3a4c3d4baba6a978bca
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/693386
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Replace structure member "level" in power_signal_info with "flags".
"level" has been used on all boards to indicate active-high or
active-low levels. Addition of "flags" allows easy extension of
power_signal_info structure to define various flags that might be
applicable to power signals (e.g. "level"). Going forward, additional
flag will be added in follow-up CLs.
Also, provide a helper function power_signal_is_asserted that checks
the actual level of a signal and compares it to the flags level to
identify if a power signal is asserted.
BUG=b:65421825
BRANCH=None
TEST=make -j buildall
Change-Id: Iacaabd1185b347c17b5159f05520731505b824b8
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/679979
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
1.Add LG battery for Santa and Porbeagle.
2.Santa LG battery manufacture name is same as BATTERY_LGC011, so use
device name to recoginze Santa LG battery.
3.These two battery have different process to get FET status, make
sure battery not use this process is before BATTERY_LGC15 to separate
these two different process.
BRANCH=none
BUG=b:65426428, b:64772598
TEST=Make sure battery can cutoff by console "cutoff" or "ectool cutoff"
and resume by plug in adapter.
Change-Id: I7095b9d0915fb4d39aa6c9f8c8751aa22941e938
Signed-off-by: David Huang <David.Huang@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/674472
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Servo / Suzy-Q related debugging methods is a big challenge
in factory especially after servo debug header is removed.
Expose some information to OS from EC will do a great help
for massive production.
+ expose charge/battery related state to ectool
1. chg_ctl_mode
2. manual_mode
3. battery_seems_to_be_dead
4. battery_seems_to_be_disconnected
5. battery_was_removed
6. disch_on_ac (learn mode state)
7. battery DFET
BUG=b:65265543
BRANCH=master
TEST=`ectool chargestate param x10000~0x20006 get correct state`
Change-Id: Ib64ab3c7b68a634ea098425c93e5234361cd1936
Reviewed-on: https://chromium-review.googlesource.com/662318
Commit-Ready: Ryan Zhang <ryan.zhang@quanta.corp-partner.google.com>
Tested-by: Ryan Zhang <ryan.zhang@quanta.corp-partner.google.com>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The manufacturer names for the Robo LG and Simplo batteries were
incorrect. Both of them had an '/011' which is not actually part of
the name. This has been fixed. In addition, the ship mode command
needs to be 0x0000 followed by 0x1000, but it was using 0x0000 and 0x0001.
BUG=b:64821365
BRANCH=None
TEST=manual
Tested Celpext, SMP, and LG batteries with EVT systems. Verified that
'cutoff' from EC console and 'ectool batterycuttof' from AP console
caused the battery cutoff to take effect. Also verified the
manufacturer name from the batteries matched the what's stored in the
battery info table.
Change-Id: I48369da4d2c6137b50614b003df57a359a49c4f4
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/662137
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reworked suzy-q and suzy-qable all provide Rp, so there is no need for
special detection handling in S5. Also, CONFIG_USB_PD_QUIRK_SLOW_CC_STATUS
is no longer relevant, since we no longer take special action when VBUS
is seen without Rp.
BUG=chromium:737755
BRANCH=None
TEST=On kevin, verify reworked suzy-q and suzy-qable are detected in S5.
Also, verify zinger works in S5 on reef.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I50967bd6415d964a038b2e7d134374132eda11ec
Reviewed-on: https://chromium-review.googlesource.com/656067
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
SYSTEM_IMAGE_RW_B hasn't been globally treated as a RW copy.
This change makes EC treat it also as a RW copy.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Iae5a9090cdf30f980014daca44cdf8f2a65ea1f2
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/656337
Reviewed-by: Randall Spangler <rspangler@chromium.org>
- This CL adds the infrastructre needed to support different battery
types for the Coral project.
- This includes adding a battery_check_disconnect common function
that's used folloiwng battery cutoff events to ensure that the
battery is able to provide power before reporting it as present.
When the battery is not present, there is a 1 second delay used
before allowing the battery to report as present. This specific
change is motivated by an issue discovered on Eve which resulted in
H1 power rail issues and could lock up the H1.
https://chromium-review.googlesource.com/c/592717https://chromium-review.googlesource.com/c/585837
- This includes a battery_cutt_off_battery common function that can
be used by all battery types using the register and regiseter data
required for each battery's ship mode.
BUG=b:64772598,b:64728711,b:64821365
BRANCH=None
TEST=manual testing on Coral proto with Sanyo battery and tested on
Nasher with BYD and LGC-LGC.593 batteries. Verified that battery
cutoff command via EC console works. Verified that can start up as
expected following battery cutoff. Also tested battery cutoff
initiated by removing the battery from the system while it's powered
up. Also tested 'ectool batterycutoff at-shutdown' from the AP console
and verifed that battery cutoff was successful following 'apshutdown'
on the EC console.
Change-Id: I9d884efa9d64fb94d46447feb028c5d9ae82a20f
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/627496
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Allow reporting that keyboard backlight doesn't exist even when the code
is compiled in. Useful if there are multiple device models that should
share firmware.
BUG=b:64705535
BRANCH=none
TEST=none
Change-Id: I9c1fc370aedf66ef856a571f73831095d27e3d39
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/633926
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
we need to properly restart the anx3429 after a firmware update.
simply initializing the chip doesn't seem to get it to reload its
firmware - at least not the portion of the chip that implements the
firmware version register. so, we explicitly power down and reset the
chip before reinitializing it to force it to run the new firmware.
the chip also needs a 10ms "off" time so the reset is properly seen by
the chip, so i did a light refactoring of the code paths that reset
the anx3429.
TEST=used 2 different firmware blobs and verified it switches between
them during software sync.
BRANCH=none
BUG=b:35586895
Change-Id: I967898dd906f21bdc5bc4ce9c1dff9f873d198c1
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/631976
For some boards, the control lines to the charging port controller are
all tied to a power rail. In essence, this leaves the ILIM_SEL as the
only signal able to be controlled, which means that we only support
CDP/SDP.
This commit adds a new CONFIG_* option which describes this.
CONFIG_USB_PORT_POWER_SMART_CDP_SDP_ONLY
Additionally, some cleanup is made to not always assume the number of
smart power ports.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: I080ccd67ffc20ccccf1e6b33a3cf9374a6b70ad6
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/634274
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This CL enables the config option CONFIG_USB_PD_TCPC_BOARD_INIT and
modifies the board level tcpc init function to wait up to 2 seconds
to ensure that the battery is out of its disconnected state.
This change was put into Eve to ensure the PD chips are not reset until
the battery is out of disconnect and delay start of the pd_task
(and PD negotiation) until the battery is out of disconnect state.
This is part of a change was initially done on Eve
https://chromium-review.googlesource.com/c/592716.
For Coral the delay of tcpc init relative to the PD task also
addresses an issue where VBUS would be dropped by the external charger
when attempting to boot with no battery connected. When no battery is
connected there is a timing issue between the Analogix TCPC and the EC
related to when the TCPC sends its auto GOODCRC. This results in a
hard reset which causes the drop of VBUS.
BUG=b:64375688
BRANCH=none
TEST=Tested by Bitland using 500 iterations and showed no occurrence
of the hard reset causing VBUS to drop. Prior to this CL, the failure
rate was 1 out 300 attempts.
Change-Id: I28fe3266eb1c0a2940e1bdacee65cf4e642d3483
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/627115
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to satisfy factory testing requirements we need to
boot a bare board with just an AC adapter without requiring
a power button.
However we also don't want to always allow booting of the
battery is present but cut-off (which will indicate BP_NO so
we can't use the existing battery_is_present function) or has
critically low level as it may not immediately boot.
To accomplish this add a function that allows the board to
specify a custom "hardware presence" for the battery that is
separate from the battery presence check.
This CL is taking a change done for Eve and pulling into TOT so it can
be used for other projects that have the same
requirements. https://chromium-review.googlesource.com/c/582544
BUG=b:63957122
BRANCH=none
TEST=manual
Change-Id: Ib1dc4f659adbf0eebd3dc8c3c61b39b8fa36cb4a
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/627113
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The Coral schematics are being changed to reflect that volume up is
connected to GPIO83 and volume down to GPIO82. The current EC code
implemented this same assignment, but introduced an intermediate
signal name to match with previous schematics which had the opposite
assignment. With the signal names fixed on the schematic, the
intermediate #defines are no longer needed.
BUG=b:64012307
BRANCH=None
TEST=manual testing on Coral proto. Verified that up button presses
cause the volume bar to go up and volume down button presses cause the
volume bar to go down.
Change-Id: Ib04f8416e8f36271972fc650bf1593a4babaeb82
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/625063
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
