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>
Seems like we were setting outputs too early during boot, sometimes causing a
power leak. SPI should only turn on power levels more active than S3, not on the
S5->S3 transition.
BUG=chrome-os-partner:32824
BRANCH=None
TEST=Pinky powers on, Scope VCC33_PMUIO and VCC33_IO, note that they're smooth
Change-Id: I05c3622d124c2539222b883b895bc9092c5f0b12
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224508
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is the first step to fix a leak when powering up the system.
Some stuff should wait till after the rails are up.
The SPI timeout was removed because there's a simpler way to determine this:
SPI is only ready when the AP goes from S3->S0
BUG=chrome-os-partner:32824
BRANCH=None
TEST=Pinky powers on
Change-Id: Ia4281f54f7735d4efe2bc3e8ba1e462fccc51fd0
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222632
Reviewed-by: Randall Spangler <rspangler@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>
So far, we always use channel 1 of the Tx timer and the configuration
code is hard coded. We need to support other channels for new Ryu
boards. Let's make this a configurable bit.
BRANCH=samus
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Plug in Zinger to Ryu and see 20V come up.
Change-Id: Id08d4eb0d6a5721d8a03672484d0892a0714383b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223836
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>
- Remove hardware double-buffering : it's complex to get right and does
not provide any performance improvement.
- Increase buffer size x2 to decrease overflow frequency.
- Fix buffering and simplify code.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28337
TEST=make BOARD=twinkie
do a long acquisition on a sample pattern from the function generator
and verify that no packet are missing and the waveform looks good.
Change-Id: I12a9e8370d3f238e8894f15ce0190e2e0fbc26d7
Reviewed-on: https://chromium-review.googlesource.com/223565
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-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>
VCORE needs time to come up after PCH_PWROK is asserted and we
should be waiting for VCORE_PGOOD to be 1 before proceeding.
This also moves the 5ms delay for PCIe to be before SYS_PWROK
since that is where it is requried according to the power
sequence specification (rev 1.3 figure 2-4).
BUG=chrome-os-partner:33027
BRANCH=samus
TEST=build and boot on samus
Change-Id: I4bd969bdb56ecf14cc68754318452861b70f0539
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224033
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The timeout when we are not seeing a PS_READY message has been updated
to 450-550 ms in the PD specification, reflect that change in the code.
In case we are reaching this timeout, we need to send a HARD_RESET.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=plug a PD source with a 300ms delay before PS_READY.
Change-Id: I116a858c42a55f2036b3f2e13730cf29392a3420
Reviewed-on: https://chromium-review.googlesource.com/223785
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Enable hibernate on zinger for DVT. Note: this may break
some EVT zingers.
BUG=chrome-os-partner:28335
BRANCH=samus
TEST=make buildall
Hibernate tested in CL:220837
Change-Id: I65f4776d27ad88beee101fb00d0b6221ba272a26
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223738
Reviewed-by: Vincent Palatin <vpalatin@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>
USB PD spec now calls for HPD signal to be managed across the USB PD
protocal. In preparation this CL makes the HPD GPIOs outputs and
initially low.
This should NOT effect older revs of the design as GPIOs were unused
(had unstuffed option for external XTAL).
BRANCH=samus
BUG=chrome-os-partner:30645
TEST=compiles & runs. With reworked board can manually trigger HPD.
Change-Id: I0a64c1daf8d8c866f5de237c3daf4be028eecd63
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223462
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@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>
The ADC interrupt does not clear the NVIC pending register. This
can cause the interrupt to fire more than once for a given
interrupt.
BUG=none
BRANCH=samus
TEST=Send hard reset from samus to zinger using "pd 1 hard" on
PD MCU console. This causes zinger to cut its output voltage
and go into voltage discharging mode. When voltage discharge is
complete, we get an ADC interrupt and switch back to current
monitoring. Before this CL, sometimes (1 out of 20) times the
ADC interrupt will fire twice, causing an OCP to be detected.
With this CL, we never see the double fire.
Change-Id: I91397a04773d04e263bc80a698c8799342b80a2e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223381
Reviewed-by: Vincent Palatin <vpalatin@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>
The PD task is using more space in the stack and I'm seeing frequent
stack overflow on Plankton. On Samus, we already increased the stack
size. Let's also increase this on Ryu and Plankton.
BUG=None
TEST=make buildall
BRANCH=None
Change-Id: I468985303b7fd38455dd1fed9db54544581c49cf
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223368
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Display battery percentage on the lightbar whenever AC status
changes.
BUG=chrome-os-partner:32894
BRANCH=samus
TEST=Plug and unplug AC in S0 and in G3 and make sure that lightbar
displays battery percentage each time
Change-Id: I281c9242d185da06b0c778de12e4f6340779a840
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223362
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Implemented source recovery time following a hard reset. According
to the spec:
After a hard reset, the source must dissipate output voltage
to vSafe5V. After establishing the safe voltage condition on VBUS,
the power supply shall wait tSrcRecover before powering VBUS to
vSafe5V.
BUG=none
BRANCH=samus
TEST=plug in a type-c to type-a adapter to samus. then issue a hard
reset from the console and verify that it takes nearly a second before
samus re-enables vbus.
Change-Id: Id21eb7cf03759b7ecd64ad11c3c57e66cf35370a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222935
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For a sink, when there is no source cap packet within SinkWaitCapTimer,
then it sends a hard reset. Once the hard reset has been retried
nHardResetCount times then it shall be assumed that the remote
device is non-responsive, and we stop sending the hard reset.
BUG=none
BRANCH=samus
TEST=Tested with a non-PD charger. When plugged in, we see two hard
resets and then it stops
VBUS 1, 1!
C1 st3
C1 st14
C1 st2
HARD RESET!
[494.906344 HC 0x100]
C1 st3
C1 st14
C1 st2
HARD RESET!
[495.668624 HC 0x100]
C1 st3
> adc
C0_CC1_PD = 20
C1_CC1_PD = 1783
C0_CC2_PD = 36
C1_CC2_PD = 21
V_BOOSTIN = 5329
>
Change-Id: Ib0fc49642aba754015b8055cf1971577b48ac058
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222853
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add support for enabling Vconn on Raiden ports by defining
CONFIG_USBC_VCONN. This is enabled by default for ryu, samus,
and fruitpie.
BUG=chrome-os-partner:30445
BRANCH=samus
TEST=Load onto samus. Make sure we can still charge from zinger.
Plug in type-A to type-C adapter with pulldown and see that samus
becomes power source. Do a gpioget and verify that only one VCONN
GPIO is enabled (low), and the VCONN that is enabled is opposite of
the polarity queried by pd 1 state. Try both ports, both polarities
and make sure the correct VCONN gpio is enabled.
Change-Id: Icea4c18b9c813cf7e8e21fd4f455bbd5fb4dbc91
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222850
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Per alternate mode this GPIO should not be enabled until alternate
mode has been successfully entered.
BRANCH=none
BUG=chrome-os-partner:31192
TEST=manual, compile & boot on hoho gpioget PD_SBU_ENABLE = 0
Change-Id: Ide2a47851f30812b289221e302a930134a58a8a0
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223159
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Move the 3.3DSW_GATED rail to be enabled in transition to S0 and
disabled in the transition to S3.
This is the rail for the core regulator and temp sensors so it
does not need to be enabled in S5.
BUG=chrome-os-partner:32382
BRANCH=samus
TEST=build and boot on samus, successfully suspend/resume and
ensure that PP3300_DSW_GATED is turned off in S3.
Change-Id: Ic47f81860e3f0cb7b5d81ba96181b7ee7cf72f66
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223077
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reboot the PD device after a successful flash so that it will boot into
the new RW. This syncs the ectool PD update to the implementation in
flash_pd.py.
BUG=chrome-os-partner:31361
TEST="./ectool --name=cros_pd flashpd 0 1 ec.RW.bin", verify flashing
succeeds and PD is rebooted after flash.
BRANCH=samus
Change-Id: I14e7dffe59fcc7ca678c76890dbc825df5b19862
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223062
Reviewed-by: Alec Berg <alecaberg@chromium.org>
There's already an external pull-up to PP3300. The internal pull-up has
no use but provides a leakage path when the AP is off.
BUG=chrome-os-partner:31762
TEST=Repeatedly power cycle Ryu. Check the system goes to S0/S5.
TEST=Power off from the AP. Check the system goes to S5.
BRANCH=None
Change-Id: Id0ae966414de01e3a2b91314f661f37941175a87
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222625
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Wire up the discovery's four LEDs and one user
button as GPIOs that can be written and read using
the new USB GPIO driver. This also adds an extra
tool called usb_gpio that provides control of GPIOs
from the linux command line.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=cd board/discovery-stm32f072 ; make flash
cd extra/usb_gpio ; make
usb_gpio write 0x1e 0x00
Change-Id: I15115f82b15b6c35d1a34b83b7114a6bfa6a3d67
Reviewed-on: https://chromium-review.googlesource.com/218270
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
