summaryrefslogtreecommitdiff
path: root/common
Commit message (Collapse)AuthorAgeFilesLines
* charge_ramp: Specify port number in board_is_vbus_too_low()Shawn Nematbakhsh2017-02-022-3/+5
| | | | | | | | | | | | | | | | | | | charge_ramp needs to make a decision based upon the VBUS level on one specific port - the port that is ramping. The VBUS level on any other charge ports (if present) is not relevant. BUG=chrome-os-partner:54099 BRANCH=reef, gru TEST=With subsequent patches, verify charge_ramp success with a variety of BC1.2 chargers. Change-Id: Ie0a51a577e2b7491222560cd08dd5321ff3b7975 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/435561 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Shawn N <shawnn@chromium.org>
* usb_pd_policy: make pd_set_vbus_discharge work with devices with one USB PD portphilipchen2017-02-021-2/+6
| | | | | | | | | | | | | | | | | | We see compile error in case that pd_set_vbus_discharge is called when GPIO_USB_C1_DISCHARGE is not defined. BUG=chrome-os-partner:62207 BRANCH=gru TEST=make buildall -j Change-Id: I17c324d26ee6bf94c13ec7e0f92b7352de602329 Reviewed-on: https://chromium-review.googlesource.com/435458 Reviewed-by: Shawn N <shawnn@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/435540 Commit-Ready: Philip Chen <philipchen@chromium.org> Reviewed-by: Philip Chen <philipchen@chromium.org>
* Cr50: i2cs: Added counter for write mismatch errorScott2017-02-021-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | During TPM I2CS stress testing as described in chrome-os-partner:59191 there were instances of write mismatch errors. Previously, there was a CPRINTF for this condition. The CPRINTF being in the i2cs ISR then affects any subsequent i2cs activity and can create a cascade of errors. To avoid this issue, added a counter to track these instances and made it to be retrieved similar to the fifo adjust counter. BRANCH=none BUG=chrome-os-partner:57338,chrome-os-partner:59191 TEST=manual Ran the stress test as described in chrome-os-partner:59191 and found that when the write mismatch occurred the counter ticked up by 2 where before there would be numerous console log prints of the same error. Change-Id: I2837d02037e2f47b5bd4b001d3394ad6eb4bd92c Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/410032 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* Revert "version: Store image size data in version struct"Vadim Bendebury2017-02-014-26/+24
| | | | | | | | | | | | | This is a dependency of the uderlyaing patch which breaks header composition of g chip based boards. This reverts commit 7cbb815732d7434f5985d3b50a869aa71ba5c507. Change-Id: I4d94647cf5cb09fd338e5a581c956df6b5d83081 Reviewed-on: https://chromium-review.googlesource.com/435551 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org>
* Revert "system: Use stored size in image_data for determining image_used"Vadim Bendebury2017-02-011-23/+62
| | | | | | | | | | | | This breaks header composition of g chip based boards. This reverts commit 93951a491dd00e20addc1ff99c2896bb9752e665. Change-Id: Ia52cf1d9c56fbb588317cec73487b2c9e89b7234 Reviewed-on: https://chromium-review.googlesource.com/435550 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org>
* system: Use stored size in image_data for determining image_usedShawn Nematbakhsh2017-01-301-62/+23
| | | | | | | | | | | | | | | | | | | Image used size is now part of the image_data struct present in all images at a fixed offset, so use it rather than scanning from the end of the image. BUG=chromium:577915 TEST=Verify on kevin + lars + lars_pd that system_get_image_used() returns the same value as the old implementation, for both RO and RW images. BRANCH=None Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Ic8db5c706d82f7ca2ded2e90129747e7fbefdb38 Reviewed-on: https://chromium-review.googlesource.com/427959 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* version: Store image size data in version structShawn Nematbakhsh2017-01-304-24/+26
| | | | | | | | | | | | | | | | | | | | | Store our image size (known at build time) in our version struct (now renamed to image_data). This will allow us to more efficiently determine the size of an image in a follow-up CL. Note that compatibility is broken for old ROs that do not include this CL. BUG=chromium:577915 TEST=Verify on kevin + lars + lars_pd that stored image size matches output of system_get_image_used() for both RO and RW images. BRANCH=None Change-Id: I49ea5fc27a7f11f66daba485a87d0dfe7d0c770f Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/427408 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* tpm: rename tpm_reset to tpm_reset_requestMary Ruthven2017-01-281-13/+18
| | | | | | | | | | | | | | tpm_reset just requests a tpm reset it doesn't reset the tpm. Rename the function to reflect that. BUG=none BRANCH=none TEST=make buildall Change-Id: I6f4763b5de578a8cf263b2fac98fad3af2c25d65 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/434245 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* nvmem: do not use malloc for cached bufferVadim Bendebury2017-01-282-222/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With introduction of encryption it is becoming impossible to read NVMEM contents directly from flash. Decrypting the contents each time there is a read request creates a significant performance hit. NVMEM needs to be rearchitecture such that there is no need to run decryption each time NVMEM read is performed. This patch does just that, implementation details are described in the header comment in common/nvmem.c. To reduce memory impact the size of NVMEM is being decreased from 16K to 12K. This is acceptable because eviction objects stored in NVMEM serialized now, which dramatically reduces NVMEM size requirements. The TPM2 NVMEM size definition must be kept in sync. Another optimization this change introduces is bypassing writing into the flash if NVMEM contents did not change, which is verified by examining the hash of the cached storage. A test is added to verify that the new commit scheme works as expected, and the nvmem test is re-introduced to the list of test ran on each 'make buildall'. CQ-DEPEND=CL:433839 BRANCH=none BUG=chrome-os-partner:62260,chrome-os-partner:62421 BUG=chrome-os-partner:62437 TEST=ran the following tests, all succeeded make buildall -j TEST_LIST_HOST=nvmem make runtests tcg test suite corp enroll on reef, reboot a few times, verify that enrollment sticks Change-Id: I177daa3ceb4fd7aac299ca26b4506b863e31b946 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/433184 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* tcpm: enable pd message passing after hard resetDivya Sasidharan2017-01-271-0/+10
| | | | | | | | | | | | | | | | | | | | | On ANX port connecting hoho and issuing hard reset never recovered. From TCPCI spec R1.0.4.7.2 "TCPM writes to the RECEIVE_DETECT register to enable PD message passing". This was missing when the port sent HARD RESET when it acts as SRC. BRANCH=none BUG=chrome-os-partner:61377 TEST= On Electro, on anx port, connect hoho and issuing pd 0 hard successfully recovers from hard rst Change-Id: Ia2cfcaf52b88fbc24ee702c6a089389400eb42d1 Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/433387 Commit-Ready: Divya S Sasidharan <divya.s.sasidharan@intel.com> Tested-by: Divya S Sasidharan <divya.s.sasidharan@intel.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* servo_v4: pd: Added Device Test System supportScott2017-01-262-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | - Modified src attach state to enable vbus when debug accessory is detected. - servo_v4 has two pd ports, but each port requires a different default power role. Port 0 can only ever be a SNK, but port 1 which acts is intended to be a DTS port should default to a SRC so it can be be a source debug accessory. It may also act as a sink debug accessory, but is not intended to toggle automatically but will swap roles if necessary via pd role swap messaging. - Add hook for ccd enable/disable for DTS mode BUG=chrome-os-partner:61878 BRANCH=servo TEST=Manual Verfied that can still build servo_v4 project. All changes in this CL are contingent on config option CONFIG_USB_PD_DTS being enabled. Change-Id: Iab968b6fbdfc8f2d155c4f8618921b32f313b9ec Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/428308 Commit-Ready: Scott Collyer <scollyer@chromium.org> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: support gotoMin and giveBackSam Hurst2017-01-262-2/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Sink mode, on the receipt of a GotoMin message, reduce the current consumption to some minimum level. BUG=chrome-os-partner:33688 TEST=Manual testing Used a Kevin, with test routine, to test GotoMin feature on another Kevin unit. Test routine: if (!strcasecmp(argv[2], "gm")) { ccprintf("send goto min\n"); send_control(port, PD_CTRL_GOTO_MIN); send_control(port, PD_CTRL_PS_RDY); } Kevin with GotoMin feature: # ectool usbpdpower 0 Port 0: SNK DRP PD 4277mV / 3000mA, max 5000mV / 3000mA / 15000mW Port 1: Disconnected After Test routine is executed: # ectool usbpdpower 0 Port 0: SNK DRP PD 4906mV / 500mA, max 5000mV / 500mA / 2500mW Port 1: Disconnected BRANCH=none Change-Id: Iaac6e19706ceb10ccaff4d602d63fc086c808c8f Reviewed-on: https://chromium-review.googlesource.com/425728 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: Move PD_DEFAULT_STATE to a common define in usb_pd.hScott2017-01-261-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | Servo_v4 requires the ability to have a different default state per port. In previous devices, the assumption was that each supported port had the same default usb pd state and power role. This CL moves the by the default power role which in turn is derived from CONFIG_USB_PD_DUAL_ROLE. In addiiton to moving the location, it now uses 'port' as argument so it can be port specific if required. PD_DEFAULT_STATE was a board.h specific config, but in practice each instance used to date was set to PD_STATE_SNK_DISCONNECTED if CONFIG_USB_PD_DUAL_ROLE was defined and set to PD_STATE_SRC_DISCONNECTED otherwise. BUG=chrome-os-partner:61878 BRANCH=servo TEST=Manual run 'make -j buildall' to verify that all instances of PD_DEFAULT_STATE were removed. Change-Id: Iaf40718668732f525485ed7942ee7fc246d3f75d Signed-off-by: Scott <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/431787 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* nvmem: encrypt contents using crypto apiVadim Bendebury2017-01-251-112/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes incompatible changes to the nvmem layout: the header is increased to accommodate a 16 byte sha ans a 16 byte padding for future extensions. The layout version field is also introduced to make it easier to track changes in the future. When calculating SHA the entire partition above the SHA field is processed. Encryption covers everything above the header. Introducing encryption makes it impossible to use flash contents directly for read and compare operations. The nvmem_setup function is modified to use the nvnem_save() instead of writing into the flash directly. BRANCH=none BUG=chrome-os-partner:62260 TEST=ran the following tests, all succeeded make buildall -j TEST_LIST_HOST=nvmem make runtests tcg test suite corp enroll on reef, reboot a few times, verify that enrollment sticks Change-Id: I50b148ac0dc6bc924f4d65c67bc6610100d9dfc0 Reviewed-on: https://chromium-review.googlesource.com/428691 Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* g: common: introduce generic crypto APIVadim Bendebury2017-01-251-13/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | On boards based on the g chip cryptographic functions come from hardware, they should be implemented in chip/g as opposed to a particular board. The common modules (like nvmem) should be using some generic API, which hopefully will be implemented by other chips, or could be replaced by a purely software implementation where crypto hardware support is not available. Crypto API definition is being added in include/ and the g chip implementation (a wrapper around dcrypto functions) is being added in chip/g. test/nvmem_vars.h needed to be edited to avoid conflict with <string.h>. BRANCH=none BUG=chrome-os-partner:62260 TEST=make buildall -j still passes. Booting reef with the new image works fine too. Change-Id: Ifef281215f89239966882ecbe3e90c8351b9b91a Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/431313 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Nagendra Modadugu <ngm@google.com>
* flash: Fix ccprintf parameters in flasherase/writeNicolas Boichat2017-01-251-3/+2
| | | | | | | | | | | | | | Both these functions had a superfluous offset parameter. BRANCH=none BUG=chrome-os-partner:61671 TEST=flasherase/write Change-Id: I2973490e472c2e658440b56a0b76ec9f2aab749a Reviewed-on: https://chromium-review.googlesource.com/432176 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* nvmem: rename version to generationVadim Bendebury2017-01-241-27/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With upcoming versioning of NVMEM contents let's replace term 'version' with term 'generation' in the existing nvmem implementation. Generation would allow to tell between two instances of NVMEM stored in flash memory. The upcoming version field in the header will be used to tell between different nvmem layouts. This patch was created by invoking the following command: sed -i 's/VERSION/GENERATION/g;s/version/generation/g' \ common/nvmem.c include/nvmem.h test/nvmem.c and then editing a few remaining capitalized instances. This also fixes nvmem test broken by an earlier patch. BRANCH=none BUG=chrome-os-partner:62260 TEST=the following tests succeed: make buildall -j TEST_LIST_HOST=nvmem make runtests booitng reef with cr50 Change-Id: I96e52dc93ca7c52c55794ba3e8c2774571212de0 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/431312 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* device_state: signal if device_set_state changed the stateMary Ruthven2017-01-231-6/+7
| | | | | | | | | | | | | | | | Each device keeps track of the last known state. If device_set_state updates the device state to a new known state, then return true. Cr50 uses this returned value to check if the state has changed instead of calculating it itself. BUG=none BRANCH=none TEST=device detection still works Change-Id: I8afac178c2c731def6f4f62ff7023fe169ec1479 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/430970 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* CHERRY-PICK: motion_lid: Add more reliability measurements.Aseda Aboagye2017-01-201-19/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously in motion lid, we only considered the lid angle as unreliable when the hinge is too closely aligned with the direction of gravity. However, there are other cases where the lid angle can be unreliable. For example, when the device is being shaken and is under acceleration that's not solely due to gravity. This commit adds some more checks for a reliable lid angle measurement. - Checking if the device is significant motion by checking the deviation of the magnitudes of the base and lid vectors. - Making sure that the calculated angles agree with the current state of the lid switch. BUG=chrome-os-partner:59480 BUG=chrome-os-partner:59203 BRANCH=gru,cyan,glados,oak TEST=Flash kevin; use ectool motionsense lid_angle and monitor the instantaneous lid angle. Verify that unreliable is reported for cases where the device is under significant motion. TEST=Flash kevin; use evtest to monitor the tablet mode switch. Verify that tablet mode switch is much more robust. Change-Id: I4bd9e818e617b056364cce2e46385e743a7522d4 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/430344 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* button: Check volume up/down status and set recovery modeNicolas Boichat2017-01-202-2/+16
| | | | | | | | | | | | | | Add support for entering recovery mode using volume up/down keys. BRANCH=none BUG=chrome-os-partner:61930 TEST=Press Power+Volume Up+Volume Down, poppy enters recovery Change-Id: Id40a144e9b430cfb9dfd47048e9e96d598bc3db8 Reviewed-on: https://chromium-review.googlesource.com/428530 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* charge_manager: Update power supplier prioritystabilize-9199.BVijay Hiremath2017-01-181-5/+5
| | | | | | | | | | | | | | | | | | | From the USBC spec 1.2 "Table 4-14 Precedence of power source usage" USB Type-C 3.0 A & 1.5 A takes precedence over BC1.2 hence updated the power supplier priority of charger manager. BUG=chrome-os-partner:61420 BRANCH=none TEST=Manually tested on reef. Donette bottom port can switch from 1.5A to 3A upon high load. Change-Id: Iff936d6a8643e88e0b2738251254e896fe8562fe Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/430153 Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org>
* Revert "charge_ramp: Adjust minimum ramp current"Vijay Hiremath2017-01-182-26/+2
| | | | | | | | | | | | | | | | | | | | From the USBC spec 1.2 "Table 4-14 Precedence of power source usage" USB Type-C 3.0 A & 1.5 A takes precedence over BC1.2. Hence reverting this patch. This reverts commit 6a7e4a7b353c53d33d44662c71763490ffd1fdc4. BUG=chrome-os-partner:61420 BRANCH=none TEST=make buildall -j Change-Id: I2ed3f767973ff9c47fa7d2a2cca1aca15d13aa65 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/430152 Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org>
* common: prepare nvmem for encryption supportVadim Bendebury2017-01-181-88/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch mostly is rearranging the code to make it easier to add encryption layer in the upcoming change. One substantial change is making sure that in case when NVMEM contents are corrupted for whatever reason, the initialization function re-creates a blank NVMEM space; it was just bailing out before not leaving any initialized partitions behind. There is no need in two separate tables - one for base absolute addresses of the NVMEM partitions, and one for their flash memory offsets, one can be easily derived from the other. Code erasing the destination partition, calculating the SHA1 of the new blob and writing it into the flash was separated into own function. BRANCH=none BUG=chrome-os-partner:55331 TEST=make buildall -j still passes (which means NVMEM tests succeed). TPM TCG test suite also passes. Change-Id: I378265d8b49b81398aece2eadf9698abb05caaa1 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/428172 Reviewed-by: Scott Collyer <scollyer@chromium.org>
* poppy: updating variable name to power_button_pulse_enableShelley Chen2017-01-181-3/+4
| | | | | | | | | | | | | | | | | Updating variable name from smi_enabled to power_button_pulse_enabled, which is a more accurate description of the intended functionality. BUG=chrome-os-partner:61275 BRANCH=None TEST=reboot reef and try using power button for selection during the detachable menus and ensure that the DUT doesn't turn off. Change-Id: Ia04e032818c73439d2aeacdb8fcabbe3bce7c151 Signed-off-by: Shelley Chen <shchen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/429070 Reviewed-by: Duncan Laurie <dlaurie@google.com>
* pd: Reduce VDO_CMD_GET_LOG timeout to 75msShawn Nematbakhsh2017-01-171-1/+1
| | | | | | | | | | | | | | | | | | | VDO_CMD_GET_LOG is sent for each port from a host command handler, so we must ensure that it returns quickly to prevent host timeout. BUG=chrome-os-partner:61910 BRANCH=gru TEST=Manual on kevin, attach hoho and verify 'cros-ec-spi' timeout errors are not seen every 60s. Also verify that zinger pdlogs are correctly retrieved. Change-Id: Ie0466a8b614ec6bfe5874cde9d700e80a15d298e Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/428164 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* cr50: reinstate nvmem commits 3 s after tpm resetVadim Bendebury2017-01-141-13/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relying on the AP sending a PCR read as an indication of the completed boot process does not work on the resume path. Let's just enable commits 3 s after they were stopped to process tpm reset. BRANCH=none BUG=chrome-os-partner:61795 TEST=observed the following on the cr50 console on a reef during reboot: [0.018692 tpm_init] tpm_manufactured: manufactured [0.021180 tpm_reset_now: done] . . [1.166496 Skipping commit] [1.425888 Skipping commit] [1.439112 Skipping commit] . . [3.021892 Committing NVMEM changes.] and verified that reef booted normally. Change-Id: I5f64fe24b961a9d0366f8e4f40a0e44d4e7263fa Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/427328 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* poppy: host command for configuring power buttonShelley Chen2017-01-131-4/+29
| | | | | | | | | | | | | | | | | Specifically, we are using a bit to disable the SMI pulse on x86 systems so that we can use the power button for menu selection. BUG=chrome-os-partner:61275 BRANCH=None TEST=Try running with depthcharge sending the host command during detachable FW menus and making sure power button select doesn't turn off device on reef. Change-Id: I4a68cf514d514a4abe98beb99e7934d6fb0f44bd Signed-off-by: Shelley Chen <shchen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/427413 Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* charge_ramp: Adjust minimum ramp currentVijay Hiremath2017-01-132-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | A valid charge port is always detected as VBUS supplier type, 'USB charger' can detect the same port as BC1.2 DCP supplier type & also 'TCPC' can detect the same port as TYPEC supplier type. Thus a valid port is detected as 2 or 3 supplier types. Depending on the supplier's priority and the power that the supplier can provide, charge manager choses the charge supplier type of the port. If the USB charger detected supplier is BC1.2 DCP and the TCPC detected supplier is TYPEC then the supplier can provide stable current from TYPEC supplier's advertised current hence start ramping from TYPEC supplier's advertised current. BUG=chrome-os-partner:61420 BRANCH=none TEST=Manually tested on reef. Donette bottom port can switch from 1.5A to 3A upon high load. Change-Id: I871eca3ae4041f00bb3fd50e6aa939643f30a1f2 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/427961 Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Shawn N <shawnn@chromium.org>
* npcx: flash: Do not delay flash access requests.Shamile Khan2017-01-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | When depthcharge invokes a Host command that needs EC to access flash, the response is delayed by approx 150 ms because EC is busy with another flash operation to determine size of RW image for computing hash. We can eliminate this delay and also speed up the flash operation by using the same mechanism that is used for mec1322 based designs which also use external SPI flash. The changes are: a) We access 4 bytes from SPI flash at a time instead of a single byte b) We split flash accesses into smaller parts which means that mutex lock is acquired for a short duration. BUG=chrome-os-partner:59875 BRANCH=none TEST=make buildall -j After sysjump to RW, in EC Log the "hash start" is printed approx 120 ms earlier. Change-Id: Icb633379c992e795ba40eaf54fe9ec31747d4be6 Signed-off-by: Shamile Khan <shamile.khan@intel.com> Reviewed-on: https://chromium-review.googlesource.com/426016 Reviewed-by: Shawn N <shawnn@chromium.org>
* nvmem_vars: use dynamic memory allocationVadim Bendebury2017-01-091-16/+16
| | | | | | | | | | | | | | | To avoid SRAM footprint, let's use dynamic memory allocation in nvram_vars. No one is using this module yet, but the cr50 use case is coming up. BRANCH=none BUG=chrome-os-partner:61107 TEST=make buildall -j passes Change-Id: I21534430217ad387a3787fcc127da596a1b48e03 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/426088 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* motion_sense: Add "spoof" modeAseda Aboagye2017-01-071-7/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds a "spoof" mode feature to the motionsense stack. It allows the user to arbitrarily set the outputs of the sensor in order to "spoof" the readings of the sensor. This can be useful in emulating tablet mode or device rotations. A command is available from the EC console named `accelspoof` and there is a corresponding motionsense command in ectool called `spoof`. The usage is as follows: - EC console > accelspoof [id] [on/off] [X Y Z] - ectool # ectool motionsense spoof -- [id] [0/1] [X Y Z] If on or off(or 0/1) is not specified, the current spoof mode status of the sensor is returned. If on is specified, but no components are provided, the sensor will lock the current values and provide those as the spoofed values. If the components are provided, those will be used as the spoofed values. BUG=chromium:675263 BRANCH=cyan,glados,gru,oak TEST=Flash a DUT with accels. From AP console, run `ectool motionsense lid_angle` in a loop, use 'accelspoof' EC console command to set spoofed values. Verify that the angle is fixed regardless of the actual angle of the DUT. TEST=Flash a DUT with accels. From AP console, use `ectool motionsense spoof` to spoof values and verify that `ectool motionsense` reflects the spoofed values. Test with both provided component values and no component values. Change-Id: Ie30688d22f38054e7243b1af493a3092b2cdfb72 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/421280 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* charge_state_v2: Correct Smart battery charging/discharging statusVijay Hiremath2017-01-061-1/+25
| | | | | | | | | | | | | | | | | | | | | | | AverageTimeToFull() and AverageTimeToEmpty() are the predicted time based on the AverageCurrent(), these do not reflect the instant time of charging or discharging. Hence we observe huge number of time (1092h because register has 65535) to full time when battery starts accepting current upon reaching 100%. To overcome this issue, explicitly checking if the AverageTimeToFull() and AverageTimeToEmpty() register values are updated with the valid data. BUG=chrome-os-partner:60802 BRANCH=none TEST=Manually tested on Reef. Charge the battery to 100%, once the battery starts accepting current again observed time to full is not huge number. Change-Id: I6d6c21b72ab824dbe47e44e1e77f1c5319ac2720 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/425324 Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* iec: Improve efficiency of host command dispatcherSam Hurst2017-01-061-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use binary search in host command lookup dispatcher BUG=chromium:570895 TEST=manual testing on kevin - Kevin boots - ectool hello make buildall -j Verify *.smap hcmds section is sorted: BOARD with host commands and private host commands 0004d0ec R __hcmds 0004d0ec R __host_cmd_0x00000x0000 0004d0f8 R __host_cmd_0x00000x0001 0004d104 R __host_cmd_0x00000x0002 0004d110 R __host_cmd_0x00000x0003 0004d11c R __host_cmd_0x00000x0004 0004d128 R __host_cmd_0x00000x0005 0004d134 R __host_cmd_0x00000x0007 0004d140 R __host_cmd_0x00000x0008 0004d14c R __host_cmd_0x00000x000a 0004d158 R __host_cmd_0x00000x000d 0004d164 R __host_cmd_0x00000x0010 0004d170 R __host_cmd_0x00000x0011 0004d17c R __host_cmd_0x00000x0012 0004d188 R __host_cmd_0x00000x0013 0004d194 R __host_cmd_0x00000x0015 0004d1a0 R __host_cmd_0x00000x0016 0004d1ac R __host_cmd_0x00000x0017 0004d1b8 R __host_cmd_0x00000x0087 0004d1c4 R __host_cmd_0x00000x008c 0004d1d0 R __host_cmd_0x00000x008f 0004d1dc R __host_cmd_0x00000x0092 0004d1e8 R __host_cmd_0x00000x0093 0004d1f4 R __host_cmd_0x00000x0097 0004d200 R __host_cmd_0x00000x0098 0004d20c R __host_cmd_0x00000x00b6 0004d218 R __host_cmd_0x00000x00d2 0004d224 R __host_cmd_0x00000x00d3 0004d230 R __host_cmd_0x3E000x0000 0004d23c R __host_cmd_0x3E000x0002 0004d248 R __evt_src_EC_MKBP_EVENT_HOST_EVENT 0004d248 R __hcmds_end BOARD with host commands only 100bc888 R __hcmds 100bc888 R __host_cmd_0x00000x0000 100bc894 R __host_cmd_0x00000x0001 100bc8a0 R __host_cmd_0x00000x0002 100bc8ac R __host_cmd_0x00000x0003 100bc8b8 R __host_cmd_0x00000x0004 100bc8c4 R __host_cmd_0x00000x0005 100bc8d0 R __host_cmd_0x00000x0006 100bc8dc R __host_cmd_0x00000x0007 100bc8e8 R __host_cmd_0x00000x0008 100bc8f4 R __host_cmd_0x00000x0009 100bc900 R __host_cmd_0x00000x000a 100bc90c R __host_cmd_0x00000x000b 100bc918 R __host_cmd_0x00000x000d 100bc924 R __host_cmd_0x00000x0010 100bc930 R __host_cmd_0x00000x0011 100bc93c R __host_cmd_0x00000x0012 100bc948 R __host_cmd_0x00000x0013 100bc954 R __host_cmd_0x00000x0015 100bc960 R __host_cmd_0x00000x0016 100bc96c R __host_cmd_0x00000x0017 100bc978 R __host_cmd_0x00000x0025 100bc984 R __host_cmd_0x00000x0026 100bc990 R __host_cmd_0x00000x0029 100bc99c R __host_cmd_0x00000x002a 100bc9a8 R __host_cmd_0x00000x002b 100bc9b4 R __host_cmd_0x00000x002c 100bc9c0 R __host_cmd_0x00000x0044 100bc9cc R __host_cmd_0x00000x0045 100bc9d8 R __host_cmd_0x00000x0046 100bc9e4 R __host_cmd_0x00000x0047 100bc9f0 R __host_cmd_0x00000x0061 100bc9fc R __host_cmd_0x00000x0062 100bca08 R __host_cmd_0x00000x0064 100bca14 R __host_cmd_0x00000x0065 100bca20 R __host_cmd_0x00000x0067 100bca2c R __host_cmd_0x00000x0087 100bca38 R __host_cmd_0x00000x008c 100bca44 R __host_cmd_0x00000x008d 100bca50 R __host_cmd_0x00000x008f 100bca5c R __host_cmd_0x00000x0092 100bca68 R __host_cmd_0x00000x0093 100bca74 R __host_cmd_0x00000x0096 100bca80 R __host_cmd_0x00000x0097 100bca8c R __host_cmd_0x00000x0098 100bca98 R __host_cmd_0x00000x0099 100bcaa4 R __host_cmd_0x00000x009e 100bcab0 R __host_cmd_0x00000x00a0 100bcabc R __host_cmd_0x00000x00a1 100bcac8 R __host_cmd_0x00000x00a8 100bcad4 R __host_cmd_0x00000x00a9 100bcae0 R __host_cmd_0x00000x00b6 100bcaec R __host_cmd_0x00000x00b7 100bcaf8 R __host_cmd_0x00000x00d2 100bcb04 R __host_cmd_0x00000x00d3 100bcb10 R __host_cmd_0x00000x00db 100bcb1c R __host_cmd_0x00000x0101 100bcb28 R __host_cmd_0x00000x0102 100bcb34 R __host_cmd_0x00000x0103 100bcb40 R __host_cmd_0x00000x0104 100bcb4c R __host_cmd_0x00000x0110 100bcb58 R __host_cmd_0x00000x0111 100bcb64 R __host_cmd_0x00000x0112 100bcb70 R __host_cmd_0x00000x0113 100bcb7c R __host_cmd_0x00000x0114 100bcb88 R __host_cmd_0x00000x0115 100bcb94 R __host_cmd_0x00000x0116 100bcba0 R __host_cmd_0x00000x0117 100bcbac R __host_cmd_0x00000x0118 100bcbb8 R __host_cmd_0x00000x011a 100bcbc4 R __evt_src_EC_MKBP_EVENT_KEY_MATRIX 100bcbc4 R __hcmds_end BRANCH=none Change-Id: I5d13d2a7fe7fa9a0fbeed43177cc612f572a58bb Reviewed-on: https://chromium-review.googlesource.com/419702 Commit-Ready: Sam Hurst <shurst@google.com> Tested-by: Sam Hurst <shurst@google.com> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* cr50: Avoiding nvram commits at startupVadim Bendebury2017-01-052-1/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch eliminates NVMEM commits at system startup, namely between the moment the TPM is reset and the moment the AP is trying to read a PCR (which is an indication of the AP having booted into OS). To avoid losing NVMEM changes in case TPM is reset before PCR Read command is issued, pending changes (if any) are saved before TPM reset is processed. For the same reason TPM reset invocation is being added to the hard reboot path; this will kick in when there is a restart after cr50 firmware update. BRANCH=none BUG=chrome-os-partner:59873 TEST=with instrumented coreboot/depthcharge observed the following execution times for various TPM command issued at startup command 0x144, 15203 us command 0x14e, 11814 us command 0x182, 12461 us command 0x182, 12456 us command 0x138, 11503 us command 0x138, 11512 us command 0x14e, 14648 us command 0x14e, 12597 us command 0x121, 11353 us which totals 113 ms and shaves more than 200 ms off the boot time. Change-Id: Ic52309291fdb9c3ede96e0ad015ad9fc076bddc5 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/424063 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>
* common: introduce malloc/free implementationVadim Bendebury2017-01-052-1/+396
| | | | | | | | | | | | | | | | | | | | | | | | | | | The new code allows to replace the existing one buffer at a time shared memory facility with a malloc/free implementation. A new configuration option is being provided (CONFIG_MALLOC). The names of functions allocating and freeing memory are not being changed to allow to switch between the two implementations seamlessly. A double linked list of buffers is used to keep track of free and allocated memory. During initialization the entire free memory block is considered a single free buffer. No allocations/frees are allowed from within interrupts. The control structures are protected by a semaphore, so allocate and free invocation could be blocking. A test is added which randomly allocates and frees memory, continuing until all branches in the allocate and free functions are taken. BUG=chrome-os-partner: TEST=make buildall -j succeeds, which includes testing the new malloc/free implementation. Change-Id: I5e71c0190c6c247ec73bb459f66a6d7a06e3d248 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/420466 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* motion: Disable tablet mode if one accel is brokenGwendal Grignou2017-01-043-2/+16
| | | | | | | | | | | | | | | | We need 2 accelerometer for tablet mode. If one of them is not working, disable tablet mode. We will stay in clamshell mode, lid angle will be always unreliable. BUG=chrome-os-partner:61141 TEST=On kevin with a single sensor. Check we are in clamshell mode when rebooting the EC. BRANCH=kevin Change-Id: I7bf6cdc9d85370fce20e5183622b4bc18f4f5f99 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/424184 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* pstore: Fix issue with block calculation for pstore blocksMoritz Fischer2017-01-031-2/+2
| | | | | | | | | | | | | | | | Fix issue where the block is calculated wrong since the offset that gets added is wrongly EEPROM_BLOCK_COUNT_PSTORE which is the number of total blocks rather than the starting block given by EEPROM_BLOCK_START_PSTORE. TEST=Build test, ran on board with stubbed out functions. BUG=none BRANCH=none Change-Id: Ide4839845353c2b9f95a37eb689c8d800169bb22 Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Reviewed-on: https://chromium-review.googlesource.com/424182 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* charger_profile: Add common code for charger profile overrideVijay Hiremath2017-01-023-0/+196
| | | | | | | | | | | | | | | | | | | Added common code for charger profile override for fast charging. Fast charging configs can be defined in the respective board battery file and use the common code for imposing the custom data. BUG=chrome-os-partner:59393 BRANCH=none TEST=Enabled the config on Reef. Manually overrode the temperature and voltage. Observed correct charge profile config is selected for each tests. Change-Id: I075d271258470b98d38e4d5395d749469d3fd469 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/407928 Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* motion: Fix last timestamp calculationGwendal Grignou2016-12-281-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | last_collection is used for sensor in forced mode to be sure we are not calling the read routine too often. We should update last_collection even when the reading fails, and not on the interrupt path. For sensors that support interrupt, the new timing diagram is: /-------- data rate period ---------\ --------------+------------------------------------+-----------------> t | /\ read (sample request) | | Interrupt (sample available) \/ | sensor BUG=chrome-os-partner:59423 BRANCH=reef TEST=Check the ALS read is not called too often even when the sensor reports an error because the read value is not changed. Change-Id: I2def7bbd5227cf373c1f613c9b70bc6215861008 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/424222 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* motion: Fix oversampling calculationGwendal Grignou2016-12-281-1/+1
| | | | | | | | | | | | | | | | | CL/385081 was incorrect, MAX should be used instead of MIN when calculating the oversampling factor, to be sure it can't be 0. BUG=b:27849483,chrome-os-partner:59423 BRANCH=reef TEST=Using a special firmware on Reef reporting the ALS in motionsense, check that oversampling is 1 when requested frequency is 5Hz while the maximal frequency supported is 1Hz. Check the ALS sensor reports information to ARC++. Change-Id: I3c2d447bbc3a9ca0a5963aa86d5a24ee87ca6ab6 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/424221 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* als: Define CONFIG_ALS when HAS_TASK_ALS is present.Gwendal Grignou2016-12-281-1/+1
| | | | | | | | | | | | | | For oak, set a different list of task (no als, no accel) for compiling revision 4 or less. Fix GPIO include issue. BUG=chrome-os-partner:59423,chrome-os-partner:59084 TEST=compile for oak with board 4 and 5, tested on Reef. BRANCH=kevin,reef Change-Id: I09051a69cbad6d477a7b3bf9907f4c5c144b5136 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/424220 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add nvmem-backed key=value variable storageBill Richardson2016-12-212-0/+437
| | | | | | | | | | | | | | | | | | | | | | | | | The CONFIG_FLASH_NVMEM option implements persistent, reliable storage regions in flash. This adds CONFIG_FLASH_NVMEM_VARS, which uses one of those storage regions for free-form variables. Refer to the comments in include/nvmem_vars.h and common/nvmem_vars.c for usage and implementation details. BUG=chrome-os-partner:61107 BRANCH=none TEST=make runtests This CL includes a number of new tests, specifically for this feature. No target boards use this feature yet so there's nothing to test on actual hardware, but the test/nvmem_vars executable includes console commands ("get", "set", "print") to try it out. Change-Id: I8597415dc3b00a1462f5b164eeb5073129030525 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/414194 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* tcpm: anx74xx: Remove auto-toggle supportShawn Nematbakhsh2016-12-201-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Auto-role toggle on the anx74xx does not function correctly with e-marked cables and cannot be used. Also check for TCPC support for auto-toggle at runtime, to allow auto-toggle supported TCPC to be used alongside an unsupported part. (from CL:420405) BUG=chrome-os-partner:60890 BRANCH=reef TEST=Manual on reef, boot to S0: `pd 0 state`: Toggling between SRC_DISCONNECTED / SNK_DISCONNECTED `pd 1 state`: DRP_AUTO_TOGGLE Also verify port 0 can become sink + source correctly in S0. Change-Id: Iafdedf31773feef23923cefe1f4fb02fcffda120 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/420866 Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* cr50: keep board properties related code in board.cVadim Bendebury2016-12-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | There are plans to extend use of the LONG_LIFE_SCRATCH1 register for other purposes than keeping board properties. Just as the board properties, the new use is also very board specific. This patch moves the board properties code from chip/g to board/cr50, where it belongs. Instead of reading board properties bitmap and checking if various bits are set, api functions are now provided to allow determining various properties settings without actually looking at the properties bitmap. CQ-DEPEND=CL:*313057 BRANCH=none BUG=chrome-os-partner:58961 TEST=verified that both Gru and Reef boot with the new image, additionally, on Reef confirmed that it is possible to communicate with the H1 over USB, and that plt_reset signal is handled properly. Change-Id: Id0dd2dc16389f773a149fb01eee1ce7bb99c4547 Reviewed-on: https://chromium-review.googlesource.com/422081 Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org>
* charge_ramp: Fix OC detection on chargers which recover quicklyShawn Nematbakhsh2016-12-201-10/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | If VBUS is lost and then quickly recovers, we may detect the re-presence of the charger before charge_ramp has been informed about the loss. In this case, charge manager's supplier registration time will precede our ACTIVE_OC_INFO timestamp. Fix our timestamp comparison to correctly detect OC in this case. In addition, correctly mark all OC events stale once we have encountered a disconnect / reconnect that we determine not to be related to OC. BUG=chrome-os-partner:56367 TEST=Manual on reef, verify Motorola 800mA DCP charger settles at ~800mA after OC. BRANCH=reef Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I3fdfd3929d07c60b82655999dd5aa731c1c7bc9b Reviewed-on: https://chromium-review.googlesource.com/419775 Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 19ba4a053027486ca415c4d703944b38e3c5e652) Reviewed-on: https://chromium-review.googlesource.com/421208 Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* common/i2c.c: Check that i2c port is always 0 or greaterMartin Roth2016-12-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, an assert was checking the port value after the port value had been converted to the controller. Instead, verify that the value is not negative, and return if it is. The if sequence generates much less code than the ASSERT, and protects both paths. Fixes coverity warning 141748: Negative array index read 42 files changed. Total size change: -1248 bytes. Average size change: -29 bytes. These platforms increased in size: lucid/RO/ec.RO.flat grew by 4 bytes: (64404 to 64408) lucid/RW/ec.RW.flat grew by 20 bytes: (63996 to 64016) pyro/RO/ec.RO.flat grew by 120 bytes: (131212 to 131332) pyro/RW/ec.RW.flat grew by 144 bytes: (130764 to 130908) TEST=Build BUG=None BRANCH=None Change-Id: I8d39db04c4ca3194f99e17840365429ed2d39390 Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/371401 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* spi_nor.c: Initialize variables to fix GCC warningsMartin Roth2016-12-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looking at these warnings, none of these are real issues, so just initialize the variables to make GCC happy. There might be a way to rewrite the functions to make GCC be less confused, but I haven't figured it out yet, and the solutions I tried generally ended up increasing the binary size. The function spi_nor_read_jedec_id() will initialize the variables or return an error, so there isn't a path where they would be used without initialization. common/spi_nor.c: In function 'command_spi_nor_info': common/spi_nor.c:771:3: error: 'mfn_id' may be used uninitialized in this function [-Werror=maybe-uninitialized] common/spi_nor.c:771:3: error: 'mfn_bank' may be used uninitialized in this function [-Werror=maybe-uninitialized] The function spi_nor_device_discover_sfdp_page_size() will either set these variables or return an error, so these should never actually be uninitialized when they get used. common/spi_nor.c: In function 'spi_nor_init': common/spi_nor.c:449:30: error: 'capacity' may be used uninitialized in this function [-Werror=maybe-uninitialized] common/spi_nor.c:450:31: error: 'page_size' may be used uninitialized in this function [-Werror=maybe-uninitialized] This does not change the size of any ec.*.flat file. BRANCH=none BUG=none TEST=build succeeds under GCC 4.9.2, 5.3, and 6.2 Change-Id: I6bbe73b4acf3dcbbaa03d9cbf1dcdfeb883c0a6d Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/403503 Reviewed-by: Shawn N <shawnn@chromium.org>
* i2c_passthru: fix virtual battery operationphilipchen2016-12-144-68/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | In some cases, the virtual battery code creates transactions that violate SB spec. One example: If the host command is structured as two messages - a write to 0x03 (reg addr), followed by two bytes of write data, the first byte of the second message (write data) will be sent to virtual_battery_read(), as if it were a reg read request. Let's do the following change for virtual battery: 1. Parse the command more carefully with state machines. 2. Support write caching for some critical registers. 3. Cache more attributes (0x03 and 0x0f). BUG=chrome-os-partner:59239, chromium:659819 BRANCH=none TEST='power_supply_info' works on kevin Change-Id: Icdeb12b21f0dc3c329f29b206b7b9395ca4c9998 Reviewed-on: https://chromium-review.googlesource.com/407987 Commit-Ready: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* usb_pd_protocol: Force rediscovering identity on bootNicolas Boichat2016-12-141-0/+2
| | | | | | | | | | | | | | | | This is useful with Apple's HDMI adapter, as the code that sends the discovery message will also swap vconn as required. BRANCH=none BUG=chromium:644663 TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm, display works. Change-Id: I21d47c69e2c7153a5d808dedcb1abe360ce3f5c0 Reviewed-on: https://chromium-review.googlesource.com/415698 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* usb_pd_policy: Automatically swap vconn if adapter requests itNicolas Boichat2016-12-142-1/+18
| | | | | | | | | | | | | | | | | | | | | | During discovery, if adapter requests vconn power in the AMA flags, make sure that we provide vconn. This, for example, is necessary for the Apple HDMI adapter to work on boot, when connected in S5. In that case, adapter does request vconn swap, but we reject that as the system is off, and, therefore 5V supply is off. On boot, we send another discovery request, which will detect this case and swap the power. BRANCH=none BUG=chromium:644663 TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm, type "pd 0 vdm ident" in console, display works. Change-Id: I55b6658c2bc0574b8427ae086f61daf03730a725 Reviewed-on: https://chromium-review.googlesource.com/415697 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
View Lorry Controller Status