Attention is currently required from: Marshall Dawson, Paul Menzel, Karthik Ramasubramanian, Felix Held. Hello build bot (Jenkins), Jason Glenesk, Furquan Shaikh, Marshall Dawson, Paul Menzel, Rob Barnes, Karthik Ramasubramanian, Felix Held,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/54070
to look at the new patch set (#4).
Change subject: soc/amd/common/block/espi_util: Work around in-band reset race condition ......................................................................
soc/amd/common/block/espi_util: Work around in-band reset race condition
When performing an in-band reset the host controller and the peripheral can have mismatched IO configs.
i.e., The eSPI peripheral can be in IO-4 mode while, the eSPI host will be in IO-1. This results in the peripheral getting invalid packets and thus not responding. This causes the NO_RESPONSE status bit to be set and cause eSPI init to fail.
If the peripheral is alerting when we perform an in-band reset, there is a race condition in espi_send_command. 1) espi_send_command clears the interrupt status. 2) eSPI host controller hardware notices the alert and sends a GET_STATUS. 3) espi_send_command writes the in-band reset command. 4) eSPI hardware enqueues the in-band reset until GET_STATUS is complete. 5) GET_STATUS fails with NO_RESPONSE and sets the interrupt status. 6) eSPI hardware performs in-band reset. 7) espi_send_command checks the status and sees a NO_RESPONSE bit.
As a workaround we allow the NO_RESPONSE status code when we perform an in-band reset.
BUG=b:186135022 TEST=suspend_stress_test and S5->S0 tests on guybrush and zork.
Signed-off-by: Raul E Rangel rrangel@chromium.org Change-Id: I71271377f20eaf29032214be98794e1645d9b70a --- M src/soc/amd/common/block/lpc/espi_util.c 1 file changed, 30 insertions(+), 2 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/70/54070/4