Renaming this to 'opos' for consistency with USP-PD specifications
'object position' in VDM header.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35495
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdgetmode pdsetmode can successfully enter/exit
other modes
3. Works across hard & soft resets
Change-Id: I08cb8e003ced4de481adcb503bcba3437ebb1ab7
Reviewed-on: https://chromium-review.googlesource.com/241718
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Most GPIO/peripheral interrupts are enabled in HOOK_INIT or some other
*_init() functions that are called before task_start(). Quite a lot of
these IRQ handler wake some task to process the interrupt, and this
causes a race condition. If the interrupt is triggered before
task_start() is called, the system may crash/hang/whatever.
Fix this by only allowing rescheduling tasks if task_start() is called.
This is basically the cortex-m version of commit e541eeb2.
BRANCH=Ryu
BUG=None
TEST=Without this fix, my Ryu P3 always crashes when cold resetting from
bootloader mode. After applying this fix, it doesn't anymore.
Change-Id: I0f81e90482ff97469c4f0423d6aa060f2ac76f74
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/243626
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
The PROCHOT assertion that happens when PECI temp crosses the
Thigh threshold has a severe impact to performance so raise
this value a bit to compensate for the 5C degree change that
was made for broadwell.
This still leaves a few degrees between Thigh and Thalt for
PROCHOT to cool down the system before power will be cut.
BUG=chrome-os-partner:35483
BRANCH=samus
TEST=build and boot on samus, verify table with 'thermalget'
Change-Id: Id29d5100b90c68c59b275592b7f4e1738dd33878
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243243
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
If we put the touchscreen in reset solely based on the lid state then
we do not allow the kernel driver to properly save and restore controller
state when entering suspend from a lid close event.
Since we want to always have touchscreen in reset in suspend/off state
and not in reset when the system is on then we can just remove this hook
because there is already logic in power_handle_state for that behavior.
BUG=chrome-os-partner:35879
BRANCH=samus
TEST=manual testing on samus:
1) put the device to sleep with lid open and powerd_dbus_suspend,
verify that TOUCHSCREEN_RESET_L=0
2) put the device to sleep with lid close and verify that
TOUCHSCREEN_RESET_L=0
3) check for kernel errors to ensure that there are no issues
saving touchscreen controller registers in the suspend path.
Change-Id: I5bff6356c54f064879a164e9ad4e67f1b2bcce6a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243242
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Misidentifications are still occurring on slow plug insert, so double
the debounce time.
BUG=chrome-os-partner:35633
TEST=Manual on Samus. Plug 1A Apple charger and verify detection is
correct. Test various plug speeds and verify detection is correct on all
but intentional slow plugs (first contact to fully plugged > 1s).
BRANCH=Samus
Change-Id: I1c34a6b8cfd1550d1ae5d3f45d9709277e39c51d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243328
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Turn off prochot warning on bq24773 by default because our
battery can always supply enough power for the whole system
so we don't need to throttle the CPU if the BQ senses too much
input current.
BUG=chrome-os-partner:34885
BRANCH=samus
TEST=force BQ into it's prochot condition on samus by setting
the charging voltage temporarily below the battery voltage, which
causes INA to turn off and the BQ to think IADP is > 4.1A. in
this condition PROCHOT is normally asserted and CPU slows down,
but with this patch PROCHOT is not asserted and the CPU does not
slow down.
Change-Id: I658dbe568b7bfe94944ef90d6d59656a0683c8a0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243231
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Several modifications to samus fast charging to fix bug where
charging circuit stops charging the battery.
- Fix bug: if we have a bad temperature reading, fast charging should
ignore it.
- Change the fast charging high temperature profile to set a charging
voltage equal to the maximum of 8.3V and the current battery voltage.
- Divide the normal temperature profile into two phases, low voltage
charging and high voltage charging. Once we transition to second
phase, don't allow it to go back to phase 1 unless AC is removed.
On samus, we have to make sure we never command the BQ to a charging
voltage that is below the present battery voltage or else the INA will
lose power and we will not be able to charge the battery until AC
is disconnected.
This also changes charge_state_v2 so that the fast charging profile
override is called even when AC is disconnected to avoid jumps in
temperature as seen by the fast charging code.
Also changes the voltage threshold for transitioning from phase 1 to
phase 2 of normal temp charging so that the transition is taken a little
earlier to match the desired profile slightly better.
BUG=chrome-os-partner:35491
BRANCH=samus
TEST=Added custom console command to be able to directly control the
battery temperature that charger_profile_override() uses:
static int command_chgtemp(int argc, char **argv)
{
char *e;
if (argc < 2)
return EC_ERROR_PARAM_COUNT;
chg_temp = strtoi(argv[1], &e, 10);
if (*e)
return EC_ERROR_PARAM1;
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(chgtemp, command_chgtemp,
"",
"",
NULL);
Using this command, I jumped back and forth between all three temperature
fast charging regions and made sure that (1) we never set a charging voltage
below the present battery voltage and (2) we never stop charging the battery.
I ran this test at low battery and high battery percentage and with low load
(G3) and high load (S0 with webgl aquarium).
Change-Id: I035603a4ab48a156ab43f8c93f21200c4b664aab
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243143
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change the charge override hot keys to ctrol+search+0|1|2
BUG=none
BRANCH=samus
TEST=use the hot keys and verify that the PD console shows
charge override host command
Change-Id: I5551190743ea064a967164b9d95143cc966662e1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242832
Reviewed-by: Shawn N <shawnn@chromium.org>
Samus panels are spec'ed at 23mA max LED current. Limit the max
current to that.
BRANCH=samus
BUG=chrome-os-partner:35816
TEST=The following command should read back the value of 0x4 after
system boot, resume as well as after panel off/on sequence:
ectool --dev=0 i2cread 8 0 0x58 0x11
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Change-Id: I8f94a8bdc987ca5169ca3b6f8236ab7263ee4ef2
Reviewed-on: https://chromium-review.googlesource.com/242971
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
To achieve higher power efficiency, we want the input voltage to be as
low as possible. If the PD source advertise several choices over
PD_MAX_POWER_MW, choose the one with the lowest voltage.
BRANCH=Ryu
BUG=None
TEST=Plug in Ryu to Zinger and check that 12V is selected.
Change-Id: Id8c4da65bfd3dfd174e1fd5528af9f7df7da2a74
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/242670
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
To prevent overloading inductor L2, we can't really draw too much power
from the type-C power. The voltage at L2 is around 4V, and we want to
keep the current below 6A, so let's limit the input power to 24W.
BRANCH=Ryu
BUG=None
TEST=Charge the battery on Ryu while the system is up.
Change-Id: I80f46d7992c64765f4de985e3a9f9492c719907b
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/242602
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Currently, we only use PD_MAX_POWER_MW for battery power source and
PD_MAX_CURRENT_MA for other sources. This change makes it so that both
limits are honored no matter what the power source is.
BRANCH=Ryu
BUG=None
TEST=Set current limit to 1A on Ryu and charge from Zinger. Make sure
only 1A is pulled.
Change-Id: If9b2451f1351c6548b831d36c8162b2f86f42492
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/242629
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Poll USB PD accessories for event log entries only after we have
performed a Discover Identity and identified them as a Google device
(USB VID = 0x18d1) in order to avoid confusing third party devices with
our logging VDM.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35858
TEST=connect Zinger to Samus and see the proper PD log entries.
Change-Id: I022fa0d19dc012e46a27b786a724ff251280eeaf
Reviewed-on: https://chromium-review.googlesource.com/242871
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Design capacity and Design Energy need to be multiplied by the scaling factor.
BUG=None
TEST=Manual test with hadoken without charging enabled. Observed the battery
level decreasing.
BRANCH=NONE
Change-Id: Icb5f74766c2416128277df4fe1bb00fc7307f5e5
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242890
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fix bug if we are executing a power swap to a sink, and we don't
get PS_RDY from port partner, then we transition to SNK_DISCONNECTED
without switching our power role to sink, which could cause us to
get wedged in the wrong state if we also receive a hard reset a
little later because we will have Rd asserted but are will transition
to source role and can never get out of it.
BUG=none
BRANCH=samus
TEST=load onto two samus' and executing a bunch of power swaps. load
custom code on one samus to never send PS_RDY when switching from sink
to source and make sure when power swap occurs the state machine does
not get wedged with the wrong role.
Change-Id: I7eb2bd4d48f32770b8d7a754fee8ac8da35fa949
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242760
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The new toolchain is putting again the __enter_hibernate function in
flash (.text) rather than in SRAM (.iram.text) after inlining both the
hibernate() and __enter_hibernate() function.
Workaround this issue by forcing "noinline" on __enter_hibernate().
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=chrome-os-partner:35774
TEST=make BOARD=samus dis
and check the disassembly, the __enter_hibernate is called in SRAM
through a veneer.
Change-Id: I015928ebe18ba8fd93252eece3e8a0fcf4b2a037
Reviewed-on: https://chromium-review.googlesource.com/242691
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
When the MPU region to modify is empty (size == 0) returns EC_SUCCESS
rather than EC_ERROR_INVAL, so we are not failing MPU activation on
systems without anything in the .iram.text section.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=chrome-os-partner:35774
TEST=on Samus, with WP, try "sysjump disable" on the EC command line
and see "RAM locked. Exclusion 20006ee0-20006ee0" message.
Change-Id: I0103e0f7aa81ee64a70dd47ffb1c50067ce5a6ee
Reviewed-on: https://chromium-review.googlesource.com/242690
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
If we don't do this, some code later on (like the S3 hook) might check the
POWER_GOOD too early, note that it's on and move to the wrong state:
[8.457344 power button not released in time]
[8.457541 long-press button, shutdown]
// power_off() happens:
[8.459853 power shutdown complete]
[8.593443 power state 7 = S0->S3, in 0x0001]
[8.593653 power state 2 = S3, in 0x0001]
// power_get_signals check happens here ^^^, but POWER_GOOD did not have enough
// time to fall and cause the power_update_signals interrupt
[8.593863 power state 6 = S3->S0, in 0x0001]
[8.594132 power state 3 = S0, in 0x0000]
// system is actually off here
BUG=chrome-os-partner:34816
TEST=Hold Power+Refresh, release after about 10 seconds, the ec should not
have an assertion error and reboot
BRANCH=veyron
Change-Id: Ic7a06a5d255f2b8d056b0b454fc32a4c05c998b4
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242620
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 5f954620fa3d36e8e1a88bf7d3963dc7996ec445)
Reviewed-on: https://chromium-review.googlesource.com/242711
Adding setup_openocd function to take care of setup of either servo v2 and or
servo v3 setup (setting up OCD_PATH and OCD_CFG variables). Have modified
flash_link, flash_lm4, and flash_npcx functions to use setup_openocd function.
BUG=chromium:412249
BRANCH=None
TEST=made sure that outputted flash_ec command lines prior/after change on host
are identical for link and peppy. Also made sure that flash_ec command
works on peppy with updated image on beaglebone. Also ran "make runtests".
Change-Id: Iacf42fae1f175d6acd08bbd16352afb8f3bd21b0
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242043
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the AP ignores the LPC_ST_BUSY bit (which is software-defined) and
tries to send a second host command while the first one is still
processed, we discard it.
This doesn't prevent the host to re-write the command arguments stored
in LPC shared mem (aka LPC_POOL_CMD_DATA) but when we will call
host_packet_receive, we will have either the old arguments or the new
arguments (or even a mix of both, which is less unlikely to pass the
checksum check), and we will copy them once before calling the HOSTCMD
task. So the host command task will have a single coherent (not
changing) view of the arguments when performing its input validation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:31492 chrome-os-partner:23806
TEST=Boot Samus and play with ectool
Change-Id: I9aa1b8cdac05e323b91998188bd873826e83c274
Reviewed-on: https://chromium-review.googlesource.com/242593
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
The VCC_PWRGD pin is used as an indication of VCC2 state and controls
the internal VCC_PWRGD signal. On Glower, the pin is floating so we
can't use it as is. Instead, configure the pin as a GPIO so that the
internal VCC_PWRGD is gated high.
Without this, nSIO_RESET would be kept asserted and most LPC-related
peripheral won't work.
BRANCH=None
BUG=chrome-os-partner:35308
TEST=Without this, the interrupt status of LRESET# cannot be cleared.
After applying this patch, LRESET# interrupt can be cleared properly.
Change-Id: I6e250b8dff5d38e61ee84500da8236db35395a81
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/242130
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
If our battery params seem uninitialized when calling
charge_prevent_power_on, try to retrieve them and make a decision based
upon the retrieved data. This should prevent the case where power-up is
incorrectly prevented early in the boot process.
BUG=chrome-os-partner:35762
TEST=Manual on Samus. Write protect unit and run "reboot" from the
console, verify that unit powers up. Verify that unit still correctly
prevents low-power power-on and correctly allows non-low-power power-on.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9030a2d5e526f4b03996a89bf2c801533683bb67
Reviewed-on: https://chromium-review.googlesource.com/242560
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On VBUS event, only wake PD task if task_start() has already
been called.
BUG=none
BRANCH=samus
TEST=make buildall. use similar patch on ryu and sysjump
back and forth while toggling vbus and make sure we don't
crash.
Change-Id: I79152cd2325949dea080d432d80600ff62d37085
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242231
Reviewed-by: Vic Yang <victoryang@chromium.org>
Set the battery threshold for tap for battery to show red to match
the kernel percentage at which the battery icon turns red. This
threshold is 14% real battery percentage which is equivalent to 10%
battery for what the user is shown.
Note: due to rounding we may still be off, but this closes the window
at which these will differ.
BUG=chrome-os-partner:35664
BRANCH=samus
TEST=make buildall. compare to CL:48904 where we made a similar change
for the lightbar color to turn red when running.
Change-Id: I31d3c4544c57bc11967d0ba7a54d26e543f6bf5b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242255
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If UFP fails to enter mode after tAMETimeout, UFPs should advertise
there USB Billboard class. If at a later time, DFP does successfully
enter a mode the USB device should disconnect permanently.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33968
TEST=manual,
Change UFPs response to 'discover identity' to be busy until after
tAMETimeout and see hoho enumerate (18d1:5010). Then see it
disconnect after DisplayPort mode is entered.
Change-Id: I2d72ed968302fbf74e70f76891a758c47f3773b4
Reviewed-on: https://chromium-review.googlesource.com/242148
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Increase debounce time to decrease the probability of misidentification
on slow plug insert.
BUG=chrome-os-partner:35633
TEST=Manual on Samus. Plug 1A Apple charger, verify detection is
correct.
BRANCH=Samus
Change-Id: I031f1cfdbf6b2aabe7c8b64e0e6a740d4b5df14d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242093
Reviewed-by: Alec Berg <alecaberg@chromium.org>
These numbers are too low right now and keep the fans going
even in idle states. We should repopulate this table with
better numbers when we get them.
BUG=chrome-os-partner:34598, chrome-os-partner:34789
TEST=flash, check fan rpm
BRANCH=ToT, samus
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Change-Id: I651f82610b924ee9f1be5ade856bdc18d7cfc066
Reviewed-on: https://chromium-review.googlesource.com/242042
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Lock access to the MUX GPIO to prevent other tasks from toggling away
from our active chip while in use.
BUG=chrome-os-partner:35567
TEST=Manual on samus_pd. Boot system, verify that no "write failed"
print is seen. Also verify that charger detection functions as expected.
BRANCH=Samus
Change-Id: Ica02b8fbd8f9ee04f6389ce0b0e5bd58104ff698
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242125
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Use one line per entry and display the real time for the events.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33248
TEST=ectool --name=cros_pd pdlog
and see a nice log like:
2015-01-20 15:14:02.974 P0 Disconnected
2015-01-20 15:14:05.676 P0 SNK Charger Type-C 4958mV max 5000mV / 500mA
2015-01-20 15:14:11.810 P1 SRC
2015-01-20 15:14:14.460 P0 Disconnected
2015-01-20 15:14:17.277 P0 SNK Charger Type-C 5185mV max 5000mV / 3000mA
2015-01-20 15:14:17.287 P0 SNK Charger PD 5015mV max 20000mV / 3000mA
2015-01-20 15:14:17.383 P0 SNK Charger PD 20198mV max 20000mV / 3000mA
--- END OF LOG ---
Change-Id: Ibf189cdb9e5d9ba74cb1fb241a2945439dfb50f7
Reviewed-on: https://chromium-review.googlesource.com/242082
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
When VBUS is initially present, we set a type-c charge_manager supplier.
Therefore, when we clear our VBUS present flag, we also need to zero our
supplier.
BUG=None
TEST=Manual on Samus. Quickly plug + unplug SDP charger, verify that pd
correctly detects that no charger is present on the board.
BRANCH=Samus
Change-Id: Ie72503f8a9b0f749b7529cfd6ff0675bd5640257
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242092
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For dual-role USB ports (host/device), let the AP know whether we are
currently DFP (USB host) or UFP (USB device) by exporting the data role
in addition to the power role in the EC_CMD_USB_PD_CONTROL response.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=ectool --name=cros_pd usbpd 0
plug various accessories on the port and see properly "SRC DFP" for the
USB key, "SNK DFP" for the power supply and "SNK UFP" for a regular
C-to-A charging cable.
Change-Id: I292da15fa8cf3566109dd05995ef1d00bed6f92d
Reviewed-on: https://chromium-review.googlesource.com/242012
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This adds a sensor-specific attentuation factor, which will be
applied to the ALS raw sensor readings on the EC. This is to
account for the attenutation due to glass, tinting, etc.
BUG=chrome-os-partner:34590
BRANCH=ToT,Samus
TEST=manual
In a root shell, run this:
cd /sys/bus/acpi/drivers/acpi_als/ACPI0008:00/iio:device1
while true; do cat in_illuminance_raw; sleep 1 ;done
Shine a flashlight on the ALS. Note that the readings are 5X
higher than they were before this CL.
Change-Id: I2a53872ecb5fab62e5f443d43588a26d3d7e697f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241191
Reviewed-by: Bryan Freed <bfreed@chromium.org>
Increase the time from the last USB PD RX edge to allow deep sleep
to 100ms to allow us to receive retries if we miss the first attempt.
BUG=chrome-os-partner:34624
BRANCH=samus
TEST=make -j buildall
Change-Id: Id4dd5614b52c9bcd97997e95b0c5f21fbd9b2cf3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241954
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit 74fd6f9 largely got rid of default printing of VDM traffic to console but
one in custom_vdm was missed. Lets remove it too. Note can still view these by
'pd dump 1'
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=none
TEST=manual when pd flashing samus_pd console (chan usbpd) is quiet.
Change-Id: Idc04750de09572df8d5b15afcdde63f6afc4b5e2
Reviewed-on: https://chromium-review.googlesource.com/241952
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Fix bug in USB PD initialization after a sysjump. Since the CC pull
resistors weren't being initialized after a sysjump, we would sometimes
end up stuck in sink debounce state because we would have Rp applied
and our initial state of sink disconnected would think that a source
was attached. And since we continued to apply Rp, we would never make
a connection with a charger, so we would be stuck in sink debounce
until a reboot.
BUG=chrome-os-partner:35608
BRANCH=samus
TEST=load on samus and keep rebooting and sysjumping and making sure
that we don't falsely go to the sink debounce state.
Change-Id: Ic81fe02be78f3f4ffe00e3e3e378f5befe8545a5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241874
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix a couple bugs that cause problems when executing a power
swap with a poor PD connection.
1) If we are a sink switching to a source and we have turned on
vbus and then get an error, then make sure to turn off vbus.
2) If we are a sink switching to a source and we receive a
redundant PD_RDY, then ignore it.
BUG=chrome-os-partner:32392
BRANCH=samus
TEST=load on samus and connect port 0 to 1 creating a poor
PD connection with a lot of retries and missed responses. with
this change, I swapped power ~20 times with "pd 0 swap power"
and each time it was eventually successful.
Change-Id: Ib6b97961c7e40186a14ca1d2922b2ce6a6598180
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241872
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Set the PD protocol last state to hard reset when executing a
hard reset. This fixes a bug in which if we receive a hard reset
while in one of the hard reset recovery states the last state
doesn't change, which means we don't restart timeout periods and
it is possible to be indefinitely stuck in the hard reset recovery
state until PD MCU reboots.
BUG=none
BRANCH=samus
TEST=when connecting samus port 0 to port 1 we get a very crappy
PD connection and about 1 in 5 times it causes us to get stuck in
SNK_HARD_RESET_RECOVER until a reboot. with this fix, we never get
stuck.
Change-Id: I294462ffa56a804ca613535ab9bdc466175f8066
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241871
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
