summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* pd: Move *_set_input_current() to common codeShawn Nematbakhsh2018-02-1218-391/+20
| | | | | | | | | | | | | | | | | | | | | | | Boards that use charge_manager have identical implementations of typec_set_input_current_limit() and pd_set_input_current_limit(), so move these functions to charge_manager. BUG=b:67413505 TEST=`make buildall -j`, also verify that fizz continues to power-on and boot AP, in both protected and unprotected mode, with barrel jack power and with zinger. BRANCH=None Change-Id: I5f08357fe4b117c6452c0ed984b2a9d3a883a3bb Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 286b800f14b139ca5d349d35142d7f31f3655689 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Change-Id: I99a5314d02c4696db944c0f8ac689405f4f1f707 Original-Reviewed-on: https://chromium-review.googlesource.com/701412 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914650
* charge_manager: Support no-BC1.2 configurationShawn Nematbakhsh2018-02-123-1/+12
| | | | | | | | | | | | | | | | | | | | If BC1.2 isn't supported, don't waste space + time checking for inputs that don't exist. BUG=chromium:759880 BRANCH=None TEST=`make buildall -j` Change-Id: I59dfe04d779b14269d398f339566eebdee802b27 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: c781609bfd19b16737bec5482da5c1a021a6afa6 Original-Change-Id: I47e81451abd79a67a666d1859faf2610ee5c941a Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/663838 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914649
* pd: Add pd_capable() to check PD capability of partner portShawn Nematbakhsh2018-02-122-4/+16
| | | | | | | | | | | | | | | | | | | | | | | It's undesirable to do BC1.2 detection on power swap, so add a function to check if the partner port is known to be PD-capable. BUG=chromium:780905 BRANCH=gru TEST=With subsequent CL, attach USB-PD phone capable of role swap. Verify USB 2.0 device is enumerated on plug, and not re-enumerated through a series of "pd # swap power" commands on the EC console. Also verify BC1.2 charging and PD charging are still functional on kevin. Change-Id: I4b775506beadb66e170b34a8acedf69a8a5dcf3d Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: fee1bde58def62ff7cbd40e060844c0cc496a032 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Change-Id: Ifa75c94e9758d3e407492bbda6fc52ed7bc378fa Original-Reviewed-on: https://chromium-review.googlesource.com/755877 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914648
* pd: Remove ACCESSORY statesShawn Nematbakhsh2018-02-1212-137/+51
| | | | | | | | | | | | | | | | | | | | | | | According to the USB-C spec, when a debug accessory is identified, we may optionally establish USB PD communication over CC. Some DTS partners (eg. servo_v4) expect us to speak PD, so let's make it so. There is no need for special ACCESSORY states, these do not exist in the PD spec. BRANCH=servo BUG=chromium:737755,b:65837068 TEST=On scarlet, attach servo_v4 and verify scarlet charges. Also verify EC and cr50 consoles are available through servo_v4. Change-Id: I84e7b1664a7503a889739b8872d9a2410c9ba5c5 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 251212fb9dea6d95a8caa43ec9eeb210abfa2df8 Original-Change-Id: I59d1ca50b4766509eccf38562cdf926578138585 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/693294 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914647
* cleanup: pd: Remove CONFIG_CASE_CLOSED_DEBUGShawn Nematbakhsh2018-02-126-99/+13
| | | | | | | | | | | | | | | | | | | | | | CONFIG_CASE_CLOSED_DEBUG (CCD functionality implemented by EC) is no longer used in conjunction with CONFIG_USB_POWER_DELIVERY, and the common routines are only used by one board. BUG=chromium:737755 BRANCH=None TEST=`make buildall -j` Change-Id: I19a86afc99907502678d01cf1b6c07604803b7a9 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 1e72cc1f5719d5c5df6dbe76a8c86f60a525fe1a Original-Change-Id: Idc3d2fccef6cbec2af786cef634d752a02a0e859 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/656315 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Nick Sanders <nsanders@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914646
* pd: Add "freeze" dual-role policyShawn Nematbakhsh2018-02-126-3/+25
| | | | | | | | | | | | | | | | | | | | | Add a new DRP policy to "freeze" the power role of each port, never toggling automatically, though manual role swaps may still occur. BUG=chromium:769895 BRANCH=servo TEST=On servo_v4, verify DUT port stays in SRC role and POWER port stays in SNK role while disconnected. Change-Id: Ic4480cb6d241563dee2a848c4b35763ed83cd182 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 7c2c5a9dc3779587f78a7c602cefeb667d210d41 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Change-Id: Ibff3cd1ffaf0e884b030c231003763a57acbe02e Original-Reviewed-on: https://chromium-review.googlesource.com/715276 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914645
* bd9995x: Leave USB data switches closed on PD power swapShawn Nematbakhsh2018-02-122-35/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order for BC1.2 detection to succeed, USB data switches must be open. Previously we performed BC1.2 detection whenever VBUS transitioned up to 5V, including on power swap. In fact, there is no need to do BC1.2 detection on a PD-capable port, since we will always charge using the USB-C or PD negotiated ILIM. Skip BC1.2 detection on power swap (and more generally when a partner port is known to speak PD) by manually triggering BC1.2 detection. In addition, manage USB switch state differently, so that "auto mode" is only enabled during BC1.2 detection. BUG=chromium:780905 BRANCH=gru TEST=Attach USB-PD phone capable of role swap. Verify USB 2.0 device is enumerated on plug, and not re-enumerated through a series of "pd # swap power" commands on the EC console. Also verify BC1.2 charging and PD charging are still functional on kevin. Change-Id: I53a0c0b72a439524b9726713018c607425451ff1 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 0354ad02cba910c90fd0c0e622c3b0b698802a1c Original-Change-Id: I1d7d4dee3bc8d2e7885e7adb49ded84b4f515ad5 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/755878 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914644
* bd9995x: Use fixed PD-port-to-VBUS/VCC mappingShawn Nematbakhsh2018-02-1213-99/+38
| | | | | | | | | | | | | | | | | | | | | The bd9995x driver was written to allow any PD port # to be VBUS or VCC, but the mapping is broken in a few places. Since all boards use VBUS = port 0, remove the conversion entirely. BUG=chromium:781849 BRANCH=kevin TEST=Verify PD and BC1.2 charging still works on kevin. Change-Id: I53162fb6e93e89dd161369302a18fc59e48e5dc8 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: f4ee6caa665009ca3306f61706074b82e1e2c347 Original-Change-Id: I3687866835d1684342d9f746d91b3a6079ab5cc4 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/755000 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914643
* charge_ramp: Move ramp allowed / ilim callbacks to common codeShawn Nematbakhsh2018-02-1219-468/+538
| | | | | | | | | | | | | | | | | | | | | | | | | The decision on whether to ramp (and how high) depends on the quirks of charger identification, so move the decision out of board, into the drivers that implement usb_charger. Also, rename CONFIG_CHARGE_RAMP to CONFIG_CHARGE_RAMP_SW, to better contrast with the existing CONFIG_CHARGE_RAMP_HW. BUG=None TEST=Manual on kevin, verify ramp occurs when port plugged into Z840 workstation. BRANCH=None Change-Id: Ia354879652651485183762bda10b42f4467ed542 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: b87fe062eca43fc00909098e716581bf2aeea7eb Original-Change-Id: I5b395274133837a18a4f4ac34b59b623287be175 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/702681 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914642
* Fix inconsistent task function declarationsStefan Reinauer2018-02-1224-25/+25
| | | | | | | | | | | | | | | | | | | Tasks are defined inconsistently across the code base. Signed-off-by: Stefan Reinauer <reinauer@google.com> BRANCH=none TEST=make buildall -j, also verify kevin boots to OS BUG=none Change-Id: I4e5ef4137cc17307848a8365b26b403a61cbbaed Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 9939855231350875737f9b05e208454451e3bb4a Original-Change-Id: I19a076395a9a8ee1e457e67a89d80d2f70277c97 Original-Reviewed-on: https://chromium-review.googlesource.com/602739 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914641
* npcx: unset ESPIRSTWE bit to prevent ec cannot enter low power modeCHLin2018-02-122-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL fixed the issue that ec cannot enter low power mode, which increases more power consumption in s5, by not setting ESPIRSTWE bit. For more detail, please see the npcx5's errata rev1_7, No.2.21. BRANCH=none BUG=b:69351155 TEST=No build errors for "make buildall". TEST=build and flash soraka, run commands to read the power consumption: dut-control pp3300_dsw_ec_cfg_reg:0x7327k dut-control pp3300_dsw_ec_mw -t 20 | grep "@@" the average power consumption measured reduces from 42.x to 10.x mw. TEST=do cold reboot stress test for 4 hours and no symptom occurred. Change-Id: Ib7be851e62a0d1d3d4730bad796a089783426268 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 216bb5f9d7fdeac65e3ed572b463ca13982b7e83 Original-Change-Id: Ic6fd7fe14ae8acaefd4e1a99ca1625254f67d708 Original-Signed-off-by: CHLin <CHLIN56@nuvoton.com> Original-Reviewed-on: https://chromium-review.googlesource.com/778709 Original-Commit-Ready: CH Lin <chlin56@nuvoton.com> Original-Tested-by: CH Lin <chlin56@nuvoton.com> Original-Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914640
* npcx: espi: Add new bit fields of eSPI regs and remove useless ones.Mulin Chao2018-02-121-36/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this CL, we introduced new bit fields of eSPI registers on npcx5/7 for the incoming patches. We also remove useless registers such as VWGPMS, VWGPSM and PING in order to let the driver look more clearly. This CL also includes: 1. Fixed typo from ESPIIWE to ESPIWE. 2. Introduce ESPIWE bits fields on npcx5/7. 3. Introduce new bit fields in ESPISTS of npcx7. 4. Remove useless VW1-4, VW1IE1-4 bits in ESPISTS and ESPIIE registes. 5. Introduce new bit field, WE, in VWEVMSn register of npcx7. BRANCH=none BUG=none TEST=No build errors for npcx5/7 series. Using "suspend_stress_test -c 1000" to do stress test and no symptom occurred on poppy. Both warmboot and coldboot stress test for 3 hours and no symptom occurred on poppy. Change-Id: I5cad37ccc577e9d234c14f20256b530998eb6e81 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 367e11ba28302292f125c8d108f60bae1a6fd002 Original-Change-Id: Ie8aa3dbd148588b0d9a756572d66604a6836a760 Original-Signed-off-by: Mulin Chao <mlchao@nuvoton.com> Original-Reviewed-on: https://chromium-review.googlesource.com/672026 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Original-Reviewed-by: Amit Maoz <Amit.Maoz@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/914639
* bd9995x: Clear VSYS_PRIORITY when Vbat > Vbat_minScott Collyer2018-02-121-2/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VSYS_PRIORITY in the register VIN_CTRL_SET is set during bd9995x initialization to ensure VSYS remains up and stable during deeply discharged battery conditions. However, outside of this case, this bit should remain cleared. If set, there the input current limit is disabled between the time that the boost converter is enabled (USB_SUS = 0) and charging is enabled (CHG_EN = 1). This can lead to too much current being drawn which results in the connecting port shutting off VBUS due to its overcurrent protection. This has been observed when attempting to charge one DUT from another chromebook port, or with a Type C only charger. This CL adds a check in the bd99965x driver implementation of charger_get_voltage() that compares the current battery voltage to its minimum voltage. If it's higher, then it's not a deeply discharged battery and VSYS_PRIORITY can be cleared. BUG=chromium:69143827,71814128 BRANCH=coral,eve TEST=Tested with 2 Coral DUTs. Verified that VSYS_PRIORITY gets cleared when the charger state machine gets the charger parameters. Also verified that I can repeatedly initated charging from one Coral device to another. Without this fix, this would fail most of the of the time. Also tested Eve with deeply discharged battery to make sure the startup conditon still works. Change-Id: I14179d7c91a0865d3d83d5b9746853c6b246b2d0 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: f793f81b8b9bd82f14a18adf3f179df78a813261 Original-Change-Id: I5230560fa98e5bf16921eb4f2c70802eb962e7f3 Original-Signed-off-by: Scott Collyer <scollyer@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/875178 Original-Commit-Ready: Scott Collyer <scollyer@chromium.org> Original-Tested-by: Scott Collyer <scollyer@chromium.org> Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914638
* charge_state: Change CHARGE_MAX_SLEEP_USEC to 1 minuteFurquan Shaikh2018-02-122-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CHARGE_MAX_SLEEP_USEC was originally set to 1 minute (i.e. equal to POLL_PERIOD_VERY_LONG) in CL:191767. However, during re-factoring in CL:193876 it got changed to 1 second as charge_state_v1 used this value. Looking at the way CHARGE_MAX_SLEEP_USEC is used, value of 1 minute makes more sense because sleep_usec could be set to POLL_PERIOD_VERY_LONG when device is off or suspended. With the current logic in suspend/off state, sleep_usec is set to POLL_PERIOD_VERY_LONG and immediately gets reset to CHARGE_MAX_SLEEP_USEC in charger_task. This change fixes the above behavior by defining CHARGE_MAX_SLEEP_USEC as 1 minute. As a side-effect of this, we might not wake up early enough in case of critical battery. Thus, check if we need to shutdown on critical battery and adjust sleep time accordingly. BUG=b:69695376 BRANCH=None TEST=make -j buildall Change-Id: I238689342a6c68b3269e7cdd0f2dad89eebb9156 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 55b87f4847394935d05cdefab2dc18dff9d6fa0e Original-Change-Id: Ieba7279dc4b02c3d64022c3c5ac09fb869a3632d Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/788181 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914637
* panic: Set EC_HOST_EVENT_PANIC on chipset resetFurquan Shaikh2018-02-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Add a hook for CHIPSET_RESET to allow the EC to indicate if there is any new panic info present. This helps coreboot to log EC panic info in eventlog. Also, update the hook priority for CHIPSET_RESET and HOOK_INIT to HOOK_PRIO_LAST to allow the EC to first log any software panic before it is checked. BUG=b:65732924,b:69334392 BRANCH=None TEST=Verified following: 1. Force panic_set_reason in EC on CHIPSET_RESET 2. reboot on AP console 3. mosys eventlog list shows "EC Event | Panic Reset in previous boot" Change-Id: I314539a724a3f23cd54ebfb8114ff64ee6ff2ce7 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 9fa6de15cf57e4beaa5726ebbe0e4ac6af004a79 Original-Change-Id: I77b49cd0b3bf05b10efc708e3d81af9ed0e3aa49 Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/797911 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914636
* software_panic: Add a new software panic type for PMIC faultFurquan Shaikh2018-02-121-0/+1
| | | | | | | | | | | | | | | | | | This change adds a new software panic type PANIC_SW_PMIC_FAULT that can be used to report any PMIC faults during previous boot. BUG=b:65732924,b:69334392 BRANCH=None TEST=make -j buildall Change-Id: I4fda802a5e010caae8d749fbb0253cfe117c8a1b Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 0fd88135208873cb08eb89cc4f017feeb5ee9caf Original-Change-Id: I218b5d01ee145bb02a773495046f4255f1ec8986 Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/797910 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914635
* intel_x86: Auto power-on after battery SOC is above minimum requiredFurquan Shaikh2018-02-121-5/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If power-up is inhibited by charger because of battery SOC, then check for the conditions again on BATTERY_SOC_CHANGE. This allows the EC to boot the AP up on connecting AC power and SOC going above the minimum required. BUG=b:65864825 BRANCH=None TEST=Verified following on coral and soraka: 1. Discharge battery to ~0% 2. Connect AC power ==> Power-up is inhibited 3. When battery SOC reaches 1%. AP is not taken out of reset: "[12.974428 Battery 1% / 8h:4 to full] [12.980439 power-up still inhibited]" 4. When battery SOC reaches 2%, AP is taken out of reset: "[9.230148 Battery 2% / 4h:5 to full] [9.236122 Battery SOC ok to boot AP!]" Change-Id: I61ccde13810212e901a594199339a4061c0df769 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: c147530f1046743d15647faae404073855d77f18 Original-Change-Id: Ifa89f8929987d86c9e02530b663d563dbe25ed85 Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/753294 Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914634
* skylake: Check for hard and soft off in chipset_force_shutdownFurquan Shaikh2018-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Intention of chipset_force_shutdown is to power off the AP by simulating power button press until it results in power button override and shuts down AP. However, if AP is already in hard or soft off conditions (i.e. G3, S5G3, G3S5 or S5) then AP is already off, and simulating power button press results in charge_prevent_power_on from incorrectly assuming that the power button is pressed by user. Thus, check if the system is in soft or hard off before shutting it down. BUG=b:65864825 BRANCH=None TEST=Verified that apshutdown still works fine from EC console on soraka. Change-Id: I522ea359adc36074a8c42e0c7243e39b47f80d48 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 7e2d3cd3a6ec36e33a4a175e9343a23140b75af5 Original-Change-Id: Id892e5b2c8c1e4ce0bad95a70ea6a3ed547a7047 Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/774298 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914633
* npcx: Use compatible MPU configShawn Nematbakhsh2018-02-122-48/+7
| | | | | | | | | | | | | | | | | | | | MPU is already configured for access restriction in cortex-m core code so take care not to conflict. BUG=chromium:782244 BRANCH=None TEST=Build + boot on kevin, verify hibernate doesn't panic. Change-Id: I42448338dc44afa453dc7990b0fc25828d4a0f85 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 68bd2d4fb278781d1ff7c40f42f43e8e445d89ac Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Change-Id: I9903cbc69002529ebbfa3fc1be3de4f74264e4aa Original-Reviewed-on: https://chromium-review.googlesource.com/759157 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914632
* cortex-m: mpu: Support unaligned regions and protect code RAMShawn Nematbakhsh2018-02-124-60/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support protection of regions that aren't aligned to a power of 2 by using two MPU entries, and taking advantage of the sub-region feature. Also protect code RAM from being overwritten, on parts that use external storage. BUG=chromium:782244 BRANCH=None TEST=On kevin, call: mpu_protect_data_ram(); mpu_protect_code_ram(); mpu_enable(); Verify that first call results in the following update_region params: addr: 0x200c2000 size: 0xc01d Decoded: Protect 24K region Verify that second call results in the following params: addr: 0x100a8000 size: 0xc021 Decoded: Protect 96K region addr: 0x100c0000 size: 0xf01b Decoded: Protect remaining 8K region Also verify that writes to beginning and end of code ram region trigger data access violation after enabling protection. Also verify that sysjump fails. Change-Id: I57d9b05b7f34eabb4e7126b2a0d45f0881905621 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: b6991dd96d8bf6cb86a39b3da590ccd8b4e1e036 Original-Change-Id: Ieb7a4ec3a089e8a2d29f231e1e3acf2e78e560a1 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/757721 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914631
* npcx: fixed the assembly code of deep idle bypassCHLin2018-02-122-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original assembly code of deep sleep bypass will cause build error if both CONFIG_LOW_POWER_IDLE and CONFIG_LTO are defined when buildiing board glkrvp/zoombini. This CL fixed it by change the bypass assembly code from: asm ("push {r0-r5}\n" "ldr r0, =0x100A8000\n" "wfi\n" "ldm r0, {r0-r5}\n" "pop {r0-r5}\n" "isb\n" ); to: asm ("push {r0-r5}\n" "wfi\n" "ldm %0, {r0-r5}\n" "pop {r0-r5}\n" "isb\n" :: "r" (0x100A8000) ); BRANCH=none BUG=none TEST=No build errors for "make buildall". TEST=build zoombini/glkrvp with CONFIG_LOW_POWER_IDLE and CONFIG_LTO, no build errors. TEST=build npcx7_evb/npcx_evb and do stress test for deep idle->wakeup on EVB, no symptom observed. Change-Id: I1b4cd66bc78524f0ad42c7dcd3ca005461bf3e36 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 16f4c65daf528de399bf622d0aefcadc19238544 Original-Change-Id: I90b13b4baf418e3f4b3234d4811e3978b6436aac Original-Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Original-Signed-off-by: CHLin <CHLIN56@nuvoton.com> Original-Reviewed-on: https://chromium-review.googlesource.com/756535 Original-Commit-Ready: CH Lin <chlin56@nuvoton.com> Original-Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/914630
* charger: Prevent SET access to EC_CMD_CHARGE_STATE on locked systemsShawn Nematbakhsh2018-02-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The SET sub-command of EC_CMD_CHARGE_STATE sets charger current / voltage parameters to arbitrary values and should be locked down. EC_CMD_CHARGE_CONTROL, on the other hand, switches between several safe operation modes, and should be allowed. BUG=None TEST=On kevin, set force_locked, plug zinger, and verify: ectool chargestate param 4 3 <-- ACCESS_DENIED ectool chargestate show <-- prints params ectool chargecontrol idle <-- stops charging battery ectool chargecontrol normal <-- battery charges again BRANCH=None Change-Id: I2114d75ded4c8839e56dd9a12354d00b207ac308 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: e4deceba8d6a8afff50ca2223be59b755ee3eca2 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Change-Id: I5503f07bb196d023a9bcd2e33f2e247f061f05e5 Original-Reviewed-on: https://chromium-review.googlesource.com/757237 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914629
* npcx: espi: fixed bug that ec cannot wakeup from deep idle by VW eventsMulin Chao2018-02-122-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According npcx ec wake-up mechanism by espi VW events, the driver needs to make sure the IE/WE bits in VWEVMSn and the VWUPD bit in ESPIWE registers are both set. Or ec won't wakeup by VW signals until the other wake-up events occured. (WE bit of VWEVMSn is introduced on npcx7.) In this CL, we turn on IE/WE bit in VWEVMSn registers during espi driver initialization and toggle the bits of ESPIWE register for VW and general events such as ESPI_RST and so on when ec turn on/off host interface's interrupts to make sure ec can wake-up from deep idle by espi events in time. BRANCH=none BUG=none TEST=No build errors for npcx5/7 series. Using "suspend_stress_test -c 1000" to do stress test and no symptom occurred on poppy. Both warmboot and coldboot stress test for 5 hours and no symptom occurred on poppy. Change-Id: Id5ecd6f372e898be2f82525c0edb7d49f56b61df Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 32cc460bad5ad02a4b7e0a85ef54361049e80897 Original-Change-Id: I853532508bf9da5f3abc39e20ab848e659ca5e26 Original-Signed-off-by: Mulin Chao <mlchao@nuvoton.com> Original-Reviewed-on: https://chromium-review.googlesource.com/725559 Original-Reviewed-by: Amit Maoz <amit.maoz@nuvoton.corp-partner.google.com> Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/914628
* sensors: Remove debug printfGwendal Grignou2018-02-081-2/+0
| | | | | | | | | | | | | Remove prints when activity triggers. BUG=b:72533440 BRANCH=eve TEST=compile Change-Id: I047e14990ef734c35161293b9c5fbbece0ddab0c Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/907216 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* driver: BMM150: Set max frequency based on repetitions settingGwendal Grignou2017-11-014-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compass uses oversampling to produce accurate values. MAX_ODR is functions of the repetitions setting. 80Hz is too high, calculate the frequency based on preset setting. Currently, we use 'SPECIAL' that was calculated for Ryu. BUG=b:68394559 BRANCH=eve,reef,poppy TEST=Check with ectool motionsense info 3 the frequency is around 30Hz. Before: Min Frequency: 781 mHz Max Frequency: 80000 mHz After: Min Frequency: 781 mHz Max Frequency: 29579 mHz Check with AIDA64 the compass is not stuck and return changing values. Fixup of CL/570482 Change-Id: Iffb2875fd15fb95d3c3b7d85c1100dff665731b2 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 8a2d0a5de6fc03eeea79a65469b361ae0ca694c9 Original-Change-Id: Idcfed1418f59e755e5647d018351c6a7397ffe1b Original-Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/742146 Original-Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/749884
* Fix keyboard in systemd-bootStefan Reinauer2017-11-011-13/+5
| | | | | | | | | | | | | | | | | | | | | | | This prevents problematic disabling of the keystrokes by making it so that 0xAD can't disable keystrokes. Also cleans up keyboard controller enable/disable code. BRANCH=none BUG=none TEST=keyboard now working in UEFI bootloaders like systemd-boot (aka gummiboot) Change-Id: I5ef3ef3bb32138e19b7bc20f607ab0a05df54b5f Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 3bd60c42ecd3d2ade28e1ce4fbc05aef4afdf077 Original-Change-Id: I921834fc418572c9a0f4586039ac1ce05504bf1d Original-Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Original-Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/722124 Original-Tested-by: Stefan Reinauer <reinauer@google.com> Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/749883
* keyboard_8042: ensure key scanning on when keyboard enabledStefan Reinauer2017-11-011-0/+2
| | | | | | | | | | | | | | | | | BRANCH=none BUG=none TEST=Boot Windows in legacy mode and observe keyboard is working. Change-Id: I620998e8b968d887f65c3a2be77da9bf05e40ee2 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 38d23e4af0fe502f67367dd87af4755551988435 Original-Change-Id: Id203a8804b86e0fcfbb9974658f66e9bd2602151 Original-Signed-off-by: Matt DeVillier <matt.devillier@gmail.com> Original-Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/722123 Original-Tested-by: Stefan Reinauer <reinauer@google.com> Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/749882
* kionix: Issue soft reset before checking whoami resultDuncan Laurie2017-10-261-1/+24
| | | | | | | | | | | | | | | | | Issue a soft reset before checking the whoami register against the expected value. The early whoami check is left in place to probe for when the chip is responding on i2c, but the returned value is not checked. BUG=b:67865186 BRANCH=eve TEST=manual on eve: 'crash watchdog' and verify that kxcj9 initializes properly and is functional after the EC crash. Change-Id: I5c4e2510c8e913a9160838923354d9a63e5acbd4 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://chromium-review.googlesource.com/739801
* charge_manager: Delay power on if battery is not presentDuncan Laurie2017-10-101-0/+11
| | | | | | | | | | | | | | | | | | If the battery is not physically present in the system then delay power-on until the charger is providing at least 15W of power. (currently defined as LIKELY_PD_USBC_POWER_MW) This will allow a board without a battery to boot without browning out the system. BUG=b:66977532 BRANCH=eve TEST=successfully boot on the first attempt without a battery Change-Id: Ia362b55962d15aa9c72eb4b0742989e3cac0b5d4 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://chromium-review.googlesource.com/709473 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* eve: Make BATTERY_DISCONNECTED depend only on XDSGScott Collyer2017-10-101-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The battery_check_disconnect() function was checking for both XCGH and XDSG to be set before returning BATTERY_DISCONNECTED. This works consistently when recovering from a battery cutoff when issued via a I2C command. However, if the battery cutoff was initiated due to a cell under voltage (CUV) trip, only the discharge FET will be disabled. When an external charger is connected, the battery may not be able to recover if the CUV event happened while SOC > 3%. By modifying the battery_check_disconnected to look only at XDSG then the normal battery cutoff and CUV triggered cutoff are recovered properly when an external charger is connected. BUG=b:67332823 BRANCH=eve TEST=Had two different units where I was able to confirm that a CUV event had happened. I obsereved that the system would brown out when the AP was powered up, preventing the EC from being able to charge the battery to get out of the CUV condition. Once I loaded FW that only checked XDSG, then verified that the AP was not powered on and the battery was able to be charged by the EC. Change-Id: I893cfcdd4123810137e2d09a15256d51c918b38b Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/705055 Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@google.com> Commit-Queue: Duncan Laurie <dlaurie@google.com>
* eve: Provide batteryparam implementation to disable CTOScott Collyer2017-10-032-0/+251
| | | | | | | | | | | | | | | | | | | | | | | | | | The charger timeout threshold settings are not correct. This can lead to the CTOS (charge timeout suspend) safety alert getting set. Until the batteries flash can be updated, disable this check by clearing bit 4 of the protect_c register. This CL implements battery_set_vendor_param() and battery_get_vendor_param() where param of 0 means to disable the CTO bit in the protect_c flash register (bit 4 of 0x482c). BUG=b:66457399 BRANCH=eve TEST=Sent 'ectool batteryparam set 0 <key>' and verifed that new value of this register is 0x5. Also, used debug console command to write the value back to 0x15 and repeated the test. Change-Id: Ia77a505fddfbcedfe31a92caae37e09e0a7f17a1 Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/696436 Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@google.com> Commit-Queue: Scott Collyer <scollyer@chromium.org> Trybot-Ready: Scott Collyer <scollyer@chromium.org>
* pd: Apply consistent Rp at bootShawn Nematbakhsh2017-09-281-0/+5
| | | | | | | | | | | | | | | | | | | | CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT Rp is applied when neither port is a source, so apply it at boot to be consistent. BUG=chromium:766814 BRANCH=gru TEST=On kevin, verify 3A Rp is applied to both ports at boot. Change-Id: Id8d4fc58229a8c243c311b9677ebd812cf51cfa9 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 7b473c8efdd97bdd7e6a86213731edb4d80b5d96 Original-Change-Id: Ib62a96063783e8ef9ac9240800f445fa9e5a59af Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/675845 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/690178
* pd: Allow deep sleep in SRC_DISCOVERYShawn Nematbakhsh2017-09-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the PD state machine remains in SRC_DISCOVERY for an extended period of time, it's likely that a non-PD USB peripheral is attached. In this case, we don't need to inhibit deep sleep, since we're not likely to receive PD packets. This change will cause us to enter deep sleep slightly more aggressively, not inhibiting deep sleep until source caps are received or replied with GoodCRC by the port partner. We can accommodate additional task latency up to this point, since the spec calls for source caps to be sent up to 50 times before failure. BUG=b:35582718,chromium:763002 TEST=Test with `sleepmask 1` on kevin. - Go to S3 with USB-C flash drive plugged, verify `sleepmask` shows 0. - Go to S3 with zinger + USB C flash drive plugged - Unplug zinger, verify `sleepmask` shows 0. - Plug zinger, verify PD negotiates to 20V @ 2A. - Plug OEM kevin charger, verify same. BRANCH=gru Change-Id: Iaedb8ed124a8aa614fabb58b7aed151ae7003dad Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 9abb9f762efb3f386befc74e90275fe8789e3bd2 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Change-Id: Ib8e1bc94bdbcfddea004d572edf1ccadc8c8c1ce Original-Reviewed-on: https://chromium-review.googlesource.com/655919 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/690177
* pd: Remove support for debug accessories that provide VBUS + RdShawn Nematbakhsh2017-09-289-48/+3
| | | | | | | | | | | | | | | | | | | | | | | Reworked suzy-q and suzy-qable all provide Rp, so there is no need for special detection handling in S5. Also, CONFIG_USB_PD_QUIRK_SLOW_CC_STATUS is no longer relevant, since we no longer take special action when VBUS is seen without Rp. BUG=chromium:737755 BRANCH=None TEST=On kevin, verify reworked suzy-q and suzy-qable are detected in S5. Also, verify zinger works in S5 on reef. Change-Id: I3712c38bf41603fef85e9f06b9c6952fd3da77c8 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: dde1a514de4cc5a570db6a3cff4f43396e8c90f4 Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Original-Change-Id: I50967bd6415d964a038b2e7d134374132eda11ec Original-Reviewed-on: https://chromium-review.googlesource.com/656067 Original-Commit-Ready: Shawn N <shawnn@chromium.org> Original-Tested-by: Shawn N <shawnn@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/690176
* npcx: bypass for CSAE issue if CONFIG_LOW_POWER_IDLE is disabledMulin Chao2017-09-282-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to prevent keeping the CSAE bit at 1 forever impacts the eSPI performance, the npcx driver enables host access wakeup functionality before ec enters deep sleep or wfi. But this bypass also should be added in __idle() of core/cortex-m/task.c if CONFIG_LOW_POWER_IDLE is disabled. This CL also narrows the bypass only when host interface is eSPI. BRANCH=eve BUG=b:64730183 TEST=No build errors for make buildall. Disable CONFIG_LOW_POWER_IDLE functionality on poppy and use following script "count=0; while :; do echo "--- iteration --- $count"; time flashrom -p ec -r ec.bin; sleep 1; count=$((${count}+1)); done" to test eSPI performances over 300 times. No errors occur and all tests' efficiency are the same as removing CSAE bypass. Change-Id: Icf75a47862360638261c4881956bd03661527ac6 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: ebe3caeb69aeaa9144701415decc3e6647df01cd Original-Change-Id: I8b6b69e37318208c185747151c06b3e6bdfd2f4e Original-Signed-off-by: Mulin Chao <mlchao@nuvoton.com> Original-Reviewed-on: https://chromium-review.googlesource.com/644967 Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/690175
* npcx: bypasses for SHM reading fail via eSPI and CSAE impact efficiencyMulin Chao2017-09-282-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In eSPI systems, when the host performs a data read from the Shared Memory space, the returned data may be corrupted. This is a result of the Core-to-Host access enable bit being toggled (by toggling CSAE bit in SIBCTRL register) during an eSPI transaction. The bypass for this symptom is to set CSAE bit to 1 during initialization and remove the toggling of CSAE bit from other EC firmware code. But keeping the CSAE bit at 1 forever also impacts the eSPI performance a lots. When the core clock is stalled by sleep, deep sleep or wfi instruction, the eSPI Peripheral Channel transaction is stalled if this bit is set. The bypass for this symptom is to wake up the core by eSPI peripheral channel transaction and let eSPI module handle the remaining packet. BRANCH=eve BUG=b:64730183 TEST=No build errors for make buildall. Flash poppy ec image, make sure it can boot to OS. Run "ectool version" over 100000 times, no error occurs. Use following script "count=0; while :; do echo "--- iteration --- $count"; time flashrom -p ec -r ec.bin; sleep 5; count=$((${count}+1)); done" to test eSPI performances over 1000 times. No errors occur and all tests' efficiency are the same as removing CSAE bypass. Change-Id: I13f184f5422ffc5cd8bda4349cd88249e509ee05 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 20c3de1c36bf44822834ff0daa308499aa466b5c Original-Change-Id: I1b9051c5a3d368a5917882d9d1c3bb00481a53ad Original-Signed-off-by: CHLin <CHLIN56@nuvoton.com> Original-Signed-off-by: Mulin Chao <mlchao@nuvoton.com> Original-Reviewed-on: https://chromium-review.googlesource.com/620301 Original-Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/690174
* driver: bm160: Fix minimal gyro frequencyGwendal Grignou2017-09-201-1/+1
| | | | | | | | | | | | | | | | | | Was set in Hz unit instead of mHz. The minimal frequency of the gyroscope is 25Hz. By setting it at 25mHz, we make believe that the gyro was also supporting 5Hz or 10Hz: the test would complain when instead the samples came with a 25Hz. Fix up of cl/482703 BUG=b:65000611 TEST=compile BRANCH=caroline,eve,twinkie Change-Id: I162d0d2e9b545af82698d8d484875761f426efe4 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/675783
* eve: Enable optimized SHA256 implementationDuncan Laurie2017-09-131-0/+1
| | | | | | | | | | | BRANCH=eve BUG=b:64196191 TEST=boot eve and check hash done time Change-Id: I48e64d126b67c3f58fc3a8cd4f0aa3226ce89f33 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://chromium-review.googlesource.com/664164 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* common/sha256: agressive SHA-256 unrolling as an optionNicolas Boichat2017-09-133-0/+30
| | | | | | | | | | | | | | | | | | | | Reduces "hash done" time from ~1.30 to ~1.15s on soraka. BRANCH=none BUG=chromium:702378 BUG=b:64196191 TEST=Boot soraka, looks at hash done time. TEST=make run-sha256 run-sha256_unrolled passes. Change-Id: I396e52b699874afb8a3cfd324bc9464722bf2d9a Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 797d740727813c7b600e8ecd9df0bb87b0d39678 Original-Change-Id: Ia29ee27404d6e9aa615ff59755b59d3f26648e71 Original-Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/652327 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/663919
* port80: Disable default print of port80 messages in interrupt contextFurquan Shaikh2017-09-132-30/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Add a new config option CONFIG_PORT80_PRINT_IN_INT which is disabled by default to disable printing of port80 messages in interrupt context. 2. If CONFIG_BRINGUP is defined, redefine CONFIG_PORT80_PRINT_IN_INT to enable printing of port80 messages in interrupt context for boards that are in bringup phase. 3. If print_in_int is disabled, add a deferred call to dump port80 buffer to EC console 4 seconds after the last port80 message is received. BUG=b:64196191 BRANCH=None TEST=Verified following: 1. make -j buildall 2. Port80 messages are not printed by default on Soraka 3. Port80 buffer is dumped 4 seconds after last port80 message, if BIOS is stuck for 4 seconds, in recovery mode and when reboot from AP console. 4. Boot time on soraka went down from ~1.59seconds to ~1.45 seconds in EC reboot case (savings of ~140ms). Change-Id: Ia43d9849b3ff3c9c20f531e3353cc8d60f65a45c Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 1bece4ee08aa8505e9613e614fc75d254ad5cd40 Original-Change-Id: I9aee0987765f905b4ac49d04ffc54d71ee3a04f9 Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/661880 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/663918
* eve: Re-enable discharge-on-ac for all boardsDuncan Laurie2017-09-132-1/+3
| | | | | | | | | | | | | Enable discharge on ac when battery is full. BUG=b:64913617 BRANCH=eve TEST=test that when on AC and battery is full it goes into discharge mode Change-Id: I71397e7f0b24e449b13c00da87c8f81cfd806c2c Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://chromium-review.googlesource.com/662907 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* eve: Modify LED tables to match updates to specScott Collyer2017-09-131-25/+23
| | | | | | | | | | | | | | | | | | | One of the pulse red patterns has been removed, so only 1 pulse red pattern is required. In addition the double tap length of the two lowest battery patterns has been increased. BUG=b:35584895 BRANCH=eve TEST=Manual Used 'battfake' EC console command to move through the different battery charge states and verifed that the correct double tap pattern is displayed. Change-Id: I6f92ecdbdd5476da2eb0d9f09e9f853ed5f45b53 Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/663951 Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@google.com> Commit-Queue: Duncan Laurie <dlaurie@google.com>
* charger: bd9995x: Disable topoff modeShawn Nematbakhsh2017-08-311-3/+1
| | | | | | | | | | | | | | | | | | | | | Zero ITERM_SET to keep the charger out of topoff mode, since it has undesirable side-effects related to dead / low battery charging. BUG=b:35575421 BRANCH=reef TEST=Previous testing on kevin with same register setting. Change-Id: Ic1dd280e1069d410895498c0f72989654a6b8c63 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/636152 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 98405d4eaec40e1ac9b8f0344ea8ddbc2747a4c9) Reviewed-on: https://chromium-review.googlesource.com/646486 Reviewed-by: Duncan Laurie <dlaurie@google.com> Commit-Queue: Duncan Laurie <dlaurie@google.com> Tested-by: Duncan Laurie <dlaurie@google.com>
* eve: Make a few pmic init commands run on RW imageDuncan Laurie2017-08-161-10/+10
| | | | | | | | | | | | | | | | | | Currently all of board_pmic_init() is skipped if you jump to the image, which means it never runs on RW, or on RO if it is updated by flashing, and requires a power+refresh boot to take effect. Move a few of these that are adjusting important settings to also run on system jump so they get applied when rolling out a new FW. BUG=none TEST=manual: flash new ec.bin and check that pmic register is set to disable VCCIO from ALL_SYS_PWRGD. Change-Id: I07a96dd052d142e5026778a7e785e1cb4c4849a1 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://chromium-review.googlesource.com/617267 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* Revert "npcx: workaround the bug that SHM data read via eSPI may be corrupted"Duncan Laurie2017-08-161-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 9271f4ca437095420506ee7e1971b3f95abc11ca. Reason for revert: Appears to be causing issues. BUG=b:64730183 TEST=none Original change's description: > npcx: workaround the bug that SHM data read via eSPI may be corrupted > > In eSPI systems, when the Host performs a data read from the Shared > Memory space, the returned data may be corrupted. This is a result of > the Core-to-Host access enable bit being toggled (by toggling CSAE bit > in SIBCTRL register) during an eSPI transaction. > > The workaround in this CL is to set CSAE bit to 1 during initialization > and remove the toggling of CSAE bit from other EC firmware code. > (i.e., let the CSAE bit be always 1.) > > BRANCH=none > BUG=none > TEST=No build errors for make buildall. Flash poppy ec image, make sure > it can boot to OS. Run "ectool version" over 100000 times, no error > occurs. > > Change-Id: I905d8c193378e6fdd03dd944d4734611e93091d4 > Signed-off-by: Duncan Laurie <dlaurie@google.com> > Original-Commit-Id: ddbfe690e294e595c6ed3511dcf417410d9b2804 > Original-Change-Id: I7aac6805ece64e8f77964d4acb026d9871cd2ebe > Original-Signed-off-by: CHLin <CHLIN56@nuvoton.com> > Original-Reviewed-on: https://chromium-review.googlesource.com/590396 > Original-Commit-Ready: Shawn N <shawnn@chromium.org> > Original-Tested-by: CH Lin <chlin56@nuvoton.com> > Original-Reviewed-by: Shawn N <shawnn@chromium.org> > Reviewed-on: https://chromium-review.googlesource.com/604726 Bug: none Change-Id: I7fe3842fac1cad76bcc4d8f21430dd8b8ca63e5d Reviewed-on: https://chromium-review.googlesource.com/617242 Reviewed-by: Duncan Laurie <dlaurie@google.com> Commit-Queue: Duncan Laurie <dlaurie@google.com> Tested-by: Duncan Laurie <dlaurie@google.com> Trybot-Ready: Duncan Laurie <dlaurie@google.com>
* eve: Disable PMIC power button shutdown timerDuncan Laurie2017-08-151-0/+3
| | | | | | | | | | | | | | | Disable the PMIC shutdown timer for power button to prevent it from being able to shutdown the system. Refresh+Power is still the best way to do a PMIC reset. BUG=none TESET=manual: Close lid and enter suspend, hold power button for >30 seconds and ensure EC stays up and system stays in suspend. Change-Id: I1e03c6acab57aeba10083eb7bb6a6141bfa56993 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://chromium-review.googlesource.com/614600 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* usb_pd_protocol: Req SNK Cap if not received yet.Aseda Aboagye2017-08-121-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In the SRC_READY state, we'll only request sink caps if we haven't received them yet and only if its the first transition to the state. However, we also don't send any PD traffic in that state if there's an incoming message in order to prevent a collision. This could create a scenario where upon entry to the SRC_READY state, a message is incoming. When this occurs, we never request the sink caps. This commit simply removes the condition that we may only request sink caps on the first transition to the SRC_READY state. BUG=b:64037926 BRANCH=gru TEST=Flash kevin; Connect to a DR port partner; Verify that sink caps are requested even after the first transition to the SRC_READY state. Change-Id: Ia1393c7a866a40a2b588b12fbb318235341daa2b Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 8d6da80f34cab49cd773e462d9720a210d4ce471 Original-Change-Id: I6bc9ad01d45e6584a7a14b28806ae4872a22d98f Original-Signed-off-by: Aseda Aboagye <aaboagye@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/611320 Original-Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Original-Tested-by: Aseda Aboagye <aaboagye@chromium.org> Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/612783
* charge_manager: Consider port in source PDO.Aseda Aboagye2017-08-128-22/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT is defined for a board, as its name implies, the board can source a higher current if there is only one port acting as a source. This commit fixes an issue with selecting the right source capability message to advertise. charge_manager_get_source_pdo() was simply checking if there was more than one sink connected, instead of checking if there were any *other* sinks connected. In the event that a sink was connected to a different port, we would advertise the max source PDO. BUG=b:64037926, b:35577509 BRANCH=gru,eve,reef TEST=Connect sink to port 1. Connect a AMA to port 0 that claims that VBUS isn't necessary. Start sending source caps, verify that the max PDO is not being advertised in the source caps. Change-Id: Ie3ab6f6cc161e01dc4db2e3cfc7a7c00bf727fe6 Signed-off-by: Duncan Laurie <dlaurie@google.com> Original-Commit-Id: 79ae73477c1d6a84ce9c64eb82a183a163aa3646 Original-Change-Id: Ie4145ecaf98d5b9070ad3e8b139e5653685fa801 Original-Signed-off-by: Aseda Aboagye <aaboagye@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/610479 Original-Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Original-Tested-by: Aseda Aboagye <aaboagye@chromium.org> Original-Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/612782
* eve: Modify LED behavior to show double tap patterns when chargingScott Collyer2017-08-111-172/+255
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous LED behavior was to have only the LED on side that was charging show white or green. The other side LED was always off. This CL modifies the behavior so that when double tap patterns are allowed and a charger is connected to display the double tap pattern on the opposite side LED which was previously off. In addition, when the device is charging, if the power level is such that AP can't boot, the opposite side LED will display the BLINK_RED pattern continuously as it would duirng a double tap event. In order to support the ability to have different LED patterns simultaneously, the LED code was refactored so that static variables used to manage the patterns and varialbes required to manage color gradient transitions were grouped together in to a static led descriptor. In addition, the led_manage_pattern and change_color functions had to be modified to deal with each LED independently. BUG=b:35584895 BRANCH=eve TEST=Manual Used EC console command 'battfake' to force different charge levels and verified the correct patterns for double tap events. Confirmed that double tap patterns are displayed on the non-charging port when a charger is connected. Tested connecting and removing charger while observing non-charging port. Change-Id: I05e1671deada761388bf898096ed7d3ae6f8da0f Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/611781 Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@google.com> Commit-Queue: Scott Collyer <scollyer@chromium.org>
* eve: Update hibernate delayDuncan Laurie2017-08-111-0/+6
| | | | | | | | | | | | | | Hibernate after 7 days, or 1 day if battery is less than 10%. BUG=b:35584895 BRANCH=eve TEST=check that hibernate delay by default is 604800 seconds, but only 86400 seconds if the battery is less than 10%. Change-Id: I826b6df170f296afb2af8c053c05521383030cb1 Signed-off-by: Duncan Laurie <dlaurie@google.com> Reviewed-on: https://chromium-review.googlesource.com/611017 Reviewed-by: Scott Collyer <scollyer@chromium.org>
View Lorry Controller Status