summaryrefslogtreecommitdiff
path: root/chip
Commit message (Collapse)AuthorAgeFilesLines
* chip: stm32: Fix Timers 9 through 11 for STM32F4Moritz Fischer2019-03-163-2/+8
| | | | | | | | | | | | | | | | | | The timers 9 through 11 have different enable bits in the STM32_RCC_APB2ENR on STM32F446/411/412 targets versus the default (used by STM32F4/L4/STM32L) value set. Break out the CHIP_FAMILY_STM32F4 case separately. BRANCH=none BUG=none TEST=Observe PWM output on STM32412 EVM vs none before Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Change-Id: I9f00902afe58ef8ef141da39b2b912ecc592944b Reviewed-on: https://chromium-review.googlesource.com/1493273 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* kukui: scp: fix ULPOSC index using 0 base numberingRong Chang2019-03-161-15/+14
| | | | | | | | | | | | | | | | | | Where ULPOSC1 should be 0 and ULPOSC2 is 1. BRANCH=none BUG=b:125616659 TEST=manual Check scp console comamnd: > ulposc still output correct ULPOSC1 and ULPOSC2 clock in MHz. Change-Id: I3730ebb83bbe5e0021360116dbd37bcccdbc77aa Signed-off-by: Rong Chang <rongchang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1520570 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* kukui: scp: fix ULPOSC configuration and add OSC clock measurementRong Chang2019-03-162-53/+113
| | | | | | | | | | | | | | | | | | | | The initial clock change turned on wrong clock gate while enabling ULPOSC2. This change fixed clock gate and ULPOSC configuration. A clock measuring console command is added to check clock speed. BRANCH=none BUG=b:120176040,b:125616659,b:124472114 TEST=manual Build and load on kukui. Check console command out: > ulposc ULPOSC1 frequency: 210 MHz ULPOSC2 frequency: 271 MHz Change-Id: I19e637d97bc125a1bbfd102a5fc5ec24573d9e09 Signed-off-by: Rong Chang <rongchang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1485040 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* kukui: scp: fix wrong logic on checking ULPOSC numberRong Chang2019-03-161-1/+1
| | | | | | | | | | | | | | | | | The logic should be either OSC1 or OSC2. BRANCH=none BUG=b:125616659 TEST=manual rw 0xA000C708 bit 23 should be 1 Change-Id: I15f75f37b09bde04e7d23aebe549f3ec49767783 Signed-off-by: Rong Chang <rongchang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1488636 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* kukui: scp: move clock and oscillator configuration code to clock.cRong Chang2019-03-163-109/+119
| | | | | | | | | | | | | | | | To implement ULPOSC calibration, clock and oscillator APIs are moved from system to its own module. BRANCH=none BUG=b:120176040 TEST=manual make BOARD=kukui_scp -j Change-Id: I143b331f5d36cd0d0964920a9b7e7fe00afb6e3b Signed-off-by: Rong Chang <rongchang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1488635 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* kukui: scp: set CPU clock to ULPOSC2Rong Chang2019-03-162-0/+6
| | | | | | | | | | | | | | | | | | | | SCP CPU clock source can be sourced from 26MHz system clock, 32K low speed clock, and 2 high speed sources ULPOSC1, ULPOSC2. ULPOSC2 is enabled to run at 330MHz by default. This CL switch CPU to ULPOSC2 after enabling the source. BRANCH=none BUG=b:125616659 TEST=manual check current clock source using console command: > rw 0x405C4000 read 0x405c4000 = 0x00000803 Change-Id: I11672e2eb5b5a3ebebdf2a21a6ebed83b4535ee5 Signed-off-by: Rong Chang <rongchang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1482631 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* clock: define the function clock_enable_module to all EC chipsCHLin2019-03-131-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | The API clock_enable_module(MODULE_FAST_CPU, x) allows common layer code to set the CPU frequency to turbo or normal when it is needed. However, not all of the EC chips support/implement the function. It causes build error if this function is added to the common codes which most of EC chips will use (EX: vboot_hash.) This CL fixes this issue by defining the function as weak by default. This CL also implements the clock_enable_module function for NPCX7 chip. BRANCH=none BUG=b:77608104 TEST=pass "make buildall" TEST=on npcx7_evb/yorp, with follow-up CL, check that security computation becomes faster and the clock goes back to normal frequency after the computation finishes. Change-Id: I731fb38f5fc1a4efa5fb331a59f8c3e2803ca30a Signed-off-by: CHLin <CHLIN56@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1475097 Commit-Ready: CH Lin <chlin56@nuvoton.com> Tested-by: CH Lin <chlin56@nuvoton.com> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* adc-stm32f0: initialize adc upon invocation of channel readYH Lin2019-03-131-36/+38
| | | | | | | | | | | | | | | | In some scenarios ADC read needs to be done before hook_init handler take place therefore calling adc_init() directly upon invocation of adc_read_channel, instead of waiting for the hook_init handler to initialize adc. BUG=b:126770302 BRANCH=None TEST=Test together with CL:1507320. Change-Id: I8161e8a2d0051e01804e47eb87f28b3548f1d2ac Signed-off-by: YH Lin <yueherngl@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1515821 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* mt_scp: Check for IPI_NS_SERVICE in ipi_send.Pi-Hsun Shih2019-03-121-0/+5
| | | | | | | | | | | | | | | | | Since the IPI_NS_SERVICE is send-only, there's no corresponding IPI handler on the SCP side, and the IPI ID is 0xFF which is outside of the table range. Check that the IPI ID is not IPI_NS_SERVICE before checking if the IPI is a wakeup source. BUG=b:126535633 TEST=build BRANCH=none Change-Id: Id8b67be235afd9606b8d09257c7938a2695bcc0b Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1498953 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Yilun Lin <yllin@chromium.org>
* mt_scp/ipi: Support host event over IPI.Yilun Lin2019-03-121-4/+37
| | | | | | | | | | | | | | | | | | | | mt_scp doesn't support GPIO-interrupt-based and mkbp_event-based host event. This CL enables host event over IPI, and shares the same IPI channel with host command, and use an extra byte to distinguish the host command and host event. BUG=b:120808999 TEST=run FW on kukui, and set host_event via hostevent set 0x111 and see AP sends host command: EC_CMD_GET_NEXT_EVENT [33.737487 HC 0x67] to querry event. BRANCH=None Change-Id: I741718e24aa107da3ec1733bdbb8482f16c8a38d Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1411432 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* arcada_ish: Send MKBP events over HECIMathew King2019-03-111-7/+50
| | | | | | | | | | | | | | | | This adds a 4 byte header to the HECI messages so that host commands and MKBP events can share the same HECI client. BUG=b:123634700 TEST=make buildall -j, turning on the FIFO and to enable these events is in the next cl BRANCH=none Change-Id: I3fe8dd4356bceba26ef3bf1fbff7906c5c4bf75e Signed-off-by: Mathew King <mathewk@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1506414 Tested-by: Jett Rink <jettrink@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* Reland "npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is ↵Mulin Chao2019-03-073-20/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | zero." This is a reland of 93d7bcea8121869520b0d02bf94f95eb261bee05 with a fix for fan_is_stalled. Original change's description: > npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is zero. > > In npcx pwm driver, it turns off pwm module directly when its duty cycle > is set to zero. But we saw pwm signal isn't turned off by the following > sequence: > 1. pwm_set_raw_duty(ch, 0); > 2. pwm_enable(ch, 1); > > Please notice setting zero in DCRn doesn't mean duty cycle is zero. > (NPCX duty cycle: ( (DCRn+1) / (CTRn+1) ) x 100). Hence in step 2, we > can observe a very low duty cycle once the driver enables pwm module. > > According to figure. 24 in npcx5's datasheet, setting DCRn greater than > CTRn means that the result of 16-bits comparator is always false. It > equals the duty cycle is zero. This CL adopts this method to present it > and removes the dependency between pwm_enable()/ pwm_get_enabled() and > pwm_set_raw_duty()/pwm_get_duty(). > > In order to make sure DCRn can be greater than CTRn, we also defined > the PWN maximum duty cycle is (0xFFFF -1) since both DCR and CTR are > 16-bits registers. > > BRANCH=none > BUG=b:123552920 > TEST=No build errors for npcx5/7 series. > > Test pwm console command on npcx5/7 evbs by the following sequence. > 1. pwm_set_raw_duty(ch, 0); > 2. pwm_enable(ch, 1); > And no symptoms are observed. PWM_CONFIG_ACTIVE_LOW flag is tested also > and no symptom occurred. > > Test fan control by faninfo & fanset console commands. Connect Sunon > 4-pins PWM fan and evb by following steps: > 1. Connect PWM0 to PWM pin of fan. > 2. Connect TA1_TACH1 and 3.3 PU on Tacho pin of fan. > 3. Connect 5V and GND pins of fan to power supply. > No symptoms are observed. > > Change-Id: I92517ff0bf3e027ae191be00112cd71ec4b55a2b > Signed-off-by: Mulin Chao <mlchao@nuvoton.com> > Reviewed-on: https://chromium-review.googlesource.com/1475096 > Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> > Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Bug: b:123552920 Change-Id: I4ea76c51811507ee4a35e5c0edfb70e9fb6c4c8b Reviewed-on: https://chromium-review.googlesource.com/1506115 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* kukui_scp/ipi: Clarify ipi_send() signature.Yilun Lin2019-03-072-2/+2
| | | | | | | | | | | | | | | | ipi_send() shuold not modify the buffer argument. This CL changes argument type from 'void *' to 'const void *'. TEST=make BOARD=kukui_scp -j BUG=b:120808999 BRANCH=None Change-Id: I1e629c7d6ba6902df1e8e2a21b7ac29bf3dffebf Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1490796 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Pi-Hsun Shih <pihsun@chromium.org>
* chip: stm32: Fix GPIO base addresses for STM32F4/LMoritz Fischer2019-03-061-3/+12
| | | | | | | | | | | | | | | | | | The CHIP_FAMILY_STM32L has the base addresses for the GPIO F, G and H banks swapped w.r.t CHIP_FAMILY_STM32F4 and the alphabetic order vs the base addresses. Break out the CHIP_FAMILY_STM32F4 case in the registers file, such that GPIOH bank works for both cases. BUG=none BRANCH=none TEST=Use pin PH0 on STM32F412/11, observe it actually toggling Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Change-Id: I9a639c4872f6e4c5b384cdab9e3da2f626e32227 Reviewed-on: https://chromium-review.googlesource.com/1481650 Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* Revert "npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is ↵Daisuke Nojiri2019-03-062-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | zero." This reverts commit 93d7bcea8121869520b0d02bf94f95eb261bee05. Reason for revert: fan_is_stalled is broken Original change's description: > npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is zero. > > In npcx pwm driver, it turns off pwm module directly when its duty cycle > is set to zero. But we saw pwm signal isn't turned off by the following > sequence: > 1. pwm_set_raw_duty(ch, 0); > 2. pwm_enable(ch, 1); > > Please notice setting zero in DCRn doesn't mean duty cycle is zero. > (NPCX duty cycle: ( (DCRn+1) / (CTRn+1) ) x 100). Hence in step 2, we > can observe a very low duty cycle once the driver enables pwm module. > > According to figure. 24 in npcx5's datasheet, setting DCRn greater than > CTRn means that the result of 16-bits comparator is always false. It > equals the duty cycle is zero. This CL adopts this method to present it > and removes the dependency between pwm_enable()/ pwm_get_enabled() and > pwm_set_raw_duty()/pwm_get_duty(). > > In order to make sure DCRn can be greater than CTRn, we also defined > the PWN maximum duty cycle is (0xFFFF -1) since both DCR and CTR are > 16-bits registers. > > BRANCH=none > BUG=b:123552920 > TEST=No build errors for npcx5/7 series. > > Test pwm console command on npcx5/7 evbs by the following sequence. > 1. pwm_set_raw_duty(ch, 0); > 2. pwm_enable(ch, 1); > And no symptoms are observed. PWM_CONFIG_ACTIVE_LOW flag is tested also > and no symptom occurred. > > Test fan control by faninfo & fanset console commands. Connect Sunon > 4-pins PWM fan and evb by following steps: > 1. Connect PWM0 to PWM pin of fan. > 2. Connect TA1_TACH1 and 3.3 PU on Tacho pin of fan. > 3. Connect 5V and GND pins of fan to power supply. > No symptoms are observed. > > Change-Id: I92517ff0bf3e027ae191be00112cd71ec4b55a2b > Signed-off-by: Mulin Chao <mlchao@nuvoton.com> > Reviewed-on: https://chromium-review.googlesource.com/1475096 > Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> > Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Bug: b:123552920 Change-Id: Iece29c665d3a7518159514291f3c17a7b58c3284 Reviewed-on: https://chromium-review.googlesource.com/1505014 Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org> Tested-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* cr50: use closed loop reset based on board propertyMary Ruthven2019-03-061-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the closed loop reset when cr50 needs to reset the device. Cr50 expects the board to reset in three places: board_reboot_ap, board_reboot_ec, or during init after any cr50 reset other than deep sleep. This change modifies these to use the closed loop reset if the board property is set. In board_reboot_ap and board_reboot_ec it calls board_closed_loop_reset instead of doing the normal reset steps if the board property is set. In init_ap_detect call board_closed_loop_reset if cr50 just resumed from any reset other than hibernate. Don't trigger the tpm_rst_isr manually. BUG=b:123544145 BRANCH=cr50 TEST=manual Flash firmware that supports resetting the AP when EC_RST_L is asserted. Reboot cr50 and verify deferred_tpm_rst_isr is only called after tpm_rst_asserted. Open Cr50. Verify the AP is reset Flash old Mistral firmware which seems to take around 12 seconds for the warm reset to happen. Boot the AP. Reboot cr50 while the AP is up. The AP wont reset for a while. While the AP is still up, verify Cr50 keeps EC_RST_L asserted, the AP state is Unknown, and tpm commands fail while the AP is in this state. Eventually the AP resets. Make sure the TPM becomes usable again and the AP state is on. Change-Id: I6f0e8728717f1ed35c96b2669f1796078ebf93f7 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1447001 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* npcx: pwm: Use DCRn greater than CTRn to present its duty cycle is zero.Mulin Chao2019-03-052-15/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In npcx pwm driver, it turns off pwm module directly when its duty cycle is set to zero. But we saw pwm signal isn't turned off by the following sequence: 1. pwm_set_raw_duty(ch, 0); 2. pwm_enable(ch, 1); Please notice setting zero in DCRn doesn't mean duty cycle is zero. (NPCX duty cycle: ( (DCRn+1) / (CTRn+1) ) x 100). Hence in step 2, we can observe a very low duty cycle once the driver enables pwm module. According to figure. 24 in npcx5's datasheet, setting DCRn greater than CTRn means that the result of 16-bits comparator is always false. It equals the duty cycle is zero. This CL adopts this method to present it and removes the dependency between pwm_enable()/ pwm_get_enabled() and pwm_set_raw_duty()/pwm_get_duty(). In order to make sure DCRn can be greater than CTRn, we also defined the PWN maximum duty cycle is (0xFFFF -1) since both DCR and CTR are 16-bits registers. BRANCH=none BUG=b:123552920 TEST=No build errors for npcx5/7 series. Test pwm console command on npcx5/7 evbs by the following sequence. 1. pwm_set_raw_duty(ch, 0); 2. pwm_enable(ch, 1); And no symptoms are observed. PWM_CONFIG_ACTIVE_LOW flag is tested also and no symptom occurred. Test fan control by faninfo & fanset console commands. Connect Sunon 4-pins PWM fan and evb by following steps: 1. Connect PWM0 to PWM pin of fan. 2. Connect TA1_TACH1 and 3.3 PU on Tacho pin of fan. 3. Connect 5V and GND pins of fan to power supply. No symptoms are observed. Change-Id: I92517ff0bf3e027ae191be00112cd71ec4b55a2b Signed-off-by: Mulin Chao <mlchao@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/1475096 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* kukui_scp: Add rpmsg name service.Peter Shih2019-03-042-0/+25
| | | | | | | | | | | | | | | | rpmsg name service provide a way for firmware to announce available rpmsg channels and its IPI id to AP, without AP having to hard-code all the IPI ids. BUG=b:120953723 TEST=manually BRANCH=none Change-Id: I8ec539a45b58f20e70a798ede4abaad5a7bb4360 Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1389986 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Yilun Lin <yllin@chromium.org>
* makefile: add manifest header supportJett Rink2019-03-042-1/+66
| | | | | | | | | | | | | | | | | | The ISH FW image needs to have a static manifest header prepended to built ISH image before it can be loaded on to hardware. The header we prepend is static and is the bare minimum to make the corresponding shim loader work correctly. BRANCH=none BUG=b:122371717,b:124788278 TEST=ec.bin output will chain load properly when sent to the kernel driver. Change-Id: I5458782d70308c99e297b823fd085a74480d252e Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1490671 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
* ec: Cleanup ish config optionsMathew King2019-03-014-496/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Remove all ISH related CONFIG_* options except for: CONFIG_HOSTCMD_HECI: This will be used to enable the host command interface using HECI. Similar to CONFIG_HOSTCMD_LPC or CONFIG_HOSTCMD_ESPI. arcada_ish uses this config. CONFIG_HID_HECI: This will be used to enable a HID interface using HECI. It is compatible with the intel-ish-hid kernel driver. atlas_ish uses this config. Also remove ipc.c the functionality it has been superceded by ipc_heci.c. BUG=b:123634700 TEST=Built and tested on a arcada device Verified that atlas_ish builds BRANCH=none Change-Id: I9d97693e2beca1c9fec8c4f17bd3706b0ea8e795 Signed-off-by: Mathew King <mathewk@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1490551 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* ec: cleanup: Add CONFIG_RTCJack Rosenthal2019-03-016-3/+8
| | | | | | | | | | | | | | | | | | This allows the chipset task to print RTC information, without requiring CONFIG_CMD_RTC to be enabled. BUG=chromium:649851 BRANCH=none TEST=Built and flashed on grunt (careena), confirmed RTC state printed when the power state was changed, but without RTC command present Change-Id: I6b11c4d2822117c57febdacf299a865710ed1edd Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1490672 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Raul E Rangel <rrangel@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* stm32: spi: fix link to bug in commentsNicolas Norvez2019-02-271-3/+3
| | | | | | | | | | | | | Wrong link makes it harder to find the issue at hand, fix the URL BRANCH=none BUG=b:35539666 TEST=none Change-Id: I71bb069c43e540d101cdb60d6fa6f5d4e90a4d13 Signed-off-by: Nicolas Norvez <norvez@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1481661 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* audio_codec: Implement NPCX version of audio host command functionsCheng-Yi Chiang2019-02-272-0/+163
| | | | | | | | | | | | | | | | | | | | | This CL implements the host sub command functions for the audio codec by adding calls to the appropriate wov driver API functions. BRANCH=none BUG=b:116766596 TEST=On cheza verifed recording works using the following kernel commands and the loading the audio file into audacity. amixer -c 0 cset iface=MIXER,name='MultiMedia1 Mixer SEC_MI2S_TX' on amixer -c0 cset numid=27 30,30 arecord -D hw:0,0 -f dat /tmp/rec.wav -d 5 Change-Id: Ifda8f94ce6bbe35a715b04b1fb8cbec8d9c3922c Signed-off-by: Scott Collyer <scollyer@google.com> Reviewed-on: https://chromium-review.googlesource.com/1356185 Commit-Ready: Gwendal Grignou <gwendal@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Wai-Hong Tam <waihong@google.com>
* ish: fix LAPIC error by sending EOI to IOAPIC RTERong Chang2019-02-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | ISH APIC has a bug when sending multiple IOAPIC interrupts to LAPIC at the same time, there's a small chance that the IRR (interrupt request register) states are not sync between LAPIC and IOAPIC REDTBL (redirection table). LAPIC raises internal error with error code 'receive illegal vector' in ESR. This CL handles above LAPIC local vector table error condition by comparing LAPIC IRR bits with IOAPIC REDTBL entries. And sends EOI (end of interrupt) to IOAPIC RTE if corresponding vector in LAPIC IRR was not set. BRANCH=none BUG=b:112750896,b:124128140 TEST=manual Cherry pick stress test program CL:1372875 and load on Atlas. Place a touch tester on TP and connect to ground. Chech console LAPIC error count and IOAPIC pending count. Change-Id: I1cddc91b2eca35719a83415f1548379574219a58 Signed-off-by: Rong Chang <rongchang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1411953 Reviewed-by: Jett Rink <jettrink@chromium.org>
* ish: add reboot supportJett Rink2019-02-262-9/+15
| | | | | | | | | | | | | | | Make the `reboot` EC commands (console and host) operational BRANCH=none BUG=none TEST=`reboot` on ISH console will power cycle ISH Change-Id: I2dfb4437bf110493cea91087c65b62df5d08be05 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1483278 Reviewed-by: Li1 Feng <li1.feng@intel.com> Reviewed-by: Edward Hill <ecgh@chromium.org> Commit-Queue: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
* ish: add reset prep interrupt handleyangcao2019-02-263-0/+70
| | | | | | | | | | | | | | | | | Upon reset prep interrupt from PMC, ISH HW will do warm reset. Before full stack of power management in place, this workaround will help fix S5 issue. BRANCH=none BUG=b:123528909 TEST=run "reboot" from host, ISH reboots too. Change-Id: I421ec25a198eb91672ffe770566a4edbe4855fee Signed-off-by: yangcao <yang.a.cao@intel.com> Signed-off-by: li feng <li1.feng@intel.com> Reviewed-on: https://chromium-review.googlesource.com/c/1476299 Reviewed-by: Jett Rink <jettrink@chromium.org> Commit-Queue: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
* ish: adjust timers for ISH 4/5 32kHz clockJett Rink2019-02-262-127/+178
| | | | | | | | | | | | | | | | | | | | | | | The main timer for ISH 4/5 is a 32kHz clock so we need to adjust the current hardware timer interface to scale it correctly. Also, the timer has problems staying armed without 1) ensuring the timer is at least 25 ticks in the future 2) waiting for the status register to specify that the timer1 updates have actually been written to the hardware BRANCH=none BUG=b:123762212 TEST=events are firing correctly on arcacda_ish in motion sense task with testing CL. Otherwise polling would stall completely Change-Id: I5d3a32df96e0290dc0381738689cc3f2d5fd430f Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1457597 Reviewed-by: Edward Hill <ecgh@chromium.org> Commit-Queue: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
* ish: add cros_ec command interface over heciJett Rink2019-02-262-0/+112
| | | | | | | | | | | | | | | | | | | | Implement the cros_ec host command V3 interface using the HECI (and ISHTP client) transport layer with the host. To work, the kernel needs a cros_ec over heci implementation (which is also under development) BRANCH=none BUG=b:123075957,b:120295222 TEST=using this CL and draft kernel client implementation, AP can communicate with ISH via cros_ec interface including transferring sensor data from ISH to AP Change-Id: I1d9801ddf31ef6bdbfe44ccfca435884e2cf4da6 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1460084 Commit-Queue: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Rushikesh S Kadam <rushikesh.s.kadam@intel.com>
* ish: update power rail request (vnn)li feng2019-02-203-0/+68
| | | | | | | | | | | | | | | | | | | | | | When the AP is trying to go down to S0ix from S0 (suspend), we need to ensure that the ISH is not holding on to any power requests which would prevent the AP from transitioning to S0ix. Re-assert power request when AP enters resume back to S0. Ultimately, the VNN will be controlled at a much finer grain once more power management features are introduces here for the ISH. BRANCH=none BUG=b:123890178 TEST=run "suspend_stress_test -c [loop#]", and pass; this is workaround to fix this issue so not blocking S0ix test. Change-Id: I881f3505300cadf1e0b8dd1750bae4cf2876e514 Signed-off-by: li feng <li1.feng@intel.com> Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1461665 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Edward Hill <ecgh@chromium.org>
* mt_scp: Add functions to clean/invalidated selected ranges of D-cacheNicolas Boichat2019-02-202-11/+24
| | | | | | | | | | | | | | | | | | | | | The previous version could only work on single lines, let's add functions to work on ranges. BRANCH=none BUG=b:123676508 TEST=fill; flush; fill to generate incoherent DRAM/cache content TEST=flush 0x10000000 16 c => clean a single line flush 0x10000020 32 c => clean a single line flush 0x10000040 64 c => clean 2 lines TEST=flush 0x10000080 16 i => invalidate 1 line flush 0x100000a0 32 i => invalidate 1 line flush 0x100000c0 64 i => invalidate 2 lines Change-Id: Ib386eeb4ce5d2f64a23e558c7f562eba234e6b0d Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1475105 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Yilun Lin <yllin@chromium.org>
* mt_scp: Add functions to clean/invalidated selected lines of D-cacheNicolas Boichat2019-02-191-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For performance reasons, we want to be able to flush/invalidate only specific cache lines/addresses. BRANCH=none BUG=b:123676508 TEST=fill; flush; fill to generate incoherent DRAM/cache content: cached: 10000000: 89905d00 89905d01 89905d02 89905d03 89905d04 89905d05 89905d06 89905d07 10000020: 89905d08 89905d09 89905d0a 89905d0b 89905d0c 89905d0d 89905d0e 89905d0f direct: 30000000: 3848c300 3848c301 3848c302 3848c303 3848c304 3848c305 3848c306 3848c307 30000020: 3848c308 3848c309 3848c30a 3848c30b 3848c30c 3848c30d 3848c30e 3848c30f => Then clean a cache line > flush 0x10000000 c Clean cached: 10000000: 89905d00 89905d01 89905d02 89905d03 89905d04 89905d05 89905d06 89905d07 10000020: 89905d08 89905d09 89905d0a 89905d0b 89905d0c 89905d0d 89905d0e 89905d0f direct: 30000000: 89905d00 89905d01 89905d02 89905d03 89905d04 89905d05 89905d06 89905d07 30000020: 3848c308 3848c309 3848c30a 3848c30b 3848c30c 3848c30d 3848c30e 3848c30f => memory is updated => Then invalidate a cache line > flush 0x10000020 i Inval 10000020 cached: 10000000: 89905d00 89905d01 89905d02 89905d03 89905d04 89905d05 89905d06 89905d07 10000020: 3848c308 3848c309 3848c30a 3848c30b 3848c30c 3848c30d 3848c30e 3848c30f direct: 30000000: 89905d00 89905d01 89905d02 89905d03 89905d04 89905d05 89905d06 89905d07 30000020: 3848c308 3848c309 3848c30a 3848c30b 3848c30c 3848c30d 3848c30e 3848c30f => cache content is thrown away, and matches memory Change-Id: I5dbcc366236fef56f7cb048ce313247cf3d51276 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1475092 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Yilun Lin <yllin@chromium.org>
* kukui_scp: Always use watchdog reset on reboot.Pi-Hsun Shih2019-02-191-3/+4
| | | | | | | | | | | | BUG=b:120889996 TEST=`reboot` in SCP console, and see that it triggers a watchdog reset. BRANCH=none Change-Id: I4b629dc32dfd3bed8d802b211c1170ff72ee0943 Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1469853 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* ish: print message for misconfigured GPIOsJett Rink2019-02-141-10/+18
| | | | | | | | | | | | | | | ISH does not support level-triggered GPIOs, and we should print an error message when we encounter this bad configuration BRANCH=none BUG=none TEST=manually verified that print occurs Change-Id: I76d5c7bb2c70c664660a1c8fbe362fcbbde77ae6 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1460083 Reviewed-by: Nick Crews <ncrews@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org>
* cleanup: do not try to copy to/from NULLJett Rink2019-02-141-1/+2
| | | | | | | | | | | | | | If we receive an unsupported protocol in the ISH, we should not try to dereference a NULL ptr. BRANCH=none BUG=none TEST=builds Change-Id: I4861385c30a94496026c1918d41a18ca82f3c740 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1470897 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* g: decorate _i2cs_write_complete_int() so that LTO does not loose itVadim Bendebury2019-02-101-1/+1
| | | | | | | | | | | | | | | Otherwise LTO optimizes this function away before finding out that it, in fact, needs this it. BRANCH=cr50, cr50-mp BUG=b:65253310 TEST=after the entire stack was applied Cr50 builds successfully with CONFIG_LTO enabled, and passes TCG test suite. Change-Id: I1bd8292b7228efc982118e23455503fefd52c689 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1460087 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: use list of object files instead of the libraries for cryptocVadim Bendebury2019-02-101-6/+8
| | | | | | | | | | | | | | | | In preparation to enabling link time optimizations for Cr50, modify build system to link cryptoc tree's modules directly instead of linking the archive. CQ-DEPEND=CL:1457210 BRANCH=cr50, cr50-mp BUG=b:65253310 TEST=make buildall -j succeeds, TCG tests succeed. Change-Id: I3ffc27e8ef56a45dad8dd96aa90acace710474a1 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1457600 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* chip/g: mark symbols used that are used from assembly codePatrick Georgi2019-02-072-2/+2
| | | | | | | | | | | | | | | Otherwise LTO optimizes them away before finding out it, in fact, needs them - then complains. BRANCH=cr50, cr50-mp BUG=b:65253310 TEST=after the entire stack was applied Cr50 builds successfully with CONFIG_LTO enabled, and passes TCG test suite. Change-Id: I244e5bd3da18dddec636bbe1e99c229bc3af44ec Signed-off-by: Patrick Georgi <pgeorgi@google.com> Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1411542
* ish: remove unnecessary interrupt_enable() callHyungwoo Yang2019-01-311-3/+0
| | | | | | | | | | | | | | | | interrupt is already enabled when the first task(hook_task) scheduled. this patch removes unnecessary interrupt_enable(). BRANCH=none BUG=none TEST=verified in Atlas platform Change-Id: I4b1458a6ad2d72347720630181ef7e35bc7fc66b Reviewed-on: https://chromium-review.googlesource.com/1444538 Commit-Ready: Hyungwoo Yang <hyungwoo.yang@intel.com> Tested-by: Hyungwoo Yang <hyungwoo.yang@intel.com> Reviewed-by: Hyungwoo Yang <hyungwoo.yang@intel.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* ish: fix timer 0 periodic modeHyungwoo Yang2019-01-301-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | We are using timer 0 with periodic mode and in this mode, the value of timer 0 comparator should be automatically increased by the value last written when main counter equals the value. But due to mis-configuration, currently it is not automatically increased. This patch corrects the configuration for timer 0. BRANCH=none BUG=b:112750896 TEST=Tested on Atlas and verified increased value in timer 0 comparator. Change-Id: I1c98d980cd5c28226e223ca058b2181cf40b87f9 Reviewed-on: https://chromium-review.googlesource.com/1431874 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Hyungwoo Yang <hyungwoo.yang@intel.com> Reviewed-by: Hyungwoo Yang <hyungwoo.yang@intel.com> Reviewed-by: Jett Rink <jettrink@chromium.org>
* ish: fix task profilingJett Rink2019-01-302-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | Previously when performing 'taskinfo' command on ISH5, the time spend in exception was very high. The time spent in each task was also negative. The task profiling was broken in many ways. This CL fixes the following: - Added correct exception start and end times through out - Updated exception (isr) start and end time to 32-bit so we don't have issues with 32-bit time rollover - Fixed time spending in task, exception, and IRQ distribution - Fixed code that determines which vector is being serviced. Calculation before was backwards previously. - The IRQ_COUNT for ish was too small so we couldn't correctly profile the IRQ distribution BRANCH=none BUG=b:121343650,b:112750896 TEST='taskinfo' behaves correctly on aracada (ISH5) Change-Id: I643d3133a608865a1862a70585cfeced4d24649d Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1389058 Reviewed-by: Hyungwoo Yang <hyungwoo.yang@intel.com>
* cr50: Add NIST SP 800-90A HMAC DRBG.Louis Collard2019-01-296-176/+386
| | | | | | | | | | | | | | | | | | | This adds a new DRBG, and refactors the existing RFC6979 DRBG to make use of it. The new DRBG will initially be used to incorporate user-specific secrets into U2F key generation. CQ-DEPEND=CL:*729958,CL:*729959 BRANCH=none BUG=b:112603199 TEST=cr50 console rfc6979 test, hmac_drbg test, hmac_drbg_rand test Generate U2F key, patch CL, use U2F key Change-Id: I9af5da65cbd6fbfbd3570f40fb9e11ecef57532d Signed-off-by: Louis Collard <louiscollard@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1371584 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* chip: stm32: Enable additional I2C/UART DMA channels for STM32F412Moritz Fischer2019-01-291-5/+9
| | | | | | | | | | | | | | | | Enable additional I2C/UART DMA channel mappings for STM32F412 chip variant. Introduce new CHIP_VARIANT_STM32F41X define, to simplify further refactoring. BUG=none BRANCH=none TEST=build Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Change-Id: I61ed545619ddda8846e598fcb461cf971fc9b905 Reviewed-on: https://chromium-review.googlesource.com/1404103 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Philip Chen <philipchen@chromium.org>
* g/i2cs: Sample SDA multiple times before considering the bus wedgedRaul E Rangel2019-01-281-45/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cr50 tpm i2c protocol works as follows: 1. Master wants to read a register from the tpm. It writes the 1 byte register address to the tpm. 2. Master completes the transaction then waits for AP_INT to fire. 3. i2c write complete isr fires on the tpm. 1. register data is pushed into the tx fifo 2. AP_INT is pulsed to notify the master that the write has been processed, and the data is ready to be read. 3. tpm increments i2cs_read_irq_count 4. Master reads n bytes from the tpm. 5. Times passes 6a. Master decides to update a register on the TPM 1. Master writes n bytes to the tpm. 2. Master completes transaction then waits for AP_INT to fire. 3. i2c write complete isr fires on the tpm 1. tpm processes the write command 2. AP_INT is pulsed to notify the master that the read is ready. 4. Master receives AP_INT and continues issuing commands. 6b. Master decides to read a register from the TPM 1. goto 1 poll_read_state will currently poll SDA every 500 ms. If it sees that there have been no write completions since the last polling period and SDA is currently low, it assumes the bus is wedged and it resets the i2cs controller. This logic has the potential to terminate in flight transactions. For example: The poller runs at step 4 and notices that a write interrupt has occurred and it updates last_i2cs_read_irq_count. The master waits 499.99 ms and then initiates a new transaction (6a or 6b). This causes the master to start a new i2c write transaction. The poller then runs again at 500ms and notices that the write complete interrupt counter has not incremented and SDA is low because a 0 is currently being written by the master. The poller then resets the i2cs controller. This causes the master to receive a NAK. This cl changes the logic so that the poller requires SDA to be low for 3 consecutive periods between write completes before it resets the controller. See the comments in the code for the specifics. BUG=b:113880780 BRANCH=none TEST=Ran a reboot stress test for over 16 hours and did not see any transaction failures. Also manually grounded SDA to see if read_recovery_count incremented: [585.024822 I2CS bus is stuck] [585.475883 I2CS bus is stuck] [585.926944 I2CS bus is stuck] [586.378009 I2CS bus is stuck] [586.829067 I2CS bus is stuck] > i2cstpm rd fifo adjust cnt = 0 wr mismatch cnt = 0 read recovered cnt = 5 Change-Id: I7b6f446ee75b43e9d66a6a5e51dd077c60108f90 Signed-off-by: Raul E Rangel <rrangel@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1387346 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* ish: use correct I2C eventJett Rink2019-01-281-4/+2
| | | | | | | | | | | | | | | | | There is a section of event bits that are reserved for all tasks. We need to use one of the upper bits instead of a bit 7 which may conflict with other tasks eventually. BRANCH=none BUG=none TEST=i2c transaction still works Change-Id: Ie8b98f7a159159714f12dc87ce26b009ceee3f92 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1435479 Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org>
* ish: make unimplmented GPIOs perform no-opsJett Rink2019-01-282-5/+22
| | | | | | | | | | | | | | | When reading or writing to an UNIMPLEMENTED gpio right now, it would actually read or write GPIO0. Add guards to prevent unimplemented GPIOs from interacting with hardware BRANCH=none BUG=none TEST=build and real gpios still work Change-Id: If661ebe66a0b5d4fc4f69bee314c90bce0eedf11 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1435478 Reviewed-by: Furquan Shaikh <furquan@chromium.org>
* link_defs.h: Renames __ro_end to __data_lma_start.Yilun Lin2019-01-281-1/+1
| | | | | | | | | | | | | | | | | | The name of __ro_end is confusing. The variable is actually used as a label tagging that it is the starting address of .data LMA. Renames to __data_lma_start to be more decriptive. BRANCH=None TEST=make buildall -j BUG=b:122084384 Change-Id: I8990a2a1f3d0719739a8e649b881cb277fe5a9b8 Signed-off-by: Yilun Lin <yllin@google.com> Reviewed-on: https://chromium-review.googlesource.com/1433160 Commit-Ready: Yilun Lin <yllin@chromium.org> Tested-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* mt_scp: Add support to store some code in DRAMNicolas Boichat2019-01-241-0/+5
| | | | | | | | | | | | | | | | | This allows to store specific code/data in a .dram region. This is used by mt_scp to run code off DRAM, as we plan to have more code than what can fit in SRAM. BRANCH=none BUG=b:122058243 TEST=make BOARD=kukui_scp -j objdump -x build/kukui_scp/ec.obj => Some code is loaded in DRAM TEST=Load kukui_scp, icachetest works Change-Id: Idbab809ba86cabe3b984944adc2781b37d2d544b Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1391542
* mt_scp: Enable I/D-cache on bootNicolas Boichat2019-01-243-7/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable cache mapping on boot, add functions for cache support. Invalidate the cache on boot, and add benchmarching function. BRANCH=none BUG=b:117804463 TEST=Boot kukui_scp with TEST-ONLY CL. TEST=Run dcachetest command, see performance difference, and lack of coherency if the data is updated from AP side. > dcachetest cached: 19745 us (val: ef915230) cached+inval: 39402 us (val: ef915230) direct: 94096 us (val: ef915230) TEST=See that icachetest (cached) and perftest have similar performance: > icachetest run from DRAM (cached): 102779 us (total: 12a052eb9) run from DRAM (direct): 1867168 us (total: 12a052eb9) > perftest run from SRAM: 102566 us (total: 12a052eb9) TEST=cacheinfo reports sensible data: > cacheinfo Icache hit count: 12000127 Icache access count: 12000131 Dcache hit count: 960034 Dcache access count: 1024034 Change-Id: I3272f4ff9edc0059c4937908b1235346c582c680 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1391529 Reviewed-by: Rong Chang <rongchang@chromium.org>
* mt_scp/memmap: Enable memmap between AP and SCP.Yilun Lin2019-01-245-23/+224
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SCP/AP can access the AP/SCP address via memory address translation. TEST=Run memmap (TEST-ONLY CL), see direct mapping makes sense: Direct mapping: 00001000 INVAL 0f002000 INVAL 10003000 INVAL 1f004000 INVAL 20005000 40005000 => 20005000 OK 2f006000 4f006000 => 2f006000 OK 30007000 50007000 => 30007000 OK 3f008000 5f008000 => 3f008000 OK 40009000 INVAL 4f00a000 INVAL 5000b000 INVAL 5f00c000 INVAL 6000d000 6000d000 => 6000d000 OK 6f00e000 6f00e000 => 6f00e000 OK 7000f000 7000f000 => 7000f000 OK 7f010000 7f010000 => 7f010000 OK 80011000 80011000 => 80011000 OK 8f012000 8f012000 => 8f012000 OK 90013000 00013000 => 90013000 OK 9f014000 0f014000 => 9f014000 OK a0015000 10015000 => a0015000 OK af016000 1f016000 => af016000 OK b0017000 20017000 => b0017000 OK bf018000 2f018000 => bf018000 OK c0019000 30019000 => c0019000 OK cf01a000 3f01a000 => cf01a000 OK d001b000 1001b000 => a001b000 BAD df01c000 1f01c000 => af01c000 BAD (these are ok as 0x1* is mapped from both 0xd* and 0xa*) e001d000 a001d000 => e001d000 OK ef01e000 af01e000 => ef01e000 OK f001f000 9001f000 => f001f000 OK ff020000 9f020000 => ff020000 OK BRANCH=None BUG=b:114326670 Change-Id: I29298c2e5a897d08d21390c751bdd881170adb59 Signed-off-by: Yilun Lin <yllin@google.com> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1385910 Reviewed-by: Erin Lo <erin.lo@mediatek.com> Reviewed-by: Rong Chang <rongchang@chromium.org>
* it83xx: add enable/disable espi pad functionDino Li2019-01-223-4/+18
| | | | | | | | | | | | | | | We can call this function to enable/disable espi pad if needed. BUG=b:121105042 BRANCH=none TEST=buildall Change-Id: I61561b1a4657947e27053de3e8b2ef053651d949 Signed-off-by: Dino Li <Dino.Li@ite.com.tw> Reviewed-on: https://chromium-review.googlesource.com/1426303 Commit-Ready: Justin TerAvest <teravest@chromium.org> Tested-by: Justin TerAvest <teravest@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
View Lorry Controller Status