| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow power button presses which turn the AP off.
TEST=Manual on Samus. Boot system with depleted battery, hit power
button at dev screen and verify AP powers off.
BUG=None
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I68c9b6c07520992ebba9dcbeccc60ebfb41ca112
Reviewed-on: https://chromium-review.googlesource.com/243710
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BRANCH=samus
BUG=chrome-os-partner:35935
TEST=manual, port & size params are no longer reversed when running
ectool --name cros_pd pdlog
Change-Id: I83e5ad92c260ff71330b7b5c69b30cf3b7e81a98
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243373
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current simplified implementation allows single mode entry. Specification
allows multiple mode entry and its advantageous for things like flashing RW
while staying in DisplayPort mode on video dongles.
CL adds capability on DFP to track as many alternate modes as supported by the
DFP. Initial mode entered is still the default supported mode ( 1st entry, 1st
opos). Policy manager can then use host command, EC_CMD_USB_PD_SET_AMODE, to
enter additional supported modes.
On the UFP (hoho, dingdong) a small modification to track multiple svid mode
entries was made.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33946
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdsetmode can successfully enter/exit multiple modes.
For example,
# port:1 svid:18d1 opos:1 cmd:1==enter
ectool --name cros_pd pdsetmode 1 0x18d1 1 1
Checking with pdgetmode shows both modes entered.
3. Works across hard & soft resets
4. Can flash via ectool --name cros_pd flashpd 4 <port> <RW image>
5. Still drives external display. With bootarg drm.debug=0x6 and following
command: 'tail -f /var/log/messages | grep "Received HPD" &'
I see HPD assert & deassert when switching between GFU and DP mode.
If both modes entered screen stays lit (after reboot) during write.
Change-Id: I7a21ebea377402eb1b0a0cf1d29df59694e301b1
Reviewed-on: https://chromium-review.googlesource.com/241790
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In preparation for supporting multiple mode entry this CL cleans up access to
the mode array via get_modep. Follow-on Cls will enhance that to include svid
lookup for multi-mode support.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33946
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdsetmode can successfully enter/exit
other modes (check w/ pdgetmode)
3. Works across hard & soft resets
4. Can flash via ectool --name cros_pd flashpd 4 <port> <RW image>
5. adding CONFIG_CMD_USB_PD_PE define still works for 'pe dump'
6. Still drives external display. With bootarg drm.debug=0x6 and following
command: 'tail -f /var/log/messages | grep "Received HPD" &'
I see HPD assert & deassert when switching between GFU and DP mode.
Change-Id: I7c50c76034bc0ae73b5b019361291c0ff2c21b2a
Reviewed-on: https://chromium-review.googlesource.com/241719
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35859
TEST=manual, with CONFIG_CMD_USB_PD_PE and hoho in C1
> pe 1 dump
IDENT:
[ID Header] 6c0018d1 :: AMA, VID:18d1
[Cert Stat] 00000000
[2] 50100001 [3] 1100000b
SVID[0]: ff01 MODES: [1] 00000485
SVID[1]: 18d1 MODES: [1] 00000001
MODE[1]: svid:ff01 caps:00000485
Now see only the 2 additional product type VDOs (product, AMA)
Bits still make sense.
[2] 50100001 == 5010:Pid 0001:bcdDevice
[3] 1100000b == 1:hw vers 1:fw version
b:vbus req, USB 2.0 billboard only
Change-Id: Ie8fb74fa55a25ee760009d5a2858a62b0f696c92
Reviewed-on: https://chromium-review.googlesource.com/243080
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add range checking of type-C port arg to host commands that weren't
already doing so.
BUG=chrome-os-partner:31492
BRANCH=samus
TEST=make -j buildall
> ectool --dev=1 usbpd 2
EC result 3 (INVALID_PARAM)
Change-Id: I0bd7677857f28fc002a039c477e87efa876d0134
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242423
Reviewed-by: Vincent Palatin <vpalatin@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Send the VDO_CMD_GET_LOG VDM to accessories to get their PD event log
and append it to the PD MCU log.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33248 chrome-os-partner:32785
TEST=ectool --name=cros_pd pdlog
Change-Id: Ib52d1e2cae5f77dcec6d0489eaa49527388b02b6
Reviewed-on: https://chromium-review.googlesource.com/242013
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change charge_state_v2 to set the maximum input current limit when
there is no battery present AND the system is not locked. This allows
us to boot without a battery.
Note that using the max input current limit may cause us to overcurrent
our charger, but that's no worse than putting a limit on it and having
the system brownout. Either way you must have a high enough power
charger to boot without a battery.
BUG=chrome-os-partner:35570
BRANCH=samus
TEST=load on samus, remove battery and plug in zinger. check "charger"
has input current limit of 8128mA, and on PD MCU jump back and forth
between RO and RW and make sure system doesn't power off. Note that
without this CL, if you sysjump on the PD MCU it causes input current
limit to reset to 500mA and causes AP to shutoff.
Change-Id: Ie13d97a6b5c0937510cff0cf05fb032898c3b131
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241762
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix some issues with how the battery present flag is reported
up to the host.
If there is no battery presence GPIO or custom function then
errors updating the smart battery info can result in the
battery present flag reporting BP_NOT_SURE and indicating to the
host that the battery is missing. In order to prevent spurious
events require a second back-to-back read of a missing battery
before the host is notified.
When the battery presence does change, the host needs to be told
to re-read the static battery info with EC_HOST_EVENT_BATTERY,
passed to the OS via Notify command to tell the OS to re-execute
_BIF/_BIX method on the ACPI battery device.
When sending these events to the host the battery flags should
first be updated in LPC shared memory so if the host handles
the event quickly it will read the correct updated flags value.
BUG=chrome-os-partner:34011
BRANCH=broadwell
TEST=manual testing on samus:
1) add a console command that allows the smart battery update
function to set batt.is_present to BP_NOT_SURE for a specified
number of update cycles.
2) ensure that when the smart battery update only returns the
battery missing for one update cycle that it does not result in
an event to the host.
3) ensure that if the smart battery update indicates the battery
is missing for more than one update cycle, such that the host is
notified the battery is missing, that it correctly gets an event
to re-read the battery info when it is indicated as present again.
Change-Id: I0da004b991ea1a89b34cd7c0f8f3628b813ffe44
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241763
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a character is received between uart_init() and task_start(), we
shouldn't try to wake console task. Usually this shouldn't happen
because the input shouldn't be floating, but still, the EC should not
crash in this case.
BRANCH=None
BUG=chrome-os-partner:35308
TEST=Boot on Glower without servo connected. Check the LED is not
blinking.
Change-Id: I62157c3ecd50b5eca6b09c1cf594b65a605546f9
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/241512
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate macros for defining delays to turn on and off VBUS on the
Raiden ports.
Tune the delays for Samus to provide extra headroom based off of
measured worst case times.
BUG=chrome-os-partner:34525
BRANCH=samus
TEST=load onto samus. connect two samus' and use twinkie to analyze
time between request and PS_RDY on connect and then on a power swap.
Change-Id: I65cec911e34c22a4aad136423362a3a65bc2ab2a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241761
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not request a voltage that is within the deadband where we
aren't sure if the boost or the boost bypass is on.
BUG=chrome-os-partner:34938
BRANCH=samus
TEST=test on samus with zinger. change the deadband to [10V, 20V]
and see that we only negotiate to 5V. change the deadband to
[13V, 20V] and see that we negotiate to 12V. change the deadband
to [10V, 13V] and see that we negotiate to 20V.
Change-Id: Id761aef35eeadfa2ab7d2ca31a48d4324625ab32
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241528
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AP informs us of the latest update image for a given device through
the EC_CMD_USB_PD_RW_HASH_ENTRY command. If the latest update image is
equivalent to our RW, we don't need to request an update.
BUG=chrome-os-partner:35510
TEST=Manual on Samus. Flash latest RW FW to Zinger. Verify that
subsequent Zinger insertion doesn't trigger the FW update host event.
Insert RO-stuck Zinger and verify that FW update host event is
triggered.
BRANCH=Samus
Change-Id: I300b150b3469e3fe32307e61273880a1a052ac5a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241172
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More updates to connection state machine. Adds CONFIG option
for backwards compatible DFP (used on zinger), and change UFP
state machine to debounce CC while VBUS is not present.
BUG=chrome-os-partner:33680
BRANCH=samus
TEST=load on samus and zinger and connect a bunch of times. also
test samus to samus connection.
Change-Id: Ia967eb6a17b10aa0c05a30686235fbf8a24e9a7b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240587
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some batteries report 0 charge when their charge level is very low.
powerd has a special interpretation of 0 charge, which causes
low-battery shutdown to not occur. Work-around this powerd behavior by
never reporting 0 charge if our battery is discharging.
BUG=chrome-os-partner:35188
TEST=Manual on Samus. Drain battery to critically low level, verify that
powerd correctly shuts down system.
BRANCH=Samus
Change-Id: I6bd50e038f0e22de7e7de754fa2ea459dc662f35
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241101
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These commands (pdgetmode & pdsetmode) will provide host with ability
to identify USB-PD alternate mode devices SVIDs and supported modes.
It will also allow host to set mode on devices which support multiple
alternate modes.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33946
TEST=manual
Plug hoho/dingdong into samus at port <port>
ectool --name cros_pd pdgetmode <port>
*SVID:0xff01 *0x00001085 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
SVID:0x18d1 0x00000001 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
ectool --name cros_pd pdsetmode <port> 0x18d1 1
ectool --name cros_pd pdgetmode <port>
SVID:0xff01 0x00001085 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
*SVID:0x18d1 *0x00000001 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
ectool --name cros_pd infopddev <port>
Port:1 DevId:4.1 Hash: 0x042cc79c 0x30cc12e3 0xe27a36e5 0x3f7eba5f 0x053c91d1
Port:1 ptype:5 vid:0x18d1 pid:0x5010
Also from samus_pd console see proper result for 'typec <port>'
typec 1
Port C1: CC1 178 mV CC2 427 mV (polarity:CC2)
No Superspeed connection
Also visually inspect packets via twinkie.
Change-Id: I4e442bcb39ec1ff3cb6efff196a660819077ad76
Reviewed-on: https://chromium-review.googlesource.com/231834
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34489
TEST=compiles, saves ~200bytes
Change-Id: I72493618af0884936c8e634fa7d52b7ecc4ab4a4
Reviewed-on: https://chromium-review.googlesource.com/241019
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34498
TEST=compiles, saves ~100 bytes
Change-Id: Ic6e1d86198b3ca2b6582414254ca80f910ff1644
Reviewed-on: https://chromium-review.googlesource.com/241091
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This output while useful at times:
1. takes ~100 bytes
2. can be replicated by 'pd dump 1'
3. can be viewed with twinkie either graphically or with 'tw console'
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:34498
TEST=compiles saves 91 bytes
Change-Id: I3529f383ef8a9dec5c9acf7e95ecb0545e7f2246
Reviewed-on: https://chromium-review.googlesource.com/241090
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain platforms may wish to have a longer shutdown timeout, so make
the timeout a config option.
BUG=chrome-os-partner:35188
TEST=Manual on Samus with subsequent CL. Set config option to increase
timeout, verify that timeout is extended.
BRANCH=Samus
Change-Id: I69feb0d31fdc53e533671dec1e88ba96cc4553c2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240815
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Record in the PD log when we fail to verify the RW signature and when
the RW partition is erased.
Also log the faults on the power supplies.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:32785
TEST=flash a bad rw on Zinger.
Change-Id: Ib62dcb0d407867151af0aaecc405533e894d773e
Reviewed-on: https://chromium-review.googlesource.com/239913
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the charging events to the PD event log FIFO
and add an ectool to retrieve/decode them.
BUG=chrome-os-partner:33248
TEST=Manual on Samus. Run `ectool --name cros_pd pdlog`, verify that
all log entries are dumped and the content matches expectation.
BRANCH=Samus
Change-Id: I65dd5696cc0487856ab42aff24134bcdfa1a8219
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238093
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a FIFO to log important events on the PD MCU and coming from the PD
accessories.
The retrieval of the accessories log from the accessories by the PD MCU
is not implemented yet.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:32785
TEST=execute "ectool --name=cros_pd pdlog"
before and after plugging Zinger charger.
Change-Id: If96d73e711ff6ad64cfb99bd3e4d2d8f2643f19a
Reviewed-on: https://chromium-review.googlesource.com/238854
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove functions for sending bist command and analyzing the
resulting stream in order to save flash space.
BUG=chrome-os-partner:32785
BRANCH=samus
TEST=make -j buildall
Change-Id: I8fec2d632bce82b1cc344e674b48c5cf2b3a3647
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240700
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assuming the dut has red/green battery led and a single power led
CONFIG_LED_POLICY_STD implements the chromeos spec:
* power led on in S0
* power led off in S5
* power led pulsing in S3
* battery led amber when charging
* battery led green when fully charged with AC
* battery led off when discharging
* battery led pulsing red when battery error
BUG=chrome-os-partner:35355
TEST=The Charging led behavior should match the cros spec
BRANCH=None
Change-Id: I645a939ecc2d44d73d2f52b295f9c7e8c923f77b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240705
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Shorten some PD protocol printf's to save flash space and add
port information to a handful of important ones to help find
errors when both ports are in use on samus.
BUG=none
BRANCH=samus
TEST=load onto samus and connect to zinger
Change-Id: Ieecb2a35ebb8c8275c520ad2bd3018e7608b5ecb
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240482
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix bug causing firefly to disconnect when changing voltage request
too fast.
BUG=chrome-os-partner:35330
BRANCH=samus
TEST=test with firefly and zinger.
Change-Id: I6efb2f6fdd1ff64cee2cc722a538164cca946380
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240460
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:35312
BRANCH=none
TEST=make buildall -j
I added a debug message to nrf51/hwtimer.c to show when the timer overflowed.
"forcetime 4 0xfffff000" overflows to 5.00000000 in 4096 microseconds.
Define CONFIG_CMD_FORCETIME to enable it.
Change-Id: I30835d038ef8cd639565ffb7a638979d95d0a684
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239968
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add npcx_evb in board folder for testing
Add shared-spi arch support in common layer.
Modified drivers for
1. Fan.c: console command “pwmduty”.
2. Pwm.c: for the issue when set duty to 0.
3. System.c: for hw reset only during system reset.
4. Flash.c: Fixed access denied bug of the flash driver for host command.
5. Comments from Patch Set 1
6. Comments from Patch Set 3 (except sha256.c)
7. Add openocd and flash_ec support for npcx_evb
8. Add little FW and spi-flash upload FW in chip folder
9. Add optional make rules for PROJECT_EXTRA
10.Replace CONFIG_SHRSPI_ARCH with CONFIG_CODERAM_ARCH and remove changes
in common layer sources for shared-spi arch. (except sysjump)
11.Find the root cause of JTAG issue and use workaround method
with SUPPORT_JTAG in clock.c
12 Execute hibernate in low power RAM for better power consumption
13 Add workaround method for version console command
14 Modified coding style issues by checkpatch.pl tool
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I5e383420642de1643e2bead837a55c8c58481786
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233742
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When displaying the temps, if the sensor has valid entries to
control the target fan speed, show them. This lets us see which
sensor is the main player in the cooling needed without doing a
bunch of math.
BUG=none
BRANCH=none
TEST=manual
On the EC console:
> thermalget
sensor warn high halt fan_off fan_max name
0 368 370 372 316 358 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 314 328 I2C-Charger-Die
3 0 0 0 0 0 I2C-Charger-Object
4 0 0 0 308 322 I2C-CPU-Die
5 0 0 0 0 0 I2C-CPU-Object
6 0 0 0 301 317 I2C-Left C-Die
7 0 0 0 0 0 I2C-Left C-Object
8 0 0 0 302 316 I2C-Right C-Die
9 0 0 0 0 0 I2C-Right C-Object
10 0 0 0 303 317 I2C-Right D-Die
11 0 0 0 0 0 I2C-Right D-Object
12 0 0 0 316 327 I2C-Left D-Die
13 0 0 0 0 0 I2C-Left D-Object
Then, before this CL:
> temps
PECI : 308 K = 35 C
ECInternal : 309 K = 36 C
I2C-Charger-Die : 307 K = 34 C
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 304 K = 31 C
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 302 K = 29 C
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 303 K = 30 C
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 303 K = 30 C
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C
I2C-Left D-Object : Not calibrated
After this CL:
> temps
PECI : 308 K = 35 C 0%
ECInternal : 309 K = 36 C
I2C-Charger-Die : 307 K = 34 C 0%
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 304 K = 31 C 0%
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 302 K = 29 C 6%
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 303 K = 30 C 7%
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 303 K = 30 C 0%
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C 0%
I2C-Left D-Object : Not calibrated
Change-Id: I12bca5826e8a5a3325710fa5d39cec88f1cc95b1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we're charging on a port and the active port supplier changes, it is
an indication of a significant change. Re-set the port as active, to
give the board-level function an opportunity to reject the port, in case
charging is untenable.
BUG=None
TEST=Manual on Samus. Plug Zinger, verify that 20V is negotiated
correctly.
BRANCH=Samus
Change-Id: I4a530d5bab510498dd9b30f141208ce33b52ef6b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239250
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
prevent_hot_discharge and prevent_deep_discharge are near-identical
copies of one another, and can be combined without the loss of any
useful functionality.
BUG=chrome-os-partner:35188
TEST=Manual on Samus. Charge to 2% and boot system with 5V power supply.
Verify that warnings print to console and AP powers down after 30s. Also
pass unit tests.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I0f1da5248825a3884f7910babc742dfa7eadf5a3
Reviewed-on: https://chromium-review.googlesource.com/240033
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow VDO responses to be sent faster by taking out the check for
incoming packet when a VDO is pending. This check isn't needed
because we already check if the PD state machine is busy sending
something.
With this change, the turn around time for responding to Discover
Identity on zinger is ~200us.
BUG=chrome-os-partner:35327
BRANCH=samus
TEST=loaded onto zinger and used twinkie to verify that discover
identity is responded to in ~200us every time. used ectool to
perform remote update on zinger, now takes ~18s (compared to ~55s).
Also, used following bash loop to constantly sent PD voltage requests:
while true; do dut-control "usbpd_uart_cmd:pd 1 dev 5"; sleep 0.3;
dut-control "usbpd_uart_cmd:pd 1 dev 20"; sleep 0.3; done
Used bash loop while updating zinger via ectool. I programmed zinger
~50 times and verified:
- we never missed a PD voltage request
- never got any PD protocol or phy layer errors (no collisions)
- zinger successfully jumped to RW after each (no packets missed)
Note: sending any other PD traffic while programming zinger does
obviously slow down zinger update (~30s with my bash loop above).
Change-Id: I94d1ac01440d096671972fa9c21c149ea432863f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240150
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure the power role and the CC pull resistor match after
receiving hard reset command in the middle of a swap.
BUG=none
BRANCH=samus
TEST=on samus connect left and right ports together with C to C
cable. note that after some collisions and some hard resets, it
eventually stabilizes with one port in SNK_READY, the other in
SRC_READY. without this CL, we get stuck executing a power swap
and our power role and CC resistor get out of sync, requiring
a reboot.
Change-Id: Ia1385eb3a1c503052ad5bfd0d1595ecc096cd5f4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239976
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid multiple power and data swaps on connect by clearing our
local flag for checking our role when we receive a role swap.
This means if the port partner sends a role swap on connect before
us and we accept, then we will not turn around and ask for another
swap.
BUG=none
BRANCH=samus
TEST=connect samus to samus and make sure only one swap on connect.
Change-Id: I2414b5bd5ffc54701b5758047e5d7e51ca3ff596
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239951
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
|