ACPI and thermal throttling are used only by x86 platforms.
Modify the conditional build to avoid building them where they are not
used.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
check the flash size on Ryu and see we are saving about 200 bytes with
this changes.
Change-Id: Ie5e1603fb3bea95eaa5cb1e6cb19f4ddb0e235e8
Reviewed-on: https://chromium-review.googlesource.com/210056
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This is a preparatory work for USB PD unit test. With this, we won't
need to duplicate these constants in both the implementation and the
test.
BUG=chrome-os-partner:31200
TEST=make buildall
BRANCH=None
Change-Id: Ia814a95450859caaa6d90e4cd866cb671d010b31
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211653
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
I2C reads from the PD happen in two separate transactions, but no stop
condition is set after the first transcation. Therefore, it is necessary
to lock the I2C bus across both transactions to prevent other tasks
from using the bus in between.
BUG=chrome-os-partner:29839
TEST=Manual on Samus. Boot to recovery screen, plug + unplug power
supply, verify that no I2C error messages are printed to console.
Then repeat 100x.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ie441637f499980a349022e281379ad2cc825b1aa
Reviewed-on: https://chromium-review.googlesource.com/211649
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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>
There is nothing chip-specific in the software CRC implementation. Let's
move it to common so that we can reuse it for other chips and unit
tests.
BUG=chrome-os-partner:31200
TEST=Define CONFIG_SW_CRC for host. Check crc.c compiles fine.
BRANCH=None
Change-Id: Icdc1d105c55c38ff07410cb5d733a31dbac53aea
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211494
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add PD communication enable flag. When disabled, the ports
will still detect source/sink connect and disconnect, and
will provide VBUS to a device, but will not send or respond
to any PD communication.
Use the CONFIG_USB_PD_COMM_ENABLED macro to define the
default state of PD communication enabled flag which may
vary board to board.
BUG=chrome-os-partner:31125
BRANCH=none
TEST=load onto samus. use "pd 0 enable" console command to
toggle between enabled and disabled. when disabled, test
that plugging in a zinger only gets you the default VBUS 5V
and that no negotiation takes place. when enabled, test
that plugging in zinger negotiates successfully.
Change-Id: I78ac3091f12d9699b19647be48ab7b6f434f5d7d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211045
If we are in SNK_DISCOVERY state and get PD_RDY, we are not sure what
the power source is. In this case, instead of happily go to SNK_READY
state, we should do a hard reset to be safe.
BUG=None
TEST=Check PD on samus/zinger still works.
BRANCH=None
Change-Id: I2baca06d45ba41e30d2ccf7a02fb65eb3966e5c1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210925
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If we are in disconnected states and get a request, it's likely either
ourself or whatever on the other side is confused. Do a hard reset in
this case.
BUG=None
TEST=None
BRANCH=None
Change-Id: Ic6504fccc55b79bd3ec4cc47007252e7dc69c778
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210924
Reviewed-by: Alec Berg <alecaberg@chromium.org>
In PD state machine, we often need to do "go to X state, and if after Y
ms we are still in X state, go to Z state." However, we do this in a way
that are suspectible to premature timeout if PD task is waken at an
unfortunate time. Let's add methods to set the state w/ or w/o timeout
to prevent this.
BUG=None
TEST=Boot on samus. Plug in zinger, and check we have 20V power.
BRANCH=None
Change-Id: I91db44ef71e31007eef4edd0f826bf81505e51e5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210874
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If a battery is found in disconnect state, we need to apply a charge
current to get it out of that state, even if the battery is full.
BUG=chrome-os-partner:29465
TEST=Manual on Samus. Put full battery into disconnect state then
power-on the EC. Pull AC and verify that the battery is no longer
disconnected.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I43e872e225dc5a651f566d7b190cff85a487805e
Reviewed-on: https://chromium-review.googlesource.com/210343
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
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>
