Messages in this thread | | | Subject | Re: Aw: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount | From | Ken Goldman <> | Date | Fri, 11 Aug 2017 17:54:19 -0400 |
| |
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.
| |