summaryrefslogtreecommitdiff
path: root/board/nocturne
Commit message (Collapse)AuthorAgeFilesLines
* intel_x86/power: Consolidate chipset specific power signals arrayVijay Hiremath2019-06-132-23/+0
| | | | | | | | | | | | | | | Currently chipset specific power signals are defined at board/baseboard level. These power signals are moved to chipset specific file to minimize the redundant power signals array defined for each board/baseboard. BUG=b:134079574 BRANCH=none TEST=make buildall -j Change-Id: I351904f7cd2e0f27844c0711beb118d390219581 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1636837 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* TCPC: Make tcpc_config handle other bus typesDaisuke Nojiri2019-06-101-9/+10
| | | | | | | | | | | | | | | | | | | | | Currently, tcpc_config assumes TCPCs are on I2C bus. ITE's EC has an embedded TCPC. This patch adds bus_type field to struct tcpc_config_t so that a TCPC location on other type of bus can be specified. Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=none TEST=buildall Change-Id: Ieac733011700b351e6323f46070dcf46d9e1154b Reviewed-on: https://chromium-review.googlesource.com/1640305 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* common: motion_sense: Require CONFIG_MOTION_SENSOR_MAX_COUNTYuval Peress2019-06-051-0/+1
| | | | | | | | | | | | | | | This changes requires all boards to define the maximum number of sensors they support. This will allow us to later create static arrays with the appropriate length. BUG=chromium:966506 BRANCH=None TEST=make buildall Change-Id: I5a2fa8f0fdcaef69065dfd4c2bfea4e3f371e986 Signed-off-by: Yuval Peress <peress@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1637414 Reviewed-by: Jett Rink <jettrink@chromium.org>
* tcpm: Refactor tcpc_config to include a flags fieldScott Collyer2019-04-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | tcpc_config contained a field for both the alert polarity and open drain/push pull configuration. There is also a possible difference in TCPC reset polarity. Instead of adding yet another field to describe this configuration, it would be better to convert alert polairty, open drain and reset polarity into a single flags field. This CL modifies the tcpc_config struct to use a single flags field and adds defines for what existing flag options can be. BUG=b:130194031 BRANCH=none TEST=make -j buildall Change-Id: Ifb7e7604edb7021fb2d36ee279049eb52fefc99e Signed-off-by: Scott Collyer <scollyer@google.com> Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1551581 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org>
* ec.tasklist: Consolidate duplicate commentsDaisuke Nojiri2019-04-081-14/+1
| | | | | | | | | | | | | | | | | | | | | | | It's simply a bad idea to describe a macro in multiple locations. It'll make it hard to change. It'll be difficult to keep all locations in sync. This patch replaces the comment duplicated in all ec.tasklist with a pointer to the CONFIG_TASK_LIST definition. The macro will be described in a single place (just like all/most other macros). Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> BUG=none BRANCH=none TEST=buildall Change-Id: Id658b9d68e742e4334c692b804d9c98c8de21313 Reviewed-on: https://chromium-review.googlesource.com/1551579 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* common: bit change 1 << constants with BIT(constants)Gwendal Grignou2019-03-261-1/+1
| | | | | | | | | | | | | | | | | Mechanical replacement of bit operation where operand is a constant. More bit operation exist, but prone to errors. Reveal a bug in npcx: chip/npcx/system-npcx7.c:114:54: error: conversion from 'long unsigned int' to 'uint8_t' {aka 'volatile unsigned char'} changes value from '16777215' to '255' [-Werror=overflow] BUG=None BRANCH=None TEST=None Change-Id: I006614026143fa180702ac0d1cc2ceb1b3c6eeb0 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1518660 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* common: replace 1 << digits, with BIT(digits)Gwendal Grignou2019-03-261-5/+5
| | | | | | | | | | | | | | | | Requested for linux integration, use BIT instead of 1 << First step replace bit operation with operand containing only digits. Fix an error in motion_lid try to set bit 31 of a signed integer. BUG=None BRANCH=None TEST=compile Change-Id: Ie843611f2f68e241f0f40d4067f7ade726951d29 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1518659 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* nocturne: Check DP MF-bit against selected pin cfgAseda Aboagye2019-03-261-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. BUG=chromium:919756 BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne, plug in Insignia NS-PU369CH-WH USB-C to HDMI adapter, verify that 4k60 display is shown. TEST=Plug in Belkin dock which supports SuperSpeed ports, verify that SuperSpeed ports work and display is shown at 4k30. Change-Id: I9febb007edc5392a6172e4709482981dbcbdc8b7 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1404136 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1530127 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Set up SBU FETs properly.Aseda Aboagye2019-03-263-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | The SBU FET control should be tied to entering/exiting DP Alt Mode and not the USB MUX position as the previous commit had. However, the SBU lines are also used for CCD and the older boards don't have the necessary hardware. BUG=b:114340064 BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne; verify that external display works after a reboot. Verify that cr50 is enumerated using SuzyQable. TEST=Repeat above test on board rev 1. Change-Id: I5ab9123816fa6ef946dde95b421c5b89bd9719a4 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1250028 Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1405611 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* motion: Define macros for custom eventsGwendal Grignou2019-03-201-2/+4
| | | | | | | | | | | | | | 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>
* mkbp_event,include/config.h: Clarify MKBP delivery method.Yilun Lin2019-03-072-20/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now we have two MKBP delivery methods: 1. define CONFIG_MKBP_USE_HOST_EVENT to notify via host event 2. undef CONFIG_MKBP_USE_HOST_EVENT to notify via GPIO interrupt It may become more complicated if new notification methods introduced. e.g.: mt_scp uses IPI, rather than host event and GPIO interrupt. This CL does: 1. add CONFIG_MKBP_USE_GPIO to explicilty declare that MKBP event are sent via GPIO interrupt. 2. CONFIG_MKBP_USE_CUSTOM for boards which have custmized methods. 3. Remove weak attribute in mkbp_set_host_active (which can be done with CONFIG_MKBP_USE_CUSTOM now. 4. Removes mkbp_set_host_active function in board Nocturne. It only deliver MKBP events through GPIO interrupt now. BRANCH=None BUG=b:120808999 TEST=grep -rn "CONFIG_MKBP_USE_GPIO\|EC_INT_L" board/ baseboard/ and see the result is reasonable: 1. EC_INT_L must be 1-to-1 mapped to define CONFIG_MKBP_USE_GPIO in every board, except that meep, yorp, ampton which are defined in baseboard octopus. 2. undef CONFIG_MKBP_USE_GPIO in bip and casta, which use host event, but also have baseboard octopus. Change-Id: I4af6110e4fd3c009968075c3623ef2d91cbd770b Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1490794 Commit-Ready: Jett Rink <jettrink@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* nocturne: Discharge on AC when changing chg portsAseda Aboagye2019-02-191-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a charger is plugged in and a higher power charger is plugged into the other port, nocturne will switch to actively charge from the higher power charger. However, during this time, the charger IC is still switching which puts a large load on the input path. While opening the FET to the higher power charger, this load can cause an overcurrent event and some chargers will latch off due to this overcurrent event. This commit simply stops the charger IC from switching while we are switching charge ports. BUG=chromium:926056 BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne, plug in Suzy-Q, verify that DUT is charging, plug in Apple 87W charger, verify DUT switches to Apple charge port and is charging and no overcurrent event is seen. TEST=Hibernate nocturne. Plug in charger, verify that DUT boots and is charging. TEST=Cutoff nocturne. Plug in charger, verify that DUT boots and is charging. Change-Id: I1287c273ad6f7ce7ebfedef6224bd45faa66eb4f Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1474746 Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 7a08e07eb6653422b43ca20bd0760da45564d574) Reviewed-on: https://chromium-review.googlesource.com/1476292 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Check IRQ and HPD in DPStatus message.Aseda Aboagye2019-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Per the VESA DisplayPort Alt Mode on USB Type-C spec, IRQ_HPD indicates that a high to low followed by a low to high transition was detected. Therefore, we should be checking when IRQ is high and HPD is low is received as that is an error. This commit fixes that bug where were comparing our level to the GPU instead of what was shown in the PDO. BUG=none BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne, plug in Apple Multiport AV USB-C adapter, verify that external display works. Change-Id: I536dd0d2556794411eb8d54a9a0c34f61fff5253 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1422458 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Benson Leung <bleung@google.com> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> (cherry picked from commit 3ed2914348316dd04a4eede7d2f7b1ce0f9434b1) Reviewed-on: https://chromium-review.googlesource.com/1422460 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* USB PD: PPC: Add overcurrent handling.Aseda Aboagye2019-01-171-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Type-C Power Path Controllers provide overcurrent protection. This commit adds support into the USB PD task for overcurrent events while we are in source role. The USB PD 3.0 spec recommends that ports issue a hard reset when an overcurrent condition occurs on a port. Additionally, we'll allow a source port to overcurrent 3 times before latching off VBUS from the port entirely. The source path will be re-enabled after ~1s after each overcurrent event. BUG=b:69935262,b:114680657 BRANCH=None TEST=Boot to ChromeOS in grabbiter. No overcurrent events reported when the sink is drawing <= 3.20 A. Overcurrent events are reported when the sink is drawing > 3.25 A. After 3 reports, the port is latched off and power delivery is stopped. The port is re-enabled only after the sink is disconnected. Also when the sink is drawing current at 3.24 A, there is one report of overcurrent. The port gets disabled in response to that event. But the port is re-enabled after 1 second since overcurrent event is reported only once. After the port is re-enabled, the sink is able to draw the set current. When the overcurrent event is reported, I can see in the kernel logs that the overcurrent condition is detected by the kernel. EC Logs: [3391.984462 C1: PPC detected Vbus overcurrent!] [3391.984953 C1: overcurrent!] [3392.044935 C1: PPC detected Vbus overcurrent!] [3392.045425 C1: overcurrent!] [3392.061404 C1: PPC detected Vbus overcurrent!] [3392.061894 C1: overcurrent!] [3392.062142 C1: OC event limit reached! Source path disabled until physical disconnect.] [3392.077226 C1: PPC detected Vbus overcurrent!] [3392.077532 C1: overcurrent!] [3392.077891 C1: OC event limit reached! Source path disabled until physical disconnect.] [3392.092660 C1: PPC detected Vbus overcurrent!] [3392.092966 C1: overcurrent!] [3392.093213 C1: OC event limit reached! Source path disabled until physical disconnect.] Kernel Logs: [ 3356.560456] usb usb2-port1: over-current condition [ 3356.768434] usb usb2-port2: over-current condition [ 3356.976446] usb usb2-port4: over-current condition [ 3357.184441] usb usb2-port5: over-current condition [ 3357.392445] usb usb2-port6: over-current condition Change-Id: Ib070f261e98264cd88725ebce7d10e0798267e3b Signed-off-by: Aseda Aboagye <aaboagye@google.com> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1286300 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Commit-Queue: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/807633 Commit-Ready: Karthikeyan Ramasubramanian <kramasub@chromium.org> Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Raise ATTACH_MAX_MV to 900.Aseda Aboagye2019-01-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | There are some devices where when connected to whiskers, the base attach ADC reading is right on the threshold for max. This may cause whiskers to not be powered appearing as the keyboard not working. This commit simply increases the threshold to 900mV to allow more whiskers to be detected. BUG=b:122361740 BRANCH=firmware-nocturne-10984.B TEST=`make -j buildall` Change-Id: I10e2d58e5277abdd28a50a3aca3ef0f26d93aeba Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1399186 Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 845edf693b9fc305a74ec4baa4b238c144dcc0d1) Reviewed-on: https://chromium-review.googlesource.com/1409493 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Discharge VBUS when stopping sourcing.Aseda Aboagye2018-12-201-1/+7
| | | | | | | | | | | | | | | | When the source power path is turned off, we should discharge VBUS. BUG=none BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne, PR_SWAP, verify that VBUS is discharged instead of floating during the swap. Change-Id: I30cbb85cefc70ef161853758ece57b324eab0014 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1385445 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Log base power fault cause.Aseda Aboagye2018-12-041-1/+2
| | | | | | | | | | | | | | | | | | | | A base power fault can be triggered by either the eFuse or the USB protection chip. This commit logs the source of the base power fault. BUG=none BRANCH=firmware-nocturne-10984.B TEST=make -j buildall Change-Id: I1082d56fef2c0b1b2963f2af98216e455e7ab958 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1358747 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 7836cdd6e6ce3ab11d49add01a91a59aa03057de) Reviewed-on: https://chromium-review.googlesource.com/1360073 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Change FIFO settingsEnrico Granata2018-11-291-2/+2
| | | | | | | | | | | | | | | | | | | | | Overly large sensor batches lead to timestamp synchronization issues on Nocturne, causing - among others - CTS to sometimes fail the sensor batching tests. Reduce the size of the FIFO and restore the threshold to being a third of the size. This value was changed in CL:1134494 in an attempt to solve a problem which turned out to be unrelated. BUG=b:117169255, b:73551961, b:120100420, b:120098451 BRANCH=nocturne TEST=run CTS sensor test cases, observe them pass Change-Id: Ia27bfe0a4756c22d4e48ba525d585ff11ab1cb63 Signed-off-by: Enrico Granata <egranata@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1354484 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>
* usb-c: use higher priority task for interruptsJett Rink2018-11-141-4/+14
| | | | | | | | | | | | | | | | | This should be the last step to make all boards on ToT follow go/usb-pd-slow-response-time. Theses boards all have the higher priority tasks, but they aren't being used since the tcpc interrupt wasn't scheduling calls on it. BRANCH=none BUG=b:112088135 TEST=builds Change-Id: I2c39e661e804f88edd5b34636b93e6e63a5af57f Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1283452 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: enable GPIO-based MKBP event notificationEnrico Granata2018-10-123-2/+23
| | | | | | | | | | | | | | | | | | | This commit configures nocturne to send MKBP events over GPIO for boards with ID >= 2, as well as over the existing host event path. This latter notification is sent for legacy compatibility purposes, largely with existing depthcharge behavior. BUG=b:112366846, b:112112483, b:112111610 TEST=physical buttons work in depthcharge + MKBP events come in on Nocturne via GPIO interrupt with no significant jitter change BRANCH=none Change-Id: I95668ab1140f1c1e6397fae42f5dc6103b404956 Signed-off-by: Enrico Granata <egranata@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1247343 Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* nocturne: Only advertise Rp-1.5A for sourcing.Aseda Aboagye2018-10-101-1/+0
| | | | | | | | | | | | | | | | | | BUG=b:117566802 BRANCH=firmware-nocturne-10984.B TEST=Flash nocturne; verify that 5V/1.5A SourceCaps are sent. Verify that Rp1.5A is advertised. Change-Id: Ibc5a45fb15ed5f50ac8609985c4de764c2e59503 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1274018 Reviewed-by: Benson Leung <bleung@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> (cherry picked from commit d118ba10a0d5dfae118e85a898f2b467b41e79ff) Reviewed-on: https://chromium-review.googlesource.com/1274906 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* ss-mux: remove unused port_addr initializationv2.0.0Jett Rink2018-09-171-3/+0
| | | | | | | | | | | | | | | | | | | We do not need to set the port_addr variable most places because the SS-MUX is also the TCPC and the tcpc_config_t information is used instead. Remove unused variable setting to avoid confusion. BRANCH=none BUG=none TEST=buildall. phaser USB-C communication (and muxs) still work which is a nominal case for all of these changes. Change-Id: I72ee5da251956eb133091974e8dce5ac7f8787c6 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1200064 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Edward Hill <ecgh@chromium.org>
* usb-c: add high priority tasks for interruptsJett Rink2018-09-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To all boards that have space, add the PD tasks that handle interrupts in parallel. This is the last change for go/usb-pd-slow-response-time. BRANCH=none BUG=b:112088135 TEST=buildall. This works on grunt and octopus. This CL is more of a clean up for ToT to ensure that newly copied boards use the correct paradigm. Below is the space taken up by this change: build/atlas/RW/space_free_flash shrank by 212 bytes: (64796 to 64584) build/atlas/RW/space_free_ram shrank by 1408 bytes: (33568 to 32160) build/cheza/RW/space_free_flash shrank by 200 bytes: (205716 to 205516) build/cheza/RW/space_free_ram shrank by 1408 bytes: (38208 to 36800) build/coral/RW/space_free_flash shrank by 212 bytes: (87980 to 87768) build/coral/RW/space_free_ram shrank by 1400 bytes: (2564 to 1164) build/dragonegg/RW/space_free_flash shrank by 276 bytes: (142136 to 141860) build/dragonegg/RW/space_free_ram shrank by 1640 bytes: (24704 to 23064) build/elm/RW/space_free_flash shrank by 204 bytes: (24644 to 24440) build/elm/RW/space_free_ram shrank by 528 bytes: (8972 to 8444) build/eve/RW/space_free_flash shrank by 216 bytes: (83748 to 83532) build/eve/RW/space_free_ram shrank by 1408 bytes: (1824 to 416) build/fizz/RW/space_free_flash shrank by 184 bytes: (17576 to 17392) build/fizz/RW/space_free_ram shrank by 736 bytes: (11648 to 10912) build/glkrvp/RW/space_free_flash shrank by 248 bytes: (92432 to 92184) build/glkrvp/RW/space_free_ram shrank by 1408 bytes: (45088 to 43680) build/kukui/RW/space_free_flash shrank by 160 bytes: (32364 to 32204) build/kukui/RW/space_free_ram shrank by 520 bytes: (11260 to 10740) build/meowth/RW/space_free_flash shrank by 240 bytes: (72232 to 71992) build/meowth/RW/space_free_ram shrank by 1408 bytes: (34496 to 33088) build/nami/RW/space_free_flash shrank by 360 bytes: (82016 to 81656) build/nami/RW/space_free_ram shrank by 1408 bytes: (2656 to 1248) build/nocturne/RW/space_free_flash shrank by 216 bytes: (62756 to 62540) build/nocturne/RW/space_free_ram shrank by 1408 bytes: (34368 to 32960) build/rainier/RW/space_free_flash shrank by 180 bytes: (45468 to 45288) build/rainier/RW/space_free_ram shrank by 528 bytes: (13516 to 12988) build/rammus/RW/space_free_flash shrank by 200 bytes: (91284 to 91084) build/rammus/RW/space_free_ram shrank by 1408 bytes: (1920 to 512) build/reef_mchp/RW/space_free_flash shrank by 212 bytes: (51048 to 50836) build/reef_mchp/RW/space_free_ram shrank by 2120 bytes: (27420 to 25300) build/reef/RW/space_free_flash shrank by 224 bytes: (84564 to 84340) build/reef/RW/space_free_ram shrank by 1408 bytes: (2208 to 800) build/rowan/RW/space_free_flash shrank by 204 bytes: (29668 to 29464) build/rowan/RW/space_free_ram shrank by 528 bytes: (9300 to 8772) build/scarlet/RW/space_free_flash shrank by 156 bytes: (29464 to 29308) build/scarlet/RW/space_free_ram shrank by 520 bytes: (11100 to 10580) build/zoombini/RW/space_free_flash shrank by 276 bytes: (66816 to 66540) build/zoombini/RW/space_free_ram shrank by 2112 bytes: (37376 to 35264) Compared 208 of 208 files. 38 files changed. Total size change: -27484 bytes. Average size change: -723 bytes. Change-Id: Ifbea67ee4d460fb197a1601d0951169f2f2b5b3b Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1220667 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
* base_detect: Expose console command to force state.RaviChandra Sadineni2018-09-132-2/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In an effort to test wake sources on any given platform, this CL exposes console command to set the base state. This console command can then be invoked by autottests from the uart interface. We have two implementations for managing base status. One is interrupt driven while the other is a polling via a task. Boards current implementations then are: interrupts: lux, soraka, cheza polling task: nocturne, zoombini For forcing base connect and disconnect, interrupts: Disable interrupts and set forced base state. polling task: Stop periodic task and set forced base state. On reset, interrupts: Schedule deferred task immediately and enable interrupts. polling task: Clear forced base state and begin rescheduling periodic task. Signed-off-by: RaviChandra Sadineni <ravisadineni@google.com> BRANCH=poppy,nocturne BUG=chromium:820668, b:37223093 TEST=Tested on lux, soraka and nocturne basestate a : attaches the lid, reflected in ui. basestate d : detaches the lid, reflected in ui. basestate r : resets to the correct state. Wakes the device up on lux and nocturne and soraka. Change-Id: Iab698e103a50b8d22bf216a6f816998cb158e38a Reviewed-on: https://chromium-review.googlesource.com/1184172 Commit-Ready: Ravi Chandra Sadineni <ravisadineni@chromium.org> Tested-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* type: Rename matrix_3x3_t to mat33_fp_tYilun Lin2018-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Naming of many vector types and matrix types are not clear enough. For example, we have: vector_3_t, which is a vector of three int. vec3_t, which is a vector of three float. size4_t, which is a vector of four size_t. mat33_t, which is a 3x3 matrix of float. matrix_3x3_t, which is a 3x3 matrix of fixed point. Besides, we have types like int8_t, uint16_t types. To clearly distinguished types, the CL propose to, For vector types, naming should be `$type + 'v' + $num + '_t'`: vector_3_t becomes intv3_t vec3_t becomes floatv3_t vector 4 of uint16_t becomes uint16v4_t (which doesn't exist yet) For matrix types, naming should be `mat$N$N_` + $type + '_t', where $N is the matrix size: matrix_3x3_t becomes mat33_fp_t # fp: fixed point mat33_t becomes mat33_float_t TEST=make buildall -j BUG=b:114662791 Change-Id: I51d88d44252184e4b7b3564236833b0b892edc39 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1215449 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* nocturne: Use USBC alert signal for TCPC alert statusScott Collyer2018-08-311-10/+14
| | | | | | | | | | | | | | | | | | | | | | | Because the TCPC and PPC share a common interrupt signal, the TCPC alert register must be read to know when to process alerts for the TCPC. However, the interrupt signal can be used to know which port to check and prevent interrupts from one port causing the TCPC on another port from being pulled out of low power mode unecessarily. This CL adds a check of the USBC interrupt line level to know which TCPC to check. BUG=b:112039224 BRANCH=nocturne TEST=Verifed that connecting to 1 of the ports no longer causes the other port to exit/enter low power mode. Change-Id: I70384a1fc8f1cc03ad81e694a4246e0cb284375f Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1196044 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: switch from tablet mode to base state reportingDmitry Torokhov2018-08-312-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | On these devices we can't decide whether we should go in/out tablet mode solely because base was attached or detached. Let's report the new "base attached" event so that upper layers can figure the state properly. Note that we disable CONFIG_DPTF_DEVICE_ORIENTATION switch since it requires CONFIG_TABLET mode which we disable as well. That means that EC_ACPI_MEM_DEVICE_ORIENTATION will always return '0', which should be fine, as it is used by the TBMC (Tablet Motion Control) device which is not enabled on Nocturne. Note that base attach/detach events, like tablet mode switch events, will still wake up the AP as handles base state transitions always notifies host of attach/detach events. BUG=b:73133611 BRANCH=nocturne CQ-DEPEND=CL:1183972,CL:1187120 TEST=Build and boot Change-Id: Ide0693a50f041be876f42295bccf2896a13a625c Signed-off-by: Dmitry Torokhov <dtor@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1180539 Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Remove CONFIG_SYSTEM_UNLOCKED.stabilize-11005.BAseda Aboagye2018-08-251-3/+0
| | | | | | | | | | | | | | BUG=b:113127952 BRANCH=firmware-nocturne-10984.B TEST=Enable HW/SW WP, plug in a PD charger, verify no PD communication is done in RO. Change-Id: Idc9219c70662b1b51e228863e2bd51a72cecb2b1 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1188929 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* nocturne: Enable CONFIG_I2C_BUS_MAY_BE_UNPOWEREDAseda Aboagye2018-08-222-0/+10
| | | | | | | | | | | | | | | | The sensor power rail is unpowered in S5, therefore enable this config option. BUG=b:111683988 BRANCH=Nocturne TEST=Verify that board_is_i2c_port_powered() is called. Change-Id: I5605c860efc61307627f7aff270e2a1414ded57b Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1182878 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* nocturne: Turn on UHALL_PWR_EN by default.Aseda Aboagye2018-08-181-1/+1
| | | | | | | | | | | | | | | | UHALL_PWR_EN needs to be enabled when the EC comes out of reset so that the top hall sensor is active when the EC boots. BUG=b:112110598 BRANCH=None TEST=Verify after EC reset that UHALL_PWR_EN is high. Change-Id: If0370dc462cb74b3f1b9bfb67aff7b9bc9c6e261 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1180493 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Enable TCPC low power modePuthikorn Voravootivat2018-08-171-0/+2
| | | | | | | | | | | | | | | BUG=b:112037915 BRANCH=none TEST=Lower power in S0ix "TCPC Enter Low Power Mode" log in ec console TCPC exit/enter low power mode when plug/unplug charger Change-Id: Iff44a3a54c3bb44b4d1d3f6ffa9c83689175e5ed Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1168110 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Control UHALL_PWR_EN based on lid state.Aseda Aboagye2018-08-172-1/+13
| | | | | | | | | | | | | | | BUG=b:112110598 BRANCH=None TEST=Flash nocturne; verify board still boots. Check that the logic would do the right thing if the board version matched. Change-Id: I39bd7eb6f3d73dde4c42b3abfbb38d0de424dcf5 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1179314 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* nocturne: Enable low power idlePuthikorn Voravootivat2018-08-171-0/+1
| | | | | | | | | | BUG=b:112037915 TEST=25mW lower in s0ix Change-Id: Ie7e6c3e3d1372f64730d322864e4315afdf7c2e6 Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1178973 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Add board_set_tcpc_power_mode().Aseda Aboagye2018-08-172-0/+12
| | | | | | | | | | | | | | | | | | | | When depthcharge needs to update the TCPCs, it needs to reset them at the end of the update procedure. Conveniently, this function will be called if it exists, therefore this commit implements that function. It simply resets the TCPCs and then waits about 50ms for the part to come up. BUG=b:69010531 BRANCH=None TEST=With other patches, flash nocturne; verify that TCPC FW can be updated. Change-Id: Ie3dfd913b376a60fbf8de4c9f53cc9c6a497aa19 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1173024 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Caveh Jalali <caveh@google.com>
* servo_v4: add per port dualrole settingNick Sanders2018-08-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This adds support to configure dualrole setting per port, so that servo v4 can adjust charge and dut port separately. servo will detect charge capability on CHG port and choose source or sink as appropriate. Fix null dereference bug in genvif duel to dynamic src_pdo. "cc" command allows src, snk, srcdts, snkdts configurations. BRANCH=None BUG=b:72557427 TEST=charge through and also passive hub. Note Dru doesn't accept DTS hub. TEST=make buildall -j Change-Id: I19f1d1a5c37647fec72202191faa4821c06fb460 Signed-off-by: Nick Sanders <nsanders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1096654 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Change RCAM_VSYNC to rising edge.Aseda Aboagye2018-08-151-1/+1
| | | | | | | | | | | | | BUG=b:111282744 BRANCH=None TEST=`make -j BOARD=nocturne` Change-Id: I2588291e4daf336ad9365bc21faef0761386c989 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1175542 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* nocturne: Flip board version reporting.Aseda Aboagye2018-08-151-5/+5
| | | | | | | | | | | | | | | | | | | It turns out that BRD_ID3 was not actually the least significant bit in the board version strapping. In actuality, it turned out to be BRD_ID0. This commit simply flips the board version reporting to have BRD_ID0 to be the least significant bit. BUG=b:73260349 BRANCH=None TEST=Flash nocturne; verify that board revision match up with board version table in the schematics. Change-Id: I8a3f3e3dbb5dbdcbdd55793d55c711d8ec9670a4 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1175557 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Update sensor active mask to include S3.Aseda Aboagye2018-08-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, the active_mask member in motion_sensor_t was set to the S0 for all the sensors. Although the sensors are only used in S0, this value should reflect the actual power state of the sensor. The config members describe the power states when the EC intends to use the sensor. This combination was causing the sensors to not have their calibration data applied following a suspend/resume cycle. This commit updates the active mask to include S3 thereby keeping the calibration settings across a suspend resume cycle. BUG=b:112462750, b:111815348 BRANCH=None TEST=Flash nocturne; set calibration attributes in VPD, reboot, verify that calibration attributes are applied. Suspend/resume, verify that the calibration attributes are still applied. Change-Id: Iad632e3bb6f61b056015ca8c9d90b0f9d7c58c5e Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1171258 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org>
* nocturne: set default ALS calibrationPuthikorn Voravootivat2018-08-091-1/+2
| | | | | | | | | | | | | | | | Use average of factory number as default ALS calibration data. This would normally get overridden by per-device calibration data from VPD but it is still useful to have default value for device that does not have VPD or VPD got erased. BUG=b:111528815 TEST=watch -n 1 grep . /sys/bus/iio/devices/*/in_il*_{raw,calib*} Change-Id: Ieb63beafa6c1d91157f265f445f6d96da00ffc8c Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1170023 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* nocturne: Dynamically disable effect of SLP_S0# on all VRsPuthikorn Voravootivat2018-08-071-2/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just setting the global VRMODECTRL register is not enough to disable the effect of SLP_S0# signal. Each VR control register needs to be set correctly to ignore the effect as well. However, disabling VR decay on SLP_S0# assertion by default results in additional power consumption during S0ix. In order to prevent this, VR decay on SLP_S0# assertion needs to be enabled and disabled dynamically as follows: 1. By default on EC boot, PMIC will be initialized to disable VR decay on SLP_S0# assertion. 2. When host indicates intent to enter S0ix, EC will enable decay of VRs on SLP_S0# assertion. 3. When host exits from S0ix and updates the intent to no longer enter S0ix using host command, EC will disable decay of VRs on SLP_S0# assertion. actual SLP_S0# assertion because PMIC seems to honor the setting only at SLP_S0# assertion and not if it is already asserted. BUG=b:112037915 BRANCH=None TEST=pp975_io power near zero in S0ix Change-Id: Iadf12203ac7dbd0adc2d050eab8fbb1839f9902f Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1162776 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Enable active discharge on V1.8A & V3.3AAseda Aboagye2018-08-031-0/+3
| | | | | | | | | | | | | | | | These A rails were taking a long time to discharge, so enable active discharge on these rails. BUG=b:109936333 BRANCH=None TEST=Verify that the V3.3A and V1.8A rails quicker than before. Change-Id: Ib048e41b9da429f882cd5ee9192e37a44f60f18f Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1155843 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: David Herrig <dherrig@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Set OTG pins on UFP for Port 0.Aseda Aboagye2018-07-311-1/+10
| | | | | | | | | | | | | | | | | Nocturne supports OTG on port 0 only. This commit sets the ID and VBUS sense pins to high when port 0 is a UFP and low otherwise. BUG=b:111963814 BRANCH=None TEST=Flash nocturne; plug in A-to-C cable; verify that USB2_ID and USB2_VBUSSENSE are high. Change-Id: I40280b120959aa1fafe13e7e4fd63b2e201040da Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1155984 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Tie batt disconnect state to DSG FET status.Aseda Aboagye2018-07-301-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | battery_get_disconnect_state() and the way that it is used in the EC code base essentially means "can the battery provide a charge?". This can be tied to the battery's discharge FET status. If the discharge FET is disabled, the battery cannot provide power to the system. This commit changes the decision to report the battery as disconnected to solely rely on the discharge FET status. Previously, we've seen issues where the charge FET was enabled, but the discharge FET was disabled due to a cell undervoltage issue. The EC would consider the pack as not "disconnected". However, this would signal to the system that the battery could provide charge, but in actuality it couldn't. BUG=b:76121712 BRANCH=None TEST=Flash nocturne; cutoff pack, apply AC, verify pack wakes up. Change-Id: I394278828c1c96112579ac84544655c3a1818e3d Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1152553 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org>
* nocturne: Enable sensor IRQs in S0.Aseda Aboagye2018-07-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | The IMU is powered off in states lower than S0, therefore the interrupts are disabled by default in order to prevent false assertions and are only enabled when sequencing up to S0. However, after the EC sysjumps to its RW image, the interrupts were disabled causing the IMU to return values of 0 on the first boot. This commit simply re-enables the sensor interrupts at hook INIT time if the system is in S0. BUG=b:111458025 BRANCH=None TEST=Flash nocturne, sysjump to RW, use ectool motionsense to see that accelerometer values can be seen in userspace. Change-Id: Ie9b2be6f1690a0d5d98c14b117c036880ce1f914 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1150932 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Enable DPTF support.Aseda Aboagye2018-07-251-0/+2
| | | | | | | | | | | | | BUG=b:111803637 BRANCH=None TEST=Flash nocturne; boot to OS; verify that DPTF thresholds are set. Change-Id: I05dbbb5ca6a1fa23cea201a638414c70cefb13fd Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1149419 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Restart base detection in S3.Aseda Aboagye2018-07-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | Previously, the base detection state machine was restarting in S5, however if the state machine ran through its loop and the system had not transitioned to S3 yet, the state machine may have been disabled. This commit simply changes the point which the state machine is restarted from S5 to S3. Since it's active in S3 and higher, we should avoid that case of having the state machine being disabled when the system is up. BUG=b:111417839, b:111540121 BRANCH=none TEST=shut device down, attach base, boot to S0, verify that base is always detected. Change-Id: I1b4a44b248732d3242ca0630668db3544de22793 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1148554 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Don't read gyro temp sensor in <= S5.Aseda Aboagye2018-07-191-1/+14
| | | | | | | | | | | | | | | | | | | | | The gyro is not powered in S5 or lower, therefore we should not return any temperature value for those power states. BUG=none BRANCH=master TEST=flash nocturne, shut AP down, verify no prints are emitted about i2c unwedging. Change-Id: I3bcc1efca40b27ec571657274aab69dca4e414d7 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1132900 Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> (cherry picked from commit 988468d17c8912c0f9a5345996b34f8848fdb739) Reviewed-on: https://chromium-review.googlesource.com/1142924 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Adjust IMVP8 step decay quantization.Aseda Aboagye2018-07-181-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | The IMVP8 vendor suggested to change the step decay quantization from 3 to 1. Doing this seems to help with the hangs that were seen. This commit simply has the EC write to the IMVP8 to set this register ~250ms after sequencing to S0. BUG=b:111224125 BRANCH=master TEST=Flash nocturne, boot to S0, read back register 0xFA from IMVP8, verify that it reads back as 0x0ac5. Change-Id: Ic7444c763ed4da3a4b80b3a9e79b60c5fa984345 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1132718 Reviewed-by: Nick Vaccaro <nvaccaro@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> (cherry picked from commit a3c9f1332a421343837cc5048ccbb9f66ff4ae95) Reviewed-on: https://chromium-review.googlesource.com/1141704 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Add Gyro temperature sensor.Aseda Aboagye2018-07-182-0/+3
| | | | | | | | | | | | | | | | | | BUG=None BRANCH=master TEST=Flash nocturne, run 'temps', verify that Gyro temp sensor is present and reasonable. Change-Id: I59e405f1267dcd35087cfe82b965e85c041a9015 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1132717 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> (cherry picked from commit 84f79f22b22b66b77ddfb64eb75f27d485a982bf) Reviewed-on: https://chromium-review.googlesource.com/1141705 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* nocturne: Reduce input current limit by 5%.Aseda Aboagye2018-07-171-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | Nocturne seems to overdraw its set input current limit by about 5%. Therefore, this CL simply reduces the set current limit to 95% of what's desired. BUG=b:72775843, b:111224125 BRANCH=master TEST=Flash nocturne; verify with USB-C power meter that power contracts are not exceeded. Change-Id: I649653427770020c97ae425e41967e755a4ec724 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/1128563 Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Benson Leung <bleung@google.com> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> (cherry picked from commit 9f741207bc0205b3c5b1099fdbd14d5612bd0f48) Reviewed-on: https://chromium-review.googlesource.com/1137993 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org>
View Lorry Controller Status