summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* usb_pd_protocol: disable VBUS when suspending PD taskCaveh Jalali2019-11-011-0/+1
| | | | | | | | | | | | | | | | | | when we suspend a port's PD task, we should also shut off VBUS on that port. BUG=b:143330980 BRANCH=none TEST=ectool pdcontrol suspend now shuts off VBUS Change-Id: Iba20586e07514276c29a91e567bf6abde8f97056 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1886450 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 1b54e57c7e7bf50dbf31f24fe5a4c293d6698ffd) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1894799 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* Makefile.rules: fix jobserver handlingCaveh Jalali2019-11-011-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | looks like make isn't smart enough to detect a recursive make invocation when the $(MAKE) command is buried inside a $(call ...) function resulting in: make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. adding a '+' to give make the appropriate hint. BUG=none BRANCH=none TEST=make buildall -j still works, make no longer complains about jobserver Change-Id: Ia923a653e1ebf9cae7dae24a5b16f821b53e70b2 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1803179 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit e1e81b2b8bbd0049f2472bb7f7c5ce1e3c9864b7) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1894798 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* tcpci: fix tcpc_alert error messageCaveh Jalali2019-11-011-2/+2
| | | | | | | | | | | | | | | | | this adds a missing newline to the end of a CPRINTF format string. BRANCH=none BUG=none TEST=builall passes Change-Id: I4a380983bce107af7a0f6eb7304bb9090c5b621a Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1886033 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Sean Abraham <seanabraham@chromium.org> (cherry picked from commit adc5678d1979b4f2bd52a5d70b5f0a08cefad8f9) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1894797 Commit-Queue: Caveh Jalali <caveh@google.com>
* atlas: fix charger selection messagesCaveh Jalali2019-11-011-2/+2
| | | | | | | | | | | | | | | | | | | this corrects the printed text and switches from CPRINTF to CPRINTS for time stamping. BRANCH=none BUG=none TEST=buildall passes Change-Id: I4647ef4348a44d3eb433afa96ad04f2483899bc0 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1886034 Commit-Queue: Sean Abraham <seanabraham@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 7dece1affb2b8bcaa449743937c55774a0aa2ee0) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1894796 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* Makefile.rules: use patsubst instead of substCaveh Jalali2019-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | the patsubst function is a better function for removing a path prefix as it is anchored at the beginning of the search space. the original "subst" function can match everywhere in the path which leads to weird transformations. patsubst is anchored at the beginning of the string which better suits the intent here. BRANCH=none BUG=none TEST=make buildall passes, $(out) now only removed at beginning of output paths. Change-Id: Ic5fe7aeb5eb8c87aa8bb49ea0865dc07327cb3e5 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1803178 Commit-Queue: Caveh Jalali <caveh@google.com> Reviewed-by: Caveh Jalali <caveh@google.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 49efdd8a8eaed593beeb8686e40d343f38e82a62) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1885832
* tcpci: protect against buffer overflowCaveh Jalali2019-10-101-6/+12
| | | | | | | | | | | | | | | | | we need to sanity check data read from TCPCs to avoid buffer overflows. the TCPC can return bogus size information which can cause a buffer overflow when processing TCPM messages. if the claimed message size is bogus, return an error. BUG=b:142296767 BRANCH=none TEST=EC no longer gets an exception Change-Id: I7754c6e3d20847827b849423c5880756bae46393 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1845586 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* usbpd: Fix infinite init loopDaisuke Nojiri2019-10-011-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | tcpci_tcpm_init can loop forever if tcpc_read or mux_read is successful but TCPC_REG_POWER_STATUS_UNINIT bit is set. This patch fixes it. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=chromium:971741 BRANCH=none TEST=buildall Change-Id: I5eeb58fc77ee0de753a6c0b049bf332e291faa29 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1647366 Reviewed-by: Scott Collyer <scollyer@chromium.org> Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 2e3ec3604f774d9c7bb9eaf0aaf339b4a8cbd9cd) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1833243 Tested-by: caveh jalali <caveh@chromium.org> Auto-Submit: caveh jalali <caveh@chromium.org> Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* gitignore: ignore emacs backup filesCaveh Jalali2019-10-011-0/+1
| | | | | | | | | | | | | | | | | emacs creates backup files ending in ~ and should be ignored by git. BUG=none BRANCH=none TEST=git status no longer complains about *~ files. Change-Id: I96043f89c1d51f8034a2427426ec07d9e2846363 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1772525 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 83169d99fe128e9a6cfe264968bbb8eb71b39a7f) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1833241 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* chip/npcx: fix cprints argumentsCaveh Jalali2019-10-011-2/+2
| | | | | | | | | | | | | | | this fixes the format string used in cprints. the intent was clearly string concatenation, but instead 2 strings were passed to cprints. BUG=none BRANCH=none TEST=buildall passes, boots on atlas Change-Id: I8942c4f5fd99b490a3da8a6a289d23454509e69d Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1832897 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* tcpci: add missing CPRINTS argumentCaveh Jalali2019-10-011-1/+1
| | | | | | | | | | | | | | | | | this adds the missing "port" argument to a CPRINTS. BUG=none BRANCH=none TEST=buildall passes, boots on atlas Change-Id: I9308a4beea716441912aaa06eb206e9d17186cd9 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1825876 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit 1906434c4e62fac6792b6b81874810495be49b2e) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1832896 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* usb_pd_protocol: add missing CPRINTF argumentCaveh Jalali2019-10-011-1/+1
| | | | | | | | | | | | | | | | | This adds the missing "port" argument to a printf. BUG=none BRANCH=none TEST=buildall passed, boots on atlas Change-Id: Ia0e27b323bf6f274efbd3498c8e7e5c7d7b81a1a Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1825875 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit b2e89b61b13cc88324699a7aefac87cce0207669) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1832895 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* EC: Do not drop SCI events responsible for wake.Ravi Chandra Sadineni2019-09-242-7/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EC currently clears all events(main copy of hostevents) on every resume. This seems to be added to clear events that are only part of wake mask and not part of SCI mask as they can stick and cause premature wake on next suspend. This patch stops clearing events that are part of SCI mask from the main copy as ACPI subsystem will query and clear them on resume anyway. This helps kernel to identify the reason for wake if it caused by events that are part of SCI mask. Previously coreboot used to depend on main copy to log wake reason. i.e on every resume coreboot used to query and log and clear the wake reason by reading all events from the main copy. Since this also comes in way of kernel in identifying the wake reason, this change also sets up events_copy_b for coreboot by clearing it on every suspend entery. More details can be found at http://go/hostevent-refactor. BUG=b:141367114 BRANCH=None TEST=Tested suspend/resume with wakeup count on hatch and grunt. Change-Id: I0fac250d4dac49af960b29e8b0e28841af2ef509 Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1717498 Reviewed-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 74f268374972bdc8bd6c2a5c412d31edafa812b1) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1816721 Commit-Queue: caveh jalali <caveh@chromium.org> Tested-by: caveh jalali <caveh@chromium.org> Reviewed-by: Caveh Jalali <caveh@google.com>
* usb_pd_protocol: Add a 3ms delay between polling ALERT#.Aseda Aboagye2019-09-191-1/+4
| | | | | | | | | | | | | | | | | | | | | | In order to prevent tasks from being starved and eventually a watchdog reset, add a short 3ms sleep to give other tasks a chance to run. BUG=b:115452695 BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne; plug in hoho on port 0 and blackcat on port 1, verify that EC does not watchdog reset. Change-Id: Ia81770e1cf4191205153aa3919290f6a5440ddf2 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1247638 Reviewed-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> (cherry picked from commit 720f1078aca231939147e9ed7c8b4ef3bfe84e89) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1812358 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* npcx7: UART: wait for Tx empty before enabling deep-sleepCHLin2019-09-124-2/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the original firmware (in the uart_buffering.c), it clears the SLEEP_MASK_UART immediately after it pushes all characters from its Tx buffer to UART's FIFO without checking the status of transmission. It may break the transmission because EC goes to deep sleep before UART TX (FIFO or shift register) becomes empty. This CL fixes it by: (1) Don't clear SLEEP_MASK_UART immediately when uart_tx_stop is called. (2) Enable the NXMIP (No Transmit in Progress) interrupt. (3) Clear SLEEP_MASK_UART in the UART interrupt handler when NXMIP is set. This fix only needs to apply to NPCX7 chips which have UART FIFO support. BRANCH=none BUG=b:137143640 TEST=No error for "make buildall" TEST=run 10 iterations of uart_stress_tester on yorp with command: ./util/uart_stress_tester.py /dev/ttyUSB2 -t 360; make sure no character lost in each iteration as below: ... INFO | UartSerial| /dev/ttyUSB2 | Detected as EC UART INFO | UartSerial| EC | Ready to test INFO | ChargenTest | Ports are ready to test INFO | ChargenTest | Test starts INFO | UartSerial| EC | Test thread starts INFO | UartSerial| EC | Test thread is done INFO | UartSerial| EC | 0 char lost / 4147200 (0.0 %) INFO | ChargenTest | PASS: lost 0 character(s) from the test INFO | ChargenTest | Test is done Change-Id: I97b1f572e8b9ebdb5102aa3e98ae2963d768b5b3 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1703944 Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Namyoon Woo <namyoon@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Commit-Queue: CH Lin <chlin56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1782399 Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Reviewed-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Commit-Queue: Karthikeyan Ramasubramanian <kramasub@chromium.org> (cherry picked from commit f3a3d893a581dc0c23dac210d836f54d6ddab337) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1783277 Tested-by: Matthew Blecker <matthewb@chromium.org> Reviewed-by: Bob Moragues <moragues@chromium.org> Reviewed-by: caveh jalali <caveh@chromium.org> Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Matthew Blecker <matthewb@chromium.org>
* atlas: Wake AP on DP AltMode Entry & AttentionCaveh Jalali2019-08-221-0/+15
| | | | | | | | | | | | | | | this is a cherry-pick of the nocturne specific patch https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1725249 applied to atlas. BUG=chromium:786721 BRANCH=firmware-atlas-11827.B TEST=verified atlas comes out of S0ix and uses external monitor on plugin Change-Id: Ia678c4438bbb7df271b91caf4786528f1934025b Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1763188 Reviewed-by: Caveh Jalali <caveh@google.com>
* atlas: Don't wake on any MKBP in suspend.Caveh Jalali2019-08-221-0/+1
| | | | | | | | | | | | | | | | this is a cherry-pick of the nocturne specific patch https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1724948 applied to atlas. BUG=chromium:786721 BRANCH=firmware-atlas-11827.B TEST=with rest of patch stack, verified atlas comes out of S0ix and uses external monitor on plugin Change-Id: I59904fc21d0a209ac8cf41a6d4d666bc1172fd74 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1762645 Reviewed-by: Caveh Jalali <caveh@google.com>
* ec_commands: Add EC_CMD_MKBP_WAKE_MASK.Aseda Aboagye2019-08-223-2/+244
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds a new host command, EC_CMD_MKBP_WAKE_MASK which allows the host to retrieve and set the MKBP host event wake mask along with the MKBP event wake mask. An accompanying console command, `mkbpwakemask` is present as well to view and adjust the wake masks. In order to use this host command, one of the following EC CONFIG_* options must be enabled in the EC: CONFIG_MKBP_HOST_EVENT_WAKEUP_MASK or CONFIG_MKBP_EVENT_WAKEUP_MASK. BUG=chromium:786721 BRANCH=None TEST=Deploy new version of ectool and EC firmware on nocturne, verify that ectool can view and adjust the wake masks. Verify that masks can be adjusted via the console command as well. Change-Id: I01a389ccd571328220eadd19ded4167dea8c6faa Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1700004 Reviewed-by: Jett Rink <jettrink@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Auto-Submit: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1724947 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1762643 Commit-Queue: caveh jalali <caveh@chromium.org> Tested-by: caveh jalali <caveh@chromium.org>
* pd_policy: Change DP AltMode event from host event to MKBP.Aseda Aboagye2019-08-223-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the EC could notify the AP that it had entered into DisplayPort Alternate mode by sending a MODE_CHANGE host event. However, there was no mechanism to disable that functionality if desired without effecting the other MODE_CHANGE events (i.e. - base attach/detach). By changing the DisplayPort Alternate mode entry to an MKBP event, we can have more granularity and only affect this single event. - This commit adds a new MKBP event, EC_MKBP_EVENT_DP_ALT_MODE_ENTERED. - The commit also changes the DP AltMode entry notification from sending a MODE_CHANGE host event to this new MKBP event. BUG=chromium:786721 BRANCH=None TEST=Build and flash nocturne, verify that system still wakes up on DisplayPort Alternate Mode entry. Change-Id: Ia5f294b26701c3c98c9b7f948fc693d26234c835 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1685787 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1724946 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1762642 Commit-Queue: caveh jalali <caveh@chromium.org> Tested-by: caveh jalali <caveh@chromium.org>
* common: pd_policy: Add notification for DP AltModeAseda Aboagye2019-08-223-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | This commit simply adds a notification that can be called when the device enters DisplayPort Alternate mode or a DP attention VDM is received. Calling the notification will send a MODE_CHANGE host event which may wake the AP. BUG=chromium:786721 BRANCH=firmware-nocturne-10984.B TEST=With other patches, flash nocturne; suspend DUT, plug in powered charge through hub, verify DUT wakes up. Change-Id: Iaa221e69060a7d1015f7c1e2f6f053e6810a674a Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1666366 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Auto-Submit: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1544249 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1762641 Commit-Queue: caveh jalali <caveh@chromium.org> Tested-by: caveh jalali <caveh@chromium.org>
* config: Add CONFIG_MKBP_EVENT_WAKEUP_MASKAseda Aboagye2019-08-222-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | This commit adds a new CONFIG_* option, CONFIG_MKBP_EVENT_WAKEUP_MASK. This allows a board to specify which MKBP events are allowed to wake the system when it is in suspend. BUG=b:136282898,chromium:786721 BRANCH=None TEST=With some other code, flash nocturne, suspend DUT, verify that only the MKBP events in the CONFIG_MKBP_EVENT_WAKEUP_MASK wake the system up. Change-Id: Ib4d04418aacab209d0e26703500df119924090b7 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1685785 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1724945 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1762640 Commit-Queue: caveh jalali <caveh@chromium.org> Tested-by: caveh jalali <caveh@chromium.org>
* cleanup: Rename CONFIG_MKBP_WAKEUP_MASK for clarity.Aseda Aboagye2019-08-224-23/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_MKBP_WAKEUP_MASK is a bit confusing and is wrongly named. The comment stated that "With this option, we can define the MKBP wakeup events in this mask (as a white list) in board level, those evets allow to interrupt AP during S3.". However, these events are NOT MKBP events at all but are instead host events. This commit tries to clear things up by renaming CONFIG_MKBP_WAKEUP_MASK to CONFIG_MKBP_HOST_EVENT_WAKEUP_MASK to better show that these events are in fact host events. BUG=b:136282898 BRANCH=None TEST=`make -j buildall` Change-Id: I42beadec8217435fd30e679ccf52d784a8ef99a0 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1685784 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Alexandru M Stan <amstan@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1724944 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1762639 Commit-Queue: caveh jalali <caveh@chromium.org> Tested-by: caveh jalali <caveh@chromium.org>
* atlas: remove dead BMI160 codeCaveh Jalali2019-08-201-8/+0
| | | | | | | | | | | | | | atlas does not have a BMI160, so remove legacy references to it. BUG=b:129078548 BRANCH=none TEST=compiles. Change-Id: Iadc3b9b885b4436f9e800110cd05d7d1f41b01cf Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1760877 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* ps8xxx: disable DCI modeCaveh Jalali2019-08-154-18/+110
| | | | | | | | | | | | | | | | | | | | | | | DCI mode is auto-enabled by default. we don't actually support DCI (intel specific SoC debug path), so we can explicitly disable DCI mode. doing so, saves about 40mW on the 3.3v rail when USB2 devices or USB-C to USB-A dongles are left plugged in. this is particulary relevant in sleep mode as this accounts for a significant portion of the system power consumption. BUG=b:119875949 BRANCH=none TEST=verified power consumption drops using sweetberry, USB devices still functional across suspend/resume. Change-Id: Id13630425c78965d2ac4f2e97715374ae0640d23 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1732231 Reviewed-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Caveh Jalali <caveh@google.com> (cherry picked from commit ce1a0c9bdfa0b35455b9619fdb1b5794caa63894) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1726826 Reviewed-by: Caveh Jalali <caveh@google.com>
* ps8xxx: stub out enter_low_power_modeCaveh Jalali2019-08-061-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the ps8751 really does not behave well with explicit low power mode commands - it enters low power mode on its own in about 2 seconds, so there's really no need to command it into low power mode. when the ps8751 is awake, it will take the low power command, but also generate an alert. when we try to read the alert register, it fails because the chip is in low power mode, so we go through the normal process of waking it up, including re-initializing the chip. we then process the alert and power down the chip again. but this time around the i2c transaction for the power down command fails (we don't check this status). the reason the i2c transaction failed is very likely because the chip processed the I2CIDLE command and didn't complete the i2c transaction. BRANCH=none BUG=b:137622553 TEST=verified chip still goes to sleep on its own Change-Id: I01b864791ae27a81a4512ddb752329e59be6a8c6 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1708034 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* atlas: Check DP MF-bit against selected pin cfgMatthew Blecker2019-08-051-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | When we are configuring a Type-C port for DisplayPort alternate mode, we should check to see that the selected pin config supports multi-function mode or not. This commit fixes a bug where we were setting the SuperSpeed muxes based solely upon the Multi-function Preferred bit in the DPStatus VDO. Some Type-C video adapters are buggy and set the MF preferred bit without actually supporting an MF pin configuration. Therefore, we trust the reported supported pin configurations in the DiscMode VDO. BRANCH=firmware-atlas-11827.B BUG=chromium:919756,b:138874110 TEST=Enable DRM debug by "echo 0xe > /sys/module/drm/parameters/debug" Monitor dmesg. Look for output indicating "Link training successful at 5400000 4 lanes". Look for monitor output at UHD4k60 on Acer B326HK using OSD. Change-Id: I946e601ed672031bc4606878531c561cf487a914 Signed-off-by: Matthew Blecker <matthewb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1736006 Tested-by: Nitin Kolluru <nkolluru@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Reviewed-by: Caveh Jalali <caveh@google.com> Reviewed-by: Nitin Kolluru <nkolluru@google.com>
* pd_protocol: Don't DRP toggle lower than S0.Aseda Aboagye2019-07-312-23/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently our USB PD protocol stack has "low power mode" tightly coupled with PD_STATE_DRP_AUTO_TOGGLE. In addition, it has the side effect of us dual role toggling (and resolving as sources) even though we have no intention of being a source. (e.g. DRP toggle in S0, once we suspend we're still toggling, even after shutting down to S5, we're still toggling.) This commit makes it such that we not dual role toggle in those lower power states, but instead behave properly as a sink and present only the Rd's. It also fixes a bug where if a port was previously sourcing in S0 and remained sourcing in suspend, if the sink was unplugged the port would be stuck presenting Rp's until a sink was plugged and unplugged again. BUG=chromium:902437 BUG=b:119055792 BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne, use twinkie verify port does not dual role toggle in suspend or off. TEST=Verify that TCPC goes into low power mode in SNK_DISCONNECTED. TEST=Verify that charging works in suspend and off. Reviewed-on: https://chromium-review.googlesource.com/c/1320909 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1667940 Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Commit-Queue: Scott Collyer <scollyer@chromium.org> Auto-Submit: Scott Collyer <scollyer@chromium.org> Change-Id: Ie44581a1a1a82cf29a786b57a71ce70760862ca2 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1708033 Commit-Queue: caveh jalali <caveh@chromium.org> Tested-by: caveh jalali <caveh@chromium.org>
* usb_pd_protocol.c: exiting from try.src to attach.srcRuibin Chang2019-07-312-10/+42
| | | | | | | | | | | | | | | | | | | | | | | | The port shall transition to Attached.SRC when the SRC.Rd state is detected on exactly "one of the CC1 or CC2 pins" for at least tTryCCDebounce. See TypeC v1.4 spec 4.5.2.2.10.2 Exiting from Try.SRC State. BRANCH=None BUG=b:130615676 TEST=1.Ampton with apple type-c adapter 2.Ellisys USB-PD test Reviewed-on: https://chromium-review.googlesource.com/1564499 Commit-Ready: Diana Z <dzigterman@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Change-Id: I461c53e2b8d9189f290956964754ae5b1a11a950 Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1708032 Tested-by: caveh jalali <caveh@chromium.org> Auto-Submit: caveh jalali <caveh@chromium.org> Commit-Queue: caveh jalali <caveh@chromium.org>
* usb: add inline helper method for CC linesJett Rink2019-07-243-35/+56
| | | | | | | | | | | | | | | | | | | | Expressing logic for CC lines can get very verbose. Add helper inline methods that logical describe the condition we are testing to clean up call sites. BRANCH=none BUG=none TEST=Builds, no functional change. Reviewed-on: https://chromium-review.googlesource.com/1589906 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Sam Hurst <shurst@google.com> Change-Id: I48c117437bc14f3c55473df7f7c778b55af2706d Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1708031 Tested-by: caveh jalali <caveh@chromium.org> Auto-Submit: caveh jalali <caveh@chromium.org> Commit-Queue: caveh jalali <caveh@chromium.org>
* pd_protocol: add hard_reset_complete_timerCaveh Jalali2019-06-152-55/+73
| | | | | | | | | | | | | | | | | | | | | | | | | certain chargers have noisy CC lines which can prevent overly sensitive TCPCs from detecting a bus idle state. this means the TCPC will not send out messages such as hard_reset. this condition may not clear which means our pd_task() will retry sending hard_resets. although we specify a "timeout" for the event loop in this state, the timeout can be ignored by the event wait when there are pending events. this gets us into a tight event processing loop that starves the watchdog! the solution is to add an explicit timeout timer when processing the PD_STATE_HARD_RESET_SEND state. BUG=b:134702480 BRANCH=none TEST=no more EC watchdog on affected systems Change-Id: I207323fd9cff06487c56e2edec5e9c30f4517ee3 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1654872 Commit-Queue: Bob Moragues <moragues@chromium.org> Reviewed-by: Bob Moragues <moragues@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* bip: Delete boardEvan Green2019-06-138-562/+1
| | | | | | | | | | | | | | | | | | | | | | | | | bip has an it8320bx with 256kB of flash space. After dividing by two and subtracting 0x800, this means the RO section of bip is 126kB. This is very tight. We've already removed a few commands to free up space, but this board hasn't been worked on since summer 2018. Delete it to avoid excessive maintenance burden. BUG=b:129283539 BRANCH=none TEST=make -j buildall Reviewed-on: https://chromium-review.googlesource.com/1536490 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Signed-off-by: Evan Green <evgreen@chromium.org> Change-Id: Iac903397dd653c8e012c8b3956807ba1bacf681e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1657429 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* atlas: Don't enter DP Alt Mode when AP is off.Aseda Aboagye2019-06-121-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | According to the DisplayPort Alt Mode on USB Type-C specification, if the DisplayPort Source device does not need to maintain HPD connectivity information prior to entering a low power state, the device shall exit the DP Alternate Mode. Previously, we were always entering DP Alt Mode regardless of the SoC state. When we are shutting the device down to S5 or G3, there's no need to monitor the HPD connectivity information. This commit simply does not enter DP Alt Mode when the SoC is off. BUG=chromium:927636 BRANCH=firmware-atlas-11827.B TEST=Flash atlas, shut DUT down to S5/G3, plug in a USB-C monitor that can also act as a Source, verify with PD analyzer that DUT does not Enter DP Alt mode, boot system up, verify that external display works. Change-Id: Ic465e4ecb73ba09388e3e4b665f526354bcedf6e Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1650621 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Bob Moragues <moragues@chromium.org> Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* pd_protocol: Add ready_state_holdoff_timer.Aseda Aboagye2019-05-221-17/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently a sink holdoff timer was added to the PD stack which allowed the state machine to prevent initiating any messages for 200ms after entering the SNK_READY state. This was to give time for some chatty sources to send messages to avoid a collision. Apparently, the same thing can happen when we are a source (collision with chatty sink). This commit reuses the holdoff timer for resolution as a source as well, which starts after an explicit contract is established. In order to prevent any potential new collisions, some jitter based off of the system timestamp is added to the holdoff timer. BUG=b:132202148, chromium:925618 BRANCH=firmware-atlas-11827.B TEST=Flash atlas, plug in a fully featured C-C cable between atlas and the LG 27UK850-W, verify that no conflict occurs and external display always works. TEST=Verify that no messages are initiated by the source within 200ms of sending PS_RDY. TEST=Flash nocturne, verify Dell U3818DW still works over C-C cable. TEST=Flash nocturne, verify CableMatters MST DP hub still works with charge through. TEST=Verify with Twinkie that messages are sent at varied timestamps between 200-300ms in the SNK/SRC_READY state. Change-Id: I195199de271950ae09c2b26194ddc5f271b296a0 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1600510 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org> (cherry picked from commit 7495960f1f6f780fa63a57b9caaddbb82bdd2a32) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1617217 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* board: atlas: Remove BMI160 supportGwendal Grignou2019-05-093-50/+1
| | | | | | | | | | | | | | | | | | Atlas may ship without IMU. hardware_features.xml indicates no IMU support (CL:*1168651 and CL:*1138132) Prevent EC to report IMU even if present. BUG=b:129078548 TEST=Compile BRANCH=atlas Change-Id: I600ef7268d7cea50164bf2e9fe7dd54d00329437 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1601879 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* pd_protocol: Keep Try.Src flag while debouncing.Aseda Aboagye2019-05-021-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PD_FLAGS_TRY_SRC flag was being cleared every time we entered the *_DISCONNECTED state. However, this would lead to a case where if the state machine was debouncing the CC lines and decided to re-enter the SRC_DISCONNECTED state, the Try.Src flag would be cleared and the state machine would not transition to the TryWait.SNK state after timing out. This commit simply keeps the Try.Src flag set if the previous state was a debounce as it means the state machine decided it didn't meet the condition to exit and should continue waiting before transitioning to TryWait.SNK. BUG=b:115452695 BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne; boot to S0, plug in Apple 87W USB-C charger with eMarked cable, verify we form an explicit 45W contract. Change-Id: I6d8f5d69b8bd0d25ac7af008bbbe91f2658cdfe2 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1286299 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> (cherry picked from commit 1f30c7483fa5621e9d67c5977709dce73f31a66d) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1592200 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* npcx: disable the selection of JTAG0 signals due to strapCHLin2019-05-0110-196/+271
| | | | | | | | | | | | | | | | | | | | | | | | It was observed that pressing recovery key combination + the other keys, some keys on the keyboard become invalid after system reboots. (see b:129908668 for more detail.) It is because the hardware strap pin for JTAG0 signals is unintentionally triggered. This CL reverts the selection of JTAG signals and set them back to keyboard scan function at system initialization. The revert applies to all real platforms except npcx_evbs. BRANCH=none BUG=b:129908668 TEST=pass "make buildall" TEST=Press the specific key combination, after the system reboots, the keyboard function works normally. On npcx EVBs, the JTAG0 is still functional. Change-Id: I7ede1ea4609466fea50a97b1f60308e4cdfd4544 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1586179 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* atlas: stop advertising tight-timestampsCaveh Jalali2019-04-301-0/+1
| | | | | | | | | | | | | | | | | atlas currently does not have a low jitter sensor timestamping mechanism, so use the recently added config option that disables the advertising a the low jitter feature to the AP. BUG=b:123700100,b:129084649,b:129086694 BRANCH=none TEST=system boots normally Change-Id: I2581d36f38531f227cca31d6ba5a23bedbc57829 Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1585599 Reviewed-by: Bob Moragues <moragues@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Commit-Queue: Gwendal Grignou <gwendal@chromium.org>
* driver: bmi160: Check enable_fifo flags before processing FIFOGwendal Grignou2019-04-261-13/+13
| | | | | | | | | | | | | | | | | | If there is an interrupt pending after we suspend the BMI160, we will try to collect length from the FIFO, but the FIFO is suspended. Bring back enable_fifo flags check before processing the FIFO. It has been move after gathering the length in CL:1128555 BUG=b:127321764,b:131272795 BRANCH=master TEST=Using flip_flop.sh script at b/131272795#comment2 Check the messages "unexpected empty FIFO" disappear. Change-Id: Iaab1a7f3607b902acd92b75c926365d7eb09fd5e Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1585420 Reviewed-by: Enrico Granata <egranata@chromium.org>
* board: atlas: Set Accel at 0Hz by defaultGwendal Grignou2019-04-261-9/+0
| | | | | | | | | | | | | | | Atlas does neither need accelerometer for lid angle nor orientation. Therefore put BMI160 in suspend when not needed by ARC++. BUG=b:131272795 BRANCH=master TEST=Check in EC console that sensor ODRs are 0 when host set frequency to 0. Change-Id: Ie7e103b2524313170503983f59dad3f523bb7f42 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1585419 Reviewed-by: Caveh Jalali <caveh@google.com>
* motion: Split configuration for sensor FIFO and tight timestampsEnrico Granata2019-04-263-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_ACCEL_FIFO was being used both to control the size of the sensor FIFO, and the notion of tight timestamps. The latter is related to the format the EC uses to send sensor event timestamps and not to the size of the FIFO. Split this latter portion into its own configuration flag, CONFIG_SENSOR_TIGHT_TIMESTAMPS. This defaults to enabled, and should be turned on for all new boards. It will be selectively disabled on a few boards where the AP-side filtering this enables does not perform optimally due to jitter issues. BUG=b:123700100 BRANCH=rammus TEST=observe tight_timestamps on the sensor_ring device in kernel be enabled/disabled depending on whether CONFIG_SENSOR_TIGHT_TIMESTAMPS is #undef'ed or not Change-Id: I806ba6bb45a0007512afec9151c57c60d30fd604 Signed-off-by: Enrico Granata <egranata@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1524666 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Alexandru M Stan <amstan@chromium.org> (cherry picked from commit 184410c9ee7530404813f5bd0a80a0a9d21f2a5a) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1584036 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* motion: Define macros for custom eventsGwendal Grignou2019-04-2629-49/+107
| | | | | | | | | | | | | | | | | | | Define macros to define custom events used by sensor interrupt handlers. Remove CONFIG_ for activity events. BUG=none BRANCH=none TEST=compile, sensors work on eve. Change-Id: I08ef6ed2a004466ebc5f7650d6952a150b9de713 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1272189 Reviewed-by: Jett Rink <jettrink@chromium.org> (cherry picked from commit 4b9a3c0cc9cee9ed85ba18dd2f9c23e90ca051fc) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1584657 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* motion: Wake up motion task when sampling rate changesGwendal Grignou2019-04-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Wake up motion task to evacuate pending samples to the host as soon as the sampling rate changes. It is required for CST testSanitizedContinuousEventsUidIdle to pass, it assumes only new samples will be present. BUG=b:111422556,b:124085261 BRANCH=eve TEST=cheets_CTS_P.9.0_r2.x86.CtsSensorTestCases passes on eve-arcnext. (cherry picked from commit e18316ecc7f7f6d7226fc741570a94c5024d42e8) Reviewed-on: https://chromium-review.googlesource.com/1217604 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Change-Id: I34e51c0db42fe1a8d5abc91c6d80bcce974da099 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1470773 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> (cherry picked from commit 0559c39dd30862f831d2db68564d675d110cf0dd) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1584035 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* motion: Change ODR only within the motion sensor taskGwendal Grignou2019-04-261-41/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When changing ODR for one sensor, we insert a timestamp in the FIFO. That timestamp can be misinterpreted by other sensor while in batch mode, condensing all events in a small timezone. Also, it can lead the motionsense stack to insert timestamp from the past. (cherry picked from commit f62f2ebbecb131956a5edc4bf60c094bc67972a1) Conflicts: common/motion_sense.c Integrate changes on top of CL/1450288. Now there is guarantee the ODR "flush" event is between 2 streams of sensor data with different ODR. BUG=b:111422556,chromium:562245,b:124085261 BRANCH=none TEST=Check cheets_CTS_P.9.0_r2.x86.CtsSensorTestCases pass on meep. Reviewed-on: https://chromium-review.googlesource.com/1204692 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Change-Id: If76aa3abcedbe463321ccbb1c183dc16edda8693 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1470772 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Enrico Granata <egranata@chromium.org> (cherry picked from commit 88976ba6340caf58a704d6eef8d60f17cc07eaf2) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1584655 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* motion_sense: send ODR events to the APEnrico Granata2019-04-262-6/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commits enables the EC to send a motion sense event to the AP when a sensor's ODR is changed. This is done in a way that is backwards compatible on the AP side, in order to enable previous kernels to continue to work (albeit at a loss of new functionality) with up-to-date ECs. Since clients are not required to use a FLUSH when changing ODR, it is possible for the sensor ring to get in a state where it is spreading based on out-of-date delay information, which we observed leading to spreading of overly large intervals, and thus too far into the future. This patch ameliorates that by causing an ODR change to implicitly flush the batching history. BUG=b:123700100 TEST=run CTS sensor tests, observe the sensor ring not spreading too far into the future due to a period change BRANCH=bobba Change-Id: I5a881e9fc5ddb1dbe6690c455d43dc20bffe889a Signed-off-by: Enrico Granata <egranata@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1450288 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> (cherry picked from commit bf646a9ebc3b9bf9cbf0ce64968204adf799ef2d) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1584654 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* driver: bmi160: Add temporary variable in decode_headerGwendal Grignou2019-04-261-7/+9
| | | | | | | | | | | | | | | | | | | | | Use a single variable instead of (s+i) to point to the sensor we are working on. BUG=chromium:917868 BRANCH=eve TEST=With ./mems_start_collection.sh, check samples are collected. Change-Id: Ib05059bea776aec978a8feb350f2dacb8aae7311 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1390940 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Enrico Granata <egranata@chromium.org> (cherry picked from commit a48a9cc46d08223d904e7df97da557b8e960c660) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1584034 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* FIXUP: sensor: Adjust max_frequency based on EC performanceGwendal Grignou2019-04-263-8/+4
| | | | | | | | | | | | | | | | | | | | Remove unnecessary code, sensor maximal ODR is guaranteed to be smaller than EC support maximial ODR. BUG=b:118205424,b:118851581,chromium:615059 BRANCH=none TEST=Check the limits have not change and an error is reported when frequency is set to high in sysfs. Change-Id: Ia10bf2cc58c5609c4fded16a0bff3018916a2346 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1390937 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> (cherry picked from commit f3931a6cd7a0c69e64caf87aa6ff3d9a4fdabf50) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1584653 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* driver: bmi160: Add setting calibration scaleGwendal Grignou2019-04-261-8/+40
| | | | | | | | | | | | | | | | | | | Implement get_scale, set_scale and apply the scale when normalizing. BUG=b:112957338 BRANCH=nocturne TEST=Check calibscale is taken into account on bmi160. Change-Id: I2c72053b026fe09798cd1009e77cc36c3c4fdac2 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1279186 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Enrico Granata <egranata@chromium.org> (cherry picked from commit 99adc669fb417eee09a85a5fda5106de0a923d6a) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1584033 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* atlas: let AP fully control display backlightCaveh Jalali2019-04-263-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | this change removes the EC from the display backlight control logic. previously, the EC would enable/disable the backlight master enable directly based on the lid switch. this turns out to be redundant and in some cases causes timing violations between backlight enable and the backlight PWM signal. the AP already controls the display power load switch (EN_PP3300_DX_EDP), so when the AP is off, display power (including the backlight) is also off. in addition, the AP correctly controls the backlight using PCH_EDP_BKLTEN. with this change, we're only removing the EC's master kill switch for the backlight. BRANCH=none BUG=b:129651119,b:128625720 TEST=verified no ill effects on atlas. EE scoped PWM vs. BL enable. Change-Id: Ibef9062ce66dfec1363626e674f144a1a3d55b5e Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1566482 Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* i2c:xfer i2cwrite invalid in ec consoleTony Zou2019-04-251-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | In command xfer i2cwrite port addr offset value 16bit offset and 8bit offset call the wrong i2c write interfacefix it. BRANCH=none BUG=b:126820386 TEST=1:) Build flapjack EC and flash to DUT , in ec console can read/write i2c device correctly. 2:) Build kukui EC , build pass. Change-Id: Ib3aa058ae0917fe62f38bc500a8227d6e36dbab1 Reviewed-on: https://chromium-review.googlesource.com/1496676 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Tony Zou <zoutao@huaqin.corp-partner.google.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit fa5900976db7b738a5bdb9f66fa56ce811b852d9) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1522848 Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com> Tested-by: Caveh Jalali <caveh@google.com>
* led_pwm: use NEAR_FULL_COLOR when discharging-on-acCaveh Jalali2019-04-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | when CONFIG_PWR_STATE_DISCHARGE_FULL is enabled for a board, the charge state machine can enter a special PWR_STATE_DISCHARGE_FULL state used to indicate that we're on AC but powering the system from the battery. the system will hover in-and-out of this state over time while on AC. this should generally be transparent to the user, so we should indicate it using the LEDs the same way we indicate PWR_STATE_CHARGE_NEAR_FULL. BUG=b:128709632 BRANCH=none TEST=verified LED stays white on atlas while battery is draining on AC. LED goes out when charger is removed Change-Id: I3af6783bcdbe399a444099fcee8ebab07451ff2c Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1570612 Tested-by: Caveh Jalali <caveh@google.com> Reviewed-by: Caveh Jalali <caveh@google.com> Commit-Queue: Caveh Jalali <caveh@google.com>
* atlas: remove obsolete commentCaveh Jalali2019-04-161-1/+0
| | | | | | | | | | | | | | | we're going to keep the ability to turn on the blue LED channel for testing the hardware, if nothing else. BUG=b:130447080 BRANCH=none TEST=no functional change Change-Id: Ibc30c0c39cbac4a539ea7fbd55d815f66d098a5a Signed-off-by: Caveh Jalali <caveh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1570610 Commit-Queue: Caveh Jalali <caveh@google.com> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
View Lorry Controller Status