Disable most of the pd console command to save space. The command
can still be used with subcommands "state" and "dump" to get state
information and change debug level.
BUG=none
BRANCH=none
TEST=make buildall with CONFIG_CMD_PD defined and undefined. Also
undefined the config option and loaded onto samus and verified that
the pd 0 state command still works.
Change-Id: Ie41bad53122a1e2a9ef4bad6423b9cdc85f53742
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229420
Reviewed-by: Vic Yang <victoryang@chromium.org>
This enables forwarding of the local PD/EC console
over debug USB. It gates the console functionality
based on the CCD mode that is set.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable partial CCD mode on ryu and verify that it is
enumerated by the host correctly, but doesn't respond
to console input, and doesn't generate output.
Enable full CCD mode on ryu and verify that it is
enumerated and that the console works as expected.
Verify that the console still works by default on the
discovery-stm32f072 board.
Change-Id: I0325ce9689486c41387d6075330be1d7d42f1d42
Reviewed-on: https://chromium-review.googlesource.com/229342
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
This provides a framework for additional work. It
exposes an API (ccd_set_mode) that can be used by the
PD code to enable Case Closed Debug. Enabling CCD will
result in the USB 2.0 lines on Ryu (proto 2) to be
disconnected from the AP and for the USB peripheral to
be enabled and connected to the host. The result is
an enumerated device with no interfaces.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable CCD ryu_p2 and verify that it is enumerated
by the host correctly. This requires a reworked
Ryu (proto 2 with pullup).
Change-Id: I1fbecdd5f94a61519cfc18c5e087892c6bd77fde
Reviewed-on: https://chromium-review.googlesource.com/229139
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Allow a charge port to be selected as the override port, which means it
will always be selected as the charge port, if any charge supplier is
available.
BUG=chrome-os-partner:32003
TEST=Attach PD charger and BC1.2 charger. Verify that active charge port
switches to BC1.2 after running `chargeoverride [port]` from console.
Also, pass unit tests.
BRANCH=Samus
Change-Id: Ia1b48ca89641842d51be7eed3b92d36d3eedc9ef
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227730
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When a PD charger is detected, gets its max charge capability, but
initially negotiate for its minimum charge mode. If we later determine
that the port will be the one active charge port, re-negotiate for the
max charge capability.
BUG=chrome-os-partner:32003
TEST=Manual on Samus. Plug in Zinger, verify that current limit is
initially set to 500 mA, then switches to 3000 mA shortly after. Plug in
two Zingers, verify that one provides 3000 mA current while the other
negotiates to 500 mA. Verify that the 500 mA charger bumps up to a high
current once becoming active.
BRANCH=Samus
Change-Id: Ifa562b72d763642fc8bd62bc7f5aaa4eda1ef950
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225922
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This simply renames ryu to ryu_p1, and ryu_p2 to ryu. 'ryu_p1' will be
kept for a while and will be decommisioned when most developers make
switch to the new boards.
BRANCH=None
BUG=chrome-os-partner:33583
TEST=Build ryu and boot on P2 board.
Change-Id: Ief61c64c6aefdaeae76ac7b86e0ea28131810aa1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229291
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previously the USB RAM size was off by a factor of two
for chips that required 32-bit alignment of accesses,
even though the underlying memory was 16-bits in size.
This change adds an additional configuration for the
access size (it still assumes that the underlying memory
is 16-bits in size) and uses that to adjust the USB_RAM
memory section in the linker scripts.
This change also removes the default values for the USB
RAM from stm32/config_chip.h because they mask issues
when new chips are added. It is better for a new chip
to fail to compile until these values are provided.
Finally, this change introduces a common USB API header
so that common code doesn't need to include the STM32
specific header.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable console on ryu_p2 and discovery-stm32f072 board
Verify that it works on both
Change-Id: Id118627f53e9e8ff1bd09fb51f1f9634ff495d19
Reviewed-on: https://chromium-review.googlesource.com/228833
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
Once a mode is entered object position (OPOS ... AKA alternate mode) field in
the VDM header should always track that mode.
CL fixes DP status & config messages which did not add the correct OPOS. In
fixing I mapped to the UFPs function pd_alt_mode which for the DFP did require
the addition of port parameter. Finally I cleaned up code to use this function
throughout common policy layer where previously I'd just accessed the pe
structure directly.
BRANCH=samus_pd
BUG=none
TEST=manual, compiles, insert hoho/dingdong into samus and see OPOS=1 from samus
for enter, dp_config, dp_status SVDMs
Change-Id: I66448c3386be01bae58768632da216aff41a9a30
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228130
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Wait to send source cap packet until port partner is showing
UFP on CC line. This is necessary because while we are applying
VBUS, the other side could toggle its role, and when VBUS is
finally up, we must wait to send source cap until other side
is pulling down.
BUG=none
BRANCH=samus
TEST=make buildall
Change-Id: If7e811913f5ec9eed28171ffca0cec98712b96fe
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227722
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Move tDRPHold timeout to after vbus is on. This makes sure we give
the right amount of time for a dual-role device to recognize that
it should be the UFP.
BUG=none
BRANCH=samus
TEST=make buildall
Change-Id: I8432eb172783c689d636a435073bb86828488b06
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227720
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Add delay for power supply startup time before sending source
capabilities packets.
BUG=none
BRANCH=samus
TEST=load on samus, plug in C to A receptacle adapter, see that
VBUS enabled before source cap packet sent.
Change-Id: If3b595e1671d089e859693b420841a639fdb146b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227423
Add support for PR_SWAP command as per PD specification.
BUG=chrome-os-partner:28343
BRANCH=samus
TEST=test by connecting two samus' and running 'pd 1 swap power'
from console. verified that both sides switch power roles by
observing console output. also tested against third party
devices.
Change-Id: I0e8738b544de9f9a4348250630e67d0fefb4486d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225559
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Update source and sink capacity tables for all PD boards. As
per spec, the first entry in both tables must be a fixed power
supply PDO. Added dual-role capable bit to fixed PDOs and added
new state variable to keep track of that information for each
port. This will be used to make decisions in charge manager and
to pass up via host commands.
BUG=chrome-os-partner:28869
BRANCH=samus
TEST=make buildall. use "pd 1 status" to check
if part partner is dual-role capable and check zinger is not,
C to A receptable adapter is not, and another samus is.
Change-Id: I49f034a372bc145cd524577c17ca210eec4c1013
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227170
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Modules that are enabled are listed below:
- Power Sequencing
- Keyboard Scan and Protocol
- LPC to support Keyboard
- Power Button Task
ec.spi.bin has to be generated manualy using
pack_ec.py
BUG=None
BRANCH=None
TEST=Tested on Stargo-Proto board
Change-Id: Ic5d504c3d6e9c7c5f3482fb7e9e37800b6274824
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/226303
Reviewed-by: Vic Yang <victoryang@chromium.org>
The fans on samus have a recommended minimum duty cycle of 20%
while running, but 30% in order to start. We've been using the
EC's built-in fan controller for the start requirement, but it
has a minimum fast-start duty cycle of 50%. It turns out that
that speed is noticeably noisy.
This change handles the startup with logic in the EC instead, so
that the fan only tries to spin at 30% initially (or if it drops
too much below the minimum turning speed).
BUG=chrome-os-partner:33429
BRANCH=ToT,samus
TEST=make buildall -j
Boot the system, let it idle with the browser windows closed, the
browse a bit, then idle. Listen for changes to the fans.
Before, I could hear the fans kick in and out as the AP load
changed. Now it's much quieter.
Change-Id: Id35215520c064eb6843686ec8bb5f3618dac6cf6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227658
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the battery cut-off command is issued with external power present,
the battery can end up in one of the following two states:
1. The battery stays responsive but is waiting for the external power
to go away.
2. The battery decides to cut itself off right away.
In case 1, we are already avoiding charging the battery again, so we're
good. However, in case 2, the charge state machine mistakenly thinks the
battery is dead and tries to revive it. Fix this by checking if the
battery is cut off before starting to revive it.
BRANCH=None
BUG=chrome-os-partner:33372
TEST=Cut off the battery with external power connected. Wait for a while
and then disconnect external power. Check the battery is sure cut off.
Repeat for several times.
Change-Id: Icf343b168a556a490bc1786802a8a6e230863a28
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227521
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously the version string was special cased in the USB stack
because the build system prevented the inclusion of ec_version.h in
any file other than common/version.c. This lead to common/version.c
being the only place that the USB version string could be computed
and thus the special case of filling in the version string descriptor
at run time. This made the USB stack more complex, and lead to the
common/version.c file including usb.h, which is actually STM32
specific.
Now, the portion of ec_version.h that is deterministic is only
updated when something in the tree actually changes (by way of a
conditional in the makefile), and ec_version.h no longer has to
depend on all object files (other than the special version.o).
This allows anyone to include ec_version.h as needed. In particular,
each board that wants to define a USB version string can directly
include ec_version.h and do so.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
touch files and verify rebuilds happen correctly
Change-Id: Ic84d0b9da90f82ebb4630fb550ec841071e25a49
Reviewed-on: https://chromium-review.googlesource.com/227211
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
When sysjump between RO and RW code, the motion sensor global
data structure get reset to 0. The motion sensor task does not
get notification from the power state change event.
Added chipset S0 state check logic to re-init sensor active flag to S0.
BUG=chrome-os-partner:33370
BRANCH=ToT
TEST=sysjump RW; accelread 0
Test Cases:
1 - press power cycle button; checked with powerinfo,accelread
2 - press power cycle button + F3 (refresh) key; checked with powerinfo,accelread
3 - Go to G3, S0, S3; checked with powerinfo, accelread
4 - boot up to S0; sysjump RW; accelread 0|1|2
Change-Id: Ibfe4ba581c8b771be15adb7440374d09fdf03953
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226698
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Sheng-liang Song <ssl@chromium.org>
Tested-by: Sheng-liang Song <ssl@chromium.org>
USB Billboard class can be used to advertise an alternate mode capable
device that hasn't entered a mode. Additionally it can remain after
mode entry providing its Billboard capabilities descriptor is
updated.
This CL postpones enumeration which previously occurred after boot
until tAMETimeout has passed and alternate mode has NOT been entered.
Future CL could choose to also (re)enumerate with mode capabilities
although this is not required by the USB PD specification.
BRANCH=none
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual,
With DFP_U which does not enter mode see Billboard class enumerate
else it does not.
Change-Id: I59a0815cd0ea551ba9a878907c0184df4ba9480c
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224663
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix bug in tap gesture. When turning on tap detection, don't
clear the history circular array index. This was causing inconsitent
tap for battery recognition because the inner window sum of z-axis
data (sum_z_inner) was relying on subtracting out old historical
data and adding in the new data, but when the array index changed,
it was subtracting out the wrong old data. This really only came in
to play if there was significant z motion before the last wakeup.
BUG=none
BRANCH=samus
TEST=keep going to sleep and waking up and test that tap for
battery works every time.
Change-Id: I55e00c805d504dd6d257a81f2cd25fe384a53257
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226591
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Get type-c port power info including power role, charger type,
and charging info. Also added host command to get number of type-c
ports.
Also adds new charging suppliers for pericom identified chargers
including DCP, CDP, SDP, proprietary, and other chargers. Priority
of these for charging is set in samus board file.
BUG=chrome-os-partner:32650
BRANCH=samus
TEST=run 'ectool --name=cros_pd usbpdpower' and verify correct
status with minimuffin, zinger, and type-C to type-A adapter.
Change-Id: I1dabbe7de4185a23df5684a5ea9a2d944f1f6ff5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223523
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Split motion_sense.c.
Translate the accel data in the Android coordinate right away.
BUG=chrome-os-partner:32002
BRANCH=ToT
TEST=On samus, check lid angle are still correct.
Change-Id: If743e25245dc1ce4cdacb8a4d5af22616c4a79e4
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225486
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Move gesture to common directory, 1st step to be reused by
other board.
Cleanup motion_sense shutdown path.
BUG=chrome-os-partner:33102
TEST=Double tap still works on Samus
BRANCH=ToT
Change-Id: I0a3b38c4a7dbe95c27dcdebff04c1176aaf932d1
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225235
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Wait until we have a confirmed PD charger before setting the PD charge
limit to non-zero.
BUG=None
TEST=Manual on samus_pd. Insert type C non-PD charger, verify that
current limit is correctly set to to 3000 mA.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib4ec663d926e6ed955427e4a77123caac0e20252
Reviewed-on: https://chromium-review.googlesource.com/225691
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Allow the list of charge suppliers and port selection priority to be
specified at the board level.
BUG=chrome-os-partner:32650
TEST=Manual on samus_pd. Plug + unplug PD and BC1.2 chargers, verify
that PD is always preferred and higher power port / supplier is always
selected.
BRANCH=Samus
Change-Id: Ic867a40120c809111bf76bf290ed6f204eab1168
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225292
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Added return parameter to enter mode functions. For DP mode on
samus and fruitpie, only send enter mode if device is a DP
sink (DFP_U).
BUG=none
BRANCH=samus
TEST=make buildall. tested a simpler version of this with a
third-party DFP_D capable device and verified we don't send
enter mode.
Change-Id: I5caf008b7b3711232aeb1a1012cde2022584109b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225288
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Shorten the hard reset timeout so that we transition out of hard
reset state faster.
BUG=none
BRANCH=samus
TEST=test on third-party product that sends source cap very soon
after we send hard reset. without this patch we weren't responding
to the first few source caps, with this change we respond right
away.
Change-Id: I285aaf0296604da22438e31bc962629701694b7b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225247
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Once alternate mode is entered the DFP will make an initial status
request to the UFP. Future status changes on the UFP are then sent to
the DFP via the attention command. This VDM consists of the VDM
header plus another VDO containing mode specific information.
CL adds ability of DFP to consume the attention VDMs status message
and in the case of DisplayPort SID toggle the necessary HPD gpio
accordingly.
BRANCH=samus
BUG=chrome-os-partner:30645
TEST=manual, for DFP w/ HPD over CC see HPD toggle correctly without
manually driving it providing cable connected when AMA is inserted.
Change-Id: Ifef60b5d0170cbcc1b518e3b13e84bac99a17e32
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224769
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>
Udelay function might get delay less than the time indicated by the
input parameter. udelay(4) sometimes get the tick like, 6->7->7->
8->8->9->A and then the udelay return. But, the sampling point of 6
could be at the end of 6(close to 7) and the point of A could be
right at the beginning of A(close to A). This function could get
delay from (us - 1) to (us + 1). This change is to ensure the delay
at least over the parameter, us.
BRANCH=master
BUG=None
TEST=Build an EC FW iamge and run on Rambi to ensure at the time
duration indicated by the parameter is elaspsed and satisfied.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: I797f80c577d7e29e75a304aec1e02d2c750f8a23
Reviewed-on: https://chromium-review.googlesource.com/224660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mohammed Habibulla <moch@chromium.org>
This updates the lightbar params with the values determined in
the optic lab. The full-on primary colors are of uniform
intensity at the brightness level used by Link. The Google colors
provide the closest match to the official color palette (at full
brightness) described at
https://sites.google.com/a/google.com/brandsite/the-colours
BUG=chrome-os-partner:33017
BRANCH=ToT,samus,ryu
TEST=manual
The calibration and testing was done in the optic lab.
You can see the result just by looking at the lightbar. For best
results, set the brightness to the max with
ectool lightbar brightness ff
Change-Id: I1cb64e3c547844adf733cd46bff1256319b4f612
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224992
Integrate charge_manager and include several API changes designed
for reporting voltage.
1. Make pd_choose_voltage set the chosen voltage for use by caller.
2. Add voltage parameter to pd_set_input_current.
3. Add pd_get_role to grab the sync / source state of a port.
4. Add charge manager PD + type C port initialization to the pd
state machine.
BUG=chrome-os-partner:32003
TEST=Manual on samus. Insert Apple charger, verify charge limit is
selected appropriately. Insert PD charger, verify that charge port
switches to PD port. Remove + reinsert chargers, verify that port /
limit is selected appropriately. Remove battery, insert power source, verify
that our power source port never becomes disabled.
BRANCH=samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Idf3198c71d2ddf1e401e766fc82a4b7a02aed068
Reviewed-on: https://chromium-review.googlesource.com/223758
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Ryu uses the same LEDs as Samus, so let's use the same brightness values
for them. Also, increase the stack size for console task so that
'lightbar' command doesn't cause stack overflow.
BRANCH=None
BUG=chrome-os-partner:32203
TEST=See lightbar in action on Ryu.
Change-Id: I89b61f6df2751c9dd6b40f9e374f01e1b0dfd504
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224426
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Fix bug causing unit to falsely shutdown due to low battery.
The shutdown warning time was not getting reset, so two false
readings of battery SOC or voltage, seperated by more than 30
seconds in time would cause "charge force shutdown due to low
battery"
BUG=chrome-os-partner:33111, chrome-os-partner:33144
BRANCH=samus
TEST=make buildall
Change-Id: I6f00187516d23aa78139e5c1565febca34176ecc
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224765
Per revisements to the DisplayPort Alternate mode specification there
are two additional SVDMs for DPout support: status & configure.
This CL adds those SVDMs and calls them (status then config) after
finding a device that supports DP Alternate mode.
Future CLs will use these SVDMs to complete providing HPD over CC
support.
BRANCH=none
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual, plug hoho/dingdong into samus and see:
1. Additional DP status [16] & DP configure [17]
2. Drives DPout properly
Change-Id: I52b373085ddc330e4afb1d1883d2621bc2e4ee95
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223260
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
All non-interactive console prints should use their tasks channel
parameter to make it easy for developers to inhibit console output.
This CL corrects printf's in the various usb_pd_policy files that
belong to the USB PD task to use cprintf(CC_USBPD, ...) instead of the
macro reserved for interactive console commands ccprintf.
BRANCH=none
BUG=none
TEST=manual, set 'chan 1' and see none of the previous chatter
relating to USB PD. set 'chan 0x08000000' and see it return.
Output from DFP side for SVDM discovery now looks:
SVDM/4 [1] ff008041 340018d1 00000000 11000008
[1119.966911 DONE]
SVDM/2 [2] ff008042 ff010000
[1119.970135 DONE]
SVDM/2 [3] ff018043 00100081
[1119.973437 DONE]
SVDM/1 [4] ff018184
Change-Id: I47e5f4ec2d4a6a25f171177ead5ebc99409f80b6
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224191
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previous reading of specification left some doubt about how SVDM
responder to 'discover modes' command communicated the number of valid
modes. It is communicated via the 'object position' field in the VDM
header where: opos = modes + 1.
This change adds the mode count to the opos field and sends only that
amount of data back to the initiator. Initiator stores that mode_cnt
so that it can correctly choose a mode when 'enter mode' phase occurs.
BRANCH=none
BUG=chrome-os-partner:30645
TEST=manual,
1. see SVDM responder to Discover modes only send supported number of
modes for SVID.
2. 'pe 0 dump' displays correct set of discovered modes on initiator.
Change-Id: I9b626dd6dd3e85e80b4f0596332300d74b1830ee
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223981
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Original implementation was complicated by belief that we'd want PD
MCU to manage entry of multiple alternate modes. This simply won't be
practical given the upper level system policies that would need to
weigh in on these decisions as well as the seemingly endless additions
to the alternate mode ecosystem.
Longer term we'll need to pass the generic alternate mode discovery
VDO info to the kernel/userland to implement remainder of policy.
However, for short term lets implement single mode entry instead.
BRANCH=none
BUG=chrome-os-partner:30645
TEST=manual, mode entry is successful on both ports.
Change-Id: Ia24f5ee4d59c13c62d68b30f8587b5e5fbdb2fa0
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223980
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
