mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-12-03 09:04:21 +08:00
77218e83c8
ioread8() operations to TPM MMIO addresses can stall the CPU when immediately following a sequence of iowrite*()'s to the same region. For example, cyclitest measures ~400us latency spikes when a non-RT usermode application communicates with an SPI-based TPM chip (Intel Atom E3940 system, PREEMPT_RT kernel). The spikes are caused by a stalling ioread8() operation following a sequence of 30+ iowrite8()s to the same address. I believe this happens because the write sequence is buffered (in CPU or somewhere along the bus), and gets flushed on the first LOAD instruction (ioread*()) that follows. The enclosed change appears to fix this issue: read the TPM chip's access register (status code) after every iowrite*() operation to amortize the cost of flushing data to chip across multiple instructions. Signed-off-by: Haris Okanovic <haris.okanovic@ni.com> Link: https://lore.kernel.org/r/20230323153436.B2SATnZV@linutronix.de Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> |
||
|---|---|---|
| .. | ||
| agp | ||
| hw_random | ||
| ipmi | ||
| mwave | ||
| pcmcia | ||
| tpm | ||
| xilinx_hwicap | ||
| xillybus | ||
| adi.c | ||
| apm-emulation.c | ||
| applicom.c | ||
| applicom.h | ||
| bsr.c | ||
| ds1620.c | ||
| dsp56k.c | ||
| dtlk.c | ||
| hangcheck-timer.c | ||
| hpet.c | ||
| Kconfig | ||
| lp.c | ||
| Makefile | ||
| mem.c | ||
| misc.c | ||
| mspec.c | ||
| nsc_gpio.c | ||
| nvram.c | ||
| nwbutton.c | ||
| nwbutton.h | ||
| nwflash.c | ||
| pc8736x_gpio.c | ||
| powernv-op-panel.c | ||
| ppdev.c | ||
| ps3flash.c | ||
| random.c | ||
| scx200_gpio.c | ||
| sonypi.c | ||
| tlclk.c | ||
| toshiba.c | ||
| ttyprintk.c | ||
| uv_mmtimer.c | ||
| virtio_console.c | ||