Commits (3)
-
Stanley Wu authored
Configure I2C bus 5 high and low time for p-sensor device. BUG=b:181727056 TEST=Measured the I2C bus frequency reduce to 387 KHz. Change-Id: I4b6d78d84b8ea145093f52bbb13684e2c6aa979c Signed-off-by:
Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51198Tested-by:
build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by:
Karthik Ramasubramanian <kramasub@google.com>
5c4056dd -
Stanley Wu authored
1. Follow GT7375P Programming Guide_Rev.0.6 to increase reset delay to 180ms. 2. Add TOUCH_RPT_EN pin(GPP_A11) control to fix TOUCH_RPT_EN pin keep high after system suspend. BUG=b:181711141 TEST=Build and boot boten to OS. Confirm TOUCH_RPT_EN pin keep low after system suspend. Change-Id: I98efbe68dab538906802647582eba0e068d9c11f Signed-off-by:Stanley Wu <stanley1.wu@lcfc.corp-partner.google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51254Reviewed-by:
Paul Fagerburg <pfagerburg@chromium.org> Tested-by:
build bot (Jenkins) <no-reply@coreboot.org>
105d91e1 -
Furquan Shaikh authored
CB:49896 added support in `intel_microcode_find()` to cache the found microcode for faster subsequent accesses. This works okay when the function succeeds in finding the microcode on BSP. However, if for any reason, `cpu_microcode_blob.bin` does not contain a valid microcode for the given processor, then the logic ends up attempting to find microcode again and again every time it is called (because `ucode_updates` is set to NULL on failed find, thus retriggering the whole find sequence every time). This leads to a weird race condition when multiple APs are running in parallel and executing this function. A snippet of the issues observed in the scenario described above: ``` ... microcode: Update skipped, already up-to-date ... Microcode header corrupted! ... ``` 1. AP reports that microcode update is being skipped since the current version matches the version in CBFS (even though there is no matching microcode update in CBFS). 2. AP reports microcode header is corrupted because it thinks that the data size reported in the microcode is larger than the file read from CBFS. Above issues occur because each time an AP calls `intel_microcode_find()`, it might end up seeing some intermittent state of `ucode_updates` and taking incorrect action. This change fixes this race condition by separating the logic for finding microcode into an internal function `find_cbfs_microcode()` and maintaining the caching logic in `intel_microcode_find()` using a boolean flag `microcode_checked`. BUG=b:182232187 TEST=Verified that `intel_microcode_find()` no longer makes repeated attempts to find microcode from CBFS if it failed the first time. Change-Id: I8600c830ba029e5cb9c0d7e0f1af18d87c61ad3a Signed-off-by:
Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/51371 Reviewed-by: Patrick Rudolph Reviewed-by:
Angel Pons <th3fanbus@gmail.com> Reviewed-by:
Aaron Durbin <adurbin@chromium.org> Reviewed-by:
Tim Wawrzynczak <twawrzynczak@chromium.org> Tested-by:
build bot (Jenkins) <no-reply@coreboot.org>
f14c05f1
Showing