tpm(4): fix delay units

tpm(4): fix delay units

tpm(4) has timeout constants in milliseconds, e.g.

#define TPM_ACCESS_TMO			2000	/* 2sec */

This is fine.

The odd thing is that tpm(4) first converts these timeouts to counts
of ticks via tpm_tmotohz() before using DELAY() to busy-wait.  DELAY()
takes a count of microseconds, which are not equivalent to ticks, so
the units are all screwed up.

Let's correct this:

- Remove tpm_tmotohz().  We're not working with ticks so we don't it.

- Multiply the timeouts to match the delay interval.  tpm_request_locality()
  and tpm_getburst() use intervals of 10 microseconds, so multiply the
  millisecond timeouts by 100.  In tpm_waitfor() the delay interval is 1
  microsecond, so multiply the millisecond timeout by 1000.

- Update the parameter name in tpm_waitfor() to note that we expect a
  count of milliseconds, not "tries".

Discussion: https://marc.info/?l=openbsd-tech&m=160995671326406&w=2

Prompted by kettenis@.

Suspend/resume tested by florian@ on an X1 Gen 2.  For the record, it
looks like this:

tpm0 at acpi0 TPM_ addr 0xfed40000/0x5000, device 0x0000104a rev 0x4e

Earlier versions of this patch were reviewed by kn@, but the patch
became more ambitious when kettenis@ got involved so those reviews
are no longer applicable.

jcs@ notes (https://marc.info/?l=openbsd-tech&m=160834427630142&w=2)
in a related discussion that this driver "sucks" and should be
replaced with NetBSD's rewrite.  This would get us a cleaner driver
with TPM 2.0 support.  So there is future work to do here.

ok kettenis@