Send the current limit chosen by charge manager to the EC so
that it can set the current limit appropriately. Note, before
this change, only the PD negotiated current limit was sent to
EC.
BUG=none
BRANCH=samus
TEST=use a non-PD type-C charger and verify current limit gets
set appropriately on EC.
Change-Id: Ic4bfce052ec8150cad07d35e2cb2fcbfd3d3e6c8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225667
Reviewed-by: Vincent Palatin <vpalatin@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>
When we are a UFP with a plug, for the supported DisplayPort pinout,
we need to state which DFP pin configuration we support.
Update the field used for declaring pin configuration in our display
dongles.
HoHo is a protocol converter : update the pin assignment to C.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:30645
TEST=none
Change-Id: Ie5484f228bd39666c6b01055bd11f68eb9acad88
Reviewed-on: https://chromium-review.googlesource.com/225231
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>
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>
We defined the DMA channel for UART Rx DMA to use, but we didn't
actually enable it.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=Check the console is still responsive
Change-Id: I0dcbeeccb3a4213305c84ec5238e6e9dbee09b33
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225280
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
There is no external pull-up on UART signals and this could lead to
garbage characters received. Let's enable the internal pull-up to avoid
this.
BRANCH=None
BUG=None
TEST=On a Ryu board with which UART Rx gets garbage when servo is not
connected, check that we don't get garbage characters anymore.
Change-Id: I014b399dfecc1b8495cce7c80c481c3668976084
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225095
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We updated the source PDO indices and we also need to update the output
voltage selection function.
BRANCH=None
BUG=chrome-os-partner:33133
TEST=On Plankton, output 5V and measure with INA.
Change-Id: I771c04cf929a8e473cf09ae3eb222518f042600a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225154
Reviewed-by: Pin-chih Lin <johnylin@chromium.org>
The battery cut-off is achieved by putting BQ27742 in SHUTDOWN mode.
BRANCH=None
BUG=None
TEST=Unplug AC and do 'cutoff' in EC console. The EC console goes
unresponsive.
Change-Id: I4a1aa359d79333d47aaf53b685a52960e5dfd652
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225007
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On an interrupt from the Pericom charger detection IC, check the current
limit of the attached charger. Charge manager is informed of available
charge from BC1.2 source and PD sources and selects the proper port + charge
limit in each case.
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.
BRANCH=samus
Change-Id: I47e1e3be1c522f1e11529a0b4ac665e695f33e14
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221791
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This is needed for inductive charging to work.
BRANCH=None
BUG=chrome-os-partner:31392
TEST=On Ryu, close the lid and check BASE_CHARGE_VDD_EN is toggled.
TEST=Open the lid and see the AP booting.
Change-Id: Ib153c08a803088b832c7d65261c71605c3378d5f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224804
Reviewed-by: Vincent Palatin <vpalatin@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>
Unlike STM32F0, we need to configure alternate function for USB module
on STM32F373. Adds the pin configuration for ryu_p2 and also adds the
proper configuration step in USB module.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=With changes to enable USB on ryu_p2, see the device enumerated
Change-Id: I5e2cb7cfc44a1bb88bae69804021c783c8d17968
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224789
Reviewed-by: Vincent Palatin <vpalatin@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>
The new build target ryu_p2 is mostly based on ryu. On ryu_p2, we have a
new EC chip with bigger flash, so make the corresponding changes:
- Pinout changes
- HW Timer: TIM5
- USB PD Tx Timer: TIM3_CH4
- USB PD Rx Timer: TIM2_CH4
- Use UART2 for EC console
- Disable UART Tx DMA as it conflicts with USB PD Tx DMA
- Use 24MHz HSE x2 = 48MHz for SYSCLK
BRANCH=None
BUG=chrome-os-partner:32660
TEST=Sanity check on a new board:
- i2cscan
- PD negotiation
- UART console
- gettime
Change-Id: I4ef6b53a928a2777721e3874032aeb0e6b2b4c92
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221404
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
