diff options
Diffstat (limited to 'debian/patches-rt/tpm_tis-fix-stall-after-iowrite-s.patch')
-rw-r--r-- | debian/patches-rt/tpm_tis-fix-stall-after-iowrite-s.patch | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/debian/patches-rt/tpm_tis-fix-stall-after-iowrite-s.patch b/debian/patches-rt/tpm_tis-fix-stall-after-iowrite-s.patch index 3a4c242e1..de92d6b59 100644 --- a/debian/patches-rt/tpm_tis-fix-stall-after-iowrite-s.patch +++ b/debian/patches-rt/tpm_tis-fix-stall-after-iowrite-s.patch @@ -1,14 +1,14 @@ From: Haris Okanovic <haris.okanovic@ni.com> Date: Tue, 15 Aug 2017 15:13:08 -0500 Subject: [PATCH] tpm_tis: fix stall after iowrite*()s -Origin: https://www.kernel.org/pub/linux/kernel/projects/rt/5.2/older/patches-5.2.17-rt9.tar.xz +Origin: https://www.kernel.org/pub/linux/kernel/projects/rt/5.4/older/patches-5.4.3-rt1.tar.xz 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_FULL kernel). The spikes are caused by a +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 @@ -30,7 +30,7 @@ Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> return container_of(data, struct tpm_tis_tcg_phy, priv); } -+#ifdef CONFIG_PREEMPT_RT_FULL ++#ifdef CONFIG_PREEMPT_RT +/* + * Flushes previous write operations to chip so that a subsequent + * ioread*()s won't stall a cpu. |