On Fri, Aug 11, 2017 at 05:54:19PM -0400, Ken Goldman wrote: > 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.
Does this break anything lets say in a decade time frame? If it does, I will not even consider this. Can you give a definitive answer for that? /Jarkko ------------------------------------------------------------------------------ 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