On 8/9/2017 4:43 PM, Peter Huewe wrote:

Yes that's bad, especially with current msleep(5) is actually
msleep(20). However, please also keep in mind SPI tpms show a much
higher burst count value,  (255) our I2C TPM SLB9645 even shows
something in the range of 1k. :)

One of our platforms has a TPM 1.2 with an 8 byte FIFO and a static burst count. This is where we're debugging.

Would another solution be to reduce the burst count poll and sleep
to, e.g., 100 usec or even 10 usec? This would probably help
greatly, but till not incur the wait states that triggered the
NACK.

If you use sleep it's not guaranteed that you wakeup after exactly xx
specified amount of time. Just that you sleep at least xx amount of
time. Otherwise you would have to do delay/busywaiting.

Understood. However, if the DD maintainers will not accept ignoring burstCount, would a short sleep (e.g., 10 usec) be acceptable.

If so, we can benchmark it.

Imho the best option is to figure out whether any vendor can
determine the "FIFO flush time" i.e. how much time does it take to
empty the fifo and fillup the burstcount and use this on the lower
bound of an usleep range. I don't think tpms are in the range of < 10
us...

@Ken: Maybe can you check in DDWG?

I asked this week.

Nuvoton, ST Micro, and Infineon confirmed that the TPM empties a byte from the FIFO in under 1 usec. So, even with a static burst count, the entire FIFO would empty in under 10 usec.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
tpmdd-devel mailing list
tpmdd-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

Reply via email to