This addition allows the AP to query whether the PD device is currently
running from RO or RW FW.
BUG=chrome-os-partner:34599
TEST=Manual on Samus. Run 'ectool --name cros_pd infopddev 0' and verify
that correct RO/RW status of Zinger is printed. Verify that the output
matches the index printed by "pd 1 hash" on samus_pd console.
BRANCH=Samus
Change-Id: I4266cae931f5c7855ca0531717c4a18b138b2d62
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236771
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add active charge port for the PD status exchange so that EC
knows which port we are currently charging from.
BUG=chromo-os-partner:32227
BRANCH=samus
TEST=load onto samus. use "pdcmd 0x100 0 0"
from EC console to read the active charge port and
verify that it matches which port we are charging from.
Change-Id: I419befef8f0a14ca2da237be1a4944fd08733b83
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231349
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Add host command to set charge port override.
BUG=chrome-os-partner:32003
BRANCH=Samus
TEST=Manual on Samus. Insert PD charger in port1 and BC1.2 charger in
port0.
./ectool --name=cros_pd chargeoverride 0 --> Charges from port 0
./ectool --name=cros_pd chargeoverride off --> Charges from port 1
./ectool --name=cros_pd chargeoverride dontcharge --> No charge port
./ectool --name=cros_pd chargeoverride 1 --> Charges from port 1
./ectool --name=cros_pd chargeoverride 2 --> Correctly returns error
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib35f797a4a24e96fd2e3c008ace3fd6291b89d25
Reviewed-on: https://chromium-review.googlesource.com/230910
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>
Factory test process need lid switch no function or keep lid opened
BUG=chrome-os-partner:33304
BRANCH=paine,yuna
TEST=Run command "ectool forcelidopen 1" and "reboot". Then lid close
quickly, the system boot as lid opened.
Deault value or run command "ectool forcelidopen 0" make the device normal.
Change-Id: I94527b7ef7f9efe779c6b86f3eab651f99af6000
Signed-off-by: Henry Hsu <Henry.Hsu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/230180
Reviewed-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-by: Bowgo Tsai <bowgotsai@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
During the discovery identity phase of type-C devices that support it
there is some info that could be useful to kernel & userland for
policy decisions. CL starts by passing up the vid, pid & product type
(ptype) of the discover identity VDO.
BRANCH=samus
BUG=chrome-os-partner:32650
TEST=manual,
From host, w/ hoho in port 1
ectool --name=cros_pd infopddev 1
Port:1 Device:4 Hash: 0x57b1e4e0 0x7204075f 0x65c0fa72 0xdcca15ed 0xf3231237
Port:1 ptype:6 vid:0x18d1 pid:0x5010
Change-Id: Ie05d191149ada0ec860b713d780b0345eab3a647
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226899
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add flag for whether or not device plugged into a given port is a
dual-role PD device. For now, the dual-role flag is always 0, but
need to add the flag to the host command now for compatibility
in the future.
BUG=chrome-os-partner:32650
BRANCH=samus
TEST=load onto samus, run ectool --name=cros_pd usbpdpower and
verify that for anything plugged in it says "dedicated charger"
Change-Id: I2d3c8c149802492f27a87a47aaa68fbf505ee7a9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226820
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Add support for more host events and add a host command for the host
to use to get which host events have fired. The EC only uses one
real host command to notify the AP whenever the PD MCU needs attention
so the EC_CMD_PD_HOST_EVENT_STATUS host command can be used to
differentiate the possible triggers for the host event.
Current events include: PD remote device needs update, type-C power info
changed, and PD identity response received.
Added host event for power info change, which fires whenever a charger
or device is plugged into a type-C port.
BUG=chrome-os-partner:32650
BRANCH=samus
TEST=tested on samus by connected various peripherals to type-C ports
and verifying on EC console that a host event is sent.
Change-Id: Ibfc2cafe5826a0ab41aee96a68fdb561c0a2b4ab
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225841
Reviewed-by: Duncan Laurie <dlaurie@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>
This implements a new API for EC modules to define MKBP event sources
and send MKBP event to the AP. Also, a new host command
EC_CMD_GET_NEXT_EVENT is added for the AP to query the pending MKBP
events. Each event type may have custom event data sent along with the
event.
BRANCH=None
BUG=chrome-os-partner:33194
TEST=Enable MKBP event on Ryu. Set a host event from EC console, run
'ectool nextevent', and see MKBP event 0x01 (HOST_EVENT) and the set
host event.
Signed-off-by: Vic Yang <victoryang@chromium.org>
Change-Id: I28a1b7e826bcc102bbe39016c9bb3e37d125664c
Reviewed-on: https://chromium-review.googlesource.com/224905
Reviewed-by: Randall Spangler <rspangler@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>
With only four LED segments, it's confusing to indicate a power
percentage by dimming the top segment unless you can see the
indicator smoothly ramping up from all-off. This does that.
Kind of pretty, if I say so myself.
BUG=chrome-os-partner:29041
BRANCH=ToT, Samus
TEST=make buildall
Run "ectool lightbar demo on", then press the T key to invoke the
pattern and the arrow keys to fake the charge state.
Change-Id: Ib6a56aea56078b8c1fc9edddda469d7f41735ff7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223300
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This prepends EC_ a macro exposed in ec_commands.h, moves a
macro into lbcc that is not used elsewhere, and changes lb_program
structs to lightbar_program.
BUG=None
BRANCH=ToT
TEST=make buildall -j
Change-Id: I481562da72d91f846c64cf9af40338027641462c
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222406
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The PD protocol no longer uses a SHA1 RW hash. Instead, it uses the
first 20 bytes of the SHA-256 hash. Update constants and comments
accordingly.
BUG=chrome-os-partner:31361
TEST='make buildall -j'
BRANCH=samus
Change-Id: Ice74b841dbd1d81205c1ef0079a5e18fca2153b6
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222446
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
ectool autofanctrl 1 - set auto fan control for fan 1
BUG=chrome-os-partner:23803
TEST=Tested the above EC command on Auron
BRANCH=none
Change-Id: Idcd3690ad98d7965420f26f7cc445207fe73704d
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221816
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add a minor revision to the PD device hardware ID field in the info
custom VDM and set increment this minor ID from 0 to 1 for zinger.
This differentiates zingers for the auto-update payload, so we can
update only those with a specific major and minor ID version.
BUG=none
BRANCH=samus
TEST=load onto samus and zinger. when connect zinger, see on PD
console: Dev:0x0401 SW:2289 RW:0, which shows the appropriate
device ID.
Change-Id: I482ee2d850332b608cdd81537f68d4dc509bfc1a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221320
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
First case is for legacy support
ectool pwmsetfanrpm <targetrpm> - set all fans to <targetrpm>
ectool pwmsetfanrpm <fan> <targetrpm> - set <fan> to <targetrpm>
BUG=chrome-os-partner:23803
TEST=Tested the above EC commands on Auron
BRANCH=none
CQ-DEPEND=CL:220960
Change-Id: I8f447f53289abaa9c5cc1285f9f0921328fbf32c
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221291
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=none
BRANCH=ToT
TEST=manual
make BOARD=samus
for i in extra/lightbar/programs/[g-z]*.bin; do
./build/samus/util/lbcc -d $i /tmp/x.lbs
./build/samus/util/lbcc /tmp/x.lbs /tmp/x.bin
cmp $i /tmp/x.bin
done
Change-Id: I86c014c425e917ecafadd1c6845fcf2e5b4edbb7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220244
If there is any delay between AC status and the battery charge status
it is possible for the power_manager to read the battery state when
the AC status event is sent and still see that the battery is not
yet charging. This can cause lag in the UI battery icon because the
AP is not notified when the battery charge state changes.
In order for the host to be able to differentiate the dynamic battery
state changing (re-read ACPI _BST by sending Notify 0x80) from the
static battery info (re-read ACPI _BIX/_BIF by sending Notify 0x81)
it needs a separate host event.
BUG=chrome-os-partner:32196
BRANCH=samus
TEST=Test AC instertion and removal while watching state on the host
to ensure that an event is sent to the host which triggers power
manager to re-read the battery status and notice that the charge
state has changed if there is any delay after the AC status event:
watch -n 0.1 "cat /sys/class/power_supply/AC/online;
cat /sys/class/power_supply/BAT0/status;
tail -10 /var/log/power_manager/powerd.LATEST"
Change-Id: I18ce70719dc231c43c474cefad2068f949675a2b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220257
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This diff allows the user to send small programs to the EC and
gain control of the lightbar. Right now, this is only exposed
through ectool, and sysfs support will come later.
To send a program to the EC, use
$ ectool lightbar program /path/to/program.bin
and then start running the program with
$ ectool lightbar seq program
BUG=None
BRANCH=ToT
TEST=Using the above steps with hand-assembled programs.
Checked that infinite bytecode loops do not hang the EC.
Checked that bad opcodes exit with an error.
Stress tested pushing programs and changing sequences.
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Change-Id: I635fb041a5dc5c403f7c26fb9a41b5563be9b6b7
Reviewed-on: https://chromium-review.googlesource.com/219558
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add three retries for EC to PD host commands. With this change,
removed retry mechanism in host_command_pd.c which was a retry
only for the specific EC_CMD_PD_EXCHANGE_STATUS host command.
BUG=chrome-os-partner:32006
BRANCH=none
TEST=Loaded EC code onto samus. Added the following code
for testing failed host commands to samus_pd common/host_command.c
host_command_task():
if ((evt & TASK_EVENT_CMD_PENDING) && pending_args) {
if (i++ != 4)
pending_args->result =
host_command_process(pending_args);
else {
pending_args->result = -7;
i = 0;
}
host_send_response(pending_args);
}
This test code on samus_pd drops one in every five host commands.
With this code, from the EC, I send "pdcmd 0 0", and verified that
1 out of 5 times the EC prints a host command failed code, but then
retries successfully.
Change-Id: Ibf43feefbfc7d791c45c6689b82c66f5d71046ab
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217461
Reviewed-by: Todd Broch <tbroch@chromium.org>
CL provides some useful information similar to the EC console command
'pd state <port>' when host command 'usbpd <port>' is sent from host
with no additional arguments.
Also added a few build asserts for role & mux strings.
BRANCH=none
BUG=chrome-os-partner:31690
TEST=manual
ectool --interface=lpc --dev=1 usbpd 1
Port C1 is enabled. Role:SNK Polarity:CC1 State:6
# has zinger attached
ectool --interface=lpc --dev=1 usbpd 0
Port C0 is enabled. Role:SNK Polarity:CC1 State:2
Change-Id: Id44eb7bf6a6fcfa888a0008a2249601967c50bcc
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217138
Reviewed-by: Alec Berg <alecaberg@chromium.org>
PD accessories that are RW update-able will broadcast their rw_hash
SHA1 digest upon connection to the PD MCU which will store it.
For update purposes, the host needs that accessories device id and
rw_hash to determine its proper firmware update payload.
This CL creates a host command that requests the type-C accessory info
attached to a particular port. It also implements an ectool command
to expose the host command.
BRANCH=none
BUG=chrome-os-partner:31361
TEST=manual,
# connect zinger to port 1 on samus
ectool --dev=1 --interface=lpc infopddev 1
Port:0 Device:1 Hash: 0x7f4d7a13 0xf07b65b9 0x41181e10 0xb99b3d5f 0x9dee1206
ectool --dev=1 --interface=lpc infopddev 0
Port:0 has no valid device
Also do the same on port 0 with similar results.
Change-Id: Id63c7edad77a43d43c14d8cd6bd96e08d0d9b501
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216814
Reviewed-by: Alec Berg <alecaberg@chromium.org>
PD accessories that are RW update-able will broadcast their rw_hash
SHA1 digest upon connection and remain in RO briefly for a response.
In order to speed-up the response and decouple common case of
accessory is up-to-date, the PD MCU will keep a small 4 entry table of
PD accessory device ids and their corresponding RW hashes for quick
lookup.
The AP will be the source of new updates and their corresponding
device id's and RW hashes and therefore needs a method to update the
PD MCU table.
This CL creates the table, host command & ectool command to facilitate
future driver / daemon to update the RW hash entries.
BRANCH=none
BUG=chrome-os-partner:31361
TEST=manual,
# from AP
for i in `seq 1 8` ; do
ectool --dev=1 --interface=lpc rwhashpd $i $i $i $i $i $i
done
# from samus_pd console
pd rwhash
Device:5 Hash: 0x00000005 0x00000005 0x00000005 0x00000005 0x00000005
Device:6 Hash: 0x00000006 0x00000006 0x00000006 0x00000006 0x00000006
Device:7 Hash: 0x00000007 0x00000007 0x00000007 0x00000007 0x00000007
Device:8 Hash: 0x00000008 0x00000008 0x00000008 0x00000008 0x00000008
Change-Id: Ibe87b3594793cd5215eba42160489b26974aadbc
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214366
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add host event for PD up to AP. The PD toggles a gpio line to
EC causing an interrupt on EC. The EC then sends host command
down to PD MCU to get its status. There is a new status bit for
PD host event, so when EC see's the PD host event status bit,
it sends a PD host event to the AP.
There is currently only one host event for PD to AP.
BUG=chrome-os-partner:31361
BRANCH=none
TEST=added PD console command pdevent, which initiates the host
event. when sent, verified on EC that it sets the correct host
event bit using hostevent console command
Change-Id: If1a59a3232e2f9a49f272c6dee5319254d87b9a9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213371
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a new host commmand for sending RW updates to PD devices.
The host command has a variety of sub-commands for performing the
update, including: erase RW, reboot, write new hash, write flash.
To program zinger RW, you should send host commands in this order:
write new hash to all 0's
reboot (zinger boots into RO since RW hash doesn't match)
erase RW
write flash
write new hash to match contents of RW
reboot
This also adds an ectool command to write a new RW. Just pass it
the RW .flat or .bin file.
BUG=chrome-os-partner:31361
BRANCH=none
TEST=ectool --dev=1 --interface=lpc flashpd 0 0 zinger.RW.flat
Change-Id: Ia81615001b83ad7ee69b1af2bf1d7059177cde04
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213239
Reviewed-by: Randall Spangler <rspangler@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>
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>
Host commands in the range 0x4000-0x7fff will be passed thru the EC to
the PD MCU as 0x0000-0x3fff.
BUG=chrome-os-partner:30079
BRANCH=samus
TEST=manual. On PD console:
hcdebug params
On EC console:
hostcmd 2 0 -> hex string of EC version
hostcmd 0x4002 0 -> hex string of PD version, and PD console shows host
command 2 was received. The hex response shown on the PD console
matches the one printed by the EC
Change-Id: Icc2d97c5977145a0c3ad2630d2b5a19e876a36d0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207821
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Revert
- https://chromium-review.googlesource.com/#/c/205145/2
- https://chromium-review.googlesource.com/#/c/205147/4
Now using the real AC_PRESENT gpio signal instead of whether or
not the PD MCU negotiated for 20V.
BUG=chrome-os-partner:29841, chrome-os-partner:29842
BRANCH=none
TEST=tested on a board with reworked AC_PRESENT signal. Verified
that gpio is correctly reporting state of AC and is charging when
AC is plugged in. Tested the no battery case to make sure
board powers on and stays on with just a charger. Also tested the
dead battery case by plugging in a dead battery, then plugging in
a charger and making sure system powers on and starts charging.
Change-Id: I4424771c91c8a2aa19eda68a8b5194e9265d529c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206598
Reviewed-by: Bill Richardson <wfrichar@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>
ectool must support all prior versions of commands that shipped
EC binaries use.
BUG=chrome-os-partner:29830
BRANCH=None
TEST=Manual
With an EC that only supports version 0:
- Run 'ectool batterycutoff' -> success
- Run 'ectool batterycutoff at-shutdown' -> error with explicit
message about at-shutdown not being supported
- Run 'ectool batterycutoff foo' -> error, bad parameter
With an EC that support version 0 or 1:
- Run 'ectool batterycutoff' -> success
- Run 'ectool batterycutoff at-shutdown' -> success
- Run 'ectool batterycutoff foo' -> error, bad parameter
Change-Id: Ia88cfc5fa7c5125828ec0595f0b6a505916c97ea
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205155
Reviewed-by: Vic Yang <victoryang@chromium.org>
We never implemented this. We have no devices which support it. And
we used bit #17 in a 16-bit field to flag it, so it wouldn't have
worked even if we did. So, remove this (dead) code.
BUG=chromium:382944
BRANCH=none
TEST=make -j buildall
Change-Id: Id3a4a93612d1078a3239d85921a05cfd7362b84c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204162
Reviewed-by: Doug Anderson <dianders@chromium.org>
If at-shutdown is specified, the battery is cut off
1 seconds after the host has shutdown.
BUG=chrome-os-partner:29292,chrome-os-partner:28887
BRANCH=tot,nyan
TEST=Run batterycutoff ectool command and cutoff console
command with and without 'at-shutdown' option. Verify
the battery is cut off immediately without the option
specified and 1 seconds after shutdown with. View the
console log to see the deferred cutoff occur.
The following tests are verified on big.
console:
cutoff, AC on: system is off after removing AC.
cutoff, AC off: system is off immediately.
at-shutdown, AC on: system is off after "power off" and removing AC.
at-shutdown, AC off: system is off after "power off".
ectool:
batterycutoff, AC on: system is off after removing AC.
batterycutoff, AC off: system is off immediately.
at-shutdown, AC on: battery is cut off after 1s of shutdown.
system is off right after removing AC power.
at-shutdown, AC off: system is off after 1s of shutdown.
[84.058416 power state 3 = S0, in 0x0000]
[84.058803 power lost input; wanted 0x0001, got 0x0000]
[84.059120 power off 3]
[84.072148 Cutting off battery in 1 second(s)]
[84.123896 power shutdown complete]
[84.128790 power state 7 = S0->S3, in 0x0002]
[84.139694 power state 2 = S3, in 0x0002]
[84.150857 power state 8 = S3->S5, in 0x0002]
[84.166975 power state 1 = S5, in 0x0002]
[84.177972 power state 1 = S5, in 0x0002]
[85.080012 Battery cut off succeeded.]
Change-Id: Id4bacf79ad3add885260655f80cb8127bafe1ad6
Signed-off-by: Dave Parker <dparker@google.com>
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203694
Reviewed-by: Vic Yang <victoryang@chromium.org>
Use a EC to PD host command to notify the PD MCU when a battery
is present and charged enough that it is ok to negotiate for a
higher power. The PD MCU will not negotiate until the host command
is received, which allows the system to be powered without a
battery or with a dead battery with 5V.
BUG=chrome-os-partner:28611
BRANCH=none
TEST=Tested on a samus:
1) Tested the normal case of battery charged and plugged in. When
charger is plugged in, the device immediately starts negotiating
for 20V and starts charging.
2) Tested with no battery. Plug in a charger, samus boots and stays
alive. VBUS measured at 5V. When a battery is plugged in, device
negotiates for 20V and starts charging.
3) Tested dead battery by taking a battery with no charge, and
plugging in zinger. Everything boots, but PD does not negotiate
for power. Then when battery reaches 1%, PD negotiates and zinger
switches to 20V without causing a reboot.
Change-Id: Iaa451403674e86cddbd3fe80e9503584910be576
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201958
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds a new lightbar sequence (TAP), which temporarily displays the
battery level. It pulses if the system is charging.
BUG=chrome-os-partner:29041
BRANCH=ToT
TEST=manual
From the EC console, run
lightbar seq tap
The lightbar should change temporarily.
Then run
lightbar demo on
and press the Up, Down, Left, and Right keys to fake the battery charge
level (up & down) and the AC present state (left & right). Run the
lightbar seq tap
command periodically to watch it change.
Change-Id: I84ff928d93060f7ef7d46d608732d37cf5185aff
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202964
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds three new lightbar subcommands to the EC_CMD_LIGHTBAR_CMD host
command, allowing the AP to read the current brightness level, the
current lightbar LED values, and the state of demo mode.
Because this is new, also update LIGHTBAR_IMPLEMENTATION_VERSION. All the
previous commands are unchanged, though.
BUG=chrome-os-partner:28596
BRANCH=ToT
TEST=manual
From the AP, run these commands to see the changes:
ectool version
ectool lightbar brightness
ectool lightbar 0
ectool lightbar 1
ectool lightbar 2
ectool lightbar 3
ectool lightbar demo
The version output is different, the other commands used to just emit
errors.
Change-Id: If32a5d2388217edc3ae7b9b091d66e9d2cf753be
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199881
Reviewed-by: Randall Spangler <rspangler@chromium.org>
While debugging reboot issue, it was difficult to get POST code from failing
boards. Currently POST code is only accessible from EC console. Not all boards
are fitted with servo board.
This patch adds Port 80 history access from ectool. Reuse command code 0x48,
EC_CMD_PORT80_LAST_BOOT with version 1.
Signed-off-by: Wenkai Du <wenkai.du@intel.com>
BUG=chrome-os-partner:28514
BRANCH=rambi
TEST=manually test on rambi to confirm port 80 history match EC console
Change-Id: If204d8fb457d8d8d18055f8282a406a35c03305e
Reviewed-on: https://chromium-review.googlesource.com/198012
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Commit-Queue: Wenkai Du <wenkai.du@intel.com>
Tested-by: Wenkai Du <wenkai.du@intel.com>
ectool gpioget - returns all GPIOs (with flag info)
ectool gpioget <GPIO_NAME> - get value of <GPIO_NAME>
ectool gpioget count - returns number of GPIOs
ectool gpioget all - returns all GPIOs (with flag info)
BUG=chromium:344969
TEST="ectool gpioget [<subcmd> <GPIO_NAME>]" returns correct information
on squawks
BRANCH=none
Change-Id: Ib6f0d8135a76501f08b084bfd7eb1f2689d5d6e0
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196680
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Also adds 'battparam' console command.
BUG=chrome-os-partner:25145
BRANCH=ToT
TEST=Run 'ectool batteryparam set 0 0x1234'
'ectool batteryparam get 0'
and on the console:
'battparam 0'
'battparam 0 0x1234'
on a board that implements parameter 0.
Change-Id: I9cc54d001631f53dd39ae64cfdeececaa1747181
Original-Change-Id: Ib2812f57f2484309d613b23dab12ad43e0417bd2
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195824
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197162
Added a sub-command to the motionsense host command (0x2b) for getting/setting
the lid angle at which the keyboard is disabled as a wake source in S3. The
value can be anywhere from 0 to 360 degrees, default set to 180. Note, this
only takes affect for boards that have CONFIG_LID_ANGLE_KEY_SCAN defined.
Modified ectool motionsense command to use new host sub-command.
Also modified the lid angle measurement in the EC to be in the range [0, 360],
instead of [-180, 180], and changed casting of lid angle as an int to round
to nearest.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
Using default keyboard disable lid angle of 180, made sure that when lid
angle is past 180, key presses do not wake system, and when lid angle is
less than 180, key presses do wake up system.
Used ectool motionsense kb_wake to set the keyboard disable lid angle to 0.
Made sure that keyboard never wakes up the system. Set keyboard disable lid
angle to 360 and made sure that the keyboard always wakes up the system.
Change-Id: I437164c6e38c29169ef6e20e86c9cf2a1c78f86e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193663
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194172
Added enum for motion sensor ID's into ec_commands.h so that the host
can easily send host commands targeting the desired accelerometer.
Changed sensor present flag to just senosr flags, currently with only a
single mask defined for sensor present. This allows for easier future
expansion of various flags.
Also, added a motion sense module flags to the dump sub-command for flags
that represent all sensors, such as is the motion sense task active.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Manual test on a glimmer by testing ectool motionsense command
Change-Id: Iac052269a60db9ff4506f0490c3a0c6daad5b626
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193122
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193309
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>
