DryIce , RTC not working on imx53.

DryIce , RTC not working on imx53.

[Vellemans, Noel]

Hello,

DryIce , SRTC not working on imx53. ( kernel 4.x) ?( same hardware running older kernel versions.. means , rtc is working)

During boot all seems to be fine but once you try to read or write the hardware clock later on ? it bails out with this error on the console. 

hwclock

[   97.186577] imxdi_rtc 53fa4000.rtc: Write-wait timeout val = 0x5a2ff8d3 reg = 0x00000008

Hwclock : select() to /dev/rtc0 to wait for clock tick timed out: No such file or directory



I've Added some driver ? printk?s?.

# hwclock
[   73.362559] dryice_rtc_read_time ------------------------------------------------
[   73.395077] dryice_rtc_read_time ------------------------------------------------
[   73.414156] dryice_rtc_read_time ------------------------------------------------
[   73.421700] di_write_wait ------------------------------------------------
[   73.472624] di_int_enable ------------------------------------------------
[   73.514609] imxdi_rtc 53fa4000.srtc: Write-wait timeout val = 0x5a3000c8 reg = 0x00000008
[   73.523019] di_int_enable ------------------------------------------------

<< STALLS for 5 seconds here >>
<< STALLS for 5 seconds here >>
<< STALLS for 5 seconds here >>
<< STALLS for 5 seconds here >>
<< STALLS for 5 seconds here >>

hwclock[   78.584909] dryice_rtc_alarm_irq_enable ------------------------------------------------
: select() to /dev/rtc0 to wait f[   78.593456] di_int_disable ------------------------------------------------
or clock tick timed out: No such file or directory






Strace .. logging ================================


stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0777, st_size=25300, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000, -1, 0) = 0xb6f04000
set_tls(0xb6f04490, 0xb6f04b38, 0xb6f07088, 0xb6f04490, 0xb6f06f74) = 0
mprotect(0xb6ed2000, 4096, PROT_READ)   = 0
mprotect(0xb6f06000, 4096, PROT_READ)   = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B115200 opost isig icanon echo ...}) = 0
gettimeofday({1513095430, 708097}, NULL) = 0
getuid32()                              = 0
open("/dev/rtc", O_RDONLY|O_LARGEFILE)  = -1 ENOENT (No such file or directory)
open("/dev/rtc0", O_RDONLY|O_LARGEFILE) = 3
brk(0)                                  = 0x18000
brk(0x19000)                            = 0x19000
stat64("/etc/adjtime", 0xbeec26a8)      = -1 ENOENT (No such file or directory)
ioctl(3, PHN_SET_REGS or RTC_UIE_ON, 0) = 0
select(4, [3], NULL, NULL, {5, 0}


<< STALLS for 5 seconds here  --  select is not returning !!! timeout is 5 seconds?. >>

)      = 0 (Timeout)[  141.766162] dryice_rtc_alarm_irq_enable ------------------------------------------------

write(2, "hwclock", 7hwclock)                  = 7
write(2, ": ", 2: )                       =[  141.782195] di_int_disable ------------------------------------------------
2
write(2, "select() to ", 12select() to )            = 12
write(2, "/dev/rtc0", 9/dev/rtc0)                = 9
write(2, " to wait for clock tick timed ou"..., 33 to wait for clock tick timed out) = 33
write(2, ": ", 2: )                       = 2
write(2, "No such file or directory", 25No such file or directory) = 25
write(2, "\n", 1
)                       = 1
ioctl(3, PHN_NOT_OH or RTC_UIE_OFF, 0)  = 0
close(3)                                = 0
exit_group(74)                          = ?








QUICK analyses  ( could be wrong) ? 
It seems that hwclock is reading the current-timestamp 3 times and if not changed in those 3 read cycles? it sets up an read-interrupt-abort able time reader that should return as soon as the irq fires? but this seems to be missing !

FYI:  I?ve been using following commint to enable srtc.
commit 5b725054147deaf966b3919e10a86c6bfe946a18
Author: Patrick Bruenn <p.bruenn@beckhoff.com>
Date:? ?Wed Jul 26 14:05:32 2017 +0200

? ? ARM: dts: imx53: add srtc node
? ??
? ? The i.MX53 has an integrated secure real time clock. Add it to the dtsi.
? ??
? ? Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
? ? Signed-off-by: Shawn Guo <shawnguo@kernel.org>

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 2e516f4..8bf0d89 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -433,6 +433,15 @@
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? clock-names = "ipg", "per";
? ? ? ? ? ? ? ? ? ? ? ? };
?
+? ? ? ? ? ? ? ? ? ? ? ?srtc: srtc at 53fa4000 {
+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?compatible = "fsl,imx53-rtc", "fsl,imx25-rtc";
+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?reg = <0x53fa4000 0x4000>;
+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?interrupts = <24>;
+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?interrupt-parent = <&tzic>;
+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?clocks = <&clks IMX5_CLK_SRTC_GATE>;
+? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?clock-names = "ipg";
+? ? ? ? ? ? ? ? ? ? ? ?};
+

Best Regards
Noel

DryIce , RTC not working on imx53.

[Patrick Brünn]

>From: Vellemans, Noel [mailto:Noel.Vellemans at visionBMS.com]
>Sent: Donnerstag, 5. Oktober 2017 16:19
>Hello,
>
Hi,
not sure if I can help on this, but as I did some testing myself I thought I should throw in my results as well.

>DryIce , SRTC not working on imx53. ( kernel 4.x)  ( same hardware running
>older kernel versions.. means , rtc is working)
>
Is it only the kernel you are changing? I am asking because I had the impression that hwclock behaves different on Debian stretch (util-linux 2.29.2) and jessie (util-linux 2.25.2).
I am saying impression because it seemed on jessie I would always get a response of hwclock, but on stretch never. When I did more systematic testing it looks like right after boot hwclock -r will always fail. But if I wait some minutes, all calls succeed.
>...
>QUICK analyses  ( could be wrong) ?
>It seems that hwclock is reading the current-timestamp 3 times and if not
>changed in those 3 read cycles? it sets up an read-interrupt-abort able time
>reader that should return as soon as the irq fires? but this seems to be
>missing !
>
I am seeing a lot of interrupts with kernel 4.14-rc4 (jessie and stretch), but they seem to be unhandled:
root at CX9020:~# uname -a
Linux CX9020 4.14.0-rc4+ #151 PREEMPT Wed Oct 11 10:40:34 CEST 2017 armv7l GNU/Linux
root at CX9020:~# hwclock -D -r
hwclock from util-linux 2.29.2
Using the /dev interface to the clock.
Last drift adjustment done at 1490885082 seconds after 1969
Last calibration done at 1490885082 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
[   26.795437] irq 40: nobody cared (try booting with the "irqpoll" option)
[   26.802696] handlers:
[   26.805031] [<c06029e8>] dryice_irq
[   26.808584] Disabling IRQ #40
select() to /dev/rtc to wait for clock tick timed out...synchronization failed
root at CX9020:~# cat /proc/interrupts
           CPU0
 17:       4276      tzic   1 Edge      mmc0
 18:         52      tzic   2 Edge      mmc1
 22:          0      tzic   6 Edge      sdma
 30:        176      tzic  14 Edge      53f80200.usb
 40:     100000      tzic  24 Edge      53fa4000.srtc
 48:        268      tzic  32 Edge      53fc0000.serial
 55:       2288      tzic  39 Edge      i.MX Timer Tick
 74:          0      tzic  58 Edge      53f98000.wdog
 79:        278      tzic  63 Edge      63fc4000.i2c
 93:          0      tzic  77 Edge      arm-pmu
103:        662      tzic  87 Edge      63fec000.ethernet
145:          0  gpio-mxc   1 Edge      50004000.esdhc cd
148:          0  gpio-mxc   4 Edge      50008000.esdhc cd
368:        674       IPU  23 Edge      imx_drm
369:          0       IPU  28 Edge      imx_drm
Err:          0

I added some tracing to dryice_irq() and saw that most of the time (if not all the time) dsr == DSR_MCO /* monotonic clock overflow */ with dier vary between 0x110, 0x10 and even 0x0.
I don't know what's the right thing to do, to recover from DSR_MCO. " return IRQ_HANDLED" will stop the nobody cared message but hwclock still times out.

And for completeness:
root at CX9020:~# dmesg | grep srtc
[    0.299043] imxdi_rtc 53fa4000.srtc: Unlocked unit detected
[    0.299539] imxdi_rtc 53fa4000.srtc: security violation interrupt not available.
[    0.299757] rtc rtc0: 53fa4000.srtc: dev (253:0)
[    0.299778] imxdi_rtc 53fa4000.srtc: rtc core: registered 53fa4000.srtc as rtc0
[    0.436785] imxdi_rtc 53fa4000.srtc: setting system clock to 2017-10-12 06:38:08 UTC (1507790288)
[  445.486624] imxdi_rtc 53fa4000.srtc: Write-wait timeout val = 0x59df0f8e reg = 0x00000008
[ 3025.076612] imxdi_rtc 53fa4000.srtc: Write-wait timeout val = 0x59df19a2 reg = 0x00000008
[ 3082.316612] imxdi_rtc 53fa4000.srtc: Write-wait timeout val = 0x59df19db reg = 0x00000008

Novice question: Is hwclock still required these days? For me it looks like the kernel is synchronizing with rtc on it's own. Maybe some kernel config is incompatible with hwclock?

Regards,
Patrick
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075

DryIce , RTC not working on imx53.

[Russell King - ARM Linux]

On Thu, Oct 12, 2017 at 07:50:41AM +0000, Patrick Br?nn wrote:
> Novice question: Is hwclock still required these days? For me it looks
> like the kernel is synchronizing with rtc on it's own. Maybe some kernel
> config is incompatible with hwclock?

It depends on your application.  If you want the kernel's idea of time
to be wrong up to a second or two, then you can rely on the kernel's
time setting.

Please realise that the kernel has always set the time from the RTC,
even on x86 where hwclock has been used.  hwclock, however, has some
advanced features and advantages that are beneficial if you're after
accuracy.

1) hwclock will try to read the RTC as close to a second-change as
   possible, so that the time read from the RTC is as close to the
   second.

2) hwclock can measure and correct the RTC time for its own drift if
   hwclock has been allowed to capture and process the offset.

What this means is that hwclock has the capability to precisely set
the kernel's time at boot, way more accurately than the kernel does.
The kernel's time setting is focused on speed, not accuracy.

So, if your userspace application is to monitor something using a
precise timestamp, and you are NTP synchronising (or other method) the
time on the system, then you need the kernel's idea of time to be set
much more precisely to avoid NTP making big corrections over the
following three to six hours.

This happens because NTP will slew the clock for a few seconds of
difference, which makes storing and reloading the PPM value useless,
and can also mean that in such a monitoring application, the results
are unreliable until NTP has re-stabilised.

Here's an example of an application where this may matter: average
speed camera system.  You have two cameras over a section of road,
each with their own processing, which are NTP synchronised.  Each
reads the numberplate of passing vehicles using ANPR technology,
and timestamps the passing of the vehicle using their local clock.
The distance is known, so it's an easy calculation to calculate the
vehicle speed.  If the vehicle speed is over the limit, the driver
is fined.

Consider what the implications are if one of the systems rebooted
and then had incorrect time (up to two seconds wrong) for up to six
hours after - a two second error is about a 3% error in recorded
speed.  Would you want to be sent a speeding fine from such a system?

(We have the first non-motorway road in Surrey, UK to have average
speed cameras installed down its entire length because of "piston
heads" who think the speed limit is 60mph rather than the sign-
posted 40mph.)

Another, probably more relevant application is a stratum-1 NTP server
synchronised via PPS to a GPS.  I wonder how many people are aware
that if you reboot such a setup relying on the kernel's time setting
only, the time sent to clients will be wrong while NTP slews the local
clock.  I've seen these effects locally, where rebooting exactly such
a system results in slaved systems which have no other source of time
also making big corrections.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

DryIce , RTC not working on imx53.

[Alexandre Belloni]

On 12/10/2017 at 07:50:41 +0000, Patrick Br?nn wrote:
> I am seeing a lot of interrupts with kernel 4.14-rc4 (jessie and stretch), but they seem to be unhandled:
> root at CX9020:~# uname -a
> Linux CX9020 4.14.0-rc4+ #151 PREEMPT Wed Oct 11 10:40:34 CEST 2017 armv7l GNU/Linux
> root at CX9020:~# hwclock -D -r
> hwclock from util-linux 2.29.2
> Using the /dev interface to the clock.
> Last drift adjustment done at 1490885082 seconds after 1969
> Last calibration done at 1490885082 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> [   26.795437] irq 40: nobody cared (try booting with the "irqpoll" option)
> [   26.802696] handlers:
> [   26.805031] [<c06029e8>] dryice_irq
> [   26.808584] Disabling IRQ #40
> select() to /dev/rtc to wait for clock tick timed out...synchronization failed
> root at CX9020:~# cat /proc/interrupts
>            CPU0
>  17:       4276      tzic   1 Edge      mmc0
>  18:         52      tzic   2 Edge      mmc1
>  22:          0      tzic   6 Edge      sdma
>  30:        176      tzic  14 Edge      53f80200.usb
>  40:     100000      tzic  24 Edge      53fa4000.srtc
>  48:        268      tzic  32 Edge      53fc0000.serial
>  55:       2288      tzic  39 Edge      i.MX Timer Tick
>  74:          0      tzic  58 Edge      53f98000.wdog
>  79:        278      tzic  63 Edge      63fc4000.i2c
>  93:          0      tzic  77 Edge      arm-pmu
> 103:        662      tzic  87 Edge      63fec000.ethernet
> 145:          0  gpio-mxc   1 Edge      50004000.esdhc cd
> 148:          0  gpio-mxc   4 Edge      50008000.esdhc cd
> 368:        674       IPU  23 Edge      imx_drm
> 369:          0       IPU  28 Edge      imx_drm
> Err:          0
> 
> I added some tracing to dryice_irq() and saw that most of the time (if not all the time) dsr == DSR_MCO /* monotonic clock overflow */ with dier vary between 0x110, 0x10 and even 0x0.
> I don't know what's the right thing to do, to recover from DSR_MCO. " return IRQ_HANDLED" will stop the nobody cared message but hwclock still times out.
> 

hwclock times out because the alarm is not working properly. Can you
check whether rtctest is working?


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

DryIce , RTC not working on imx53.

[Patrick Brünn]

>From: Alexandre Belloni [mailto:alexandre.belloni at free-electrons.com]
>Sent: Donnerstag, 9. November 2017 04:03
>
>hwclock times out because the alarm is not working properly. Can you
>check whether rtctest is working?
>
You mean "tools/testing/selftests/timers/rtctest", right?

I just run it and it's stuck at "Counting 5 update (1/sec) interrupts from reading /dev/rtc0:"

Kernel log shows a new message for each try I restart rtctest.
[ 1032.349562] imxdi_rtc 53fa4000.srtc: Write-wait timeout val = 0x5a042418 reg = 0x00000008"


Regards, Patrick

Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075

DryIce , RTC not working on imx53.

[Alexandre Belloni]

+Cc Fabio

On 09/11/2017 at 09:59:02 +0000, Patrick Br?nn wrote:
> 
> >From: Alexandre Belloni [mailto:alexandre.belloni at free-electrons.com]
> >Sent: Donnerstag, 9. November 2017 04:03
> >
> >hwclock times out because the alarm is not working properly. Can you
> >check whether rtctest is working?
> >
> You mean "tools/testing/selftests/timers/rtctest", right?
> 
> I just run it and it's stuck at "Counting 5 update (1/sec) interrupts from reading /dev/rtc0:"
> 

So alarms or interrupts definitively don't work.

> Kernel log shows a new message for each try I restart rtctest.
> [ 1032.349562] imxdi_rtc 53fa4000.srtc: Write-wait timeout val = 0x5a042418 reg = 0x00000008"
> 

That would explain it because failing to write DCAMR means that the
alarm is not set to the proper value.

But that doesn't explain all the spurious interrupts you are seeing.

Fabio, is there any recent change in the platform code that would make
reading/writing the rtc register fail?


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

DryIce , RTC not working on imx53.

[Fabio Estevam]

Hi Alexandre,

On Mon, Nov 13, 2017 at 2:15 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:

> Fabio, is there any recent change in the platform code that would make
> reading/writing the rtc register fail?

I don't recall of any recent change in this area.

Patrick/Noel,

Does the change below help?

--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -436,8 +436,7 @@
                        srtc: srtc at 53fa4000 {
                                compatible = "fsl,imx53-rtc", "fsl,imx25-rtc";
                                reg = <0x53fa4000 0x4000>;
-                               interrupts = <24>;
-                               interrupt-parent = <&tzic>;
+                               interrupts = <24 25>;
                                clocks = <&clks IMX5_CLK_SRTC_GATE>;
                                clock-names = "ipg";
                        };

DryIce , RTC not working on imx53.

[Fabio Estevam]

On Mon, Nov 13, 2017 at 2:54 PM, Fabio Estevam <festevam@gmail.com> wrote:

> I don't recall of any recent change in this area.
>
> Patrick/Noel,
>
> Does the change below help?
>
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -436,8 +436,7 @@
>                         srtc: srtc at 53fa4000 {
>                                 compatible = "fsl,imx53-rtc", "fsl,imx25-rtc";
>                                 reg = <0x53fa4000 0x4000>;
> -                               interrupts = <24>;
> -                               interrupt-parent = <&tzic>;
> +                               interrupts = <24 25>;
>                                 clocks = <&clks IMX5_CLK_SRTC_GATE>;
>                                 clock-names = "ipg";
>                         };

With this change I no longer get the spurious interrupts:

# cat /proc/interrupts | grep rtc
 40:          0      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc

The timeout is still present though and we need to figure this out.

DryIce , RTC not working on imx53.

[Patrick Brünn]

>From: Fabio Estevam [mailto:festevam at gmail.com]
>Sent: Montag, 13. November 2017 19:57
>> I don't recall of any recent change in this area.
>>
I don't think the behavior changed recently. I tried a kernel 4.4.65 and it shows the same symptoms. I guess Noel really means 3.19-> 4.0.

>> Patrick/Noel,
>>
>> Does the change below help?
Unfortunately no. Did you run hwclock or rtctest?
I still see:
root at CX9020:~# cat /proc/interrupts | grep rtc
 40:          0      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc
root at CX9020:~# hwclock -D -r
hwclock from util-linux 2.29.2
Using the /dev interface to the clock.
Last drift adjustment done at 1490885082 seconds after 1969
Last calibration done at 1490885082 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
[   41.035269] irq 40: nobody cared (try booting with the "irqpoll" option)
[   41.042514] handlers:
[   41.044847] [<c06031e0>] dryice_irq
[   41.048398] Disabling IRQ #40
select() to /dev/rtc to wait for clock tick timed out...synchronization failed
root at CX9020:~# cat /proc/interrupts | grep rtc
 40:     100000      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc


or if I run rtctest from tools/testing/selftests/timers/ (after reboot):

root at CX9020:~# cat /proc/interrupts | grep rtc
 40:          0      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc
root at CX9020:~# ./rtctest

                        RTC Driver Test Example.

Counting 5 update (1/sec) interrupts from reading /dev/rtc0:[   37.550399] irq 40: nobody cared (try booting with the "irqpoll" option)
[   37.557646] handlers:
[   37.559980] [<c06031e0>] dryice_irq
[   37.563532] Disabling IRQ #40
^C
root at CX9020:~# cat /proc/interrupts | grep rtc
 40:     100000      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc


With the attached patch I get rid of the unhandled interrupts. But that patch just ACKs everything.
 root at CX9020:~# cat /proc/interrupts | grep rtc
 40:          0      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc
root at CX9020:~# hwclock -D -r
hwclock from util-linux 2.29.2
Using the /dev interface to the clock.
Last drift adjustment done at 1490885082 seconds after 1969
Last calibration done at 1490885082 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
select() to /dev/rtc to wait for clock tick timed out...synchronization failed
root at CX9020:~# cat /proc/interrupts | grep rtc
 40:     301844      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc

>From 422747686f5723ac75b98ad610b3ef4d94ef271f Mon Sep 17 00:00:00 2001
From: Patrick Bruenn <p.bruenn@beckhoff.com>
Date: Tue, 14 Nov 2017 05:23:24 +0100
Subject: [PATCH] XXX: disable interrupts manually

---
 drivers/rtc/rtc-imxdi.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index 80931114c899..4b64a5350bac 100644
--- a/drivers/rtc/rtc-imxdi.c
+++ b/drivers/rtc/rtc-imxdi.c
@@ -686,6 +686,24 @@ static irqreturn_t dryice_irq(int irq, void *dev_id)
        dier = readl(imxdi->ioaddr + DIER);
        dsr = readl(imxdi->ioaddr + DSR);

+       /* ack monotonic counter overflow */
+       if (DSR_MCO == dsr) {
+               return IRQ_HANDLED;
+       }
+       if (dier & DIER_WCIE) {
+               if (dsr & DSR_MCO) {
+                       di_int_disable(imxdi, DIER_WCIE);
+                       return IRQ_HANDLED;
+               }
+       }
+
+       if (dier & DIER_CAIE) {
+               if (dsr & DSR_MCO) {
+                       di_int_disable(imxdi, DIER_CAIE);
+                       return IRQ_HANDLED;
+               }
+       }
+
        /* handle the security violation event */
        if (dier & DIER_SVIE) {
                if (dsr & DSR_SVF) {
@@ -710,7 +728,10 @@ static irqreturn_t dryice_irq(int irq, void *dev_id)
                  operations. It means the interrupt is for DryIce -Security.
                  IRQ must be returned as none.*/
                if (list_empty_careful(&imxdi->write_wait.head))
+               {
+                       printk("rtc: XXXX: dier: 0x%x dsr: 0x%x\n", dier, dsr);
                        return rc;
+               }

                /* DSR_WCF clears itself on DSR read */
                if (dsr & (DSR_WCF | DSR_WEF)) {
@@ -737,6 +758,9 @@ static irqreturn_t dryice_irq(int irq, void *dev_id)
                        rc = IRQ_HANDLED;
                }
        }
+       if (rc != IRQ_HANDLED) {
+               printk("rtc: XXXX: dier: 0x%x dsr: 0x%x\n", dier, dsr);
+       }
        return rc;
 }

--
2.11.0
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff
Registered office: Verl, Germany | Register court: Guetersloh HRA 7075

DryIce , RTC not working on imx53.

[Vellemans, Noel]

HI all,

I've been digging a while in the DryIce code (some time ago, it was in a hurry because I needed to release).

I finally ended up by NOT using the DryIce code , for the IMX53 ( internal RTC)

If I recall correctly , this is not the correct driver for the Internal IMX53 RTC, ( for example the register BASE-Addresses / offsets are not correct..) 
resulting in all kind of strange behavior, depending on your situational use-cases:-(




Best Regards
Noel

_______________________
Noel Vellemans
BMS bvba

-----Original Message-----
From: Patrick Br?nn [mailto:P.Bruenn at beckhoff.com] 
Sent: Tuesday, November 14, 2017 6:00 AM
To: Fabio Estevam; Alexandre Belloni
Cc: Vellemans, Noel; linux-arm-kernel at lists.infradead.org; linux-rtc at vger.kernel.org
Subject: RE: DryIce , RTC not working on imx53.

>From: Fabio Estevam [mailto:festevam at gmail.com]
>Sent: Montag, 13. November 2017 19:57
>> I don't recall of any recent change in this area.
>>
I don't think the behavior changed recently. I tried a kernel 4.4.65 and it shows the same symptoms. I guess Noel really means 3.19-> 4.0.

>> Patrick/Noel,
>>
>> Does the change below help?
Unfortunately no. Did you run hwclock or rtctest?
I still see:
root at CX9020:~# cat /proc/interrupts | grep rtc
 40:          0      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc
root at CX9020:~# hwclock -D -r
hwclock from util-linux 2.29.2
Using the /dev interface to the clock.
Last drift adjustment done at 1490885082 seconds after 1969 Last calibration done at 1490885082 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
[   41.035269] irq 40: nobody cared (try booting with the "irqpoll" option)
[   41.042514] handlers:
[   41.044847] [<c06031e0>] dryice_irq
[   41.048398] Disabling IRQ #40
select() to /dev/rtc to wait for clock tick timed out...synchronization failed root at CX9020:~# cat /proc/interrupts | grep rtc
 40:     100000      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc


or if I run rtctest from tools/testing/selftests/timers/ (after reboot):

root at CX9020:~# cat /proc/interrupts | grep rtc
 40:          0      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc
root at CX9020:~# ./rtctest

                        RTC Driver Test Example.

Counting 5 update (1/sec) interrupts from reading /dev/rtc0:[   37.550399] irq 40: nobody cared (try booting with the "irqpoll" option)
[   37.557646] handlers:
[   37.559980] [<c06031e0>] dryice_irq
[   37.563532] Disabling IRQ #40
^C
root at CX9020:~# cat /proc/interrupts | grep rtc
 40:     100000      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc


With the attached patch I get rid of the unhandled interrupts. But that patch just ACKs everything.
 root at CX9020:~# cat /proc/interrupts | grep rtc
 40:          0      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc
root at CX9020:~# hwclock -D -r
hwclock from util-linux 2.29.2
Using the /dev interface to the clock.
Last drift adjustment done at 1490885082 seconds after 1969 Last calibration done at 1490885082 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
select() to /dev/rtc to wait for clock tick timed out...synchronization failed root at CX9020:~# cat /proc/interrupts | grep rtc
 40:     301844      tzic  24 Edge      53fa4000.srtc
 41:          0      tzic  25 Edge      53fa4000.srtc

>From 422747686f5723ac75b98ad610b3ef4d94ef271f Mon Sep 17 00:00:00 2001
From: Patrick Bruenn <p.bruenn@beckhoff.com>
Date: Tue, 14 Nov 2017 05:23:24 +0100
Subject: [PATCH] XXX: disable interrupts manually

---
 drivers/rtc/rtc-imxdi.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c index 80931114c899..4b64a5350bac 100644
--- a/drivers/rtc/rtc-imxdi.c
+++ b/drivers/rtc/rtc-imxdi.c
@@ -686,6 +686,24 @@ static irqreturn_t dryice_irq(int irq, void *dev_id)
        dier = readl(imxdi->ioaddr + DIER);
        dsr = readl(imxdi->ioaddr + DSR);

+       /* ack monotonic counter overflow */
+       if (DSR_MCO == dsr) {
+               return IRQ_HANDLED;
+       }
+       if (dier & DIER_WCIE) {
+               if (dsr & DSR_MCO) {
+                       di_int_disable(imxdi, DIER_WCIE);
+                       return IRQ_HANDLED;
+               }
+       }
+
+       if (dier & DIER_CAIE) {
+               if (dsr & DSR_MCO) {
+                       di_int_disable(imxdi, DIER_CAIE);
+                       return IRQ_HANDLED;
+               }
+       }
+
        /* handle the security violation event */
        if (dier & DIER_SVIE) {
                if (dsr & DSR_SVF) {
@@ -710,7 +728,10 @@ static irqreturn_t dryice_irq(int irq, void *dev_id)
                  operations. It means the interrupt is for DryIce -Security.
                  IRQ must be returned as none.*/
                if (list_empty_careful(&imxdi->write_wait.head))
+               {
+                       printk("rtc: XXXX: dier: 0x%x dsr: 0x%x\n", 
+ dier, dsr);
                        return rc;
+               }

                /* DSR_WCF clears itself on DSR read */
                if (dsr & (DSR_WCF | DSR_WEF)) { @@ -737,6 +758,9 @@ static irqreturn_t dryice_irq(int irq, void *dev_id)
                        rc = IRQ_HANDLED;
                }
        }
+       if (rc != IRQ_HANDLED) {
+               printk("rtc: XXXX: dier: 0x%x dsr: 0x%x\n", dier, dsr);
+       }
        return rc;
 }

--
2.11.0
Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075

DryIce , RTC not working on imx53.

[Fabio Estevam]

Hi Noel,

On Tue, Nov 14, 2017 at 4:40 AM, Vellemans, Noel
<Noel.Vellemans@visionbms.com> wrote:
> HI all,
>
> I've been digging a while in the DryIce code (some time ago, it was in a hurry because I needed to release).
>
> I finally ended up by NOT using the DryIce code , for the IMX53 ( internal RTC)
>
> If I recall correctly , this is not the correct driver for the Internal IMX53 RTC, ( for example the register BASE-Addresses / offsets are not correct..)
> resulting in all kind of strange behavior, depending on your situational use-cases:-(

Could you clarify about this? Which base address or offsets are not correct?

DryIce , RTC not working on imx53.

[Vellemans, Noel]

Hi Fabio

It's been a while... ( but I'm quite sure), if you look closely at the register defines ( into the DRYICE-driver-code) then you will notice... that SOME registers offsets are correct , but others are not matching the INTERNAL rtc of the IMX53.

When I noticed that ( I skipped RTC driver functionality, under release pressure, I had still many items to test on those kernel , and I was under release pressure.. so I removed RTC for the time being.)

{ you can get basic RTC , timer only , no alarms/events working... by commenting a lot of things out,  but .. I decided to solve this later the correct way,  when I find some time  ( and to report back when solved, didn't want to bother many people, or otherwise said didn't want make too many noise .... ( because rtc is not critical in my application ) }

This driver will not work for the INTERNAL-RTC ( rtc into the IMX53), and will never have worked, I can confirm this, it might have worked for some other variant of the RTC, but it will not do what we all expected for the RTC located into IMX53!


Regards
Noel


PS: Just for info,  at this time I'm investigating a NOT booting problem .. and .. it?s a hard one ( keeps me busy for some day's already ... let's say in a 500 boots there is one issue where the 'kernel' locks-up in a very very early stage.. (into the first mili-sec of the boot it hangs, some-where around IRQ-initialization .. all blocks , before CPU-identification... no clue yet where exactly..!)
{ it's only happening in latest kernels 4.4.x / 4.1x.x , older 2.6.35 do not suffer this none boot behavior ( on the same hardware) , so .. digging / debugging / printing.. :-) at this time }


_______________________
Noel Vellemans
BMS bvba

-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com] 
Sent: Tuesday, November 14, 2017 11:13 AM
To: Vellemans, Noel
Cc: Patrick Br?nn; Alexandre Belloni; linux-arm-kernel at lists.infradead.org; linux-rtc at vger.kernel.org
Subject: Re: DryIce , RTC not working on imx53.

Hi Noel,

On Tue, Nov 14, 2017 at 4:40 AM, Vellemans, Noel <Noel.Vellemans@visionbms.com> wrote:
> HI all,
>
> I've been digging a while in the DryIce code (some time ago, it was in a hurry because I needed to release).
>
> I finally ended up by NOT using the DryIce code , for the IMX53 ( 
> internal RTC)
>
> If I recall correctly , this is not the correct driver for the 
> Internal IMX53 RTC, ( for example the register BASE-Addresses / 
> offsets are not correct..) resulting in all kind of strange behavior, 
> depending on your situational use-cases:-(

Could you clarify about this? Which base address or offsets are not correct?

DryIce , RTC not working on imx53.

[Fabio Estevam]

Hi Patrick,

On Tue, Nov 14, 2017 at 3:00 AM, Patrick Br?nn <P.Bruenn@beckhoff.com> wrote:
>>From: Fabio Estevam [mailto:festevam at gmail.com]
>>Sent: Montag, 13. November 2017 19:57
>>> I don't recall of any recent change in this area.
>>>
> I don't think the behavior changed recently. I tried a kernel 4.4.65 and it shows the same symptoms. I guess Noel really means 3.19-> 4.0.

Or maybe by 'old kernel' he meant the vendor 2.6.35 kernel.

I have the impression that the dryice driver has never worked in
mainlune for mx53.

> Unfortunately no. Did you run hwclock or rtctest?

Yes, this is what I get:

# hwclock -r -D
hwclock from util-linux 2.31
System Time: 14.876372
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 2167 seconds after 1969
Last calibrat[   14.892484] imxdi_rtc 53fa4000.srtc: Write-wait timeout val = 08
ion done at 2167 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


> I still see:
> root at CX9020:~# cat /proc/interrupts | grep rtc
>  40:          0      tzic  24 Edge      53fa4000.srtc
>  41:          0      tzic  25 Edge      53fa4000.srtc
> root at CX9020:~# hwclock -D -r
> hwclock from util-linux 2.29.2
> Using the /dev interface to the clock.
> Last drift adjustment done at 1490885082 seconds after 1969
> Last calibration done at 1490885082 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> [   41.035269] irq 40: nobody cared (try booting with the "irqpoll" option)
> [   41.042514] handlers:
> [   41.044847] [<c06031e0>] dryice_irq
> [   41.048398] Disabling IRQ #40

This error I don't get with the 2.31 hwclock version I tried.

DryIce , RTC not working on imx53.

[Alexandre Belloni]

+Cc Juergen

On 14/11/2017 at 08:12:03 -0200, Fabio Estevam wrote:
> Hi Patrick,
> 
> On Tue, Nov 14, 2017 at 3:00 AM, Patrick Br?nn <P.Bruenn@beckhoff.com> wrote:
> >>From: Fabio Estevam [mailto:festevam at gmail.com]
> >>Sent: Montag, 13. November 2017 19:57
> >>> I don't recall of any recent change in this area.
> >>>
> > I don't think the behavior changed recently. I tried a kernel 4.4.65 and it shows the same symptoms. I guess Noel really means 3.19-> 4.0.
> 
> Or maybe by 'old kernel' he meant the vendor 2.6.35 kernel.
> 
> I have the impression that the dryice driver has never worked in
> mainlune for mx53.
> 

I doubt that because it seems to have been used by Pengutronix.

> > Unfortunately no. Did you run hwclock or rtctest?
> 
> Yes, this is what I get:
> 
> # hwclock -r -D
> hwclock from util-linux 2.31
> System Time: 14.876372
> Trying to open: /dev/rtc0
> Using the rtc interface to the clock.
> Last drift adjustment done at 2167 seconds after 1969
> Last calibrat[   14.892484] imxdi_rtc 53fa4000.srtc: Write-wait timeout val = 08
> ion done at 2167 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
> 
> 
> > I still see:
> > root at CX9020:~# cat /proc/interrupts | grep rtc
> >  40:          0      tzic  24 Edge      53fa4000.srtc
> >  41:          0      tzic  25 Edge      53fa4000.srtc
> > root at CX9020:~# hwclock -D -r
> > hwclock from util-linux 2.29.2
> > Using the /dev interface to the clock.
> > Last drift adjustment done at 1490885082 seconds after 1969
> > Last calibration done at 1490885082 seconds after 1969
> > Hardware clock is on UTC time
> > Assuming hardware clock is kept in UTC time.
> > Waiting for clock tick...
> > [   41.035269] irq 40: nobody cared (try booting with the "irqpoll" option)
> > [   41.042514] handlers:
> > [   41.044847] [<c06031e0>] dryice_irq
> > [   41.048398] Disabling IRQ #40
> 
> This error I don't get with the 2.31 hwclock version I tried.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

DryIce , RTC not working on imx53.

[Fabio Estevam]

On Tue, Nov 14, 2017 at 8:26 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:

>> I have the impression that the dryice driver has never worked in
>> mainlune for mx53.
>>
>
> I doubt that because it seems to have been used by Pengutronix.

Juergen can confirm, but it seems the dryice driver was only used on
mx25 in mainline.

DryIce , RTC not working on imx53.

[Alexandre Belloni]

On 14/11/2017 at 08:33:09 -0200, Fabio Estevam wrote:
> On Tue, Nov 14, 2017 at 8:26 AM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> 
> >> I have the impression that the dryice driver has never worked in
> >> mainlune for mx53.
> >>
> >
> > I doubt that because it seems to have been used by Pengutronix.
> 
> Juergen can confirm, but it seems the dryice driver was only used on
> mx25 in mainline.

Ok, that would explain it.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

DryIce , RTC not working on imx53.

[Juergen Borleis]

Hi,

On Tuesday 14 November 2017 11:55:17 Alexandre Belloni wrote:
> On 14/11/2017 at 08:33:09 -0200, Fabio Estevam wrote:
> > On Tue, Nov 14, 2017 at 8:26 AM, Alexandre Belloni
> >
> > <alexandre.belloni@free-electrons.com> wrote:
> > >> I have the impression that the dryice driver has never worked in
> > >> mainlune for mx53.
> > >
> > > I doubt that because it seems to have been used by Pengutronix.
> >
> > Juergen can confirm, but it seems the dryice driver was only used on
> > mx25 in mainline.
>
> Ok, that would explain it.

Yes. The development was made on an i.MX25. But currently I have an i.MX53 
on my desk here and could test...

jb

-- 
Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ?? ?| Juergen Borleis ? ? ? ? ? ? |
Industrial Linux Solutions ? ? ? ? ? ? ? ?? ?| http://www.pengutronix.de/ ?|

DryIce , RTC not working on imx53.

[Vellemans, Noel]

Hi all, 

Juergen It won't work ( as it is) , registers are not on the correct offsets and some bits are not on the same positions ( for the IMX53)
This driver will not work for the INTERNAL-RTC ( rtc into the IMX53), and will never have worked ( on IMX53). 
I can confirm, it might work for some other variant of the RTC, but it will not do what we all expected for the RTC located into IMX53!

( not sure my previous mail got to the destination)

Best Regards
Noel




>>
>> > Juergen can confirm, but it seems the dryice driver was only used on
> > mx25 in mainline.
>>
>>> Ok, that would explain it.
>>
>>Yes. The development was made on an i.MX25. But currently I have an i.MX53 on my desk here and could test...
>>
>>jb

>>>
>>
>>
>>
>>-----Original Message-----
>>From: Vellemans, Noel 
>>Sent: Tuesday, November 14, 2017 11:30 AM
>>To: 'Fabio Estevam'
>>Cc: Patrick Br?nn; Alexandre Belloni; linux-arm-kernel at lists.infradead.org; linux-rtc at vger.kernel.org
>>Subject: RE: DryIce , RTC not working on imx53.
>>
>>Hi Fabio
>>
>>It's been a while... ( but I'm quite sure), if you look closely at the register defines ( into the DRYICE-driver-code) then you will notice... that SOME registers offsets are correct , but others are not matching the INTERNAL rtc of the IMX53.
>>
>>When I noticed that ( I skipped RTC driver functionality, under release pressure, I had still many items to test on those kernel , and I was under release pressure.. so I removed RTC for the time being.)
>>
>>{ you can get basic RTC , timer only , no alarms/events working... by commenting a lot of things out,  but .. I decided to solve this later the correct way,  when I find some time  ( and to report back when solved, didn't want to bother many people, or otherwise said didn't want make too many noise .... ( because rtc is not critical in my application ) }
>>
>>This driver will not work for the INTERNAL-RTC ( rtc into the IMX53), and will never have worked, I can confirm this, it might have worked for some other variant of the RTC, but it will not do what we all expected for the RTC located into IMX53!
>>
>>
>>Regards
>>Noel
>>
>>PS: Just for info,  at this time I'm investigating a NOT booting problem .. and .. it?s a hard one ( keeps me busy for some day's already ... let's say in a 500 boots there is one issue where the 'kernel' locks-up in a 
>>very very early stage.. (into the first mili-sec of the boot it hangs, some-where around IRQ-initialization .. all blocks , before CPU-identification... no clue yet where exactly..!) 
>>{ it's only happening in latest kernels 4.4.x / 4.1x.x , older 2.6.35 do not suffer this none boot behavior ( on the same hardware) , so .. digging / debugging / printing.. :-) at this time }

DryIce , RTC not working on imx53.

[Juergen Borleis]

Hi all,

On Tuesday 14 November 2017 13:43:14 Myself wrote:
> On Tuesday 14 November 2017 11:55:17 Alexandre Belloni wrote:
> > On 14/11/2017 at 08:33:09 -0200, Fabio Estevam wrote:
> > > On Tue, Nov 14, 2017 at 8:26 AM, Alexandre Belloni
> > >
> > > <alexandre.belloni@free-electrons.com> wrote:
> > > >> I have the impression that the dryice driver has never worked in
> > > >> mainlune for mx53.
> > > >
> > > > I doubt that because it seems to have been used by Pengutronix.
> > >
> > > Juergen can confirm, but it seems the dryice driver was only used on
> > > mx25 in mainline.
> >
> > Ok, that would explain it.
>
> Yes. The development was made on an i.MX25. But currently I have an
> i.MX53 on my desk here and could test...

After a quick look into the reference manuals:

Patch 5b72505 ("ARM: dts: imx53: add srtc node") is bad. The i.MX53 provides 
an RTC more close to the i.MX6 instead (e.g. rtc-snvs.c). But unfortunately 
it uses a different register layout than the i.MX6 does. So we can't use 
this driver without i.MX53 specific adaptions.
But at least 5b72505 should be reverted.

jb

-- 
Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ?? ?| Juergen Borleis ? ? ? ? ? ? |
Industrial Linux Solutions ? ? ? ? ? ? ? ?? ?| http://www.pengutronix.de/ ?|

DryIce , RTC not working on imx53.

[Fabio Estevam]

On Wed, Nov 15, 2017 at 7:53 AM, Juergen Borleis <jbe@pengutronix.de> wrote:

> After a quick look into the reference manuals:
>
> Patch 5b72505 ("ARM: dts: imx53: add srtc node") is bad. The i.MX53 provides
> an RTC more close to the i.MX6 instead (e.g. rtc-snvs.c). But unfortunately
> it uses a different register layout than the i.MX6 does. So we can't use
> this driver without i.MX53 specific adaptions.
> But at least 5b72505 should be reverted.

Agreed. Looked in the vendor kernel and this is the rtc driver for mx53:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-mxc_v2.c?h=imx_2.6.35_11.09.01

,which is a different one from the dryice one:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-imxdi.c?h=imx_2.6.35_11.09.01

I will send a revert for 5b72505 ("ARM: dts: imx53: add srtc node").

Thanks