sunxi: Remove already applied patch

This patch is already included in kernel v4.19.31.

Fixes: 8df12d76c642 ("kernel: bump 4.19 to 4.19.34")
Signed-off-by: Hauke Mehrtens <[email protected]>

target/linux/sunxi/patches-4.19/100-clocksource-drivers-arch_timer-Workaround-for-Allwin.patch

@@ -1,214 +0,0 @@
-From 7cd6dca3600d8d71328950216688ecd00015d1ce Mon Sep 17 00:00:00 2001
-From: Samuel Holland <[email protected]>
-Date: Sat, 12 Jan 2019 20:17:18 -0600
-Subject: [PATCH] clocksource/drivers/arch_timer: Workaround for Allwinner A64
- timer instability
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The Allwinner A64 SoC is known[1] to have an unstable architectural
-timer, which manifests itself most obviously in the time jumping forward
-a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
-timer frequency of 24 MHz, implying that the time went slightly backward
-(and this was interpreted by the kernel as it jumping forward and
-wrapping around past the epoch).
-
-Investigation revealed instability in the low bits of CNTVCT at the
-point a high bit rolls over. This leads to power-of-two cycle forward
-and backward jumps. (Testing shows that forward jumps are about twice as
-likely as backward jumps.) Since the counter value returns to normal
-after an indeterminate read, each "jump" really consists of both a
-forward and backward jump from the software perspective.
-
-Unless the kernel is trapping CNTVCT reads, a userspace program is able
-to read the register in a loop faster than it changes. A test program
-running on all 4 CPU cores that reported jumps larger than 100 ms was
-run for 13.6 hours and reported the following:
-
- Count | Event
--------+---------------------------
-  9940 | jumped backward      699ms
-   268 | jumped backward     1398ms
-     1 | jumped backward     2097ms
- 16020 | jumped forward       175ms
-  6443 | jumped forward       699ms
-  2976 | jumped forward      1398ms
-     9 | jumped forward    356516ms
-     9 | jumped forward    357215ms
-     4 | jumped forward    714430ms
-     1 | jumped forward   3578440ms
-
-This works out to a jump larger than 100 ms about every 5.5 seconds on
-each CPU core.
-
-The largest jump (almost an hour!) was the following sequence of reads:
-    0x0000007fffffffff → 0x00000093feffffff → 0x0000008000000000
-
-Note that the middle bits don't necessarily all read as all zeroes or
-all ones during the anomalous behavior; however the low 10 bits checked
-by the function in this patch have never been observed with any other
-value.
-
-Also note that smaller jumps are much more common, with backward jumps
-of 2048 (2^11) cycles observed over 400 times per second on each core.
-(Of course, this is partially explained by lower bits rolling over more
-frequently.) Any one of these could have caused the 95 year time skip.
-
-Similar anomalies were observed while reading CNTPCT (after patching the
-kernel to allow reads from userspace). However, the CNTPCT jumps are
-much less frequent, and only small jumps were observed. The same program
-as before (except now reading CNTPCT) observed after 72 hours:
-
- Count | Event
--------+---------------------------
-    17 | jumped backward      699ms
-    52 | jumped forward       175ms
-  2831 | jumped forward       699ms
-     5 | jumped forward      1398ms
-
-Further investigation showed that the instability in CNTPCT/CNTVCT also
-affected the respective timer's TVAL register. The following values were
-observed immediately after writing CNVT_TVAL to 0x10000000:
-
- CNTVCT             | CNTV_TVAL  | CNTV_CVAL          | CNTV_TVAL Error
---------------------+------------+--------------------+-----------------
- 0x000000d4a2d8bfff | 0x10003fff | 0x000000d4b2d8bfff | +0x00004000
- 0x000000d4a2d94000 | 0x0fffffff | 0x000000d4b2d97fff | -0x00004000
- 0x000000d4a2d97fff | 0x10003fff | 0x000000d4b2d97fff | +0x00004000
- 0x000000d4a2d9c000 | 0x0fffffff | 0x000000d4b2d9ffff | -0x00004000
-
-The pattern of errors in CNTV_TVAL seemed to depend on exactly which
-value was written to it. For example, after writing 0x10101010:
-
- CNTVCT             | CNTV_TVAL  | CNTV_CVAL          | CNTV_TVAL Error
---------------------+------------+--------------------+-----------------
- 0x000001ac3effffff | 0x1110100f | 0x000001ac4f10100f | +0x1000000
- 0x000001ac40000000 | 0x1010100f | 0x000001ac5110100f | -0x1000000
- 0x000001ac58ffffff | 0x1110100f | 0x000001ac6910100f | +0x1000000
- 0x000001ac66000000 | 0x1010100f | 0x000001ac7710100f | -0x1000000
- 0x000001ac6affffff | 0x1110100f | 0x000001ac7b10100f | +0x1000000
- 0x000001ac6e000000 | 0x1010100f | 0x000001ac7f10100f | -0x1000000
-
-I was also twice able to reproduce the issue covered by Allwinner's
-workaround[4], that writing to TVAL sometimes fails, and both CVAL and
-TVAL are left with entirely bogus values. One was the following values:
-
- CNTVCT             | CNTV_TVAL  | CNTV_CVAL
---------------------+------------+--------------------------------------
- 0x000000d4a2d6014c | 0x8fbd5721 | 0x000000d132935fff (615s in the past)
-Reviewed-by: Marc Zyngier <[email protected]>
-
-========================================================================
-
-Because the CPU can read the CNTPCT/CNTVCT registers faster than they
-change, performing two reads of the register and comparing the high bits
-(like other workarounds) is not a workable solution. And because the
-timer can jump both forward and backward, no pair of reads can
-distinguish a good value from a bad one. The only way to guarantee a
-good value from consecutive reads would be to read _three_ times, and
-take the middle value only if the three values are 1) each unique and
-2) increasing. This takes at minimum 3 counter cycles (125 ns), or more
-if an anomaly is detected.
-
-However, since there is a distinct pattern to the bad values, we can
-optimize the common case (1022/1024 of the time) to a single read by
-simply ignoring values that match the error pattern. This still takes no
-more than 3 cycles in the worst case, and requires much less code. As an
-additional safety check, we still limit the loop iteration to the number
-of max-frequency (1.2 GHz) CPU cycles in three 24 MHz counter periods.
-
-For the TVAL registers, the simple solution is to not use them. Instead,
-read or write the CVAL and calculate the TVAL value in software.
-
-Although the manufacturer is aware of at least part of the erratum[4],
-there is no official name for it. For now, use the kernel-internal name
-"UNKNOWN1".
-
-[1]: https://github.com/armbian/build/commit/a08cd6fe7ae9
-[2]: https://forum.armbian.com/topic/3458-a64-datetime-clock-issue/
-[3]: https://irclog.whitequark.org/linux-sunxi/2018-01-26
-[4]: https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/drivers/clocksource/arm_arch_timer.c#L272
-
-Acked-by: Maxime Ripard <[email protected]>
-Tested-by: Andre Przywara <[email protected]>
-Signed-off-by: Samuel Holland <[email protected]>
-Cc: [email protected]
-Signed-off-by: Daniel Lezcano <[email protected]>
----
- Documentation/arm64/silicon-errata.txt |  2 +
- drivers/clocksource/Kconfig            | 10 +++++
- drivers/clocksource/arm_arch_timer.c   | 55 ++++++++++++++++++++++++++
- 3 files changed, 67 insertions(+)
-
---- a/drivers/clocksource/arm_arch_timer.c
-+++ b/drivers/clocksource/arm_arch_timer.c
-@@ -361,6 +361,48 @@ static u32 notrace sun50i_a64_read_cntv_
- }
- #endif
- 
-+#ifdef CONFIG_SUN50I_ERRATUM_UNKNOWN1
-+/*
-+ * The low bits of the counter registers are indeterminate while bit 10 or
-+ * greater is rolling over. Since the counter value can jump both backward
-+ * (7ff -> 000 -> 800) and forward (7ff -> fff -> 800), ignore register values
-+ * with all ones or all zeros in the low bits. Bound the loop by the maximum
-+ * number of CPU cycles in 3 consecutive 24 MHz counter periods.
-+ */
-+#define __sun50i_a64_read_reg(reg) ({					\
-+	u64 _val;							\
-+	int _retries = 150;						\
-+									\
-+	do {								\
-+		_val = read_sysreg(reg);				\
-+		_retries--;						\
-+	} while (((_val + 1) & GENMASK(9, 0)) <= 1 && _retries);	\
-+									\
-+	WARN_ON_ONCE(!_retries);					\
-+	_val;								\
-+})
-+
-+static u64 notrace sun50i_a64_read_cntpct_el0(void)
-+{
-+	return __sun50i_a64_read_reg(cntpct_el0);
-+}
-+
-+static u64 notrace sun50i_a64_read_cntvct_el0(void)
-+{
-+	return __sun50i_a64_read_reg(cntvct_el0);
-+}
-+
-+static u32 notrace sun50i_a64_read_cntp_tval_el0(void)
-+{
-+	return read_sysreg(cntp_cval_el0) - sun50i_a64_read_cntpct_el0();
-+}
-+
-+static u32 notrace sun50i_a64_read_cntv_tval_el0(void)
-+{
-+	return read_sysreg(cntv_cval_el0) - sun50i_a64_read_cntvct_el0();
-+}
-+#endif
-+
- #ifdef CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND
- DEFINE_PER_CPU(const struct arch_timer_erratum_workaround *, timer_unstable_counter_workaround);
- EXPORT_SYMBOL_GPL(timer_unstable_counter_workaround);
-@@ -451,6 +493,19 @@ static const struct arch_timer_erratum_w
- 	},
- #endif
- #ifdef CONFIG_SUN50I_ERRATUM_UNKNOWN1
-+	{
-+		.match_type = ate_match_dt,
-+		.id = "allwinner,erratum-unknown1",
-+		.desc = "Allwinner erratum UNKNOWN1",
-+		.read_cntp_tval_el0 = sun50i_a64_read_cntp_tval_el0,
-+		.read_cntv_tval_el0 = sun50i_a64_read_cntv_tval_el0,
-+		.read_cntpct_el0 = sun50i_a64_read_cntpct_el0,
-+		.read_cntvct_el0 = sun50i_a64_read_cntvct_el0,
-+		.set_next_event_phys = erratum_set_next_event_tval_phys,
-+		.set_next_event_virt = erratum_set_next_event_tval_virt,
-+	},
-+#endif
-+#ifdef CONFIG_SUN50I_ERRATUM_UNKNOWN1
- 	{
- 		.match_type = ate_match_dt,
- 		.id = "allwinner,erratum-unknown1",