2022-02-26 02:05:36

by Mateusz Jończyk

Subject: [PATCH 1/3] rtc-mc146818-lib: reduce RTC_UIP polling period

Waiting 1ms every time is not necessary, for example on some AMD boxes
the RTC_UIP bit is documented as being high for around 270 microseconds
in some cases [1], which agreed with experiments on an SB710
southbridge. So 100us seems optimal.

This in preparation for mach_get_cmos_time() refactoring.
The functions mc146818_get_time() and mach_get_cmos_time() in
arch/x86/kernel/rtc.c perform the same function and the code is
duplicated. mach_get_cmos_time() is busy waiting for the RTC_UIP
bit to clear, so make mc146818_get_time() more similar to it by reducing
the polling period.

[1] AMD SB700/710/750 Register Reference Guide, page 307,
https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf

"SB700 A12: The UIP high pulse is 270 μS Typical when SS on SRC
clock is OFF and 100μ min when SRC SS is ON." [sic]

Signed-off-by: Mateusz Jończyk <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: [email protected]
Cc: "H. Peter Anvin" <[email protected]>
Cc: Alessandro Zummo <[email protected]>
Cc: Alexandre Belloni <[email protected]>
---
drivers/rtc/rtc-mc146818-lib.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
index ae9f131b43c0..ae4b19e0a981 100644
--- a/drivers/rtc/rtc-mc146818-lib.c
+++ b/drivers/rtc/rtc-mc146818-lib.c
@@ -21,13 +21,13 @@ bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),
unsigned long flags;
unsigned char seconds;

- for (i = 0; i < 10; i++) {
+ for (i = 0; i < 100; i++) {
spin_lock_irqsave(&rtc_lock, flags);

/*
* Check whether there is an update in progress during which the
* readout is unspecified. The maximum update time is ~2ms. Poll
- * every msec for completion.
+ * every 100 usec for completion.
*
* Store the second value before checking UIP so a long lasting
* NMI which happens to hit after the UIP check cannot make
@@ -37,7 +37,7 @@ bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),

if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) {
spin_unlock_irqrestore(&rtc_lock, flags);
- mdelay(1);
+ udelay(100);
continue;
}

@@ -56,7 +56,7 @@ bool mc146818_avoid_UIP(void (*callback)(unsigned char seconds, void *param),
*/
if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP) {
spin_unlock_irqrestore(&rtc_lock, flags);
- mdelay(1);
+ udelay(100);
continue;
}

--
2.25.1

2022-06-24 17:19:02

by Alexandre Belloni

Subject: Re: (subset) [PATCH 1/3] rtc-mc146818-lib: reduce RTC_UIP polling period

From: Alexandre Belloni <[email protected]>

On Fri, 25 Feb 2022 22:50:09 +0100, Mateusz Jończyk wrote:
> Waiting 1ms every time is not necessary, for example on some AMD boxes
> the RTC_UIP bit is documented as being high for around 270 microseconds
> in some cases [1], which agreed with experiments on an SB710
> southbridge. So 100us seems optimal.
>
> This in preparation for mach_get_cmos_time() refactoring.
> The functions mc146818_get_time() and mach_get_cmos_time() in
> arch/x86/kernel/rtc.c perform the same function and the code is
> duplicated. mach_get_cmos_time() is busy waiting for the RTC_UIP
> bit to clear, so make mc146818_get_time() more similar to it by reducing
> the polling period.
>
> [...]

Applied, thanks!

[1/3] rtc-mc146818-lib: reduce RTC_UIP polling period
commit: 4b94a798e1ca59f4614f5ff6b94fe0c287412b9b

Best regards,
--
Alexandre Belloni <[email protected]>