* Re: TS-219 RTC issue with Debian Buster [not found] <99a8e2cc-61a2-3b43-0d72-6f001cffe572@hartkopp.net> @ 2019-07-23 19:06 ` Uwe Kleine-König 2019-07-23 19:21 ` Oliver Hartkopp 0 siblings, 1 reply; 4+ messages in thread From: Uwe Kleine-König @ 2019-07-23 19:06 UTC (permalink / raw) To: Oliver Hartkopp Cc: linux-arm-kernel, Andrew Lunn, tbm, Alessandro Zummo, Alexandre Belloni, linux-rtc Hello Oliver, I added the RTC maintainers and list to Cc. On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: > I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. > > They use dtbs/4.19.0-5-marvell/./kirkwood-ts219-6282.dtb > > Unfortunately the RTC doesn't seem to work. > > root@xxxxx:~# hwclock -v --test > hwclock from util-linux 2.33.1 > System Time: 1563296223.425648 > Trying to open: /dev/rtc0 > Using the rtc interface to the clock. > Last drift adjustment done at 1563291472 seconds after 1969 > Last calibration done at 1563291472 seconds after 1969 > Hardware clock is on UTC time > Assuming hardware clock is kept in UTC time. > Waiting for clock tick... > hwclock: select() to /dev/rtc0 to wait for clock tick timed out > ...synchronization failed > Test mode: nothing was changed. > With strace the clock tick problem looks like this: > > write(1, "Waiting for clock tick...\n", 26Waiting for clock tick... > ) = 26 > ioctl(4, RTC_UIE_ON) = 0 > _newselect(5, [4], NULL, NULL, {tv_sec=10, tv_usec=0}) = 0 (Timeout) > write(2, "hwclock: ", 9hwclock: ) = 9 > write(2, "select() to /dev/rtc0 to wait fo"..., 54select() to /dev/rtc0 to > wait for clock tick timed out) = 54 > write(2, "\n", 1) = 1 > ioctl(4, PHN_NOT_OH or RTC_UIE_OFF) = 0 Maybe rtc-mv should set uie_unsupported if no irq is aquired? > It looks the same with > > # hwclock --hctosys > hwclock: select() to /dev/rtc0 to wait for clock tick timed out hwclock (from util-linux) is being stupid here. The tradtional RTC on the x86 platform has a resolution of 1s only and if you set it the next increment is 1 second after the last increment instead of 1 second after the new time was set. So hwclock waits for an update event and then sets the new time (in some cases to a tad later than requested) to ensure the PC clock is off by less than half a second. For most (if not all) other RTCs this is wrong and still worse if the RTC in question doesn't support UIE. > I wonder whether the problem comes from a missing interrupt assignment > > rtc: rtc@10300 { > compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; > reg = <0x10300 0x20>; > interrupts = <53>; <- HERE!?! > clocks = <&gate_clk 7>; > }; > > ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? > > In /proc/interrupts there's no rtc assigned to an interrupt 53. What is the output of dmesg | grep 10300 ? > Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries works > well and setting the date/time via "hwclock --systohc" does its job too. So > I2C and the rtc_s35390a driver seem to work so far. You're not using the s35390a driver, do you? > Any ideas why hwclock fails to work properly? Try if busybox hwclock works better for you. At least this one doesn't have this strange PC quirk. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 19:06 ` TS-219 RTC issue with Debian Buster Uwe Kleine-König @ 2019-07-23 19:21 ` Oliver Hartkopp 2019-07-23 19:34 ` Uwe Kleine-König 0 siblings, 1 reply; 4+ messages in thread From: Oliver Hartkopp @ 2019-07-23 19:21 UTC (permalink / raw) To: Uwe Kleine-König Cc: linux-arm-kernel, Andrew Lunn, tbm, Alessandro Zummo, Alexandre Belloni, linux-rtc Hello Uwe, nice to read from you again :-) I think I already solved the problem, see here: https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2 Will file a Debian bug for it ... Many thanks, Oliver On 23.07.19 21:06, Uwe Kleine-König wrote: > Hello Oliver, > > I added the RTC maintainers and list to Cc. > > On Tue, Jul 23, 2019 at 05:30:48PM +0200, Oliver Hartkopp wrote: >> I upgraded my TS-219 to Debian Buster with Kernel 4.19.0-5-marvell. >> >> They use dtbs/4.19.0-5-marvell/./kirkwood-ts219-6282.dtb >> >> Unfortunately the RTC doesn't seem to work. >> >> root@xxxxx:~# hwclock -v --test >> hwclock from util-linux 2.33.1 >> System Time: 1563296223.425648 >> Trying to open: /dev/rtc0 >> Using the rtc interface to the clock. >> Last drift adjustment done at 1563291472 seconds after 1969 >> Last calibration done at 1563291472 seconds after 1969 >> Hardware clock is on UTC time >> Assuming hardware clock is kept in UTC time. >> Waiting for clock tick... >> hwclock: select() to /dev/rtc0 to wait for clock tick timed out >> ...synchronization failed >> Test mode: nothing was changed. >> With strace the clock tick problem looks like this: >> >> write(1, "Waiting for clock tick...\n", 26Waiting for clock tick... >> ) = 26 >> ioctl(4, RTC_UIE_ON) = 0 >> _newselect(5, [4], NULL, NULL, {tv_sec=10, tv_usec=0}) = 0 (Timeout) >> write(2, "hwclock: ", 9hwclock: ) = 9 >> write(2, "select() to /dev/rtc0 to wait fo"..., 54select() to /dev/rtc0 to >> wait for clock tick timed out) = 54 >> write(2, "\n", 1) = 1 >> ioctl(4, PHN_NOT_OH or RTC_UIE_OFF) = 0 > > Maybe rtc-mv should set uie_unsupported if no irq is aquired? > >> It looks the same with >> >> # hwclock --hctosys >> hwclock: select() to /dev/rtc0 to wait for clock tick timed out > > hwclock (from util-linux) is being stupid here. The tradtional RTC on > the x86 platform has a resolution of 1s only and if you set it the next > increment is 1 second after the last increment instead of 1 second after > the new time was set. So hwclock waits for an update event and then sets > the new time (in some cases to a tad later than requested) to ensure the > PC clock is off by less than half a second. For most (if not all) other > RTCs this is wrong and still worse if the RTC in question doesn't > support UIE. > >> I wonder whether the problem comes from a missing interrupt assignment >> >> rtc: rtc@10300 { >> compatible = "marvell,kirkwood-rtc", "marvell,orion-rtc"; >> reg = <0x10300 0x20>; >> interrupts = <53>; <- HERE!?! >> clocks = <&gate_clk 7>; >> }; >> >> ... I found in linux/arch/arm/boot/dts/kirkwood-6282.dtsi ?!? >> >> In /proc/interrupts there's no rtc assigned to an interrupt 53. > > What is the output of dmesg | grep 10300 ? > >> Accessing the rtc values (time/date) via /sys/class/rtc/rtc0 entries works >> well and setting the date/time via "hwclock --systohc" does its job too. So >> I2C and the rtc_s35390a driver seem to work so far. > > You're not using the s35390a driver, do you? > >> Any ideas why hwclock fails to work properly? > > Try if > > busybox hwclock > > works better for you. At least this one doesn't have this strange PC > quirk. > > Best regards > Uwe > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 19:21 ` Oliver Hartkopp @ 2019-07-23 19:34 ` Uwe Kleine-König 2019-07-23 20:07 ` Oliver Hartkopp 0 siblings, 1 reply; 4+ messages in thread From: Uwe Kleine-König @ 2019-07-23 19:34 UTC (permalink / raw) To: Oliver Hartkopp Cc: linux-arm-kernel, Andrew Lunn, tbm, Alessandro Zummo, Alexandre Belloni, linux-rtc Hello Oliver, On Tue, Jul 23, 2019 at 09:21:06PM +0200, Oliver Hartkopp wrote: > I think I already solved the problem, see here: > https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2 IMHO the right fix is teach hwclock to handle your rtc correctly. Changing the driver from =m to =y is only a workaround. Maybe also using the time stuff from systemd instead of hwclock will help^Wwork around your problem (not sure though). Also I wonder why the ioctl to enable UIE doesn't fail if the driver set .uie_unsupported (but I didn't look closely). > Will file a Debian bug for it ... Not sure this will have success. These were switched from =y to =m because the kernel images got to big. (https://salsa.debian.org/kernel-team/linux/commit/c55043a43eaacb9f876dabd71273b084cb024441) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TS-219 RTC issue with Debian Buster 2019-07-23 19:34 ` Uwe Kleine-König @ 2019-07-23 20:07 ` Oliver Hartkopp 0 siblings, 0 replies; 4+ messages in thread From: Oliver Hartkopp @ 2019-07-23 20:07 UTC (permalink / raw) To: Uwe Kleine-König Cc: linux-arm-kernel, Andrew Lunn, tbm, Alessandro Zummo, Alexandre Belloni, linux-rtc Hello Uwe, On 23.07.19 21:34, Uwe Kleine-König wrote: > On Tue, Jul 23, 2019 at 09:21:06PM +0200, Oliver Hartkopp wrote: >> I think I already solved the problem, see here: >> https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2 > > IMHO the right fix is teach hwclock to handle your rtc correctly. > Changing the driver from =m to =y is only a workaround. Agreed. > Maybe also using the time stuff from systemd instead of hwclock will > help^Wwork around your problem (not sure though). > > Also I wonder why the ioctl to enable UIE doesn't fail if the driver set > .uie_unsupported (but I didn't look closely). Right. When executing the ioctl(4, RTC_UIE_ON) syscall it just get's stuck and the select() timeout captures the call after 10 seconds. I would have expected that ioctl(4, RTC_UIE_ON) returns with some -EINVAL or -ENOTSUPP value. I'm not sure if hwclock needs the trigger for precision reasons: https://github.com/karelzak/util-linux/blob/master/sys-utils/hwclock.c#L276 ... or if this can be omitted. >> Will file a Debian bug for it ... > > Not sure this will have success. These were switched from =y to =m > because the kernel images got to big. > (https://salsa.debian.org/kernel-team/linux/commit/c55043a43eaacb9f876dabd71273b084cb024441) Too late ;-) I will just wait for the answer. Best regards, Oliver ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-07-23 20:13 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <99a8e2cc-61a2-3b43-0d72-6f001cffe572@hartkopp.net> 2019-07-23 19:06 ` TS-219 RTC issue with Debian Buster Uwe Kleine-König 2019-07-23 19:21 ` Oliver Hartkopp 2019-07-23 19:34 ` Uwe Kleine-König 2019-07-23 20:07 ` Oliver Hartkopp
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).