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

Reply via email to