I managed to mess this up previously, the STM32L and STM32F should
use uint32_t and so should the STM32F3 it turns out. Only the
STM32F0 uses uint16_t right now.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: Ieca4368c4280a0f25c928b6670aeccbaf8eabbef
Reviewed-on: https://chromium-review.googlesource.com/227740
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@google.com>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
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>
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>
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>
Per table 6-24 of USB PD spec an alternate mode adapter (AMA) should
include both product & AMA VDOs.
BRANCH=samus
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual,
Connect hoho/dingdong to fpie/samus and see product VDO proceed the
AMA VDO in DFP_U console output:
Product VDO -----------------------------v
|------|
SVDM/5 [1] ff008041 340018d1 00000000 50100001 1100000b
Note, hoho's PID == 0x5010
And dingdong (0x5011)
SVDM/5 [1] ff008041 340018d1 00000000 50110001 1100000b
Also see bcdDevice field in descriptor match above data.
$ lsusb -v -d 18d1: | egrep -i "idproduct|bcddev"
idProduct 0x5011
bcdDevice 0.01
Change-Id: I4d898816a45c68c7ff75a54fd348fc11be408ae0
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226125
Reviewed-by: Vincent Palatin <vpalatin@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>
BRANCH=samus
BUG=chrome-os-partner:31192,chrome-os-partner:31193
TEST=manual
Attach hoho/dingdong to samus and see AMA VDO bits <2:0> set to 0x3
during the discover identity response.
AMA VDO
|------|
SVDM/4 [1] ff008041 340018d1 00000000 1100000b
Change-Id: I1e2459b87cceca88ab3ae09440b689041ae03c7c
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226101
Reviewed-by: Vincent Palatin <vpalatin@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>
This uses the newly allocated simple serial SubClass
and Protocol identifiers to make enumeration of serial
consoles over USB easier. The simple usb serial kernel
driver can select based on vid/class/subclass/protocol,
making it trivial to attach to serial consoles.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Enable USB console on discovery-stm32f072 and verify
that a new ttyUSB? device is discovered.
Change-Id: I6d3e414a20753573c2ee90a48fb1d5dce2c3972d
Reviewed-on: https://chromium-review.googlesource.com/225869
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@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>
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>
A USB type-C to DisplayPort dongle can support either DPv1.3 or
USB Gen 2 signaling.
Our dongles need to advertise that they support DPv1.3 and only this.
Our DFP needs to request DPv1.3 signaling.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:30645
TEST=Plug a type-C to DP dongle from another vendor to Samus and see a
display output.
Change-Id: Ie0ac16b675e86f635220a954a2c03442777cc527
Reviewed-on: https://chromium-review.googlesource.com/225250
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-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>
Simple control of SPI for flashing over USB.
This driver is working, and using the discovery board
with a W25Q16 flash chip attached flashrom can read,
erase, write, and verify the whole chip in 45 seconds.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I224f1f87cd6adc8b64c17de1df98dae0a9cfa6a5
Reviewed-on: https://chromium-review.googlesource.com/218740
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Updating the fan speeds according to the manufacturer's specs.
The fan vendor recommends that the minimum fan speed be a 20%
duty cycle. Since the built-in fan controller has a tach-based
feedback loop, I'm using the RPM value instead of the duty cycle
(20% is 2286 RPM, according to the vendor).
The vendor also wants a 30% duty cycle to start turning, but the
built-in fan controller provides support for fast-start too. The
controller's minimum fast-start duty cycle is 50%, but it also
has a programmable number of revolutions that it will wait before
backing off.
Holding my ear down close to the fans while they start and stop,
it seems that the minimum 2 revolution start period is sufficient
and provides the least noise. Of course, since I've never had any
problems starting the fans directly at 1000 RPM this noise is a
little more noticeable than that. It's quite possible that the
built-in controller is smart enough to make 1000 RPM work by
bumping the duty cycle up until the fans turn even if the fans
don't like it.
BUG=chrome-os-partner:32892
BRANCH=ToT,samus
TEST=manual
Listen closely and run the EC console "faninfo" command to see
the fans start and stop as the system boots and idles.
Change-Id: I47c9e7cef3f9f4bd815a13032fe10234decd62ed
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224830
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
This adds the DMA channel definition for UART2 and allows selection of
DMA channel for UART.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=With the CLs to enable the new Ryu boards, check the console is
working.
Change-Id: I964c284899777dda67c264e622aea6aba752ea76
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224176
Reviewed-by: Vincent Palatin <vpalatin@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>
Add macro for default hibernate delay, and set to 7 days on samus.
Also, adds CONFIG_ option for hibernating early if low on battery.
For samus, setting early hibernate at 1 day when battery < 10%.
BUG=chrome-os-partner:33088
BRANCH=samus
TEST=make buildall
Added ccprintf("Target shutdown: %.6ld\n", target_time); to print
out target shutdown time after setting it. Verifed the following
on samus
1) If CONFIG_HIBERNATE_DELAY_SEC is left at default 3600 (samus
board.h does not overwrite it), then target time is 3600s.
2) If CONFIG_HIBERNATE_DELAY_SEC is defined in samus/board.h, then
target time equals that value.
3) If CONFIG_HIBERNATE_DELAY_SEC is defined as 1 week and
CONFIG_HIBERNATE_BATT_PCT is defined to 10% and
CONFIG_HIBERNATE_BATT_SEC is 1 day, then when battery is between 8-10%
target time is 1 day and if battery is at 11%, target time is 1 week.
Change-Id: Ief155ad6c327775fa348d3458fc47ee9dd8569c3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224520
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
Added data role bit to PD message header. The data role
is currently tied to power role: source = DFP, sink = UFP.
BUG=none
BRANCH=samus
TEST=tested with third part protocol analyzer
Change-Id: Ic56ea92899d20013aace108cee794d10c3780364
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We already have interrupt handlers for channel 4 to 7. We need channel 3
for the new Ryu boards. Add the handlers for channel 1 to 3. Also,
instead of copy-pasting interrupt handlers, define a macro and declare
interrupt handlers with it.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Check PD communication on the new Ryu board (with other CLs to
enable the new boards.)
Change-Id: I51d6bd16739f31a7efbeb4ec19bb91a1546fe21d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224175
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>
The register format of INA231 and INA219 are very much alike. In our
use case, we only need to use different coversion coefficient.
BRANCH=None
BUG=chrome-os-partner:32764
TEST='ina 0' on Plankton V2.
TEST=Build twinkie.
Change-Id: I9c8e21e30ed844566793dcc1221f865400c3d90d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223370
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Adds double tap detection for samus. When user double taps
in S3 or lower to show battery state of charge on lightbar.
BUG=chrome-os-partner:29041
BRANCH=samus
TEST=make buildall
Tap the lid in S3 or lower.
Change-Id: Ic5f4709bdee2472cb7e91717318337b04bae1fc8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221965
Reviewed-by: David Schneider <dnschneid@chromium.org>
When the cable flip button is pressed, instead of only flipping on
Plankton side, we should also signal the port partner to flip. This is
done by sending a custom VDM. Upon receiving the flip VDM, the port
partner is responsible of flipping the DP/USB polarity.
Note that the "flip" here only affects the superspeed lanes. The CC
lines polarity is not changed. We need this for factory test automation,
and this "flip" function should only be used for testing purpose as it
clearly violates the USB PD spec and it only works on devices that
accept the custom flip VDM.
BRANCH=Samus
BUG=chrome-os-partner:32163
TEST=COnnect Plankton and Ryu. Press the button on Plankton and make
sure the polarity GPIOs on Ryu are negated.
Change-Id: I7ee5ea70067de4f422a7478623fe7fe8d3724372
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223325
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The valid and writable flags the EC sends back to the AP are incorrect.
They are a little bit different on differnt chips, so let's move it to
flash physical layer. This is not any causing problem, but we should fix
this.
BUG=chrome-os-partner:32745
TEST=make buildall
BRANCH=samus
Change-Id: Ibcda5ae770f5ea02cde094490997a5bc447df88f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222661
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On STM32F0, we cannot work around the hard fault triggered when trying
to protect the whole flash. Therefore, we need to go with the
ALL_AT_BOOT approach. When write protect is enabled, instead of setting
ALL_NOW flag to immediately lock down the entire flash, we need to set
ALL_AT_BOOT and then reboot to have the protection take effect.
BUG=chrome-os-partner:32745
TEST=Along with the next CL. On Ryu:
1. Enable HW WP. Check the output of 'ectool flashprotect' and see
correct flags.
2. 'flashrom -p ec --wp-range 0 0x10000'. Check RO_AT_BOOT is set.
3. Reboot EC and check RO_NOW is enabled.
4. Boot the system and check ALL_NOW is set.
5. Update BIOS and reboot. Check software sync updates EC-RW.
6. 'flashrom -p ec --wp-disable' and check it fails.
7. Disable HW WP and reboot EC. Check RO_NOW and ALL_NOW are cleared.
8. 'flashrom -p ec --wp-disable' and check RO_AT_BOOT is cleared.
TEST=Enable/disable WP on Spring. Check RO_AT_BOOT/ALL_NOW can be set
properly.
BRANCH=samus
Change-Id: I1c7c4f98f2535f1c8a1c7daaa88d47412d015977
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222622
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a preparatory work for the following change for write protection
support on STM32F0.
BUG=chrome-os-partner:32745
TEST=make buildall
BRANCH=samus
Change-Id: Ic4deea06e26c4a6ac024a5388e1a5783b40e9876
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
charge_manager is intended to manage charge limits from various tasks
(typically PD charge tasks and USB / BC 1.2 charge tasks). These tasks
can update the charge limit of a port by calling charge_manager_update
(thread-safe function). If the charge limit has changed,
charge_manager_refresh will be queued as a deferred task, which will
select the "best" charge port and set the proper charge limit.
In order to use charge_manager, a board needs to do the following:
1. Declare PD_PORT_COUNT in usb_pd_config.h
2. Implement board_set_charge_limit
3. Implement board_set_active_charge_port
4. Call charge_manager_update whenever the available charge on a port changes.
BUG=chrome-os-partner:31361
TEST=Manual on samus_pd, with subsequent commit. Insert and remove
various chargers, check console to verify PD charger always has priority
and correct current limit is set based upon 'best' charger.
BRANCH=samus
Change-Id: Iede120b69e0b46ed329bcf9b7e07c39ba5e9f77b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222723
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Makes a significant encoding change to existing opcodes and
adds several opcodes to allow for encoding the more complicated
patterns that we have on the lightbar (S0, etc.) as well as
condense the ones we technically could encode but couldn't
fit in the 192-byte footprint allotted to us (KONAMI).
We need this to remove sequences from the EC code.
BUG=chrome-os-partner:32203
BRANCH=ToT
TEST=run test programs on hardware and lightbar simulator
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Change-Id: I12fe908d3a43a924aa39f24ad66adbe53f7f38e1
Reviewed-on: https://chromium-review.googlesource.com/222949
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@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>
Remove the meaningless version string in iSerialNumber, which was incorrect
since this string should be unique to a device if it exists.
Export the firmware version string as the configuration string, so it's
traceable to a given firmware build/sources.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=make buildall
from a workstation, do "sudo lsusb -v" and see the full version string
exported as the configuration name.
Change-Id: I557df2936421e2926ac0fc0003888370cec3e201
Reviewed-on: https://chromium-review.googlesource.com/222877
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Change effects:
1. samus_pd: Acts as initiator of SVDM discovery once its reaches source
ready and upon identifying UFP with display port
alternate mode enters that mode.
2. hoho: Acts as responder for SVDM discovery providing its identity,
svids and svid capabilities which are display port only. If
asked to enter display port alternate mode it does.
3. fruitpie: Acts a initiator with mock display port mode.
BRANCH=none
BUG=chrome-os-partner:30645
TEST=manual,
Plug hoho into samus_pd
- see dpout
- from console
> typec 0
Port C0: CC1 451 mV CC2 111 mV (polarity:CC1)
Superspeed DP1
Change-Id: I1a76767353a69baeceffa3e79c37dcea77b8337d
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221354
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
