summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Clear OWNERS for factory/firmware branchfactory-auron-6772.BBrian Norris2021-09-102-10/+1
| | | | | | | | | | | | BUG=none TEST=none Change-Id: I0f03f432ada1064ffba9595be78ca7ab4d25ecd1 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3155040 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Owners-Override: Jora Jacobi <jora@google.com> Tested-by: Jack Rosenthal <jrosenth@chromium.org>
* Assert warm reset while flashing STM32 partsVic Yang2015-02-091-4/+14
| | | | | | | | | | | | | | | | | | | | | The STM32 bootloader reacts to the first command it sees and then sticks to that interface. On some devices, the AP is connected to I2C or UART on the EC, and if the AP talks when we are trying to flash the EC, the EC sticks to that interface and ignores requests from the servo board. Fix this by holding warm_reset so that the AP is down. BRANCH=None BUG=None TEST=Flash Ryu several times. TEST=Flash Plankton to make sure it doesn't break devices without warm_reset. Change-Id: I860fc65ba7fdaf0cbc9a0be641148b5095de394b Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/247360 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@google.com> Commit-Queue: Vic Yang <victoryang@chromium.org>
* Add flash_ec support for Glowerstabilize-6771.BVic Yang2015-02-091-1/+18
| | | | | | | | | | | | | | | Just so that we can program the EC more conveniently. BRANCH=None BUG=chrome-os-partner:35308 TEST=Program a Glower. Change-Id: Iaba0839c4a5b8dee805f7d31e4049198ce43918f Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/247142 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* Plankton: Support DFU modeVic Yang2015-02-091-2/+22
| | | | | | | | | | | | | | | | | | | | This includes: - Enabling SBU path for debug USB usage in USB mode (not in DP mode) - Add a console command to enable DFU mode for lab devices. This requires the additional Silego chip on the device. BRANCH=None BUG=None TEST=Hook up a Ryu with the additional Silego chip. Issue 'dfu' command and see DFU device in 'lsusb' output. Issue the command again and the device goes away. Change-Id: I3f942c6abe52784351f2242c9b0b6400e9b2b6fd Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/247350 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* samus: prevent fast enable/disable charging loopAlec Berg2015-02-081-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug fix for the new samus charging software workarounds. The problem occurs occasionally, especially with 5V chargers, and causes the new software workarounds to get out of sync with the actualy state of the charging circuit such that when ACOK actually goes high, we stop charging, and then when ACOK goes low we start charging, and we end up in a high frequency loop of enabling/disabling charging. The fix is to add a 100ms delay when ACOK goes low before allowing charging again. This guarantees that the circuit will settle down before we try charging again. BUG=chrome-os-partner:36081 BRANCH=samus TEST=can reproduce with an EVT2 samus connected to a DVT samus at ~15% battery. On the DVT samus, allow charging from the other other samus with charge override. Without this change, most of the time the PD console goes back and forth between enabling and disabling charging. With this change, we don't can actually charge briefly, although there is still a problem where VBUS can dip too low and cause ACOK to actually go low. Change-Id: If83def862fb58ef3938e2a443e1a081bd27713ec Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/247460 Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* charge_manager: Wait for dualrole determination before chargingShawn Nematbakhsh2015-02-089-152/+369
| | | | | | | | | | | | | | | | | | | | | | | If a dual-role charger is plugged, we will not realize it is dual-role until after we see a type-C charge source. It can cause us to briefly charge from a dual-role charger, which has bad side effects related to charge override and the lightbar. Fix this by not charging from a port until we are fairly certain that it is a dedicated charger (based upon PD discovery timeout). BUG=chrome-os-partner:36390 TEST=Manual on Samus. Insert 1A Apple charger, verify correct detection. Run 'chgoverride -2' to prevent charging, then repeatedly insert + remove a dual-role charger on the other charge port. Verify that charging is still prevented. Finally, insert a dedicated charger and verify that the override is removed. Also, pass unit tests and verify correct detection in various scenarios with various chargers. BRANCH=Samus Change-Id: Ia4154f34dd0a850b6e72bebadbd938f034532f14 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/247130 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: give more time for recovery from charge circuit wedgedAlec Berg2015-02-071-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | On some systems, recovering from charge circuit being wedged doesn't happen immediately, and we end up constantly detecting charge circuit wedged problems and recovering from it. This CL adds a counter to check_charge_wedged() and reads PROCHOT but does not trigger the charge circuit wedged until after a certain number of checks after the last charge wedged condition. This allows more time for the condition to magically go away before intervening. BUG=chrome-os-partner:36081 BRANCH=samus TEST=found two units that were regularly detecting charge circuit wedged and recovering from it (every 4 seconds, 2 seconds before detecting the issue and 2 seconds to recover). on one unit, the problem went away on its own. On the second unit, I loaded this CL into RO, and ToT in RW, then verified that RO does not continually trigger charge circuit wedged problems, while RW still does. Change-Id: I4c4e5c52ad382f178696d61c7b36faf9e8978926 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/247160 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* pd: Mark VBUS as present when power swapping from source to sinkShawn Nematbakhsh2015-02-061-0/+1
| | | | | | | | | | | | | | | | | If we power swap from a source to a sink and begin charging, VBUS will never be marked as present, which has bad side-effects when VBUS disappears and we wish to stop charging. BUG=chrome-os-partner:36389 TEST=Manual on Samus. Connect Samus-to-Samus and initiate charge override on the port. Verify that charging from the port begins. Unplug the cable and verify that the in-OS charge icon disappears. Repeat 10x. BRANCH=Samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I83206c341c0d74991ad60eef411d71d30b5c67a5 Reviewed-on: https://chromium-review.googlesource.com/246781 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: smoothen backlight brightness transitionsSameer Nanda2015-02-061-2/+30
| | | | | | | | | | | | | | | | | | With DBC, the backlight transitions are fairly perceptible at low brightness levels. Smoothing out backlight transitions over a 200ms period makes these far less perceptible. BRANCH=samus BUG=chrome-os-partner:36245 TEST=The following command should read back the value of 0xe7 after system boot, resume as well as after panel off/on sequence: ectool --dev=0 i2cread 8 0 0x58 0x15 Change-Id: Ia24b87a0ead179d968cfc1239be757c1822450e4 Signed-off-by: Sameer Nanda <snanda@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/246741 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Support vboot hash and system version if flash isn't memory-mappedRandall Spangler2015-02-055-24/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some EC chips (mec1322) use external SPI flash which is not mapped into the EC CPU's address space. These must explicitly read data from flash when calculating the vboot hash or reading the version string of the image which isn't currently loaded into code RAM. To test this bug, I used a board with known working mapped flash, and temporarily patched it to act like it didn't have mapped flash. Also add a flashread console command, useful for manually testing. BUG=chrome-os-partner:35308 BRANCH=glower,strago TEST=manual 1. Apply this patch to samus 2. Check result for 'vboot hash RW' 3. Check result for 'version' 4a. In board/samus/board.h, #undef CONFIG_FLASH_MAPPED and #define CONFIG_CMD_FLASH 4b. In chip/lm4/flash.c, add the following: int flash_physical_read(int offset, int size, char *data) { const char *src; if (offset > CONFIG_FLASH_SIZE || offset + size > CONFIG_FLASH_SIZE) return EC_ERROR_INVAL; src = (const char *)((uintptr_t)CONFIG_FLASH_BASE + offset); memcpy(data, src, size); return EC_SUCCESS; } Steps 4a,4b will make the LM4 chip act like it doesn't have memory-mapped flash. 5. From the dev system, util/flash_ec --board=samus --ro 6. Check result for 'vboot hash RW'. Should be same as 2. 7. Check result for 'version' for RW version. Should be same as in 3. 8. From the dev system, util/flash_ec --board=samus 9. sysjump rw 10. Check result for 'version' for RO version. Should be same as in 3. 11. Compare 'flashread 0x100 0x100' with 'md 0x100 0x40'. The results should be the same (but endian-swapped, since flashread is byte ordered and md is 32-bit ordered). 12. Revert changes from steps 4a-4b. Change-Id: I951d6f5603a84e326740936e4e84dfe6296a0f59 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/246200 Reviewed-by: Shawn N <shawnn@chromium.org>
* pi3usb9281: Fix handling of REG_CONTROL (02H) reserved bitsShawn Nematbakhsh2015-02-052-15/+22
| | | | | | | | | | | | | | | | | REG_CONTROL has two sets of reserved bits: - Bits 5 thru 7 are read x, write 0. - Bits 1 and 3 have undocumented function and should not be changed from read value. BUG=chrome-os-partner:36360 TEST=Manual on Samus. Cold boot unit and insert 2.4A charger. Verify that charger is correctly detected. BRANCH=Samus Change-Id: I240d352817910eda404b72be13e2c913a4b76079 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/246560 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Convert motion sense calculations to fixed point.Randall Spangler2015-02-0510-125/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Motion sense calculations do not require huge amounts of precision, so fixed point is plenty accurate. And fixed point works on Cortex-M0, which lacks a FPU. BUG=chrome-os-partner:36126 BRANCH=minnie (samus already works with the FPU, but could grab this if we want additional testing) TEST=manual 1. Boot system 2. At EC console: accelinfo on 250 3. Move lid through several different angles (30 degrees to max open) and see that it updates correctly and relatively smoothly. A few degrees of angle jitter is normal. 4. At several angles, rotate the chromebook around and see that the lid angle remains relatively stable. 5. If the hinge is made normal to the ground (or within 15 degrees of vertical), the angle should read 500, since the acceleration vectors don't yield good results in that orientation (for either fixed or float math). And run 'make buildall -j', which tests arc_cos() and lid angle calculations Change-Id: I70a0d08b8914629a3e21ae5578cbe8e50f29ad68 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/244116 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Add 64-bit divide library routines for Cortex-M, Cortex-M0Randall Spangler2015-02-056-2/+525
| | | | | | | | | | | | | | | | | | | These are needed for fixed-point math calculations. Taken from the same public repo where we got the 32-bit divide routines for Cortex-M0. With minor modifications to match changes we've made so far for the existing divide routines (put each function in its own section, delete dead code, etc.) BUG=chrome-os-partner:36126 BRANCH=minnie TEST=hack in a debug console command to allow arbitrary int64 divide, see that it works as expected Change-Id: I987dbca7c806c71bc38fa816971ac3a54c1641a5 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/244501 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* smbus: Don't use shared memory buffer for word writesRandall Spangler2015-02-041-12/+7
| | | | | | | | | | | | | | This is a waste of code, since it trades off a 5-byte buffer for a 4-byte pointer. BUG=chrome-os-partner:36362 BRANCH=none TEST=make buildall -j Change-Id: I2b3336ba2c4804f2781592d2c939ae28e83c846b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/246180 Reviewed-by: Vic Yang <victoryang@chromium.org>
* samus: fix lightbar tap sequence doesn't always show on AC eventAlec Berg2015-02-044-26/+35
| | | | | | | | | | | | | | | | | | | | | | | | Fix bug on samus that the battery status doesn't always show on lightbar when AC is plugged/unplugged. It doesn't show when the battery is full is S3 or S5 because in these states we turn off CHARGE_EN so that ACOK to the EC never toggles. Instead, what we want to do is display battery status whenever the active charge port changes. This will happen when AC is plugged or unplugged OR if a user has AC on both ports and toggles between them using the charge override hot-keys. BUG=chrome-os-partner:36317 BRANCH=samus TEST=test plugging and unplugging AC on both sides when battery is full and unit is in S0, and when unit is in S5. also tested lightbar flashes battery percentage when two zingers are plugged in and you switch between them using Ctrl+Search+0|1|2. Change-Id: I5cd7fff4f466adf857f1e63f07f3b0c7ae8422c7 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/245922 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* samus: enable learn mode when INA is wedgedAlec Berg2015-02-031-0/+1
| | | | | | | | | | | | | | | | | When INA doesn't have power, in order to unwedge it properly, we need to disable charing AND enable learn mode to disable the BQ. Without turning on learn mode, the BQ can backboost and cause ACOK to remain high. BUG=chrome-os-partner:36081 BRANCH=samus TEST=load on a samus and test getting the INA wedged using "charger voltage 7000" and make sure it recovers all the time. Change-Id: Icc4c508f9db1210e2384cb741a33f50afee191e7 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/245841 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* samus: automatically recover from charge circuit failuresstabilize-6752.BAlec Berg2015-02-0312-130/+332
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Occasionally the charge circuit on samus gets wedged and will not charge. This change detects when the charge circuit has failed and automatically recovers from it. It uses the BQ PROCHOT warning to detect the failure by setting PROCHOT to trigger when the BQ thinks input current is higher than the input current limit. When the failure is detected, the EC disables charging and tells PD MCU to disable CHARGE_EN, then a couple seconds later, it re-enables charging. This CL also adds more communication between EC and PD for the EC to be able to set the charge state for the PD. Valid charge states are: No charging allowed, 5V charging only, and max charging. The EC uses this as such: - When the EC gets AC present interrupt, it sets off a deferred function to change charge state to max charging after some delay to give time for the charge circuit to settle down. - When the EC gets AC disconnect interrupt, it disables charging briefly, enables learn mode, and then sets 5V charging allowed. This allows for the same starting conditions in the charge circuit for every AC attach. - When the EC detects a wedged charge circuit, it disables charging and waits a few seconds before re-enabling 5V only charging. Additionally, this change moves the charging cutoff in S3/S5/G3 when the battery is full to the EC. With the added control for the EC to set the PD charging state, it is more convenient for the EC to manage cutting off charging when battery is full. BUG=chrome-os-partner:36081 BRANCH=samus TEST=test the basics: - connect/disconnect zinger a bunch of times - connect and disconnect two zingers in different order - connect two zingers and charge override between the two test the automatic charge wedge recover: - wedge the charge circuit by setting charger voltage under battery voltage: "charger voltage 7000" - wait a few seconds for the system to recover and check it is charging with "battery" command test full battery charge cutoff: - added console command to change battery soc in board/samus/extpower.c: static int cmd_battfake(int argc, char **argv) { char *e; battery_soc = strtoi(argv[1], &e, 10); batt_soc_change(); return EC_SUCCESS; } DECLARE_CONSOLE_COMMAND(battfake, cmd_battfake, "", "", NULL); - in S0, tested "battfake 100" does not disable charging. - in G3, tested "battfake 100" disables charging and "battfake 99" re-enables charging. - set "battfake 100" and tested transitioning to S0 enables charging and transitioning to S5 disables charging. - attached two chargers and used charge override to select active port. then toggled "battfake 100" to "battfake 99" back and forth and verified charge override port is still the same. test third-party 12V charger: - plug in a bunch of times and make sure we stay at 5V for 500ms and then transition to 12V test with no battery: - tested five different units with no battery and just zinger. 3/5 boot, while the other 2 don't. But, the 2 that don't boot without battery also can't boot w/o battery when this CL is reverted, so I don't think this change is causing the problem, I think there is an electrical limitation. test with EVT zinger: - EVT zingers (P2 - C2) negotiate very quickly after connection, which can cause INA problems w/o this CL. Tested an EVT zinger with samus and did a bunch of connections and disconnections and verified that we always wait at 5V for 500ms and that we don't wedge the INA circuit on connect. test backwards compatibility: - test new PD with old EC and make sure we can charge with zinger. (note that if the charge circuit wedges, we won't be able to unwedge it). - test old PD with new EC and make sure we can charge with zinger. Change-Id: I7703b7a2ab1209d7f559b265b03517e79c74b16a Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/245253 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* hooks: add hook for battery state of charge changeAlec Berg2015-02-038-0/+27
| | | | | | | | | | | | | | Add hook for battery state of charge change. Hook will be used to cleanup the samus charging workarounds to follow. BUG=none BRANCH=samus TEST=make -j buildall Change-Id: I99cbb8264783802139cac689804b056623063695 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/245252 Reviewed-by: Shawn N <shawnn@chromium.org>
* samus_pd: Do one auto port re-detection if an SDP port is detectedShawn Nematbakhsh2015-01-311-4/+27
| | | | | | | | | | | | | | | | | Non-SDP ports can be identified as SDP on slow plug insertion. To ensure no long-term misdetection, automatically do a single re-detection 30 seconds after detecting an SDP port. BUG=chrome-os-partner:36166 TEST=Manual on Samus. Slow-plug a 1A Apple charger, verify that detection is originally 500mA. After 30s, verify that detection becomes 1000mA. Also verify that only one additional re-detection is triggered. BRANCH=Samus Change-Id: I2babaecdf2252436d1f6b35f5654c14eff9c526b Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/245153 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* charge_state_v2: ignore false battery SOC readingsAlec Berg2015-01-311-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ignore battery readings over 100%. This fixes a samus bug where a false battery SOC reading causes charging to stop. BUG=chrome-os-partner:36115, chrome-os-partner:36081 BRANCH=samus TEST=add following code to common/smart.c: static int reset_soc; in battery_get_params(): if (reset_soc) { batt_new.state_of_charge = 65535; reset_soc = 0; } after battery_get_params(): static int command_battsoc(int argc, char **argv) { reset_soc = 1; return EC_SUCCESS; } DECLARE_CONSOLE_COMMAND(battsoc, command_battsoc, "", "", NULL); This changes the battery state of charge to 65535% for one loop through charge state machine. w/o this CL, on samus the battery stops charging when you call this, but with this CL it is fixed. Change-Id: I44f054a4e84260bd7cd7b77e44b1698645ab6c35 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/244346 Reviewed-by: Shawn N <shawnn@chromium.org>
* mcdp28x0: Move structure definitions to ec_commands.hShawn Nematbakhsh2015-01-314-17/+21
| | | | | | | | | | | | | | mcdp_info is a logging payload, so related structures need to be moved to the public include file. BUG=chrome-os-partner:35935 TEST=make buildall -j BRANCH=Samus Change-Id: Idb939db884821fa85faafbfe643e713f5bcdbc59 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/244780 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Veyron: remove the pmic reset in power_onChris Zhong2015-01-301-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Alex did the reset workaround in power_on function. <https://chromium-review.googlesource.com/#/c/214360/> Now, the new version RK808 has fixed this issue, so we needn't this workaround. BUG=chrome-os-partner:35976 BRANCH=veyron TEST=The BUCK1_ON_VSEL register default value is 0x18, and coreboot and kernel will change this register to other value, but never set 0x18 to it. So we can read this register in coreboot and print out to console to check whether the RK808 reset to default after cold reboot. With this patch, the value always reset to 0x18. I have test on jerry, mighty, speedy. TEST=Use "i2cset -f -y 0 0x1b 0x21 0x0f" Power up system: it should power back up TEST=Use "i2cset -f -y 0 0x1b 0x21 0x0f" Press refresh-power: system should reboot TEST=Use "i2cset -f -y 0 0x1b 0x2a 0x00" Shut down and power back up. Use "i2cget -f -y 0 0x1b 0x2a". Confirm back to 0xff. TEST=Use "i2cset -f -y 0 0x1b 0x2a 0x00" Press refresh-power: system should reboot Use "i2cget -f -y 0 0x1b 0x2a". Confirm back to 0xff. Change-Id: Icfdd3a7eeadce2c597bf286b36bea0aa58cfe4c4 Signed-off-by: Chris Zhong <zyw@rock-chips.com> Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/243202 Reviewed-by: Douglas Anderson <dianders@chromium.org>
* ryu: improve inductive charging controlVic Yang2015-01-303-15/+95
| | | | | | | | | | | | | | | | | | | | | | | | When inductive charging just starts, there might be a blip on CHARGE_DONE signal and it'd cause our charging control logic to shut down charging. Fix this by waiting for a second before we start monitoring CHARGE_DONE. Also, once we see CHARGE_DONE=1 and disable charging, CHARGE_DONE will go low. Handle this by ignoring all subsequent CHARGE_DONE change until the next time the lid is opened. BRANCH=Ryu BUG=None TEST=Pass the updated unit test. TEST=Charge a base on Ryu P3. Change-Id: I9d911cd689d8e88ebcd66e6eca7c86dd70704880 Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/243365 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* ryu: Implement charging profileVic Yang2015-01-295-40/+219
| | | | | | | | | | | | | | | This allows us to charge at a faster rate. BRANCH=Ryu BUG=None TEST=Charge Ryu P3 in S5 and check charging current. Change-Id: If8fbaa42d34df45f3d4db35ba50031c511b0c7af Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/242666 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* power_button_x86: Don't inhibit power button in S0stabilize-6736.BShawn Nematbakhsh2015-01-291-1/+2
| | | | | | | | | | | | | | | 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>
* ectool: parse accessory logs for dingdong & hohoTodd Broch2015-01-282-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Todd Broch <tbroch@chromium.org> BUG=chrome-os-partner:35935 TEST=manual # With dingdong in C0 & hoho in C1 # Enter GFU mode for dingdong & hoho ectool --name cros_pd pdsetmode 0 0x18d1 1 1 ectool --name cros_pd pdsetmode 1 0x18d1 1 1 # read logs ectool --name cros_pd pdlog 2015-01-26 14:36:54.787 P0 SRC 2015-01-26 14:36:54.780 P1 SRC 2015-01-26 14:36:53.680 P0 DP mode enabled 2015-01-26 14:36:53.375 P1 HDMI Codec: family:000e chipid:0001 irom:1.0.0 fw:0.0.0 2015-01-26 14:36:53.771 P1 DP mode enabled # remove hoho & plug in zinger instead ectool --name cros_pd pdlog 2015-01-26 14:44:36.991 P1 SNK Charger Type-C 5153mV max 5000mV / 3000mA 2015-01-26 14:44:37.011 P1 SNK Charger PD 5021mV max 20000mV / 3000mA 2015-01-26 14:44:37.116 P1 SNK Charger PD 20211mV max 20000mV / 3000mA Change-Id: I0289cfd1d43ef1a22123b437bc8df86920fbf1a7 Reviewed-on: https://chromium-review.googlesource.com/243375 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* pd: Log events for dingdong & hohoTodd Broch2015-01-284-2/+14
| | | | | | | | | | | | | | | | Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:35935 TEST=manual, see new events for dingdong & hoho. Note must be in GFU mode to facilitate. Change-Id: I1b79237512748796cf98765a553af8c9978cb594 Reviewed-on: https://chromium-review.googlesource.com/243374 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* pd: Fix reverse of log size & port paramsTodd Broch2015-01-281-1/+1
| | | | | | | | | | | | | 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>
* pd: Allow multiple mode entry.Todd Broch2015-01-288-140/+254
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pd: Cleanup alternate mode access.Todd Broch2015-01-281-22/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pd: refactor object position index.Todd Broch2015-01-284-23/+19
| | | | | | | | | | | | | | | | | | | | | | 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>
* cortex-m: disallow rescheduling if task_start() has not yet runVic Yang2015-01-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | 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>
* samus: Raise Thigh threshold to 101CDuncan Laurie2015-01-271-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* samus: Do not put touchscreen in reset based on lid switchDuncan Laurie2015-01-271-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* samus_pd: Increase pericom debounce time againShawn Nematbakhsh2015-01-271-1/+1
| | | | | | | | | | | | | | | | 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>
* bq24773: turn off prochot warningAlec Berg2015-01-262-3/+7
| | | | | | | | | | | | | | | | | | | | | | 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>
* samus: modify fast charging profile to avoid charge problemsAlec Berg2015-01-262-33/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* samus: change charge override hot keys to ctrl+search+0|1|2Alec Berg2015-01-242-39/+41
| | | | | | | | | | | | | | 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: add battery cutoffAlec Berg2015-01-242-0/+25
| | | | | | | | | | | | | | Add battery cutoff to samus. BUG=chrome-os-partner:35744 BRANCH=samus TEST=tested "cutoff" console command cuts off battery and "ectool batterycutoff" from host cuts off battery Change-Id: I88194c9c601594dee144933cabef5b1dc536ab0d Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/242830 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: Validate size of discover identity received by DFP.Todd Broch2015-01-241-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* samus: Cap the max LED current to 23mASameer Nanda2015-01-241-0/+13
| | | | | | | | | | | | | | | | | | | | | 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>
* ryu: Choose low input voltage whenever possibleVic Yang2015-01-242-0/+17
| | | | | | | | | | | | | | | | | | 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>
* ryu: Reduce max input power to 24WVic Yang2015-01-241-1/+1
| | | | | | | | | | | | | | | | | | 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>
* pd: Honor both max power and current for all power sourceVic Yang2015-01-241-2/+2
| | | | | | | | | | | | | | | | | | | 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>
* bq27541: report battery present stateVic Yang2015-01-241-2/+12
| | | | | | | | | | | | | | | | The battery driver is not reporting battery present state, and as a result, is_present flag always remain NOT_SURE. Fix it. BRANCH=Ryu BUG=None TEST=On Ryu, 'chgstate' and see 'is_present = YES'. Change-Id: I84bedc390158797bf1e67e612d0bb3f526292dfa Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/242970 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org>
* pd: poll PD events only on Google accessoriesVincent Palatin2015-01-243-2/+18
| | | | | | | | | | | | | | | | | | | | 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>
* driver: BQ27621 scaling bug fixMyles Watson2015-01-241-2/+2
| | | | | | | | | | | | | | 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>
* nrf51: implement soft reset and hard resetMyles Watson2015-01-241-1/+29
| | | | | | | | | | | TEST=manual test with the console command. Reset flags are set correctly. BRANCH=NONE BUG=None Change-Id: I3ea4301206be6fe4e79a4b49c002c020980c516d Signed-off-by: Myles Watson <mylesgw@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/242901 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* nrf51: add the watchdog registers.Myles Watson2015-01-241-0/+30
| | | | | | | | | | | | | The definitions for the watchdog registers are needed for hard reset. BRANCH=NONE BUG=None TEST=make buildall -j Change-Id: Ief73b98fbe6fc198c3eda28394e76bdf05568fef Signed-off-by: Myles Watson <mylesgw@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/242900 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* pd: fix power swap to sink could get wedged if missing PS_RDYAlec Berg2015-01-231-11/+3
| | | | | | | | | | | | | | | | | | | | | 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>
View Lorry Controller Status