On Sat Nov 11 17, Jason Gunthorpe wrote:
On Fri, Nov 10, 2017 at 01:53:00PM -0700, Jerry Snitselaar wrote:
I wonder if it is possible that the release locality from the probe
isn't completing on the chip until after the request/check that
happens at the beginning of the tpm_get_timeouts. Perhaps we need
something like wait_for_tpm_stat for the access register, and
verifying that locality was released before returning out of
release_locality?
This is not a bad guess.. Adding a largish delay after
release_locality might be interesting too.
Are we sure our tis request/release process is even right? Another
At this point, no? :) The tpm1.2 and tpm2.0 tis devices I have
access to seem to behave properly, and the traces look like I'd
expect, but that doesn't prove anything.
I think the check_locality code is okay since it is looking at the
access register for the desired locality and seeing if the active
locality and valid register bits are set. According to the fifo
interface locality usage per register chart, the access register
should always return correct values unlike the status register.
For request_locality, currently it sets the request use bit in the
access register, and then does check_locality potentially up until
timeout a. Looking at the spec, it could take longer than timeout a
if there is another active locality. It can take up until timeout a
from the point where that locality relinquishes the tpm. So that
could possibly be improved.
Before the release_locality code would only actually release the
locality if the request use bit was set. So after it grabbed the
locality during probe it probably never released it. The idea with the
new code was to release it when it was no longer needed so another
requester would be able to take the tpm without having to wait for it
to be released. With the old code I think it would have to wait either
until the next time release_locality was called, or attempt to seize
the tpm with the seize bit in the access register. I need to read
through the spec some more, but does the tpm ever force a change when
the request use bit is set, or does it leave it up to the software
to deal with it and only gets involved in the case where the seize
bit has been set?
/me goes back to reading specs
options is that the 'check if already in locality' doesn't work on
this chip, or isn't coded right...
Jason
