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>
The BOS (Binary Device Object Store) descriptor was added to the USB
specification (3.0) to allow a richer set of device capability
specific descriptors.
The Billboard class is meant to expose (read-only) the status of USB
devices capable of alternate mode functions. It's required to use the
BOS descriptor type and at a high level looks like:
- BOS Device Descriptor (5bytes)
- Container ID Device Capability Descriptor (20bytes)
- Billboard Device Capability Descriptor (44byte + 4 * numSVIDs)
This CL adds:
1. Ability for Get Descriptor on BOS descriptors. Note hidden behind
CONFIG_USB_BOS as these descriptors change USB device requirements
to:
- bcdUSB >= 0201
- no interface descriptors
2. structures for all BOS, Container & Billboard descriptor elements
complete w/ CamelCase.
BRANCH=none
BUG=chrome-os-partner:32652
TEST=compiles with CONFIG_USB & CONFIG_USB_BOS enabled.
Change-Id: I1b24bc728f2ebba7d91840801d2ebe576e240e7c
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221570
Some platforms may need to take different actions depending on which
port is requesting a limit. Add a new port parameter to the
pd_set_input_current_limit API to accomodate this.
BUG=chrome-os-partner:32003
TEST=Manual on samus_pd. Verify zinger charges battery.
BRANCH=samus
Change-Id: I1578252c751b3a80b4da6ca68e2a958934283cbf
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222621
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This prepends EC_ a macro exposed in ec_commands.h, moves a
macro into lbcc that is not used elsewhere, and changes lb_program
structs to lightbar_program.
BUG=None
BRANCH=ToT
TEST=make buildall -j
Change-Id: I481562da72d91f846c64cf9af40338027641462c
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222406
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add support for enabling USB type-C Vconn by defining CONFIG_USBC_VCONN.
Enable Vconn support for samus, ryu, and fruitpie.
BUG=chrome-os-partner:30445
BRANCH=samus
TEST=make buildall
Change-Id: Ibe247286c96fd5a8fa12c88a4e3a5fea02997134
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222284
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The PD protocol no longer uses a SHA1 RW hash. Instead, it uses the
first 20 bytes of the SHA-256 hash. Update constants and comments
accordingly.
BUG=chrome-os-partner:31361
TEST='make buildall -j'
BRANCH=samus
Change-Id: Ice74b841dbd1d81205c1ef0079a5e18fca2153b6
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222446
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Design Goals:
1. Every time the AP boots, the same default sensor settings are configured.
2. If the AP goes to suspend (S3) and wakes back up (S0),
then the AP sensor settings will be restored.
3. In S3 and in S5, only sample specific sensors that are needed.
BUG=chrome-os-partner:32368
BRANCH=ToT
TEST=Verified on Samus.
Verified suspend and resume logic with EC console messages.
- Test Case0: close lid & open lid
- Test Case1: powerd_dbus_suspend
Change-Id: I553c53e63ecfcb39d5e649a7189aa6ea02589471
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220371
Reviewed-by: Alec Berg <alecaberg@chromium.org>
PULSE and TEST sequences are not used anywhere. Remove them to save
flash space. Also, fix msleep(MSEC) calls in the unit test; it's
essentially usleep(SECOND) written in an incorrect way.
BUG=chrome-os-partner:32203
TEST=make buildall
BRANCH=None
Change-Id: I61ba897df632538eb89364a4c913d5fee87f3864
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220711
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
ectool autofanctrl 1 - set auto fan control for fan 1
BUG=chrome-os-partner:23803
TEST=Tested the above EC command on Auron
BRANCH=none
Change-Id: Idcd3690ad98d7965420f26f7cc445207fe73704d
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221816
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add a minor revision to the PD device hardware ID field in the info
custom VDM and set increment this minor ID from 0 to 1 for zinger.
This differentiates zingers for the auto-update payload, so we can
update only those with a specific major and minor ID version.
BUG=none
BRANCH=samus
TEST=load onto samus and zinger. when connect zinger, see on PD
console: Dev:0x0401 SW:2289 RW:0, which shows the appropriate
device ID.
Change-Id: I482ee2d850332b608cdd81537f68d4dc509bfc1a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221320
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Changed sending of info VDM from the UFP side in SNK_DISCONNECTED
to the DFP side in SRC_READY to match the PD spec. Only the DFP
is supposed to send VDMs, and by default the power source is the
DFP. This affects simple DFPs such as power adapters, they must
initiate the info VDM once a power contract has been negotiated.
BUG=none
BRANCH=samus
TEST=load onto samus_pd and zinger and make sure that when you
attached zinger to samus, samus receives info VDM and prints out
something like:
VDM/7 [11] 18d1000b
Dev:1 SW:2280 RW:0
Change-Id: I16ceac31939fdc1c74be7323e628dd8706e1283b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221174
Reviewed-by: Todd Broch <tbroch@chromium.org>
This is mostly the same as previous commits, but with increased delay.
Previously, we have short delays (e.g. 3ms) which is too short and may
cause instability.
Now that we have slowed down the time when running unit tests and
increased the delay, this shouldn't cause problems anymore.
BUG=chrome-os-partner:31200
TEST=Repeatedly run multiple unit tests in parallel.
BRANCH=Samus
Change-Id: Ib55e3adc5fd27a8e233996b4799dab3cefd62318
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220734
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
First case is for legacy support
ectool pwmsetfanrpm <targetrpm> - set all fans to <targetrpm>
ectool pwmsetfanrpm <fan> <targetrpm> - set <fan> to <targetrpm>
BUG=chrome-os-partner:23803
TEST=Tested the above EC commands on Auron
BRANCH=none
CQ-DEPEND=CL:220960
Change-Id: I8f447f53289abaa9c5cc1285f9f0921328fbf32c
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221291
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Automatically go into hibernate (standby mode) if not powering
anything for 60 seconds. Will wake up when it is plugged into
something (senses pull-down on CC line).
BUG=chrome-os-partner:28335
BRANCH=samus
TEST=load onto zinger. if disconnected for 60s, see hibernate
print on zinger console. when connected to a device, verified
it boots again.
Change-Id: I2564c6192395bb5e4f6d7586c2725f13a4581049
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220837
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
