summaryrefslogtreecommitdiff
path: root/chip
Commit message (Collapse)AuthorAgeFilesLines
* stm32: Fix manual interrupt clearing functionCraig Hesling2020-03-161-1/+3
| | | | | | | | | | | | | | | | | | | | | This fixes a bug in gpio_clear_pending_interrupt, where all pending interrupts are unintentionally cleared. This is not in the code path for normal gpio interrupt handlers, since the normal interrupt clearing occurs in gpio_interrupt (right below this function). BRANCH=none BUG=chromium:1059520 TEST=none Signed-off-by: Craig Hesling <hesling@chromium.org> Change-Id: I4d6fe7947f4d76cf3b57dfbf3bb926e41851c80c Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2101208 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> (cherry picked from commit c2c2c083fef813e3e3c70f8c13a1418717ba682d) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2106673
* i2c: don't scan i2c addresses less than 0x08Jett Rink2019-08-231-3/+2
| | | | | | | | | | | | | | | | | | | None of the existing i2c addresses in the EC code base are less than 0x08 and those addresses are reserved by the i2c and SMBus specification. BRANCH=none BUG=b:138156666 TEST=i2c bus scan with a smart battery doesn't "misbehave" any more and other devices can be detected properly. Change-Id: I561b082c4c7e3df7caaa33b6ef6ad467dabbd5a5 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1715326 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1767530 Reviewed-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org>
* npcx: make i2c slave address uint16_t to be standardDenis Brockus2019-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | EC code changed over to a 7-bit slave address and stored in a uint16_t to generically be able to handle 10-bit addresses, if they are ever needed, as well as common bit flags in the most significant bits. This code does not use more than the 8 least significant bits but to be EC consistent, I am making this 16 bits. BUG=none BRANCH=none TEST=make buildall -j Change-Id: Ic5f4b3500ae7b3c18380b188efbc37c01d58d7e9 Signed-off-by: Denis Brockus <dbrockus@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1714136 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Commit-Queue: Jack Rosenthal <jrosenth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1767529 Reviewed-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org>
* Remove __7b, __8b and __7bfDenis Brockus2019-08-2315-153/+153
| | | | | | | | | | | | | | | | | | | | | | | The extentions were added to make the compiler perform most of the verification that the conversion was being done correctly to remove 8bit addressing as the standard I2C/SPI address type. Now that the compiler has verified the code, the extra extentions are being removed BUG=chromium:971296 BRANCH=none TEST=make buildall -j TEST=verify sensor functionality on arcada_ish Change-Id: I36894f8bb9daefb5b31b5e91577708f6f9af2a4f Signed-off-by: Denis Brockus <dbrockus@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1704792 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1767528 Reviewed-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org>
* Use 7bit I2C/SPI slave addresses in ECDenis Brockus2019-08-2315-378/+491
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Opt for 7bit slave addresses in EC code. If 8bit is expected by a driver, make it local and show this in the naming. Use __7b, __7bf and __8b as name extensions for i2c/spi addresses used in the EC codebase. __7b indicates a 7bit address by itself. __7bf indicates a 7bit address with optional flags attached. __8b indicates a 8bit address by itself. Allow space for 10bit addresses, even though this is not currently being used by any of our attached devices. These extensions are for verification purposes only and will be removed in the last pass of this ticket. I want to make sure the variable names reflect the type to help eliminate future 7/8/7-flags confusion. BUG=chromium:971296 BRANCH=none TEST=make buildall -j Change-Id: I2fc3d1b52ce76184492b2aaff3060f486ca45f45 Signed-off-by: Denis Brockus <dbrockus@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1699893 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1767525 Reviewed-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org>
* common: queue: Update chunk struct and get read/write logicYuval Peress2019-08-021-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This change updates the queue_get_write_chunk and queue_get_read_chunk logic to return an updated queue_chunk. The new chunk uses a void * for the buffer and replaces length with count. This more tightly aligns to how the rest of the queue functions operate. Further, it adds the ability to offset the write chunk. This is important as it allows wrapping. For example: With a queue of 8 units, 1 byte each. Assume H=2, T=5. Previously, we were only able to ever get the 3 bytes at 5-7. Using the offset of 3 though, we can now also get the 2 byte write chunk 0-1. BUG=chromium:966506 BRANCH=None TEST=Added unit tests Change-Id: I40216c36aa0dc95ec4d15fc587d4b1f08a17ef73 Signed-off-by: Yuval Peress <peress@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1637415 Reviewed-by: Enrico Granata <egranata@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1719564 Reviewed-by: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org>
* npcx: disable the selection of JTAG0 signals due to strapCHLin2019-05-096-196/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It was observed that pressing recovery key combination + the other keys, some keys on the keyboard become invalid after system reboots. (see b:129908668 for more detail.) It is because the hardware strap pin for JTAG0 signals is unintentionally triggered. This CL reverts the selection of JTAG signals and set them back to keyboard scan function at system initialization. The revert applies to all real platforms except npcx_evbs. BRANCH=none BUG=b:129908668 TEST=pass "make buildall" TEST=Press the specific key combination, after the system reboots, the keyboard function works normally. On npcx EVBs, the JTAG0 is still functional. Change-Id: I7ede1ea4609466fea50a97b1f60308e4cdfd4544 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1575887 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1603141 Reviewed-by: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org>
* common: Add BIT macroGwendal Grignou2019-05-091-586/+606
| | | | | | | | | | | | | | | | | | | As requested for integration in kernel mfd subsystem, use BIT(...) instead of (1 << ... ). Add the macros, apply just to ec_commands.h for now. BUG=None BRANCH=None TEST=Compile Change-Id: I8509f1e8dc966799c3c4f0269b15f1ccc4138c07 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1518658 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1603132 Reviewed-by: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org>
* npcx: shi: enable sleep bit in suspend hook function.Mulin Chao2019-02-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make sure ec can enter deep sleep even if there's a CS drop at S5, the shi driver turns off it's interrupt in suspend hook function in case the sleep bit, SLEEP_MASK_SPI, is disabled in shi's ISR. However, in some cases, CS dropped before ec was informed by hook function. It will make ec cannot enter deep sleep at S5. This CL allows ec enter deep idle at S5. It will enable sleep bit, directly in suspend hook function even if CS drops before ec was informed. BRANCH=none BUG=b:118844551 TEST=No build errors for npcx7 series. Change-Id: I61719fad74bfd85006b6c90dd46b69cb103dcfa9 Signed-off-by: Mulin Chao <mlchao@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1410792 Reviewed-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1460078 Reviewed-by: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org>
* npcx: lpc: don't set SHCFG[7:5] in the driver's initializationCHLin2019-01-111-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | In older Nuvoton EC chips (prior NPCX5), the Semaphore register is mapped to offset 0 of the Shared RAM Window by default. We usually disable it in the driver by setting SHCFG[7:6] both to 1 if we want to disable the Semaphore mechanism. However, in NPCX5 and later chips, this behavior is deprecated (the Semaphore register is not mapped to offset 0 of the Shared RAM Window by default). These bits (including bit 5) were removed. The driver should keep these bits at their default state. Otherwise, the Semaphore mechanism may not work as expected. BRANCH=none BUG=b:73018524 TEST=pass make buildall. TEST=build and flash reef/grunt/yorp image, stress test the host command and host event, no symptom occurs. Change-Id: I63031f3957d0485f18fb8c4f1b13ad56c2dc5804 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Previous-Reviewed-on: https://chromium-review.googlesource.com/1383675 (cherry picked from commit 3f1576e485713cbde5600985c17e52dcbd8f7aee) Reviewed-on: https://chromium-review.googlesource.com/c/1405403 Reviewed-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org>
* keyboard: restore KBD_KSO2 after keyboard factory scan testingDevin Lu2019-01-113-3/+12
| | | | | | | | | | | | | | | | | | | This patch fix the keyboard malfucntion with KBD_KSO2 line after executed "ectool kbfactorytest". BUG=none BRANCH=octopus TEST=make sure keyboard works after executed "ectool kbfactorytest" on meep. Change-Id: I33c22e59a01884ff6c961161e189583a6c3673a3 Signed-off-by: Devin Lu <Devin.Lu@quantatw.com> Previous-Reviewed-on: https://chromium-review.googlesource.com/1373389 (cherry picked from commit 59e9c0e928c92917412f73e95ab308f42c092506) Reviewed-on: https://chromium-review.googlesource.com/c/1405907 Reviewed-by: Edward Hill <ecgh@chromium.org> Commit-Queue: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org>
* chip/npcx: Default output the i2c_recovery() error messageZhuohao Lee2018-11-171-2/+3
| | | | | | | | | | | | | | | | | | | The i2c_recovery() will be called if the i2c bus error is detected. This is an serious error handling and may be caused by the slave which doesn't follow the spec. We should output this error message to let developer catch this error at the beginning like proto stage. BUG=b:118063849 BRANCH=master TEST=error message popped out on Nami and Rammus Change-Id: I4996cd18415d6ee4c5cd48ac374252a2230628b0 Signed-off-by: Zhuohao Lee <zhuohao@chromium.org> Previous-Reviewed-on: https://chromium-review.googlesource.com/1331249 (cherry picked from commit b11f8316946c68b5f56e386c8f2cc3df920b562f) Reviewed-on: https://chromium-review.googlesource.com/c/1340496 Reviewed-by: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org>
* npcx: add console command to better investigate power consumption of GPIOsCHLin2018-11-141-0/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL adds the console command to disable the input buffer of non-I2C and non-ISR GPIOs which are configured as either input or open-drain. The GPIOs set as 1.8V are also ignored because they are already disabled in the gpio_pre_init. Usage: 1. type "gpiodisable next" to disable the input buffer of next GPIO wihch is either input or open drain in the gpio list. (if the next one is I2C or 1.8V or ((!input) && (!open-drain)), it will ignore it and check the following next one). Ex: > gpiodisable next current GPIO : 16 LID_ACCEL_INT_L --> Ignore 1v8 pin! current GPIO : 17 PLT_RST_L --> Disable WKINEN! > gpiodisable next current GPIO : 18 SYS_RESET_L --> Disable WKINEN! > gpiodisable next current GPIO : 19 ENTERING_RW --> Not Input or OpenDrain current GPIO : 20 PCH_WAKE_L --> Disable WKINEN! ......... ......... > gpiodisable next current GPIO : 34 I2C0_SCL --> Ignore I2C pin! current GPIO : 35 I2C0_SDA --> Ignore I2C pin! current GPIO : 36 I2C1_SCL --> Ignore I2C pin! current GPIO : 37 I2C1_SDA --> Ignore I2C pin! current GPIO : 38 I2C2_SCL --> Ignore I2C pin! current GPIO : 39 I2C2_SDA --> Ignore I2C pin! current GPIO : 40 I2C3_SCL --> Ignore I2C pin! current GPIO : 41 I2C3_SDA --> Ignore I2C pin! current GPIO : 42 I2C4_SCL --> Ignore I2C pin! current GPIO : 43 I2C4_SDA --> Ignore I2C pin! current GPIO : 44 I2C7_SCL --> Ignore I2C pin! current GPIO : 45 I2C7_SDA --> Ignore I2C pin! current GPIO : 46 EN_USB_A0_5V --> Not Input or OpenDrain current GPIO : 47 EN_USB_A1_5V --> Not Input or OpenDrain current GPIO : 48 USB_A0_CHARGE_EN_L --> Not Input or OpenDrain current GPIO : 49 USB_A1_CHARGE_EN_L --> Not Input or OpenDrain current GPIO : 50 USB_C0_BC12_VBUS_ON --> Not Input or OpenDrain current GPIO : 51 USB_C0_BC12_CHG_DET_L --> Disable WKINEN! 2. Enable/Disable a specific GPIO's input buffer by "gpiodisable ${GPIO_NUM_IN_LIST} on|off" (use "gpiodisable list" can check the GPIO_NUM_IN_LIST of a GPIO) Ex: > gpiodisable list 16: LID_ACCEL_INT_L 17: PLT_RST_L 18: SYS_RESET_L ...... ...... > gpiodisable 17 off --> disable input buffer of GPIO PLT_RST_L > gpiodisable 17 on --> enable input buffer of GPIO PLT_RST_L BRANCH=none BUG=b:117139495 TEST=No build errors for "make buildall". TEST=Manually run the console commands and check the result as expected. Change-Id: I7c750804cf45218a3ab1baacefcda64833861b1f Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1275765 Commit-Ready: CH Lin <chlin56@nuvoton.com> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1335677 Reviewed-by: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* NPCX: Fix for alternate GPIOs on the NPCX7Diana Z2018-11-061-2/+4
| | | | | | | | | | | | | | | | | | | | During a recent naming change to the alternate GPIO tables, a few of the pins for the NPCX7 were missed. This change adds those pins back in. BRANCH=None BUG=b:118856402,b:118833549 TEST=builds, verified bobba USB 2.0 on DB type-c port works now Change-Id: Id3f3fa086b24da37eeeb49c5f4b24ffd4a5cfd6f Signed-off-by: Diana Z <dzigterman@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1315628 Commit-Ready: Ryan Zhang <ryan.zhang@quanta.corp-partner.google.com> Reviewed-by: Justin TerAvest <teravest@chromium.org> (cherry picked from commit efa0cb94e8cb111bb296523402bfa689e97dc92e) Reviewed-on: https://chromium-review.googlesource.com/c/1318950 Commit-Queue: Devin Lu <Devin.Lu@quantatw.com> Tested-by: Devin Lu <Devin.Lu@quantatw.com> Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
* npcx: gpio: fix bugs of low voltage level selectionCHLin2018-10-302-14/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL fixed the following bugs of low voltage support of GPIO: 1. fix the mismatch issue of low voltage support GPIOs when the mask passed to gpio_low_voltage_level_sel() has multiple bits set. (see more detail in the bug:118443060.) The idea is to create a new function gpio_low_vol_sel_by_mask() to iterate the match for each bit set in the mask. i.e. while (lv_mask) { bit = get_next_bit(&lv_mask); gpio_low_voltage_level_sel(p, bit, low_vol); }; The second parameter of gpio_match()/gpio_low_voltage_level_sel is also changed from "mask" to "bit" because of above modification. 2. It was observed that there are some errors of the low level mapping table because the older datasheet we used to develop the driver is not correct. After checking the latest datasheets of all EC sku, the low level table should have the following modification: - GPIO65 cannot support low level and should be removed. - GPIO86 can support low level in all EC skus. BRANCH=none BUG=b:118443060 TEST=Add GPIO_SEL_1P8V flag in the ALTERNATE macros which have multiple bits set in the mask field in npcx7_evb board. Flash the image and make sure the warning message doesn't print and the related low level bits are set. Change-Id: I7aa23eb42dda178db34fe44a663df29757910a55 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1301674 Commit-Ready: CH Lin <chlin56@nuvoton.com> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1309045 Reviewed-by: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* npcx: gpio: support internal pull-down when enable low voltage modeCHLin2018-10-301-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is the limitation that internal pull-up must be disabled when a GPIO is configured in low voltage level. However, thers is no such limitation of internal pull-down. The current GPIO driver disable no matter pull-up or pull-down when low voltage mode is set. This CL fixes it by: 1. enable internal PD when low voltage mode is set. 2. print warning message in the UART console when both low voltage and internal PU flags are set for any GPIO defined in gpio.inc. BRANCH=none BUG=b:118339468 TEST=No build error for make buildall TEST=define a gpio with internal PD+low-voltage in npcx7_evb/gpio.inc, check the releated bits of PxPULL and PxPUD are set; TEST=define a gpio with internal PU+low-voltage, check the warning message is printed on the console. Change-Id: I8e15125d3a2ccc73f84b8a559d12644b1d1af5f9 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1297872 Commit-Ready: CH Lin <chlin56@nuvoton.com> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Wai-Hong Tam <waihong@google.com> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1309044 Reviewed-by: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* system: Remember if reset was due to AP watchdog triggeringNicolas Boichat2018-10-301-0/+32
| | | | | | | | | | | | | | | | | | | | On MT8183, when EC detects a watchdog reset, EC needs to reboot itself in preparation for the next boot. This means that AP loses the reset cause (as AP system reset is toggled), and, therefore, we need to save the reset reason in the EC. BRANCH=none BUG=b:109900671 TEST=apshutdown, powerb, see that reset reason is: reset-pin TEST=Use test-wd from bug. Reset reason: reset-pin ap-watchdog Change-Id: I2e30306db5727a22de930f00dc30de40b9695bef Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1295890 Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1309037 Reviewed-by: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* npcx: gpio: refactor the composition of pinmux tableCHLin2018-10-252-365/+340
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some GPIOs in npcx chips supprt more than one alternative functions. The current GPIO driver defines a macro for a specific alternative funtion and add it in the alternative function table. If two this kind of alternative macros which are belong to the same GPIO are defined and added to the table, it wiil casue the conflict of pinmux setting. Ex: #define NPCX_ALT_I2S_SYNC ALT(A, 5, NPCX_ALT(E, I2S_SL)) #define NPCX_ALT_SPIP_CS1 ALT(A, 5, NPCX_ALT(0, SPIP_SL)) This CL refactors the macro's definition by using the name of GPIO rather than the alternative fucntion of it. Which altenative fucntion related to the GPIO depends on which module is configured. Ex: #if defined(NPCX_WOV_SUPPORT) && defined(CONFIG_WAKE_ON_VOICE) #define NPCX_ALT_GPIO_A_5 ALT(A, 5, NPCX_ALT(E, I2S_SL)) /* I2S_SYNC */ #else #define NPCX_ALT_GPIO_A_5 ALT(A, 5, NPCX_ALT(0, SPIP_SL)) /* SPIP_CS1 */ #endif This can prevent from the conflict pinmux setting because there will be the compilier error if the same macro is redefined. BRANCH=none BUG=b:117768182 TEST=No build error for make buildall TEST= Test alternative functions like I2C/keyboard/UART/WoV on yorp/grunt/poppy/npcx7_evb/npcx_evb. Change-Id: I7ca191a2199c4244f373720fb5c3c4e6af428c64 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1282531 Commit-Ready: CH Lin <chlin56@nuvoton.com> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Wai-Hong Tam <waihong@google.com> Reviewed-on: https://chromium-review.googlesource.com/c/1299898 Reviewed-by: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* npcx: Check WP_IF for internal flash before writing status registerFurquan Shaikh2018-10-011-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case of internal flash, WP_IF needs to be checked to determine if it is okay to write status register. WP_IF is R/W1S, hence once it is set, it gets cleared only on core domain reset. Thus, it is necessary to reboot EC on WP de-assertion before any attempt to write status register is made. This change checks to ensure that internal flash is not protected based on the state of WP_IF bit in DEV_CTL4 before writing status register. BUG=b:115983409 BRANCH=None TEST=Verified following: 1. Attempt to write status register without rebooting EC: a. Disable WP b. flashrom -p ec --wp-disable ---> Reports failure back to host 2. Attempt to write status register after rebooting EC: a. Disable WP b. Reboot EC c. flashrom -p ec --wp-disable ---> Reports success and SW WP is successfully disabled. Change-Id: I2a89ecfc0bed824d5e75110f00b060980627dd33 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1248481 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Sanna Fnu <fnu.sanna@intel.corp-partner.google.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Justin TerAvest <teravest@chromium.org> (cherry picked from commit 9e67cde50f6f5ecd578e47db612b1a7b9e1e1ff7) Reviewed-on: https://chromium-review.googlesource.com/1256046 Reviewed-by: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* npcx: Don't clear IBBR bit via a read-modify-write sequenceCHLin2018-09-252-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In npcx5/npcx7m6g/npcx7m6f, clearing the IBBR bit in the BKUP_STS register is not hazardous because the register only implements the IBBR bit. In npcx7m6fb/npcx7m7wb, the register implements two more bits (VSBY_STS/VCC1_STS). Using read-modify-write operation to clear IBBR bit will also clear these two bits unexpected if they are set. It is fine at this time because the firmware does not rely on these two new bits for any purpose. But it will be better to change it in case these two bits are used in the future. This CL also clears VSBY_STS/VCC1_STS bit (for npcx7m6fb/npcx7m7wb) when power-on reset. BRANCH=none BUG=none TEST=No build error for make buildall; Check IBBR(VSBY_STS/VCC1_STS) are cleared at initial when power-on reset. Check warining messages are printed and IBBR bit is cleared (in function system_check_bbram_on_reset and bbram_valid). Change-Id: I6dc1f5d7f35f9d591db62d1b022ea7b8d92f5b92 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1235733 Commit-Ready: CH Lin <chlin56@nuvoton.com> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> (cherry picked from commit dbc6feea3ed691a9f613e04af09bd8f3a28f5335) Reviewed-on: https://chromium-review.googlesource.com/1242205 Reviewed-by: Martin Roth <martinroth@chromium.org> Commit-Queue: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* npcx7: Report PSL_CTS on wake from hibernateFurquan Shaikh2018-09-181-0/+14
| | | | | | | | | | | | | | | | | | | | This is useful when debugging random wake issues from PSL hibernate to identify the actual cause of wake. BUG=b:115664415 BRANCH=None TEST=make -j buildall Change-Id: Id35be96aef2d73426781d0bf88bf5f6268bc3b6b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1225353 Commit-Ready: Jett Rink <jettrink@chromium.org> Tested-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1230994 Reviewed-by: Martin Roth <martinroth@chromium.org> Commit-Queue: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* Add CONFIG_GPIO_INIT_POWER_ON_DELAY_MSEdward Hill2018-09-183-3/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On power on, H1 releases the EC from reset but then quickly asserts and releases the reset a second time (so that the EC comes out of reset the second time after the SPI buffers have been configured by H1). Add a delay so the EC can wait for this second reset before configuring GPIO outputs, to avoid extra output toggles. Unfortunate the timer is not set up by the time gpio_pre_init() is called, so we add a new __hw_early_init_hwtimer() function to set it up so that mdelay() worked. Without that, mdelay() hangs. BUG=b:72132384 BRANCH=none TEST=GPIO_OUT_HIGH has a single rising edge after power on (before it would rise-fall-rise) Check that mdelay(10) delays for about 10ms (actually perhaps a little more using a scope line on KB_BL_EN Change-Id: Iadc96fceb190e43ac0758f291f22e03aef81c379 Signed-off-by: Edward Hill <ecgh@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/879353 Commit-Ready: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1230977 Reviewed-by: Martin Roth <martinroth@chromium.org> Commit-Queue: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* npcx: WoV: enhance the WoV driver and fix bugsCHLin2018-09-185-157/+401
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Firmware bugs fix: ---------------------------------------------------------------------- 1. wov mode change is malfunctional. 2. wov_set_mic_source set in VAD_0.VAD_INSEL field 0x3 when requested wov_mic_source is WOV_SRC_STEREO. 3. wov_set_mic_source doesn't disable I2S channel 1 when using only left or right channel. 4. wov_start/stop_ram_capture is called when needed by the driver, it is used in wov_set_mode. 5. Never activate Automatic wake-up enabled. VAD_0.VAD_ADC_WAKEUP remain '0' forever. 6. Set DMIC clock signal output to use fast transitions. (set DEVALTE.DMCLK_FAST to be '1'). 7. for VAD and RAM modes, DMIC clock setting should be 750 KHz. 8. for I2S mode (and RAM and I2S mode), DMIC clock should be 3 MHz. 9. fix issue "WoV driver may cause unsynchronized data in the I2S output" 10. fMUL2 clock tuning to LFCLK reference remain enabled when FMUL2 is enabled. 11. core-FIFO status bits in WOV_STATUS register are cleared when FIFO is reset. 12. i2S-FIFO status bits in WOV_STATUS register are cleared when FIFO is reset. 13. reset I2S FIFO when FIFO is underrun. 14. increase delay to 1msec when resets the FIFOs. 15. set MIC source prior start capturing data. 16. fix issue "enables ADC path in VAD mode when it isn't needed" 17. Increase delay in all places from 10Usec to 100Usec Firmware enhancement: ---------------------------------------------------------------------- 1. Add support for DMIC clock rate of 750 KHz and 1.2 MHz. 2. Add console command to enable/disable fmul2 tunning. > wov fmul2 <enable|disable> 3. Originally, the console command "wov cfgmod ram" will tie the function wov_set_mode(WOV_MODE_RAM) and start RAM capture together. In the CL, we split it into two console commands: > wov cfgmod ram > wov capram 4. Add APIs to set DMIC clk rate for different mode (VAD/RAM/I2S) and thier related console commands. > cfgdckV <0.75|1.0|1.2|2.4|3.0> > cfgdckR <0.75|1.0|1.2|2.4|3.0> > cfgdckI <0.75|1.0|1.2|2.4|3.0> This change allows to modify setting (ex: fmul2 tunning on/off) after the wov mode is set to RAM and before the voice capture to RAM starts. BRANCH=none BUG=b:74600211, b:74617334, b:72213375 TEST=No build errors for make buildall. TEST=Test bugs described above are fixed. TEST=Test enhancement described above is well functional. Change-Id: Id97b51fbd3e6e495d48aedf000a427538d91adf7 Signed-off-by: Dror Goldstein <dror.goldstein@nuvoton.com> Signed-off-by: Simon Liang <CMLiang@nuvoton.com> Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/942286 Commit-Ready: CH Lin <chlin56@nuvoton.corp-partner.google.com> Tested-by: CH Lin <chlin56@nuvoton.corp-partner.google.com> Tested-by: Scott Collyer <scollyer@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1230974 Reviewed-by: Martin Roth <martinroth@chromium.org> Commit-Queue: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* npcx: Change sleep in flash_wait_ready to 10usecFurquan Shaikh2018-09-171-15/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | flash_wait_ready had a sleep of 1 msec to check for busy bit status. This is too long of a wait for flash chip operation to complete and hence adds unnecessary delay during flash write. Changing the delay to 10usec helps cut the flash write time by 50%. This change reduces the delay to check busy bit to 10usec and also organizes the code slightly differently to use timestamp_expired() instead of decrementing timeout and checking it against 0. BUG=b:113530328 BRANCH=nocturne,grunt TEST=Verified that EC SW sync time is down to 3.4 seconds with this change. Change-Id: I5796ac3c493031c9623a9e5171ce9c5a7087089e Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1213553 Commit-Ready: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> (cherry picked from commit bd34ba0abea5246d47571eb12416b07b68b3c692) Reviewed-on: https://chromium-review.googlesource.com/1229134 Reviewed-by: Martin Roth <martinroth@chromium.org> Commit-Queue: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* tcpm: add TCPC RX circular buffer in ECJett Rink2018-09-101-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The alert line for TCPC will stay asserted as long as there are RX messages for the TCPM (i.e. EC) to pull from the TCPC. We should clear all of the RX messages we know about during a single alert handling session. This CL can stand on its own, but it is a part of a CL stack that will tighten the critical section of time between received messages from the TCPC and sending follow up message out through the TCPC. See go/usb-pd-slow-response-time for more details. BRANCH=none BUG=b:112088135,b:112344286,b:111909282,b:112848644,b:113124761 BUG=b:113057273,b:112825261 TEST=Reduces reset issue in most cases for phaser, bobba. Does not seem to adversely affect state machine negotiation. Full CL stack consistently sends a REQUEST at 18ms after a SRC_CAP GoodCRC, which is well below the 24 ms threshold we need to be under for USB PD spec compliance. Also testing pd_suspend scenario manually and EC was responsive after port 1 suspend because of "bad behavior" Change-Id: I1654b46400e9881f2927a5f6d6ace589edd182de Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1185727 (cherry picked from commit e8070b44b088e99e38ec741ed8091c7e4a033bef) Reviewed-on: https://chromium-review.googlesource.com/1215451 Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
* npcx: Decide erase size based on ro/rw region sizeFurquan Shaikh2018-09-065-10/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change updates the erase operation in npcx chip to use 64k/32k/4k block erase depending upon the alignment of CONFIG_RO_SIZE. This helps reduce the EC SW sync time from ~9.5 seconds to ~5.4 seconds on NPCX7. Ideally, we would want to check the offset and size of region to be erased dynamically and decide which erase operation to use. However, common flash code checks against CONFIG_FLASH_ERASE_SIZE to ensure that the area being erased is aligned to that size. Thus, even if we add dynamic erase at chip level, it isn't going to help. This change also updates CONFIG_FLASH_BANK_SIZE to be the same as CONFIG_FLASH_ERASE_SIZE since it is checked by common code. I am honestly not sure why the CONFIG_FLASH_BANK_SIZE is tightly coupled with CONFIG_FLASH_ERASE_SIZE. But, based on the usage, it seems to be a safe change. On the other hand, changing CONFIG_FLASH_BANK_SIZE helps reduce the write time as well, thus overall helping with the EC SW Sync time. Please see go/cros-npcx7-ec-sw-sync for more details. BUG=b:113530328 BRANCH=nocturne TEST=Verified that EC SW sync time goes down from 9.5 seconds to 5.4 seconds. Change-Id: I5908eeeb3e4207a27abe804db8eb9d39ef9d73c4 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1195598 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org> (cherry picked from commit 76e1d976246d90918e5f18d12d1df194b39cd90c) Reviewed-on: https://chromium-review.googlesource.com/1211365 Reviewed-by: Martin Roth <martinroth@chromium.org> Commit-Queue: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* chip/npcx: Tidy up comments for init_hw_timer()Simon Glass2018-09-062-2/+9
| | | | | | | | | | | | | | | | | | | The comments suggest that this function only operates with ITIM16 timers but it seems to support ITIM32 as well. Also it allows selecting the clock source. Update the comments, hopefully making them correct. BUG=chromium:876737 BRANCH=none TEST= make buildall -j50 Change-Id: Ic4ec2457cde2de55d51371f781d49bae80365989 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1185225 (cherry picked from commit e192f71aed932b88f3c42df4653a430a2e8ba10e) Reviewed-on: https://chromium-review.googlesource.com/1211362 Reviewed-by: Martin Roth <martinroth@chromium.org> Commit-Queue: Martin Roth <martinroth@chromium.org> Tested-by: Martin Roth <martinroth@chromium.org>
* stm32: usb_hid_touchpad: add 'device certification status' reportWei-Han Chen2018-08-311-0/+55
| | | | | | | | | | | | | | | 'device certification status' is expected by Precision Touchpad driver. BRANCH=none BUG=b:70482333 TEST=manual Signed-off-by: Wei-Han Chen <stimim@chromium.org> Change-Id: Ie71208e309378bbd604160f68a8313331a6d5308 Reviewed-on: https://chromium-review.googlesource.com/1188174 Commit-Ready: Wei-Han Chen <stimim@chromium.org> Tested-by: Wei-Han Chen <stimim@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* stm32: usb_hid_touchpad: add 'device capabilities' reportWei-Han Chen2018-08-311-0/+23
| | | | | | | | | | | | | | | 'device capabilities' report is expected by precision touchpad driver. BRANCH=none BUG=b:70482333 TEST=manual Signed-off-by: Wei-Han Chen <stimim@chromium.org> Change-Id: I8801f219cc76021f3519f0371f38bdc731dec287 Reviewed-on: https://chromium-review.googlesource.com/1188173 Commit-Ready: Wei-Han Chen <stimim@chromium.org> Tested-by: Wei-Han Chen <stimim@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* stm32: usb_hid: refactor to support `Get_Report` requestWei-Han Chen2018-08-314-34/+104
| | | | | | | | | | | | | | | | `Get_Report` request is required by USB HID standard. BRANCH=none BUG=b:70482333 TEST=manual on device Signed-off-by: Wei-Han Chen <stimim@chromium.org> Change-Id: I1543f019676259beb161db3195364998987ea529 Reviewed-on: https://chromium-review.googlesource.com/1188171 Commit-Ready: Wei-Han Chen <stimim@chromium.org> Tested-by: Wei-Han Chen <stimim@chromium.org> Reviewed-by: Wei-Han Chen <stimim@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* stm32: usb_hid_touchpad: add confidenceWei-Han Chen2018-08-311-31/+34
| | | | | | | | | | | | | | | | `confidence` is expected from a PTP-compliant touchpad BRANCH=none BUG=b:70482333 TEST=manual Signed-off-by: Wei-Han Chen <stimim@chromium.org> Change-Id: Ibe7166f43cae5fb36bbcc4e6dfd9ae6525a7225e Reviewed-on: https://chromium-review.googlesource.com/1188170 Commit-Ready: Wei-Han Chen <stimim@chromium.org> Tested-by: Wei-Han Chen <stimim@chromium.org> Reviewed-by: Wei-Han Chen <stimim@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* cr50: Release EC Reset on power button release when SuzyQ detected.Nick Sanders2018-08-291-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It complements crrev.com/c/1137434 in the way EC Reset got released. Instead of time-basis, it shall be released when the power button is released. The desired sequence of actions is: 0. (optional) Have a CR50 console and EC console connected to terminals. 1. Do a shutdown. 2. Press the power button and keep it pressed. 3. Plug a SuzyQ cable. 4. CR50 console shall be connected back, but not EC console. 5. Release the power button at any proper time, so that EC can restart. To keep EC from resetting, do "ecrst true" in CR50 console right after Step 4. It will invalidate Step 5. BRANCH=cr50 BUG=b:37351386 TEST=manually on Duts, Bob (Chrombook) and Sion (chromebox). (A) hard-reset A-1. Binary Download + Hold power button => no delay in EC reset. (B) Wake from hibernation B-1. (EC console) hibernate B-2. unplug all cables B-3. hold "POWER BUTTON" + plug SuzyQ cable => no delay in EC reset. (C) Power-on reset C-1. "REFRESH" + "POWER BUTTON" + unplug power cable. C-2. unplug SuzyQ cable C-3. plug SuzyQ cable => no delay in EC reset. (D) Power-on reset D-1. "REFRESH" + "POWER BUTTON" + unplug power cable. D-2. unplug SuzyQ cable D-3. hold "POWER BUTTON" + plug SuzyQ cable. => EC reset gets held. D-4. release "POWER BUTTON" ==> EC gets reset. (E) Power-on reset + explicit "ec_rst true" E-1. "REFRESH" + "POWER BUTTON" + unplug power cable. E-2. unplug SuzyQ cable E-3. hold "POWER BUTTON" + plug SuzyQ cable. => EC reset gets held. E-4. (CR50 console) ecrst true E-5. release "POWER BUTTON" ==> EC reset still gets held. (F) Power-on reset + explicit "ec_rst false" F-1. "REFRESH" + "POWER BUTTON" + unplug power cable. F-2. unplug SuzyQ cable F-3. hold "POWER BUTTON" + plug SuzyQ cable. => EC reset gets held. F-4. (CR50 console) ecrst false => EC gets reset. F-5. release "POWER BUTTON" ==> Nothing happens. (common) Press "POWER BUTTON" again, and check CR50 doesn't have any more "POWER BUTTON" release events. Changes to be committed: modified: board/cr50/board.c modified: board/cr50/board.h modified: board/cr50/power_button.c modified: chip/g/rbox.c Change-Id: Ic39c9ce7849fa3187e1d277320adf671f857d18d Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1192691 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* npcx7: Set booter RAM size to 2KBFurquan Shaikh2018-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | This change sets booter RAM size to 2KB as it was orignally configured. This was changed to 1KB in CL:858637, but there was no explanation about the change. Because of that, panic data would be lost on all NPCX7 boards. BUG=b:113274400 BRANCH=nocturne TEST=Verified that panic data is preserved on crash with various options on yorp. Change-Id: I15f578823ed06aed7cb064f3f76bd52d57fc6767 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/1192701 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* servo_micro: Allow setting the baud rate for usartNicolas Boichat2018-08-297-12/+40
| | | | | | | | | | | | | | | | | | | | | We set the baud rate in increments of 100 baud, to avoid overflowing the 16-bit wValue integer (921600 is the highest we are likely to use). Also, increment the buffer size for USART3 to 1024 bytes. That helps a bit to avoid losing characters, but we still can't keep up if the host is printing at maximum speed. BRANCH=servo BUG=chromium:876651 TEST=baud usart2/3/4 115200 in servo_micro console TEST=dut-control cpu_uart_baudrate:921600 seq 1 1000 shows numbers 1 to 226 before buffer overflows Change-Id: Ifca266189f93def493f207dd29d2cceca4d8d68f Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1189782 Reviewed-by: Nick Sanders <nsanders@chromium.org>
* rdd: use rdd_interrupt for rdd_connect/disconnectMary Ruthven2018-08-292-46/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Occasionally cc1 and cc2 might be in a valid debug range for a short time even if a debug accesssory isn't connected. The rdd hardware will debounce the signals long enough to make sure they're stable before triggering the Rdd interrupt. This change moves all rdd connect/disconnect logic to the interrupt instead of sampling the voltages in detect_rdd. In detect_rdd the samples of the cc lines falsely triggered rdd connect whenever the cc voltages happened to be in the valid debug range. We weren't waiting for Rdd to declare the voltage stable before running rdd connect. Moving the logic from rdd_detect to rdd_interrupt will ensure the signals are actually stable before we change the rdd state. BUG=b:113064204 BRANCH=cr50 TEST=manual connect suzyq reboot cr50 verify rdd is connected disconnect suzyq verify rdd is disconnected boot nami leave it up for a while make sure there aren't any false connects reconnect suzyq verify rdd is connected disconnect suzyq verify rdd is disconnected reboot cr50 verify rdd is disconnected run firmware_Cr50CCDServoCap and firmware_Cr50DeviceState Change-Id: I3eeaa39f79d2ccc3e997da291d8aae1f12103dc8 Signed-off-by: Mary Ruthven <mruthven@google.com> Reviewed-on: https://chromium-review.googlesource.com/1185967 Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Mary Ruthven <mruthven@chromium.org>
* npcx: don't clear DEVCNT_F_SPI_TRIS bit for chips that use intenal flashCHLin2018-08-261-1/+1
| | | | | | | | | | | | | | | | | | As documented in the datasheet, NPCX_DEVCNT_F_SPI_TRIS must be 1 for ECs that use internal flash (e.g., NPCX79nF and NPCX797W). BRANCH=none BUG=b:112906111 TEST=No build errors for make buildall. Flash image on npcx7_evb; check this bit is not cleared. Flash image on yorp; check the platform boots up to OS screen. Change-Id: I533553ad91ce0ecc79fc55b86aa83bbbcf514d89 Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1188180 Commit-Ready: CH Lin <chlin56@nuvoton.com> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Wai-Hong Tam <waihong@google.com>
* chip/npcx: Make check_reset_cause() staticSimon Glass2018-08-241-3/+2
| | | | | | | | | | | | | | | This function is not called from outside this file so make it static. Also drop a pointless comment, and rename the function since the 'system' prefix suggests it is defined in system.h (which it is not). BUG=chromium:876737 BRANCH=none TEST=make -j50 BOARD=grunt Change-Id: Ic429fb1da2e56e1888e008f4739c90e8ed2c1947 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1184975 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* cr50: only enable rbox wakeup during sleepMary Ruthven2018-08-233-2/+33
| | | | | | | | | | | | | | | | | | | | | | | Enable rbox wakeups before entering any form of sleep. Disable them immediately on resume. Without rbox wakeups enabled during normal operation, we don't need to worry about clearing them after every rbox interrupt. In TOT we missed clearing the power button rbox wakeup. This was causing cr50 to wake up immediately after entering regular sleep. It caused a ton of pmu interrupts and prevented cr50 from staying asleep. With this change cr50 enters enters sleep and deep sleep normally. It only resumes when there's a real wakeup. BUG=none BRANCH=cr50 TEST=verify power button can still wake cr50 from sleep and deep sleep. Run firmware_Cr50DeviceState with TOT Change-Id: I56bf81c19a6e32750dc9d21be7f27188635dd662 Signed-off-by: Mary Ruthven <mruthven@google.com> Reviewed-on: https://chromium-review.googlesource.com/1180572 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* CEC: Cleanup the API for the CEC buffer handlersStefan Adolfsson2018-08-221-51/+55
| | | | | | | | | | | | | | | | Since this now lives in common/, make it look a bit nicer. Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org> BUG=b:80288314 BRANCH=none TEST=emerge-fizz chromeos-ec && make -j runtests Change-Id: I2fb10e2524af13c776ea067d8a24b4cd552c9ecb Reviewed-on: https://chromium-review.googlesource.com/1073416 Commit-Ready: Stefan Adolfsson <sadolfsson@chromium.org> Tested-by: Stefan Adolfsson <sadolfsson@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* CEC: Make buffer handling code unit testableStefan Adolfsson2018-08-221-158/+1
| | | | | | | | | | | | | | | | | | | Moving code to common/ to be able to write some unit test. The API in cec.h will be refactored in a later commit since it does not look so nice for a common API. However, it is better to do the refactoring after the unit tests are in place Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org> BUG=b:80288314 BRANCH=none TEST=emerge-fizz chromeos-ec Change-Id: I2d675689cc40248d74bf812bd6c86125d681767d Reviewed-on: https://chromium-review.googlesource.com/1073414 Commit-Ready: Stefan Adolfsson <sadolfsson@chromium.org> Tested-by: Stefan Adolfsson <sadolfsson@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: minor code style touch-up on a bitbang code.Namyoon Woo2018-08-172-55/+42
| | | | | | | | | | | | | | | | | | | | | | | | | Fix 1. removed unnecessary semicolons. Fix 2. enumerated parity types for code readibility. Fix 3. ensured the bool value is passed to gpio_set_level() as val. Fix 4. converted uart_bitbang_config() to static. Fix 2 and 3 save 56 bytes, and Fix 4 saves 72 bytes in flash. BUG=b:65253310 BRANCH=cr50 TEST=manually performed flash_ec, and checked version info at EC console. (chroot)$ ./util/flash_ec --board=scarlet --bitbang_rate 57600 --image=build/scarlet/ec.bin Changes to be committed: modified: chip/g/uart_bitbang.c modified: chip/g/uart_bitbang.h Signed-off-by: Namyoon Woo <namyoon@chromium.org> Change-Id: I6cea649b908e269d32e547987121621911301a72 Reviewed-on: https://chromium-review.googlesource.com/1179238 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* i2c: Split i2c_xfer into locked/unlocked versions.Jonathan Brandmeyer2018-08-161-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename i2c_xfer to i2c_xfer_unlocked. Audit all users of i2c_xfer to see if they can use simple locking semantics or require their own locking. Since locked accesses are only safe for I2C_XFER_SINGLE transactions, remove the flags parameter from i2c_xfer. This also makes the audit a bit easier. Some remaining applications hold the bus locked across several transactions that would otherwise be atomic, and a few others implement complex I2C transactions in multiple commands. Add a (nondeterministic) verification on the I2C port locking correctness. This will catch all statically incorrect locking patterns, although dynamically incorrect locking patterns may not be caught. Related: Revise the i2c_port_active_count to be a bitmap of the active ports instead of a count of the active ports. The EC's mutex does not provide an is_locked() primitive, and we would prefer not to have one. - board/glados: Custom locking for battery reset - board/mchpevb1: Custom locking for battery reset - board/oak: Custom locking for battery reset - board/samus: Custom locking for lightbar reset - board/sweetberry: simple locking - board/servo_micro: Custom locking for funky i2c transfers - capsense: simple locking - host_command_master: multi-command transactions - lb_common: manual locking to support samus power sequence - smbus: multi-command transactions - usb_i2c: simple locking - driver/tcpm/fusb302: simple locking and multi-command transactions - driver/tcpm/tcpi: Forward _unlocked and implicitly locked interface to fusb302 - driver/touchpad_elan: simple locking BUG=chromium:871851 BRANCH=none TEST=buildall; very careful audit TEST=grunt clamshell and Coral clamshell, test boot, battery charging, PD communication, and TCPC port low-power mode. Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Change-Id: Ieabf22bcab42780bdb994fca3ced5d8c62519d56 Reviewed-on: https://chromium-review.googlesource.com/1169913 Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* test: host_command_fuzz: fuzzing testNicolas Boichat2018-08-164-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Writing fuzzing tests is a little tricky, as clang takes over the main function. Instead, we start the test main function in a thread, and have LLVMFuzzerTestOneInput prepare the host command buffer, and wake the TEST_RUNNER task. To make fuzzing faster, we only send somehow correctly formed requests, with a valid checksum and length (this can be disabled with an option). We also make sure that the emulator does not hibernate, reboot or jump to a different image when fuzzing is enabled. BRANCH=none BUG=chromium:854975 TEST=make buildfuzztests -j ASAN_OPTIONS="log_path=stderr" \ build/host/host_command_fuzz/host_command_fuzz.exe -timeout=5 Change-Id: I27b25e44c405f118dfc1296247479245e15e54b4 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1107523 Reviewed-by: Manoj Gupta <manojgupta@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Jonathan Metzman <metzman@chromium.org>
* cr50: speed up bit bang EC programmingVadim Bendebury2018-08-164-264/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original bit bang programming implementation attempted to provide a fully functional alternative UART interface for the case when EC programming is required, so that proper UART parity can be ensured. Come to think of it, this is not really necessary: - EC programming over UART does not require full duplex. - when EC is being programmed, the AP is held in reset, there is no need to support AP console or TPM at that time, as a result interrupts could be disabled for somewhat longer intervals. This patch introduces the following modifications: - remove uartn interface redirections - when bitbang mode is enabled regular EC console is not available. - instead of waiting for fixed amount of cycles on every bit, wait for the deadline calculated when character transmission started on tx side or when the original start bit was detected on rx side and recalculated after each clock. - when finishing receiving a character do not exit ISR right away, spin for a duration of a character polling the rx line, in case the EC keeps transmitting. The rx buffer is allocated on the ISR stack and is limited to 20 bytes, which would probably cause an overrun if this interface were used for reading flash contents from the EC. - connect USB EC console flow directly to the bit bang driver when bit bang mode is enabled and disable interrupts from the EC UART. - do not use the GPIO wrappers for bit bang interrupt processing - it takes too long. - when starting a bit bang session set the clock timer value to zero, this allows not to worry about wraparound, which will happen in almost 3 minutes, programming session should not take this long. - for the duration of 'bit bang enabled' state servo detection interrupt is disabled, it gets re-enabled after bit bang mode is disabled and servo_detect() gets to run on 1s hook. - it is not enough to check the DIOB5 pinmux state to tell if EC UART is connected or not, as this pin could be connected in bit bang mode as well; always report EC TX UART as disconnected when bit bang mode is enabled. - for the duration of bit bang programming session suppress 'aggregate' GPIO interrupts, triggered per port when GPIO interrupt is asserted. Additional speed up could be achieved if gpio driver wrappers were replaced with direct register accesses, but even as presented this patch allows to reliably program the STM32 on Scarlet at 57600 baud, which is 6 times faster than the current state. BRANCH=cr50, cr50-mp BUG=b:62539385 TEST=with some flash_ec modifications which make sure that bit bang mode is enabled properly (fixing timing of setting boot0 and resetting the EC), Scarlet device EC can be reprogrammed at 57600 baud 100 times in a row with and without logic analyzer connected to the EC UART pins. Change-Id: I2e3520f158943323cb015fa18650a7e177f03cc3 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1171221 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* it83xx: gpio: Set KSO/KSI pins to GPIO mode by gpio_set_flags_by_maskDino Li2018-08-161-6/+8
| | | | | | | | | | | | | | | With this change, we can reconfigure KSO/KSI pins as GPIO mode by calling gpio_set_flags_by_mask(). BUG=b:111006203 BRANCH=none TEST=Declare KSO/KSI signal with GPIO_INPUT flag and check if these pins work as GPIO input. Change-Id: I3b1fcc989745da08898d2f254dedc9655fd0ef83 Signed-off-by: Dino Li <Dino.Li@ite.com.tw> Reviewed-on: https://chromium-review.googlesource.com/1163584 Reviewed-by: Jett Rink <jettrink@chromium.org>
* cr50: bitbang does not need to support multiple UARTs.Vadim Bendebury2018-08-153-85/+50
| | | | | | | | | | | | | | | | | | | | | | | | The ability to support multiple UART interfaces complicates bit bang EC programming implementation without bringing any real benefits - we are not going to have to bit bang more than one UART interface in real Chrome OS hardware. In preparation in introducing bit a bang speed up patch let's change the API to not require passing the UART number to bit bang functions. To keep servod happy for now, the 'bitbang' cli command is being left unchanged and as such still requires to pass the UART number, it is just ignored. BRANCH=cr50, cr50-mp BUG=b:62539385 TEST=just verified that Cr50 still builds, the real test is done in the speed up patch. Change-Id: Icd5476ad777791ca483844cbf49316ddf58f03a3 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1171220 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* chip/npcx/cec: Expose cec_isr to help linkerPatrick Georgi2018-08-101-1/+1
| | | | | | | | | | | | | | | | | | | | In LTO mode (which we use) the linker partitions the object files and does some optimizations in parallel, including dead code elimination. For DCE two criteria are used: 1. the symbol is used within the current partition 2. the symbol is exported static void cec_isr() wasn't exported and if it ended up in a different partition from the code created by DECLARE_IRQ, it was eliminated just to be declared missing in the final link step. Change-Id: I404c73709602c6126558f54cd2a8d045d8e9784f Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://chromium-review.googlesource.com/1169481 Commit-Ready: Patrick Georgi <pgeorgi@chromium.org> Tested-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* servo_micro: Add enable_ite_dfu and get_ite_chipid console commands.Matthew Blecker2018-08-091-0/+18
| | | | | | | | | | | | | | | | | | | enable_ite_dfu: Enable direct firmware update (DFU) over I2C mode on ITE IT8320 EC chip by sending special non-I2C waveforms over the I2C bus wires. get_ite_chipid: Verify that DFU mode is enabled by querying the EC over I2C for its CHIPID1 and CHIPID2 registers. It will only respond over I2C when in DFU mode. BRANCH=none BUG=b:79684405 TEST=get_ite_chipid succeeds after enable_ite_dfu Change-Id: Ief2c12ebd902285ea3d285767deb8d35c0017592 Signed-off-by: Matthew Blecker <matthewb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1152565 Reviewed-by: Nick Sanders <nsanders@chromium.org>
* it83xx: Restore reset flag from BRAM during startupNaresh G Solanki2018-08-071-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | During recovery mode switch using wait-ext & ap-off followed by cold reset assertion, reset flag from BRAM was ignored & hence EC continued power on sequence instead of keeping AP in off state. This caused failure in recovery mode switch in FAFT. Also there is no mechanism to verify VBAT power loss. Now that content of BRAM is validated using magic value during startup, restore reset flag from BRAM. BUG=b:80703195 BRANCH=master TEST= Build coreboot image for BIP & run firmware_FAFTSetup test & make sure test passes i.e., DUT successfully switches to recovery mode & boots from USB storage(pendrive). Change-Id: I01a7c9ed2c0e32435a064d9de99c06d6fa505e0b Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com> Reviewed-on: https://chromium-review.googlesource.com/1140174 Commit-Ready: Naresh Solanki <naresh.solanki@intel.com> Tested-by: Naresh Solanki <naresh.solanki@intel.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* cr50: delay EC boot when Rdd detects SuzyQ at boot time.Namyoon Woo2018-08-073-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EC_RST_L deassertion shall be delayed two seconds if two conditions below are satisfied. 1. Power button is pressed. 2. RDD detectes a debug cable. This is to gain some time to issue a command to prevent a broken EC from booting. BUG=b:37351386 BRANCH=cr50 TEST=manually on dut with DELAY_EC_BOOT_USEC defined as 30 sec. (1) hard-reset Binary Download + Hold power button => no delay. (2) Wake from hibernation - (ec) hibernate - unplug all cables - Hold power button + plug SuzyQ cable => no delay. (3) Power-on Reset - (ec) cutoff - unplug all cables - Hold power button + plug SuzyQ cable => delay! (4) Power-on Reset, no delay - (ec) cutoff - unplug all cables - plug SuzyQ cable => no delay. Change-Id: I29a1a97c053cdb898ac6ac8dc2409d5d164552d9 Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1137434 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
View Lorry Controller Status