g: handle delayed processing of the 'wake' pulses
g: handle delayed processing of the 'wake' pulses

Sometimes the AP will generate a short 'wake' pulse on the SPS CS line
just in case the chip is in the sleep state. This pulse is supposed to
wake up the chip and prepare it to process the actual SPS transaction
which follows the wake pulse in 100 us.

It turns out that under certain conditions it takes the Cr50 longer
than 100 us to react to the wake pulse, for instance when it writing
into flash which is in the same bank the code is running from, there
is no way to avoid stalling in this case.

What happens then is that the 'CS deasserted' interrupt for the wake
pulse comes while the actual SPS transaction is in progress. In this
case when processing the CS deassertion interrupt the Cr50 should not
consider it an end of a transaction, but just ignore it making sure
that the next CS deassertion still would trigger an interrupt.

BRANCH=none
BUG=b:68012381
TEST=verified that this patch helps the AP firmware test case which
      was often failing due to TPM getting out of sync.

Change-Id: I412459552f4b2d13cd72800c1af7d583226e8466
Signed-off-by: Vadim Bendebury <5515d6d2d0829cbe0dd0dcf2094aaded06d58514@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754505

coreboot/chrome-ec,coreboot/chrome-ec,coreboot/chrome-ec,coreboot/chrome-ec,coreboot/chrome-ec,coreboot/chrome-ec