define CONFIG_CMD_BATDEBUG to enable console commands.
If the battery is larger than 6Ah or smaller than 150mAh, scale the parameters
transparently to the user using macros.
BUG=chrome-os-partner:34477
BRANCH=none
TEST=Custom console commands for the fuel gauge
I also used a Logic16 from Saleae and the fuel gauge on hadoken.
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: I959d51c3188336e4ad0983528ad7e53a2955a764
Reviewed-on: https://chromium-review.googlesource.com/234285
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
Fix accelerometer bug in which, if there is no new data from
the lsm6ds0 accel, it will use the old ajusted xyz instead of
the old raw xyz.
BUG=chrome-os-partner:34952
BRANCH=samus
TEST=add printf to case where it uses old data and sample faster
then ODR to read wrong data.
Change-Id: If0a6bbdec71d84567eae107aca6f1d0ab754919a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237664
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add initial serial driver for mdcp2850 dp->hdmi converter. Driver
implements 'get information' (cmd:0x40) to provide rudimentary method
to test mcdp for functionality and assert GPIO if successful.
Future CLs may expose more serial functionality if necessary.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34122
TEST=manual, when compiles with #define MCDP_DEBUG see successful
serial communication and result from get info.
buf:[00]0x04 [01]0x40 [02]0x00 [03]0xbc
...
buf:[00]0x0f [01]0x40 [02]0x00 [03]0x0e
[04]0x00 [05]0x01 [06]0x01 [07]0x00
[08]0x00 [09]0x00 [10]0x00 [11]0x00
[12]0x00 [13]0x00
family:000e chipid:0001 irom:1.0.0 fw:0.0.0
Change-Id: I35f9d9b0437633d1bd6a6c9fa14413bedb12f5c2
Reviewed-on: https://chromium-review.googlesource.com/235930
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Set charge state machine voltage to just above the battery voltage
when AC is disconnected. Also send new current before sending new
voltage to charger when there is a change. These changes reduce
input current spikes caused by current inrush into the battery and
thereby decrease chance of overcurrenting power supply on connect.
BUG=chrome-os-partner:33862
BRANCH=samus
TEST=load onto samus instrumented with input current probe. when
AC is attached note that initial current spike is much lower with
this change.
Change-Id: I7760cd2b709c6b3536cf2a9449bb1f46800ce10a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237245
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
According to specification, a DCP port is only required to provide 500mA
@ 4.75V, though actual supply limit can vary upward significantly. Set
the current limit on DCP ports to 500mA to reflect this reality.
BUG=chrome-os-partner:32003
TEST=None
BRANCH=Samus
Change-Id: I46e25b44baaa41ddf173880e52d7485d952ebf23
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236772
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Samus USB ports can't actually act as UFPs, so open switches when in
UFP mode.
BUG=chrome-os-partner:32003
TEST=Manual on Samus. Connect two Samus units, run `pd 1 swap data`,
verify that switches are opened on switch to UFP. Unplug samus and
connect a USB 2.0 device instead, verify that ports are again closed.
BRANCH=samus
Change-Id: I9e1ca58089caf29e419698c8426bf8b72500833a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233711
Reviewed-by: Alec Berg <alecaberg@chromium.org>
MOTIONSENSE_CMD_DUMP is deprecated, replaced with MOTIONSENSE_CMD_GET_DATA
Also use vector_3_t instead of x,y,z
ectool motionsense commands only work with newer firmware, to
handle a dynamic number of sensors.
- The host sends the number of sensor it has allocated space for.
- If 0, the EC just sends the number of sensors available
- Otherwise returns sensor information up to the limit imposed by the host.
Remove MOTIONSENSE_GET_STATUS: not needed. It is only useful for LPC,
to guarantee atomicity of the data.
Remove MOTIONSENSE_GET_DATA: not needed since we increase the version
number of MOTIONSENSE command.
BUG=chrome-os-partner:31071,chromium:430792
BRANCH=ToT
TEST=Compile. On a firmware that support the new command:
/usr/sbin/ectool --name=cros_sh motionsense
Motion sensing active
Sensor 0: 92 15 1030
Sensor 1: -94 -63 718
/usr/sbin/ectool --name=cros_sh motionsense active
0
On a machine with older firmware (samus), check these
functions are not working anymore.
Change-Id: I64b62afff96670fb93457760d43d4e64e26e029f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226880
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Get type-c port power info including power role, charger type,
and charging info. Also added host command to get number of type-c
ports.
Also adds new charging suppliers for pericom identified chargers
including DCP, CDP, SDP, proprietary, and other chargers. Priority
of these for charging is set in samus board file.
BUG=chrome-os-partner:32650
BRANCH=samus
TEST=run 'ectool --name=cros_pd usbpdpower' and verify correct
status with minimuffin, zinger, and type-C to type-A adapter.
Change-Id: I1dabbe7de4185a23df5684a5ea9a2d944f1f6ff5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223523
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Split motion_sense.c.
Translate the accel data in the Android coordinate right away.
BUG=chrome-os-partner:32002
BRANCH=ToT
TEST=On samus, check lid angle are still correct.
Change-Id: If743e25245dc1ce4cdacb8a4d5af22616c4a79e4
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225486
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The original algorithm is given in the TMP006 User's Guide
(SBOU107.pdf). The algorithm we previously implemented is that,
plus some additional and completely undocumented massaging of the
Tdie and Vobj registers. The original meaning of that hack is now
lost in the mists of time, thanks to our email retention policy.
This CL introduces a new algorithm variant, but at least this
time the details are in the bug report. It's essentially the same
as the User's Guide algorithm, except that we apply one-stage FIR
filters to the Tdie input and the Tobj output.
There are five new parameters: d0, d1, ds, e0, e1. Refer to
tmp006_read_object_temp_k() in ec/driver/temp_sensor/tmp006.c to
see how these new parameters are applied.
CAUTION: The tmp006 sensor algorithm is mostly math and magic
numbers. The spreadsheet attached to the bug report has six
sheets with wildly varying values for those parameters. Since the
correct parameter values haven't yet been determined for Samus,
all I can be sure of with this CL is that it seems to work and
isn't any worse than the old one.
Oh, and note that the EC's 't6cal' console command has been
disabled until/unless we add support for floating point IO. Use
ectool from the host to get and set the params instead.
BUG=chrome-os-partner:32260
BRANCH=ToT,Samus
TEST=manual
After booting, look at the sensor values using ectool:
localhost ~ # ectool temps all
0: 312
1: 314
2: 313
Sensor 3 not calibrated
4: 311
Sensor 5 not calibrated
6: 305
Sensor 7 not calibrated
8: 306
Sensor 9 not calibrated
10: 307
Sensor 11 not calibrated
12: 312
Sensor 13 not calibrated
localhost ~ #
localhost ~ # ectool tempsinfo all
0: 0 PECI
1: 1 ECInternal
2: 1 I2C-Charger-Die
3: 2 I2C-Charger-Object
4: 1 I2C-CPU-Die
5: 2 I2C-CPU-Object
6: 1 I2C-Left C-Die
7: 2 I2C-Left C-Object
8: 1 I2C-Right C-Die
9: 2 I2C-Right C-Object
10: 1 I2C-Right D-Die
11: 2 I2C-Right D-Object
12: 1 I2C-Left D-Die
13: 2 I2C-Left D-Object
EC result 2 (ERROR)
...
localhost ~ #
There are six tmp006 object temps that need calibrating. The
index used for the calibration is for the tmp006 objects, not the
3,5,7,.. numbers reported for all temp sensors. See the current
values with tmp006cal:
localhost ~ # /tmp/ectool tmp006cal 5
algorithm: 1
params:
s0 0.000000e+00
a1 1.750000e-03
a2 -1.678000e-05
b0 -2.940000e-05
b1 -5.700000e-07
b2 4.630000e-09
c2 1.340000e+01
d0 2.000000e-01
d1 8.000000e-01
ds 1.480000e-04
e0 1.000000e-01
e1 9.000000e-01
localhost ~ #
If the s0 param is zero, this sensor is uncalibrated. The params
are entered in the order in which they're displayed You can
change any or all of the parameters. Skip the ones you don't want
to update by specifying '-' for its position. (Note: throw in an
extra '--' first so that ectool doesn't think that negative
numbers are command options).
For example, to change s0 and b0:
localhost ~ # ectool -- tmp006cal 5 1.0 - - -3.0
localhost ~ #
localhost ~ # ectool tmp006cal 5
algorithm: 1
params:
s0 1.000000e+00
a1 1.750000e-03
a2 -1.678000e-05
b0 -3.000000e+00
b1 -5.700000e-07
b2 4.630000e-09
c2 1.340000e+01
d0 2.000000e-01
d1 8.000000e-01
ds 1.480000e-04
e0 1.000000e-01
e1 9.000000e-01
localhost ~ #
Now sensor 13 (tmp006 object index 5) is calibrated:
localhost ~ # ectool temps all
0: 310
1: 315
2: 313
Sensor 3 not calibrated
4: 310
Sensor 5 not calibrated
6: 305
Sensor 7 not calibrated
8: 307
Sensor 9 not calibrated
10: 307
Sensor 11 not calibrated
12: 312
13: 313
Change-Id: I61b5da486f5e053a028c533ca9e00b9a82a91615
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224409
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The register format of INA231 and INA219 are very much alike. In our
use case, we only need to use different coversion coefficient.
BRANCH=None
BUG=chrome-os-partner:32764
TEST='ina 0' on Plankton V2.
TEST=Build twinkie.
Change-Id: I9c8e21e30ed844566793dcc1221f865400c3d90d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223370
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Decode Pericom registers to current limits.
BUG=chrome-os-partner:32003
TEST=Manual on samus_pd. Insert 1A Apple charger, verify current limit
is correctly detected as 1A.
BRANCH=samus
Change-Id: I310d9f22cef80e97c1734e6a56f0034ebe01df31
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222638
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When charger is initialized disable the LEARN option i.e. reenable
charging on AC power
BUG=chrome-os-partner:32320
TEST=set DUT to discharge on AC and then reflash EC. Ensure that
charging begins again.
BRANCH=none
Change-Id: I3e83db27ab49548d5491548fa624899865c11bfb
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222644
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Design Goals:
1. Every time the AP boots, the same default sensor settings are configured.
2. If the AP goes to suspend (S3) and wakes back up (S0),
then the AP sensor settings will be restored.
3. In S3 and in S5, only sample specific sensors that are needed.
BUG=chrome-os-partner:32368
BRANCH=ToT
TEST=Verified on Samus.
Verified suspend and resume logic with EC console messages.
- Test Case0: close lid & open lid
- Test Case1: powerd_dbus_suspend
Change-Id: I553c53e63ecfcb39d5e649a7189aa6ea02589471
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220371
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Enable fast charging with profile designed for ATL cells
that will be used in EVT.
BUG=chrome-os-partner:23776
BRANCH=none
TEST=Took detailed charging/discharging data and verified
that the actual profile matches the desired profile and that
the fast charging profile is actually faster than the
standard. See bug report for more info and data collected.
Change-Id: Ic11ab89e48afb73987b8013abf8b0564e1138156
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212980
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Changed motion_sense task to assume sensors are unpowered in G3
and re-initialize sensors every time coming out of G3.
Added EC command line test utils as well.
Fixed some bug during unit tests.
BUG=chrome-os-partner:27313,27320
BRANCH=ToT
TEST=Verified on Samus.
Tested with accel EC CLIs
accelread, accelrange, accelrate, accelres
Tested accelcalib, a ACCEL calibration util, and it succeeded.
Tested sysfs interface:
cd /sys/bus/iio/devices/iio:device1
cat in_accel_*_gyro_raw
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Change-Id: I5752b00c03e1942c790ea4f28610fda83fa2dcbc
Reviewed-on: https://chromium-review.googlesource.com/211484
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Previously our accel / gyro drivers assumed that we had exactly two of
each identical part in the system. Some systems may have different
configurations, so allow this to be specified at the board-level.
Note that our motion_sense algorithm currently assumes that we have one
accelerometer in the lid and one in the base -- we'll need to fix that
in another CL.
BUG=chrome-os-partner:27320
TEST=Compile-only. Tested in future Samus commit.
BRANCH=None.
Change-Id: I1fae1f6c578fedebe78b473a5d66a5794ccaae00
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212321
Reviewed-by: Alec Berg <alecaberg@chromium.org>
During flash erase operation, read is stalled and thus interrupt might
be serviced later. This can cause PD communication to fail and thus the
board reboots if there is no battery. Print a warning message in this
case.
BUG=chrome-os-partner:31127,chrome-os-partner:31207,chrome-os-partner:31362
TEST=Boot Ryu, on software sync, see warning message before board
reboots.
BRANCH=None
Change-Id: If327a4f533fd2dfa83f92531148bd52ace927e03
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212264
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Currently charge state machine resets input current limit to default
every time AC is connected. Problem is by the time charge state machine
gets around to setting input current, it could have already been set
by successful PD negotiation, and this ends up overriding that value.
This fix has the state machine store desired input current limit, as
determined from PD negotation or any other place, and send last desired
input current limit on AC connect.
BUG=chrome-os-partner:24461
BRANCH=none
TEST=load on samus, test toggling between "pd 0 dev 5" and "pd 0 dev 20",
and test plugging and unplugging zinger numerous times, and verify charger
command always gives the expected input current limit based on PD
negotiation.
Change-Id: I18d8acc9e2085739e783c9c70c682d46bcce7fdb
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211639
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Set input current limit based on the max current from the
PD negotiation. For samus, this information is passed to
the EC as a host command. For ryu, the max current is set
directly following a negotiation.
CONFIG_CHARGER_INPUT_CURRENT is now just the default limit,
but after a successful PD negotiation, the limit can be
raised.
Note, for now the input current limit for samus is set to
2/3 of the value negotiated for. This is due to hardware
problems measuring input current on p2b boards.
BUG=chrome-os-partner:28532, chrome-os-partner:24461
BRANCH=none
TEST=tested on a samus. Verified input current limit using
"charger" console command from EC. Input current limit
after a reboot is 512. When zinger is plugged in, it jumps
to the appropriate value (currently 1280mA), and when
the negotiation is changed using the "pd 0 dev 5" command
on the PD console, the input current limit is adjusted to
match (2000mA).
Change-Id: Iab9186a0f9814655e3240217a9baf4a38f15f84d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211023
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Update the code to be compatible with charge v2 expectations :
never return EC_ERROR_UNIMPLEMENTED for battery information else the
charge code continuously tries to read them again.
Fix the State Of Charge reading : on BQ27741 the gas gauge gets confused
if we do a 16-bit I2C read while a 8-bit read works perfectly.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run a Ryu connected to a Kirby battery and check the output of the
"battery" command.
Change-Id: Ic1d6128dc02efa47662fa5ca5b9e5de62420ebe8
Reviewed-on: https://chromium-review.googlesource.com/207273
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Like Samus, the battery can be placed into a disconnect state. This CL
implements the necessary function to determine if it is so and kick it
out of this state when possible.
BUG=chrome-os-partner:30633
TEST=Put a battery in this state. Plug in AC. Verify the battery is
revived.
BRANCH=None
Change-Id: I074a72a2efe3844cbdfb0eda16a25fd8d1755a9b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209634
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The Samus battery can be placed into a disconnect state by asserting a
disconnect input signal. In this state, the battery will not function
until a charging current is applied. This patch adds detection of the
disconnect state. If a battery in disconnect state is found, a current
is force-applied to the battery to kick it out of disconnect.
BRANCH=None
TEST=Manual on Samus.
1. Put battery into disconnect state
2. Pull AC, then reattach AC
3. Verify "found battery in disconnect state" is seen on the
EC console.
4. Pull AC and verify that EC console is still accessable
Also verify that battery gets out of reset state:
1. Pull AC
2. Issue "i2cxfer w16 0 0x16 0x0 0x12" command on EC console
3. Re-attach AC
4. Pull AC and verify that EC console is still accessable
BUG=chrome-os-partner:29465
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib4268887fb483094ac4e641749200268160d3014
Reviewed-on: https://chromium-review.googlesource.com/209013
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
These changes were made in files that did not have the [%T ... ]
pattern. These files were broken by the change because they still
contained uses of the CPRINTF macro. There were two options to fix
this, switch to the CPRINTS macro and get the timestamp added to
these strings, or switch those files back to defining the CPRINTF
macro. Switching back seems like the right thing since it doesn't
change the output of those debug messages.
This commit also adds newline termination to a few invocations of
CPRINTF that were missing it, but obviously wanted it.
This breakage is only visible with a particular set of CONFIG_
defines that no boards currently use.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Change-Id: I784b52dc385b29f05d7b9bc1521e37597409153b
Reviewed-on: https://chromium-review.googlesource.com/206281
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
The ACOK input to the EC is not connected to the charger so
that signal cannot be relied on for AC presence. Instead
have the PD report when it negotiates to 20V and when it
disconnects and have the EC use that for AC presence.
BUG=chrome-os-partner:29841
BRANCH=none
TEST=test charging with zinger on samus system.
Change-Id: Ia9096a24ab05d110e31910218dc8c214a846a9a4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205145
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This changes the input current limit to 2048mA with no ramp up.
Problem is that the bq24773 is doing a really poor job of measuring
input current, so even though the zinger side can support 3A, the
samus side can cause over currents down to 2300mA. This is set
consertavily to avoid over current errors and will need to be
updated when the hardware allows.
BUG=chrome-os-partner:24461
BRANCH=none
TEST=Used bench top power supply to power multiple samus 2A proto
boards and gathered data on max current samus was drawing based on
input current setting. Samus was often underestimating current by
300-700mA.
Change-Id: Iabeb0d026f2b72a9ee539d92579ee6d11aeaa56b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205143
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On samus battery, when the battery is dead it reports 0 for desired
voltage, current, and state of charge. In this case we should allow
charging.
Added a CONFIG option for this that should be removed as soon as
the battery side is fixed.
With this CL, when a dead samus battery is used and a charger is
connected, we attempt to charge it.
BUG=chrome-os-partner:29465
BRANCH=none
TEST=test on a samus with a dead battery. w/o this CL, the battery
never charges because the charging not allowed flag is set. With this
CL, the battery charges.
Change-Id: Ic61f27a27237166d33cb9ea5f024d3ef6360ce82
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202603
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Set maximum input current limit to ~2.5A to prevent over current
faults on zinger. Note, we still get over current faults sometimes
but it always clears in < 10seconds.
BUG=chrome-os-partner:28611
BRANCH=none
TEST=Test with a samus 1.9 and a zinger. Plug and unplug charger
many times and make sure that we are eventually able to successfully
negotiate for power and start charging.
Change-Id: I5a7adf9fc7f5ed7a0c7dfdb620e0c1474f72a878
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201154
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Typically bq24xxx charging chip limits input current to minimum of
register value and ILIM pin. For fruitpie, the current limit will
be decided solely in software, and the hardware pin will be ignored.
BUG=chrome-os-partner:28611,chrome-os-partner:28311
BRANCH=none
TEST=Tested on fruitpie. Verified that current limit can be set
above the ILIM pin value of 500mA.
Change-Id: Ia687446f95f9d18fde9d2b4ebb0e1c093aebf885
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198940
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Some battery uses clock stretching feature, and this could disturb
PMU communication before battery going stable.
AP does not know and will attempt PMU setting, and could get fail
For various battery indicates usually 1s for stable
(even if it is much less in real world 200ms~700ms)
Let's checking 'battery is ready' when first pump-up power.
BRANCH=ToT
BUG=chrome-os-partner:28289
TEST=Going battery shipmode and plug-in AC, See booting and EC log
Disconnect battery, and plug-in and see booting and EC log
Change-Id: Idd8ae2ab4ec164b11fe67413bbf647cad18bc481
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/197990
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
This may not contain all. I filtered out possible code by the
following command:
find . -name "*.h*" -o -name "*.c*" | xargs grep -n CPRINTF | \
grep -v "\[" | grep -v define | less
BUG=none
BRANCH=none
TEST=make buildall tuntests
Change-Id: I674f84f5966b34aeb8d4321d22629b450627a120
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197997
Add a shortcut in smart battery driver and i2c passthru. Once
the battery cut-off order is submitted (in the factory line),
the EC will no longer talk to battery.
BUG=chrome-os-partner:28248
BRANCH=tot,nyan
TEST=See below
> remove AC, cutoff: expect system is off.
> cutoff, then remove AC: expect system is off.
> cutoff, wait for 1 min, then remove AC: expect system is off.
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Change-Id: Ied963c19d17d581ce99e4543469cf2fa165f0439
Reviewed-on: https://chromium-review.googlesource.com/196657
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
This adds the basics for the accelerometer potion only of the ST
lsm6ds0 accel/gyro. Still need to add the acceleration interrupt
functionality, and all of the gyro portion of the chip.
BUG=none
BRANCH=none
TEST=Tested on a samus prototype hacked up to have the lsm6ds0 connected
to the EC i2c bus. Added motion sense task to the samus tasklist, added
accelerometer information to the samus board file, and tested console
functions interacting with accelerometer. The data seems reasonable,
and can successfully change data rate and range.
Change-Id: I7949d9c20642a40ede82dc291b2c80f01b0a7d8b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196426
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Created a host command to set/get various motion sensor parameters and
added an ectool command to use that host command.
The host command is created such that the first argument is a
sub-command. Sub-commands created include:
dump: dumps all current motion sensor data
info: returns general information about each motion sensor
ec_rate: set/get the EC sampling rate of sensors
sensor_range: set/get the sensor range (ie +/- 2G,4G,8G)
sensor_odr: set/get the sensor output data rate (ie 50Hz, 100Hz, ...)
For sensor_range and sensor_odr parameters, since the host doesn't know
what are valid values for the parameter, the host can specify to round
up or down to the nearest valid value. For example, the host can specify
to set the output data rate to at least 100Hz, and the EC will return
the closest valid output data rate that is at least 100Hz.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Test on a glimmer using ectool from vt-2 prompt:
> ectool motionsense help
Usage:
motionsense - dump all motion data
motionsense info NUM - print sensor info
motionsense ec_rate [RATE_MS] - set/get sample rate
motionsense odr NUM [ODR [ROUNDUP]] - set/get sensor ODR
motionsense range NUM [RANGE [ROUNDUP]]- set/get sensor range
>
> ectool motionsense
Sensor 0: 0, 0, 1024
Sensor 1: 1024, 0, 0
Sensor 2: None
> ectool motionsense info 0
Type: accel
Location: base
Chip: kxcj9
> ectool motionsense ec_rate
10
> ectool motionsense ec_rate 1000
1000
> ectool motionsense odr 0
100000
> ectool motionsense odr 0 40000 1
50000
> ectool motionsense range 0 8
8
After running this I verified on the EC console that all the parameters
were set appropriately. I tested the EC sampling rate was 1000ms by
running lidangle on and making sure samples were displayed roughly every
second. I verified the sensor odr and range by defining
CONFIG_CMD_ACCELS and typing:
> accelrange 0
8
> accelrate 0
50000
Change-Id: I444e2f0eafabd607f1c7aa78b5c4e91f6cb06387
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192064
Reviewed-on: https://chromium-review.googlesource.com/193307
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This replaces the obsolete and temporary (ha!) EC_CMD_CHARGE_DUMP host
command with EC_CMD_CHARGE_STATE. This is used to monitor and adjust the new
charge state implementation, including any board-specific customizations.
This command is a single catch-all command with multiple subcommands
(similar to EC_CMD_LIGHTBAR_CMD) so that we don't have to keep adding new
top-level host commands just to support incremental changes.
BUG=chrome-os-partner:23776
BRANCH=ToT
TEST=manual
From the AP, try these commands:
ectool chargestate show
ectool chargestate param
ectool chargestate param <NUM>
ectool chargestate param <NUM> <VALUE>
Watch the EC console and use its "chg" command to verify the effects of
setting various params.
Note: the Samus-specific fast-charging profile override is param 0x10000.
You can check it with the EC console "fastcharge" command.
Change-Id: Iad2f773a085bc25c05073b3eed9866f122ae9d78
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193305
Reviewed-by: Randall Spangler <rspangler@chromium.org>
