* Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
@ 2021-08-17 9:10 kernel test robot
0 siblings, 0 replies; 9+ messages in thread
From: kernel test robot @ 2021-08-17 9:10 UTC (permalink / raw)
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 16030 bytes --]
CC: clang-built-linux(a)googlegroups.com
CC: kbuild-all(a)lists.01.org
In-Reply-To: <1629121638-3246-1-git-send-email-TonyWWang-oc@zhaoxin.com>
References: <1629121638-3246-1-git-send-email-TonyWWang-oc@zhaoxin.com>
TO: "Tony W Wang-oc" <TonyWWang-oc@zhaoxin.com>
TO: a.zummo(a)towertech.it
TO: alexandre.belloni(a)bootlin.com
TO: linux-rtc(a)vger.kernel.org
TO: linux-kernel(a)vger.kernel.org
CC: TimGuo-oc(a)zhaoxin.com
CC: CooperYan(a)zhaoxin.com
CC: QiyuanWang(a)zhaoxin.com
CC: HerryYang(a)zhaoxin.com
CC: CobeChen(a)zhaoxin.com
CC: YanchenSun(a)zhaoxin.com
Hi Tony,
I love your patch! Perhaps something to improve:
[auto build test WARNING on abelloni/rtc-next]
[also build test WARNING on v5.14-rc6 next-20210816]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Tony-W-Wang-oc/rtc-Fix-set-RTC-time-delay-500ms-on-some-Zhaoxin-SOCs/20210816-140350
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
:::::: branch date: 27 hours ago
:::::: commit date: 27 hours ago
config: x86_64-randconfig-c007-20210816 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 44d0a99a12ec7ead4d2f5ef649ba05b40f6d463d)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/f7e050c4ec0065943e88d900811d57e36ad92a36
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Tony-W-Wang-oc/rtc-Fix-set-RTC-time-delay-500ms-on-some-Zhaoxin-SOCs/20210816-140350
git checkout f7e050c4ec0065943e88d900811d57e36ad92a36
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 clang-analyzer
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
clang-analyzer warnings: (new ones prefixed by >>)
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
4 warnings generated.
Suppressed 4 warnings (4 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
4 warnings generated.
Suppressed 4 warnings (4 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
4 warnings generated.
drivers/mfd/vx855.c:89:2: warning: Value stored to 'ret' is never read [clang-analyzer-deadcode.DeadStores]
ret = mfd_add_devices(&pdev->dev, -1, vx855_cells, ARRAY_SIZE(vx855_cells),
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mfd/vx855.c:89:2: note: Value stored to 'ret' is never read
ret = mfd_add_devices(&pdev->dev, -1, vx855_cells, ARRAY_SIZE(vx855_cells),
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
4 warnings generated.
Suppressed 4 warnings (4 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
4 warnings generated.
Suppressed 4 warnings (4 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
6 warnings generated.
arch/x86/crypto/des3_ede_glue.c:167:10: warning: Although the value stored to 'nbytes' is used in the enclosing expression, the value is never actually read from 'nbytes' [clang-analyzer-deadcode.DeadStores]
while ((nbytes = walk.nbytes)) {
^ ~~~~~~~~~~~
arch/x86/crypto/des3_ede_glue.c:167:10: note: Although the value stored to 'nbytes' is used in the enclosing expression, the value is never actually read from 'nbytes'
while ((nbytes = walk.nbytes)) {
^ ~~~~~~~~~~~
arch/x86/crypto/des3_ede_glue.c:246:10: warning: Although the value stored to 'nbytes' is used in the enclosing expression, the value is never actually read from 'nbytes' [clang-analyzer-deadcode.DeadStores]
while ((nbytes = walk.nbytes)) {
^ ~~~~~~~~~~~
arch/x86/crypto/des3_ede_glue.c:246:10: note: Although the value stored to 'nbytes' is used in the enclosing expression, the value is never actually read from 'nbytes'
while ((nbytes = walk.nbytes)) {
^ ~~~~~~~~~~~
Suppressed 4 warnings (3 in non-user code, 1 with check filters).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
4 warnings generated.
Suppressed 4 warnings (3 in non-user code, 1 with check filters).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
3 warnings generated.
Suppressed 3 warnings (3 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
4 warnings generated.
Suppressed 4 warnings (4 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
5 warnings generated.
>> drivers/rtc/rtc-mc146818-lib.c:227:3: warning: 1st function call argument is an uninitialized value [clang-analyzer-core.CallAndMessage]
CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
^
arch/x86/include/asm/mc146818rtc.h:94:31: note: expanded from macro 'CMOS_WRITE'
#define CMOS_WRITE(val, addr) rtc_cmos_write(val, addr)
^ ~~~
drivers/rtc/rtc-mc146818-lib.c:128:30: note: 'save_freq_select' declared without an initial value
unsigned char save_control, save_freq_select;
^~~~~~~~~~~~~~~~
drivers/rtc/rtc-mc146818-lib.c:142:6: note: Assuming 'yrs' is <= 255
if (yrs > 255) /* They are unsigned */
^~~~~~~~~
drivers/rtc/rtc-mc146818-lib.c:142:2: note: Taking false branch
if (yrs > 255) /* They are unsigned */
^
drivers/rtc/rtc-mc146818-lib.c:163:6: note: Assuming field 'revision' is < FADT2_REVISION_ID
if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/rtc/rtc-mc146818-lib.c:163:57: note: Left side of '&&' is false
if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID &&
^
drivers/rtc/rtc-mc146818-lib.c:173:6: note: Assuming 'yrs' is <= 169
if (yrs > 169)
^~~~~~~~~
drivers/rtc/rtc-mc146818-lib.c:173:2: note: Taking false branch
if (yrs > 169)
^
drivers/rtc/rtc-mc146818-lib.c:176:6: note: Assuming 'yrs' is < 100
if (yrs >= 100)
^~~~~~~~~~
drivers/rtc/rtc-mc146818-lib.c:176:2: note: Taking false branch
if (yrs >= 100)
^
drivers/rtc/rtc-mc146818-lib.c:179:6: note: Assuming the condition is true
if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/rtc/rtc-mc146818-lib.c:180:6: note: Left side of '||' is true
|| RTC_ALWAYS_BCD) {
^
drivers/rtc/rtc-mc146818-lib.c:181:9: note: '?' condition is false
sec = bin2bcd(sec);
^
include/linux/bcd.h:13:4: note: expanded from macro 'bin2bcd'
(__builtin_constant_p((u8 )(x)) ? \
^
drivers/rtc/rtc-mc146818-lib.c:182:9: note: '?' condition is false
min = bin2bcd(min);
^
include/linux/bcd.h:13:4: note: expanded from macro 'bin2bcd'
(__builtin_constant_p((u8 )(x)) ? \
^
drivers/rtc/rtc-mc146818-lib.c:183:9: note: '?' condition is false
hrs = bin2bcd(hrs);
^
include/linux/bcd.h:13:4: note: expanded from macro 'bin2bcd'
(__builtin_constant_p((u8 )(x)) ? \
^
drivers/rtc/rtc-mc146818-lib.c:184:9: note: '?' condition is false
day = bin2bcd(day);
^
include/linux/bcd.h:13:4: note: expanded from macro 'bin2bcd'
(__builtin_constant_p((u8 )(x)) ? \
^
drivers/rtc/rtc-mc146818-lib.c:185:9: note: '?' condition is false
mon = bin2bcd(mon);
^
include/linux/bcd.h:13:4: note: expanded from macro 'bin2bcd'
(__builtin_constant_p((u8 )(x)) ? \
^
drivers/rtc/rtc-mc146818-lib.c:186:9: note: '?' condition is false
yrs = bin2bcd(yrs);
^
include/linux/bcd.h:13:4: note: expanded from macro 'bin2bcd'
(__builtin_constant_p((u8 )(x)) ? \
^
drivers/rtc/rtc-mc146818-lib.c:187:13: note: '?' condition is false
century = bin2bcd(century);
^
include/linux/bcd.h:13:4: note: expanded from macro 'bin2bcd'
(__builtin_constant_p((u8 )(x)) ? \
^
drivers/rtc/rtc-mc146818-lib.c:190:2: note: Loop condition is false. Exiting loop
spin_lock_irqsave(&rtc_lock, flags);
^
include/linux/spinlock.h:384:2: note: expanded from macro 'spin_lock_irqsave'
raw_spin_lock_irqsave(spinlock_check(lock), flags); \
^
include/linux/spinlock.h:250:2: note: expanded from macro 'raw_spin_lock_irqsave'
do { \
^
drivers/rtc/rtc-mc146818-lib.c:190:2: note: Loop condition is false. Exiting loop
spin_lock_irqsave(&rtc_lock, flags);
^
include/linux/spinlock.h:382:43: note: expanded from macro 'spin_lock_irqsave'
#define spin_lock_irqsave(lock, flags) \
^
drivers/rtc/rtc-mc146818-lib.c:195:9: note: Assuming field 'x86_vendor' is equal to X86_VENDOR_CENTAUR
if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/rtc/rtc-mc146818-lib.c:195:56: note: Left side of '||' is true
if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
vim +227 drivers/rtc/rtc-mc146818-lib.c
d6faca40f40b62 Arnd Bergmann 2016-06-01 220
d6faca40f40b62 Arnd Bergmann 2016-06-01 221 CMOS_WRITE(save_control, RTC_CONTROL);
f7e050c4ec0065 Tony W Wang-oc 2021-08-16 222
f7e050c4ec0065 Tony W Wang-oc 2021-08-16 223 #ifdef CONFIG_X86
f7e050c4ec0065 Tony W Wang-oc 2021-08-16 224 if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
f7e050c4ec0065 Tony W Wang-oc 2021-08-16 225 boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) &&
f7e050c4ec0065 Tony W Wang-oc 2021-08-16 226 (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59)))
d6faca40f40b62 Arnd Bergmann 2016-06-01 @227 CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 35697 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
@ 2021-08-16 13:47 Tony W Wang-oc
2021-08-16 8:24 ` Alexandre Belloni
0 siblings, 1 reply; 9+ messages in thread
From: Tony W Wang-oc @ 2021-08-16 13:47 UTC (permalink / raw)
To: a.zummo, alexandre.belloni, linux-rtc, linux-kernel
Cc: TimGuo-oc, CooperYan, QiyuanWang, HerryYang, CobeChen, YanchenSun
When the RTC divider is changed from reset to an operating time base,
the first update cycle should be 500ms later. But on some Zhaoxin SOCs,
this first update cycle is one second later.
So set RTC time on these Zhaoxin SOCs will causing 500ms delay.
Skip setup RTC divider on these SOCs in mc146818_set_time to fix it.
Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
---
drivers/rtc/rtc-mc146818-lib.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
index dcfaf09..322f94b 100644
--- a/drivers/rtc/rtc-mc146818-lib.c
+++ b/drivers/rtc/rtc-mc146818-lib.c
@@ -190,8 +190,18 @@ int mc146818_set_time(struct rtc_time *time)
spin_lock_irqsave(&rtc_lock, flags);
save_control = CMOS_READ(RTC_CONTROL);
CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
+
+#ifdef CONFIG_X86
+ if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) &&
+ (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59))) {
+ save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
+ CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
+ }
+#else
save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
+#endif
#ifdef CONFIG_MACH_DECSTATION
CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
@@ -209,7 +219,15 @@ int mc146818_set_time(struct rtc_time *time)
#endif
CMOS_WRITE(save_control, RTC_CONTROL);
+
+#ifdef CONFIG_X86
+ if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) &&
+ (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59)))
+ CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
+#else
CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
+#endif
spin_unlock_irqrestore(&rtc_lock, flags);
--
2.7.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
2021-08-16 13:47 Tony W Wang-oc
@ 2021-08-16 8:24 ` Alexandre Belloni
2021-08-16 10:03 ` Tony W Wang-oc
0 siblings, 1 reply; 9+ messages in thread
From: Alexandre Belloni @ 2021-08-16 8:24 UTC (permalink / raw)
To: Tony W Wang-oc
Cc: a.zummo, linux-rtc, linux-kernel, TimGuo-oc, CooperYan,
QiyuanWang, HerryYang, CobeChen, YanchenSun
Hello,
On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote:
> When the RTC divider is changed from reset to an operating time base,
> the first update cycle should be 500ms later. But on some Zhaoxin SOCs,
> this first update cycle is one second later.
>
> So set RTC time on these Zhaoxin SOCs will causing 500ms delay.
>
Can you explain what is the relationship between writing the divider and
the 500ms delay?
Isn't the issue that you are using systohc and set_offset_nsec is set to
NSEC_PER_SEC / 2 ?
> Skip setup RTC divider on these SOCs in mc146818_set_time to fix it.
>
> Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
> ---
> drivers/rtc/rtc-mc146818-lib.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
> index dcfaf09..322f94b 100644
> --- a/drivers/rtc/rtc-mc146818-lib.c
> +++ b/drivers/rtc/rtc-mc146818-lib.c
> @@ -190,8 +190,18 @@ int mc146818_set_time(struct rtc_time *time)
> spin_lock_irqsave(&rtc_lock, flags);
> save_control = CMOS_READ(RTC_CONTROL);
> CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
> +
> +#ifdef CONFIG_X86
> + if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
> + boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) &&
> + (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59))) {
> + save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
> + CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
> + }
> +#else
> save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
> CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
> +#endif
>
> #ifdef CONFIG_MACH_DECSTATION
> CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
> @@ -209,7 +219,15 @@ int mc146818_set_time(struct rtc_time *time)
> #endif
>
> CMOS_WRITE(save_control, RTC_CONTROL);
> +
> +#ifdef CONFIG_X86
> + if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
> + boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) &&
> + (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59)))
> + CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
> +#else
> CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
> +#endif
>
> spin_unlock_irqrestore(&rtc_lock, flags);
>
> --
> 2.7.4
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
2021-08-16 8:24 ` Alexandre Belloni
@ 2021-08-16 10:03 ` Tony W Wang-oc
2021-08-16 12:36 ` Alexandre Belloni
0 siblings, 1 reply; 9+ messages in thread
From: Tony W Wang-oc @ 2021-08-16 10:03 UTC (permalink / raw)
To: Alexandre Belloni
Cc: a.zummo, linux-rtc, linux-kernel, TimGuo-oc, CooperYan,
QiyuanWang, HerryYang, CobeChen, YanchenSun
On 16/08/2021 16:24, Alexandre Belloni wrote:
> Hello,
>
> On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote:
>> When the RTC divider is changed from reset to an operating time base,
>> the first update cycle should be 500ms later. But on some Zhaoxin SOCs,
>> this first update cycle is one second later.
>>
>> So set RTC time on these Zhaoxin SOCs will causing 500ms delay.
>>
>
> Can you explain what is the relationship between writing the divider and
> the 500ms delay?
>> Isn't the issue that you are using systohc and set_offset_nsec is set to
> NSEC_PER_SEC / 2 ?
>
No.
When using #hwclock -s to set RTC time and set_offset_nsec is
NSEC_PER_SEC / 2, the function mc146818_set_time() requires the first
update cycle after RTC divider be changed from reset to an operating
mode is 500ms as the MC146818A spec specified. But on some Zhaoxin SOCs,
the first update cycle of RTC is one second later after RTC divider be
changed from reset to an operating mode. So the first update cycle after
RTC divider be changed from reset to an operation mode on These SOCs
will causing 500ms delay with current mc146818_set_time() implementation.
Sincerely
TonyWWang-oc
>> Skip setup RTC divider on these SOCs in mc146818_set_time to fix it.
>>
>> Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com>
>> ---
>> drivers/rtc/rtc-mc146818-lib.c | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/rtc/rtc-mc146818-lib.c b/drivers/rtc/rtc-mc146818-lib.c
>> index dcfaf09..322f94b 100644
>> --- a/drivers/rtc/rtc-mc146818-lib.c
>> +++ b/drivers/rtc/rtc-mc146818-lib.c
>> @@ -190,8 +190,18 @@ int mc146818_set_time(struct rtc_time *time)
>> spin_lock_irqsave(&rtc_lock, flags);
>> save_control = CMOS_READ(RTC_CONTROL);
>> CMOS_WRITE((save_control|RTC_SET), RTC_CONTROL);
>> +
>> +#ifdef CONFIG_X86
>> + if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
>> + boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) &&
>> + (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59))) {
>> + save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
>> + CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
>> + }
>> +#else
>> save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
>> CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
>> +#endif
>>
>> #ifdef CONFIG_MACH_DECSTATION
>> CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
>> @@ -209,7 +219,15 @@ int mc146818_set_time(struct rtc_time *time)
>> #endif
>>
>> CMOS_WRITE(save_control, RTC_CONTROL);
>> +
>> +#ifdef CONFIG_X86
>> + if (!((boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR ||
>> + boot_cpu_data.x86_vendor == X86_VENDOR_ZHAOXIN) &&
>> + (boot_cpu_data.x86 <= 7 && boot_cpu_data.x86_model <= 59)))
>> + CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
>> +#else
>> CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
>> +#endif
>>
>> spin_unlock_irqrestore(&rtc_lock, flags);
>>
>> --
>> 2.7.4
>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
2021-08-16 10:03 ` Tony W Wang-oc
@ 2021-08-16 12:36 ` Alexandre Belloni
2021-08-17 11:09 ` tonywwang-oc
0 siblings, 1 reply; 9+ messages in thread
From: Alexandre Belloni @ 2021-08-16 12:36 UTC (permalink / raw)
To: Tony W Wang-oc
Cc: a.zummo, linux-rtc, linux-kernel, TimGuo-oc, CooperYan,
QiyuanWang, HerryYang, CobeChen, YanchenSun
On 16/08/2021 18:03:13+0800, Tony W Wang-oc wrote:
>
> On 16/08/2021 16:24, Alexandre Belloni wrote:
> > Hello,
> >
> > On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote:
> >> When the RTC divider is changed from reset to an operating time base,
> >> the first update cycle should be 500ms later. But on some Zhaoxin SOCs,
> >> this first update cycle is one second later.
> >>
> >> So set RTC time on these Zhaoxin SOCs will causing 500ms delay.
> >>
> >
> > Can you explain what is the relationship between writing the divider and
> > the 500ms delay?
> >> Isn't the issue that you are using systohc and set_offset_nsec is set to
> > NSEC_PER_SEC / 2 ?
> >
> No.
> When using #hwclock -s to set RTC time and set_offset_nsec is
> NSEC_PER_SEC / 2, the function mc146818_set_time() requires the first
> update cycle after RTC divider be changed from reset to an operating
> mode is 500ms as the MC146818A spec specified. But on some Zhaoxin SOCs,
> the first update cycle of RTC is one second later after RTC divider be
> changed from reset to an operating mode. So the first update cycle after
> RTC divider be changed from reset to an operation mode on These SOCs
> will causing 500ms delay with current mc146818_set_time() implementation.
>
What happens with hwclock --delay=0 -s ?
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
2021-08-16 12:36 ` Alexandre Belloni
@ 2021-08-17 11:09 ` tonywwang-oc
2021-08-17 13:21 ` Alexandre Belloni
0 siblings, 1 reply; 9+ messages in thread
From: tonywwang-oc @ 2021-08-17 11:09 UTC (permalink / raw)
To: Alexandre Belloni
Cc: a.zummo, linux-rtc, linux-kernel, TimGuo-oc, CooperYan,
QiyuanWang, HerryYang, CobeChen, YanchenSun
On August 16, 2021 8:36:48 PM GMT+08:00, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
>On 16/08/2021 18:03:13+0800, Tony W Wang-oc wrote:
>>
>> On 16/08/2021 16:24, Alexandre Belloni wrote:
>> > Hello,
>> >
>> > On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote:
>> >> When the RTC divider is changed from reset to an operating time
>base,
>> >> the first update cycle should be 500ms later. But on some Zhaoxin
>SOCs,
>> >> this first update cycle is one second later.
>> >>
>> >> So set RTC time on these Zhaoxin SOCs will causing 500ms delay.
>> >>
>> >
>> > Can you explain what is the relationship between writing the
>divider and
>> > the 500ms delay?
>> >> Isn't the issue that you are using systohc and set_offset_nsec is
>set to
>> > NSEC_PER_SEC / 2 ?
>> >
>> No.
>> When using #hwclock -s to set RTC time and set_offset_nsec is
>> NSEC_PER_SEC / 2, the function mc146818_set_time() requires the first
>> update cycle after RTC divider be changed from reset to an operating
>> mode is 500ms as the MC146818A spec specified. But on some Zhaoxin
>SOCs,
>> the first update cycle of RTC is one second later after RTC divider
>be
>> changed from reset to an operating mode. So the first update cycle
>after
>> RTC divider be changed from reset to an operation mode on These SOCs
>> will causing 500ms delay with current mc146818_set_time()
>implementation.
>>
>
>What happens with hwclock --delay=0 -s ?
With "hwclock --delay=0 -s" still have this problem. Actually, this 500ms delay caused by writing the RTC time on these Zhaoxin SOCs.
As I've tested, with hwclock --delay=0 -w can fix it too.
Sincerely
TonyWWang-oc
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
2021-08-17 11:09 ` tonywwang-oc
@ 2021-08-17 13:21 ` Alexandre Belloni
2021-08-18 3:54 ` tonywwang-oc
0 siblings, 1 reply; 9+ messages in thread
From: Alexandre Belloni @ 2021-08-17 13:21 UTC (permalink / raw)
To: tonywwang-oc
Cc: a.zummo, linux-rtc, linux-kernel, TimGuo-oc, CooperYan,
QiyuanWang, HerryYang, CobeChen, YanchenSun
On 17/08/2021 19:09:28+0800, tonywwang-oc@zhaoxin.com wrote:
>
>
> On August 16, 2021 8:36:48 PM GMT+08:00, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
> >On 16/08/2021 18:03:13+0800, Tony W Wang-oc wrote:
> >>
> >> On 16/08/2021 16:24, Alexandre Belloni wrote:
> >> > Hello,
> >> >
> >> > On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote:
> >> >> When the RTC divider is changed from reset to an operating time
> >base,
> >> >> the first update cycle should be 500ms later. But on some Zhaoxin
> >SOCs,
> >> >> this first update cycle is one second later.
> >> >>
> >> >> So set RTC time on these Zhaoxin SOCs will causing 500ms delay.
> >> >>
> >> >
> >> > Can you explain what is the relationship between writing the
> >divider and
> >> > the 500ms delay?
> >> >> Isn't the issue that you are using systohc and set_offset_nsec is
> >set to
> >> > NSEC_PER_SEC / 2 ?
> >> >
> >> No.
> >> When using #hwclock -s to set RTC time and set_offset_nsec is
> >> NSEC_PER_SEC / 2, the function mc146818_set_time() requires the first
> >> update cycle after RTC divider be changed from reset to an operating
> >> mode is 500ms as the MC146818A spec specified. But on some Zhaoxin
> >SOCs,
> >> the first update cycle of RTC is one second later after RTC divider
> >be
> >> changed from reset to an operating mode. So the first update cycle
> >after
> >> RTC divider be changed from reset to an operation mode on These SOCs
> >> will causing 500ms delay with current mc146818_set_time()
> >implementation.
> >>
> >
> >What happens with hwclock --delay=0 -s ?
>
> With "hwclock --delay=0 -s" still have this problem. Actually, this 500ms delay caused by writing the RTC time on these Zhaoxin SOCs.
> As I've tested, with hwclock --delay=0 -w can fix it too.
>
Both -s and -w end up calling set_hardware_clock_exact() so both should
end up with the correct time. If this is not the case, then hwclock
needs to be fixed.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
2021-08-17 13:21 ` Alexandre Belloni
@ 2021-08-18 3:54 ` tonywwang-oc
2021-10-26 11:42 ` tonywwang-oc
0 siblings, 1 reply; 9+ messages in thread
From: tonywwang-oc @ 2021-08-18 3:54 UTC (permalink / raw)
To: Alexandre Belloni
Cc: a.zummo, linux-rtc, linux-kernel, TimGuo-oc, CooperYan,
QiyuanWang, HerryYang, CobeChen, YanchenSun
On August 17, 2021 9:21:03 PM GMT+08:00, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
>On 17/08/2021 19:09:28+0800, tonywwang-oc@zhaoxin.com wrote:
>>
>>
>> On August 16, 2021 8:36:48 PM GMT+08:00, Alexandre Belloni
><alexandre.belloni@bootlin.com> wrote:
>> >On 16/08/2021 18:03:13+0800, Tony W Wang-oc wrote:
>> >>
>> >> On 16/08/2021 16:24, Alexandre Belloni wrote:
>> >> > Hello,
>> >> >
>> >> > On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote:
>> >> >> When the RTC divider is changed from reset to an operating time
>> >base,
>> >> >> the first update cycle should be 500ms later. But on some
>Zhaoxin
>> >SOCs,
>> >> >> this first update cycle is one second later.
>> >> >>
>> >> >> So set RTC time on these Zhaoxin SOCs will causing 500ms delay.
>> >> >>
>> >> >
>> >> > Can you explain what is the relationship between writing the
>> >divider and
>> >> > the 500ms delay?
>> >> >> Isn't the issue that you are using systohc and set_offset_nsec
>is
>> >set to
>> >> > NSEC_PER_SEC / 2 ?
>> >> >
>> >> No.
>> >> When using #hwclock -s to set RTC time and set_offset_nsec is
>> >> NSEC_PER_SEC / 2, the function mc146818_set_time() requires the
>first
>> >> update cycle after RTC divider be changed from reset to an
>operating
>> >> mode is 500ms as the MC146818A spec specified. But on some Zhaoxin
>> >SOCs,
>> >> the first update cycle of RTC is one second later after RTC
>divider
>> >be
>> >> changed from reset to an operating mode. So the first update cycle
>> >after
>> >> RTC divider be changed from reset to an operation mode on These
>SOCs
>> >> will causing 500ms delay with current mc146818_set_time()
>> >implementation.
>> >>
>> >
>> >What happens with hwclock --delay=0 -s ?
>>
>> With "hwclock --delay=0 -s" still have this problem. Actually, this
>500ms delay caused by writing the RTC time on these Zhaoxin SOCs.
>> As I've tested, with hwclock --delay=0 -w can fix it too.
>>
>
>Both -s and -w end up calling set_hardware_clock_exact() so both should
>end up with the correct time. If this is not the case, then hwclock
>needs to be fixed.
I checked Util-linux-2.37.2, hwclock -w will call
set_hardware_clock_exact() and hwclock -s will not.
Please correct me if I'm wrong.
Sincerely
TonyWWang-oc
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs
2021-08-18 3:54 ` tonywwang-oc
@ 2021-10-26 11:42 ` tonywwang-oc
0 siblings, 0 replies; 9+ messages in thread
From: tonywwang-oc @ 2021-10-26 11:42 UTC (permalink / raw)
To: Alexandre Belloni
Cc: a.zummo, linux-rtc, linux-kernel, TimGuo-oc, CooperYan,
QiyuanWang, HerryYang, CobeChen, YanchenSun
On August 18, 2021 11:54:20 AM GMT+08:00, tonywwang-oc@zhaoxin.com wrote:
>
>
>On August 17, 2021 9:21:03 PM GMT+08:00, Alexandre Belloni
><alexandre.belloni@bootlin.com> wrote:
>>On 17/08/2021 19:09:28+0800, tonywwang-oc@zhaoxin.com wrote:
>>>
>>>
>>> On August 16, 2021 8:36:48 PM GMT+08:00, Alexandre Belloni
>><alexandre.belloni@bootlin.com> wrote:
>>> >On 16/08/2021 18:03:13+0800, Tony W Wang-oc wrote:
>>> >>
>>> >> On 16/08/2021 16:24, Alexandre Belloni wrote:
>>> >> > Hello,
>>> >> >
>>> >> > On 16/08/2021 21:47:18+0800, Tony W Wang-oc wrote:
>>> >> >> When the RTC divider is changed from reset to an operating
>time
>>> >base,
>>> >> >> the first update cycle should be 500ms later. But on some
>>Zhaoxin
>>> >SOCs,
>>> >> >> this first update cycle is one second later.
>>> >> >>
>>> >> >> So set RTC time on these Zhaoxin SOCs will causing 500ms
>delay.
>>> >> >>
>>> >> >
>>> >> > Can you explain what is the relationship between writing the
>>> >divider and
>>> >> > the 500ms delay?
>>> >> >> Isn't the issue that you are using systohc and set_offset_nsec
>>is
>>> >set to
>>> >> > NSEC_PER_SEC / 2 ?
>>> >> >
>>> >> No.
>>> >> When using #hwclock -s to set RTC time and set_offset_nsec is
>>> >> NSEC_PER_SEC / 2, the function mc146818_set_time() requires the
>>first
>>> >> update cycle after RTC divider be changed from reset to an
>>operating
>>> >> mode is 500ms as the MC146818A spec specified. But on some
>Zhaoxin
>>> >SOCs,
>>> >> the first update cycle of RTC is one second later after RTC
>>divider
>>> >be
>>> >> changed from reset to an operating mode. So the first update
>cycle
>>> >after
>>> >> RTC divider be changed from reset to an operation mode on These
>>SOCs
>>> >> will causing 500ms delay with current mc146818_set_time()
>>> >implementation.
>>> >>
>>> >
>>> >What happens with hwclock --delay=0 -s ?
>>>
>>> With "hwclock --delay=0 -s" still have this problem. Actually, this
>>500ms delay caused by writing the RTC time on these Zhaoxin SOCs.
>>> As I've tested, with hwclock --delay=0 -w can fix it too.
>>>
>>
>>Both -s and -w end up calling set_hardware_clock_exact() so both
>should
>>end up with the correct time. If this is not the case, then hwclock
>>needs to be fixed.
>
>I checked Util-linux-2.37.2, hwclock -w will call
>set_hardware_clock_exact() and hwclock -s will not.
>Please correct me if I'm wrong.
>
>Sincerely
>TonyWWang-oc
As explained before, the root cause of this problem is: these Zhaoxin SOCs
which belong to X86 architecture do not meet the requirement of
MC146818A compatible RTC about “When the divider is changed from reset
to an operating time base, the first update cycle is one-half second later”.
Actually the first update cycle on these Zhaoxin SOCs is one second later in
this case.
This problem is not only happened when running “hwclock -w”. On X86 platform,
the 0.5s delay is default for both “hwclock –w” and NTP driver’s invoke of
sync_cmos_clock(). So set RTC time caused by NTP driver also has this problem.
As have been test pass, skip operate the RTC_REG_A (which divider-control bits in)
with these Zhaoxin SOCs in function mc146818_set_time() can fix this problem.
I think this patch seems appropriate.
Sincerely
TonyWWang-oc
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-10-26 11:57 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-17 9:10 [PATCH] rtc: Fix set RTC time delay 500ms on some Zhaoxin SOCs kernel test robot
-- strict thread matches above, loose matches on Subject: below --
2021-08-16 13:47 Tony W Wang-oc
2021-08-16 8:24 ` Alexandre Belloni
2021-08-16 10:03 ` Tony W Wang-oc
2021-08-16 12:36 ` Alexandre Belloni
2021-08-17 11:09 ` tonywwang-oc
2021-08-17 13:21 ` Alexandre Belloni
2021-08-18 3:54 ` tonywwang-oc
2021-10-26 11:42 ` tonywwang-oc
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.