| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TPM command processing should not be happening on the interrupt
context.
This patch adds a skeleton of the task which handles TPM functions. It
initializes the TPM and then enters endless loop waiting for an event
trigger from interrupt, which happens when a valid FIFO message is
received.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=none yet
Change-Id: I63dce2762cc07370a05bf00bdf144c5d9eb6019b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289332
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default receive FIFO threshold of 8 (meaning that 9 bytes need to
be received before receive IRQ fires) is good for high volume
transfers, when the amount of transferred data greatly exceeds the
threshold.
But in case of TPM transactions, which start with a 4 byte header and
then stall while the device processes it, the default threshold
guarantees delays on every transaction, as the receiver does not start
processing the header until 5 idle bytes are transferred to bring the
total number to nine.
The suggested solution is to allow to specify the receive FIFO
interrupt request threshold at run time, by adding this value to the
receive function registration API.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=verified that spstest still works fine.
Change-Id: I92517205a7d0d47893b702efa188eb524fb18a49
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289331
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
This patch adds a module which runs on top of the SPS driver and
implements the TCG SPI TPM protocol.
Basic register read and write functions are implemented as well as
rudimentary TPM state machine (claiming/releasing locality).
An enhancement is made to the SPS driver to ensure that when the CS is
deasserted the transmit FIFO is reset too, on the off chance of the CS
going away mid transaction for whatever reason.
In this implementation the slave is guaranteed to stall the master for
a few bytes in both receive and transmit transactions, which is
further aggravated by the fact that RX FIFO threshold is set to 8
(this is the minimum number of bytes the master has to send to wake up
the slave). This could be fine tuned later, for instance made a
parameter of the receive callback registration function.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=trunksd initialization (with minor changes to accommodate new
VID/DID and some status bits, to be published) succeeds with the
cr50 connected to the USB/SPI cable.
Change-Id: I28d37c3b57dde9adf59e81426efe4f58880cf0b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/285252
|
