Remove code for preventing PD negotiation until the battery
is at some minimum SOC. This was originally necessary because
transitioning voltages would cause the source voltage to go
briefly to 0V, which would kill power to the system unless
the battery was at some minimum level of charge. But, that
isn't true anymore. It is safe to transition up or down in
voltage and the source voltage should never drop to 0V.
BUG=chrome-os-partner:29499
BRANCH=none
TEST=make -j buildall. No need to do any more testing because
this code has been disabled for a while.
Change-Id: I8a3dca117f01f0f9c7d04b5d489e4a8588a89be6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211021
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add console commands to send the Vendor-Defined Messages used to flash a
USB-PD target.
Also add a simple test script to flash Zinger through its CC line. To
run the script, the board must have CONFIG_USB_PD_CUSTOM_VDM defined.
By default fruitpie has this config option enabled.
BRANCH=none
BUG=chrome-os-partner:28330
TEST=With a fruitpie connected to a zinger run
./util/flash_pd.py ./build/zinger/ec.RW.flat
and see Zinger booting on RW.
Change-Id: I06f8f545e28b93b2e646e668d81b594eb7976a2d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203375
Reviewed-by: Todd Broch <tbroch@chromium.org>
Fix bug in pd transmission. The retry mechanism was not working right
and was causing us to not do any retries.
BUG=none
BRANCH=none
TEST=Test with a zinger unplugged from the wall. Samus sends source
cap and doesn't get a response. Verify on console printout that we
retried 3 times.
Change-Id: Id273bf054655c2d24a791f4eaf4cb8d87253abe2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210559
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previous assumption assumed that the flash was remapped
to address 0.
This is not the case anymore since cl/210063
BUG=chrome-os-partner:30997
TEST=Check we can boot the EC now.
BRANCH=None
Change-Id: I46e1dc0ad840b21661aa5d87817369b29a659c9b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210407
Host commands can be generated by either the PDCMD task (in response
to PD interrupts), or the HOSTCMD task (in response to passthru
requests). Use a mutex to serialize access to the EC->PD interface.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=Boot samus
Change-Id: If65d5eb4bbef91e6c811a06ea2e1487e17143dc7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210401
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the EC sends longer commands to the PD chip (such as flash
erase/write over the passthru from AP), allow it to take a second
instead of the default 100ms timeout.
BUG=chrome-os-partner:30935
BRANCH=none
TEST=samus boots
battery command works from EC console
ectool passthru of flash erase to PD works (requires hacked ectool)
Change-Id: I08ff94f7ac6aee351aa73c9d28b5fd715d463b3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209936
Reviewed-by: Alec Berg <alecaberg@chromium.org>
We have three copies of 'typec' commands in three different boards. The
commands current mix hardware-specific logic and console command logic
together. Adding a board_get_usb_mux() interface to separate the logic
and deduplicate the console command logic.
BUG=None
TEST=make buildall
TEST=Test 'typec' command and verify GPIO settings.
BRANCH=None
Change-Id: Ie1825f49d32609c732db384679cb917f2f1a4082
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209955
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add back in sending hard reset on board fault.
BUG=none
BRANCH=none
TEST=Using zinger and firefly, create an overvoltage error by down
stepping with a 0 VOLTAGE_DOWN_STEP_TIME, and make sure that a hard
reset is received by firefly and that we re-establish negotiation
after the OVP fault is cleared.
Also tested with zinger and samus. On samus I set the input current
to 3.5A, which immediately triggers an OCP, and verified that we
get a HARD RESET from zinger and that after the reset we negotiate
correctly and get back to normal (note that when VBUS goes down, the
EC resets the input current limit to default 2A, so that's why we
don't continue getting OCP).
Change-Id: I991b15411c4ce05c1086851b1e2e56e2effab749
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209865
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow a sink to request a new voltage without dropping the established
negotiation. For this to work the sink must save the last received
source cap packet and use that to make a new RDO from the SNK_READY
state.
BUG=chrome-os-partner:30389
BRANCH=none
TEST=Tested on a firefly connected to zinger. made sure we can press
buttons to change voltage and we don't lose the existing negotiation.
Also tested on samus, ports 0 and 1, using pd x dev 5/12/20 to switch
between voltages and verified we don't lose existing negotiation.
Change-Id: I5a550b667f3aff7975185e091f3caac4555a907e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209864
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On most platforms, the power button is active low,
but the power button on Ryu is active high.
Add CONFIG_POWER_BUTTON_ACTIVE_STATE to override the default active
state.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=on Ryu, use the servo pwr_button to start and stop the AP.
Change-Id: I11c6bb3c700bccd3606ce1fa1a69905671792990
Reviewed-on: https://chromium-review.googlesource.com/207274
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Changes to match this part of the spec:
The Sink shall support the SinkWaitCapTimer. When a Sink observes an
absence of Source Capabilities messages, after VBUS is present, for a
duration of tTypeCSinkWaitCap for the Type-C connector and
tSinkWaitCap after VBUS is present,for all other connectors the Sink
shall issue Hard Reset signaling in order to restart the sending of
Source Capabilities messages by the Source (see Section 6.6.4).
tTypeCSinkWaitCap shall be between 210 and 250 ms
Also set send source cap period appropriately:
tTypeCSendSourceCap shall be between 100 and 200 ms
This should help avoid transmission collisions during negotiation.
BUG=chrome-os-partner:30135
BRANCH=none
TEST=load onto zinger and samus and verify they negotiate correctly
10 times. Then loaded custom code to zinger to not send source cap
and verified we send hard reset. Also tested plankton to samus
negotiation works.
Change-Id: Idd6118e3e0a9f7a96ebeae9518c8b10457232c70
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209558
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Include a force source mode for dual-role ports to allow us to
force a dual-role port into being a source.
BUG=chrome-os-partner:28782
BRANCH=none
TEST=tested on plankton, verified using the pd 0 dualrole console
command.
Change-Id: Ic4c2a9e11984b34b1dec09d5c71e1fd15ed9198c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209071
Reviewed-by: Vic Yang <victoryang@chromium.org>
Adds dual USB-PD port support for samus. Both ports are in dual-role
and can perform either role.
Both ports work fine when only one of the ports is in use. But,
still having problems with PD errors on the lower priority port (port
0). If you have a charger plugged into port 0, and a type-C USB dongle
plugged into port 1, then port 1 has higher priority, and in the
SRC_DISCONNECTED state, every 1.5 seconds when it sends source cap
packet, we occasionally drop pings on port 0, which results in a
lot of start/stop charging.
BUG=chrome-os-partner:28585
BRANCH=none
TEST=Tested on samus to make sure both ports work when I
plug in a charger and a type-C USB dongle with a pull-down on the CC
line. Tested on plankton and zinger to make sure PD works as expected.
Change-Id: Ie7bde3e258f5cd23a0b82b626c0993a45b0df074
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200750
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@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>
We are now using argv[5] even if the user only gives 5 arguments. Fix
it.
BUG=None
TEST=Read with i2cxfer command and doesn't see "Invalid param 5"
BRANCH=None (this can be worked around by adding a dummy param)
Change-Id: Ice13fec4ad53c71b6529daa3510fa6fc1d7f8c00
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208489
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ILIM control line is inverted before reaching the USB charge
controllers when they are cross-connected to allow only one port
to deliver the HIGH current limit at a time.
BUG=chrome-os-partner:29053
BRANCH=ToT
TEST=Verify, with a multimeter, that ILIM (pin 4) on a TPS2546
is 3.3V when the chargemode is set to CDP
Change-Id: I2f720d04b959417ae96687d7e30ee60270eeccb9
Original-Change-Id: Idd89dcfc117f1f3393ded1887e8d1cb27ba367ad
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205811
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208161
Add support for toggling between source and sink as dual-role
port. When transitioning to S0, we turn toggling on, when transitioning
to S3, we turn toggling off but remain in the same PD state, and when
transitioning to S5, we turn toggling off and force the PD role to a
sink.
Note, when toggling is off, the source disconnected state is
allowed to transition to sink disconnected, but not vice versa. This
means that if you go into S3 as a source, it will remain a source
until the device is unplugged, at which point it will transition to
a sink until the next transition to S0.
The spec specifies:
tDRP: 50ms - 100ms, Period a DRP shall complete a DFP to UFP and back
dcDRP: 30% - 70%, Percent of time that a DRP shall advertise DFP
tDRPHold: 100ms - 150ms, time to hold VBUS on after a DRP detects a UFP
tDRPLock: 100ms - 150ms, time to stay in DFP after detecting loss of UFP
This CL uses 40ms for time as a UFP (sink), 30ms for time as a DFP
(source), and 120ms for hold and lock times.
Also, if advertising as a DFP (source) and VBUS is detected, this
automatically switches to a UFP (sink).
BUG=chrome-os-partner:28782
BRANCH=none
TEST=test on samus, make sure we are toggling between source and sink
when disconnected. make sure plugging in zinger switches state machine
through to sink_ready and make sure plugging in a USB switches to
source_discovery. tested on a fruitpie by scoping the CC line and verifying
the timing (except the hold time which I can't easily test).
tested that dual role toggling is off in s3 and s5. also verified that
going into s3 as a source keeps the port as a source and going into s5
switches it to a sink.
Change-Id: I478634861f694164301d71359da35142ee7ebf75
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207154
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 HW signals to control the type-C ports muxing have changed between
Fruitpie and Samus, update the code to match the HW.
Also add the docking mux option and update the board muxing code to
prepare for the automatic mode detection :
- the polarity will be determined by the PD code.
- the port muxing will be enable/disable by the common alternate mode PD
code.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
Change-Id: I0706626270c73d2a5e3f85b86e65a7c4fc21f9ec
Reviewed-on: https://chromium-review.googlesource.com/206685
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When we reset the PD power source, ensure we always transition to
DISCONNECTED state, so we will re-enable the 5V power when transitioning
back from DISCONNECTED to DISCOVERY.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=Plug Firefly to Zinger and play with voltage transition buttons.
Change-Id: Ifa0f30391b2249b54385ce8c93df932e37803695
Reviewed-on: https://chromium-review.googlesource.com/206954
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Change PD sink to use VBUS for initial detection to match
USB type C spec.
BUG=chrome-os-partner:30116
BRANCH=none
TEST=Tested on samus. Connect and disconnect zinger a few times
and make sure we successfully negotiate each time.
Change-Id: Ifa9ff301cb34b6df6609d4bbbde3231bb029d554
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207000
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Verify the connection status at every FSM loop,
by monitoring VBUS presence for the sink and by monitoring CC going
above Vnc for the source.
Also ensure we are never stuck in the source transition state in the
sink doesn't ack the PSReady packet.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=connect Firefly to Zinger, trigger hundreds of voltage transition,
record and analyze the PD traffic : no longer see spurious PSReady
messages.
Change-Id: I4495ae5415d53d77055fb2a562c594fa9a1d4dc8
Reviewed-on: https://chromium-review.googlesource.com/206945
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Once the source has successfully sent a SourceCap packet (ie it got
acked), it needs to transition from the DISCOVERY to the NEGOCIATE
state.
This was done when the source was sending unsolicited SourceCap, but
this was missing when the SourceCap was an answer to a Sink GetSourceCap
request. The usual effect of the missing transition was sending twice
the SourceCap triggering some collisions.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=plug a Zinger to a Firefly, randomly push the Firefly voltage
selection buttons and see the transition always happening properly.
Change-Id: If4b335e2144595f22ad4e9a8a9e289506f597407
Reviewed-on: https://chromium-review.googlesource.com/206941
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This caused all platforms to check only the first 25% of each page to
see if it's already erased. Fortunately, we tend to fill flash pages
from the beginning, so in normal usage we don't hit this bug.
BUG=chrome-os-partner:30281
BRANCH=all (if convenient)
TEST=Make sure CONFIG_CMD_FLASH is defined. Then at the EC console:
flasherase 0x1f000 0x400
rw 0x1f3e0 -> 0xffffffff
flashwrite 0x1f3e0 0x20
rw 0x1f3e0 -> 0x03020100
flasherase 0x1f000 0x400
rw 0x1f3e0 -> 0x03020100 (bad!) or 0xffffffff (good)
Change-Id: If78b08b5e0414993a440bc8cd707b5ce70eb1a0a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206891
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
(cherry-pick back to ToT)
Clear the CHARGE_INHIBIT bit when requesting non-zero current/voltage
and set it when charging should be disabled. On Blaze with the
BQ24725 charger, setting this bit saves 10-15mW when we're not on AC.
This also fixes an issue where battery charging would not get enabled
when the charger is connected while the machine is in S3/S5. This is
because the kernel driver would inhibit charging when the charger was
removed and then the EC would not enable it when the charger was
re-connected while the host was off, such as in S3/S5.
BRANCH=nyan
BUG=chrome-os-partner:29386
TEST=Boot Blaze, disconnect charger, suspend, connect charger and
observe that the battery now starts charging.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203163
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit bd4469ae4ffbbd6f2cd5549bdb8809838e55d6f7)
Change-Id: Ibcb635b01a2292f214f71ab400ec34cd12e7536f
Original-Change-Id: I2efaf02296dc08c0de85950a70ad2592f4428241
Reviewed-on: https://chromium-review.googlesource.com/206909
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Until now when send_validate() receives another valid packet in place of the
GoodCRC, it was continuing its retries loop. But given that the presence
of a valid packet indicates that the other side is trying to send us
something, it's better to bail out immediatly and wait for its retry.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:29847
TEST=repeatly plug and unplug a Zinger to a Samus and record the traces
of the PD negociations.
Change-Id: I901bd8d85999ed195ed9887d7375806f61222f8b
Reviewed-on: https://chromium-review.googlesource.com/206391
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Add a retry mechanism for EC to PD host commands to make the
communication channel more robust.
BUG=none
BRANCH=none
TEST=run on system to verify that we don't drop host commands
to PD MCU.
Change-Id: Ida6f02a149e4dd9e85a5aac21790928b16864104
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205148
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a temporary workaround to allow dead battery charging without
an AC PRESENT signal by delaying going into hibernate with an extremely
low value in order to check if AC is present by waiting for PD MCU.
BUG=chrome-os-partner:29842
BRANCH=none
TEST=Test with a dead battery that when you plug in AC and reboot, it
is able to charge. Previous to this change with a dead battery and AC
plugged in the EC would boot and almost immediately go back into hibernate
Change-Id: I338a0cc9ee37dab3e6caf29369ac6e819772ca91
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205147
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>
Enough USB support to be able to enumerate the device and use bulk or
interrupt endpoints.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28295
TEST=with the following USB console CL, connect a Fruitpie through USB
and use its console over USB.
Change-Id: I37b7f3b6a754cb82ab5f940ea20122d2e16b3b5b
Reviewed-on: https://chromium-review.googlesource.com/193983
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@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>
Increase the delay after receiving a good CRC in send_validate_message()
to avoid catching the last edge as the start of a new packet.
BUG=none
BRANCH=none
TEST=Tested with zinger and samus using the python script to flash
zinger RW, and simply negotiating power and receiving pings.
Change-Id: Iffdd73e02e5d292396d46a611d728f66402f2da4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/203206
Reviewed-by: Vincent Palatin <vpalatin@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>
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>
When this option is configured, two changes take place.
First, the AP doesn't power on by default when the EC reboots. To boot it,
you can run the "powerbtn" command, or poke the power button manually, or
any of the normal things.
Second, we watch for power-related signal changes (anything that's connected
to the power_signal_interrupt() function) and keep track of them as they
happen. After a second with no further changes, we print the time and value
of each change. For example:
[19.939212 Port 80: 0x29]
[19.967971 HC 0x23]
[19.976236 Port 80: 0x3a]
[19.995700 HC 0x87]
[20.567884 Port 80: 0x73]
11 signal changes:
19.638241 +0.000000 PCH_SLP_SUS_L => 1
19.654378 +0.016137 PCH_SLP_S5_L => 1
19.654457 +0.000079 PCH_SLP_A_L => 1
19.654535 +0.000078 PCH_SLP_S3_L => 1
19.654587 +0.000052 PCH_SLP_S4_L => 1
19.659630 +0.005043 PGOOD_1_5V_DDR => 1
19.663199 +0.003569 PGOOD_1_5V_PCH => 1
19.664751 +0.001552 PGOOD_1_8VS => 1
19.668735 +0.003984 PGOOD_VCCP => 1
19.671883 +0.003148 PGOOD_VCCSA => 1
19.868406 +0.196523 PGOOD_CPU_CORE => 1
[21.908551 Port 80: 0xf0]
[21.908855 HC 0x48]
BUG=none
BRANCH=ToT
TEST=manual
Build with CONFIG_BRINGUP, notice those two changes.
Change-Id: I55fd2021a0eae7dbfd1aaf5d93971f65bf2367b9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202574
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Moved sampling of ALS to its own task. The problem is that it
spin waits on the i2c bus mutex, and it's a bad idea to spin wait
for very long in the hooks task because the hooks task tickles
the watchdog.
BUG=chrome-os-partner:29003
BRANCH=none
TEST=tested on samus: make sure ALS task is running and no
watchdog timeouts when the i2c bus is wedged indefinitely.
Change-Id: Ifcebabdfc151ea85cecdfe7a8ed489e8a82ee5ba
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202545
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For non-PD aware sink, ensure that we detect their disconnection when
the CC goes back above Vnc.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28782
TEST=on Samus, put the port in source mode (using the "pd charger"
console command), then plug and unplug the type-C to type-A cable and see the
PD state going from Disconnected to Discovery and the other way round
(using "pd state" console command).
Change-Id: Ic9e19fee78f0c5e1fc742e2443eaf4b804ee5ee9
Reviewed-on: https://chromium-review.googlesource.com/202445
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
