* DryIce , RTC not working on imx53.
@ 2017-10-05 14:18 ` Vellemans, Noel
0 siblings, 0 replies; 40+ messages in thread
From: Vellemans, Noel @ 2017-10-05 14:18 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: linux-rtc
SGVsbG8sDQoNCkRyeUljZSAsIFNSVEMgbm90IHdvcmtpbmcgb24gaW14NTMuICgga2VybmVsIDQu
eCkgwqAoIHNhbWUgaGFyZHdhcmUgcnVubmluZyBvbGRlciBrZXJuZWwgdmVyc2lvbnMuLiBtZWFu
cyAsIHJ0YyBpcyB3b3JraW5nKQ0KDQpEdXJpbmcgYm9vdCBhbGwgc2VlbXMgdG8gYmUgZmluZSBi
dXQgb25jZSB5b3UgdHJ5IHRvIHJlYWQgb3Igd3JpdGUgdGhlIGhhcmR3YXJlIGNsb2NrIGxhdGVy
IG9uIOKApiBpdCBiYWlscyBvdXQgd2l0aCB0aGlzIGVycm9yIG9uIHRoZSBjb25zb2xlLiANCg0K
aHdjbG9jaw0KDQpbICAgOTcuMTg2NTc3XSBpbXhkaV9ydGMgNTNmYTQwMDAucnRjOiBXcml0ZS13
YWl0IHRpbWVvdXQgdmFsID0gMHg1YTJmZjhkMyByZWcgPSAweDAwMDAwMDA4DQoNCkh3Y2xvY2sg
OiBzZWxlY3QoKSB0byAvZGV2L3J0YzAgdG8gd2FpdCBmb3IgY2xvY2sgdGljayB0aW1lZCBvdXQ6
IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkNCg0KDQoNCkkndmUgQWRkZWQgc29tZSBkcml2ZXIg
4oCTIHByaW50a+KAmXPigKYuDQoNCiMgaHdjbG9jaw0KWyAgIDczLjM2MjU1OV0gZHJ5aWNlX3J0
Y19yZWFkX3RpbWUgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQpbICAgNzMuMzk1MDc3XSBkcnlpY2VfcnRjX3JlYWRfdGltZSAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClsgICA3My40MTQxNTZdIGRyeWljZV9y
dGNfcmVhZF90aW1lIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLQ0KWyAgIDczLjQyMTcwMF0gZGlfd3JpdGVfd2FpdCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClsgICA3My40NzI2MjRdIGRpX2ludF9lbmFibGUg
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbICAgNzMu
NTE0NjA5XSBpbXhkaV9ydGMgNTNmYTQwMDAuc3J0YzogV3JpdGUtd2FpdCB0aW1lb3V0IHZhbCA9
IDB4NWEzMDAwYzggcmVnID0gMHgwMDAwMDAwOA0KWyAgIDczLjUyMzAxOV0gZGlfaW50X2VuYWJs
ZSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPDwg
U1RBTExTIGZvciA1IHNlY29uZHMgaGVyZSA+Pg0KPDwgU1RBTExTIGZvciA1IHNlY29uZHMgaGVy
ZSA+Pg0KPDwgU1RBTExTIGZvciA1IHNlY29uZHMgaGVyZSA+Pg0KPDwgU1RBTExTIGZvciA1IHNl
Y29uZHMgaGVyZSA+Pg0KPDwgU1RBTExTIGZvciA1IHNlY29uZHMgaGVyZSA+Pg0KDQpod2Nsb2Nr
WyAgIDc4LjU4NDkwOV0gZHJ5aWNlX3J0Y19hbGFybV9pcnFfZW5hYmxlIC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KOiBzZWxlY3QoKSB0byAvZGV2L3J0
YzAgdG8gd2FpdCBmWyAgIDc4LjU5MzQ1Nl0gZGlfaW50X2Rpc2FibGUgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpvciBjbG9jayB0aWNrIHRpbWVkIG91
dDogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQ0KDQoNCg0KDQoNCg0KU3RyYWNlIC4uIGxvZ2dp
bmcgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQpzdGF0KCIvbGliL2xkLXVD
bGliYy5zby4wIiwge3N0X21vZGU9U19JRlJFR3wwNzc3LCBzdF9zaXplPTI1MzAwLCAuLi59KSA9
IDANCm1tYXAyKE5VTEwsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxN
QVBfQU5PTllNT1VTfDB4NDAwMDAwMCwgLTEsIDApID0gMHhiNmYwNDAwMA0Kc2V0X3RscygweGI2
ZjA0NDkwLCAweGI2ZjA0YjM4LCAweGI2ZjA3MDg4LCAweGI2ZjA0NDkwLCAweGI2ZjA2Zjc0KSA9
IDANCm1wcm90ZWN0KDB4YjZlZDIwMDAsIDQwOTYsIFBST1RfUkVBRCkgICA9IDANCm1wcm90ZWN0
KDB4YjZmMDYwMDAsIDQwOTYsIFBST1RfUkVBRCkgICA9IDANCmlvY3RsKDAsIFNORENUTF9UTVJf
VElNRUJBU0Ugb3IgVENHRVRTLCB7QjExNTIwMCBvcG9zdCBpc2lnIGljYW5vbiBlY2hvIC4uLn0p
ID0gMA0KaW9jdGwoMSwgU05EQ1RMX1RNUl9USU1FQkFTRSBvciBUQ0dFVFMsIHtCMTE1MjAwIG9w
b3N0IGlzaWcgaWNhbm9uIGVjaG8gLi4ufSkgPSAwDQpnZXR0aW1lb2ZkYXkoezE1MTMwOTU0MzAs
IDcwODA5N30sIE5VTEwpID0gMA0KZ2V0dWlkMzIoKSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID0gMA0Kb3BlbigiL2Rldi9ydGMiLCBPX1JET05MWXxPX0xBUkdFRklMRSkgID0gLTEgRU5P
RU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQ0Kb3BlbigiL2Rldi9ydGMwIiwgT19SRE9O
TFl8T19MQVJHRUZJTEUpID0gMw0KYnJrKDApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgID0gMHgxODAwMA0KYnJrKDB4MTkwMDApICAgICAgICAgICAgICAgICAgICAgICAgICAgID0g
MHgxOTAwMA0Kc3RhdDY0KCIvZXRjL2FkanRpbWUiLCAweGJlZWMyNmE4KSAgICAgID0gLTEgRU5P
RU5UIChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQ0KaW9jdGwoMywgUEhOX1NFVF9SRUdTIG9y
IFJUQ19VSUVfT04sIDApID0gMA0Kc2VsZWN0KDQsIFszXSwgTlVMTCwgTlVMTCwgezUsIDB9DQoN
Cg0KPDwgU1RBTExTIGZvciA1IHNlY29uZHMgaGVyZSAgLS0gIHNlbGVjdCBpcyBub3QgcmV0dXJu
aW5nICEhISB0aW1lb3V0IGlzIDUgc2Vjb25kc+KApi4gPj4NCg0KKSAgICAgID0gMCAoVGltZW91
dClbICAxNDEuNzY2MTYyXSBkcnlpY2VfcnRjX2FsYXJtX2lycV9lbmFibGUgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCndyaXRlKDIsICJod2Nsb2Nr
IiwgN2h3Y2xvY2spICAgICAgICAgICAgICAgICAgPSA3DQp3cml0ZSgyLCAiOiAiLCAyOiApICAg
ICAgICAgICAgICAgICAgICAgICA9WyAgMTQxLjc4MjE5NV0gZGlfaW50X2Rpc2FibGUgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoyDQp3cml0ZSgyLCAi
c2VsZWN0KCkgdG8gIiwgMTJzZWxlY3QoKSB0byApICAgICAgICAgICAgPSAxMg0Kd3JpdGUoMiwg
Ii9kZXYvcnRjMCIsIDkvZGV2L3J0YzApICAgICAgICAgICAgICAgID0gOQ0Kd3JpdGUoMiwgIiB0
byB3YWl0IGZvciBjbG9jayB0aWNrIHRpbWVkIG91Ii4uLiwgMzMgdG8gd2FpdCBmb3IgY2xvY2sg
dGljayB0aW1lZCBvdXQpID0gMzMNCndyaXRlKDIsICI6ICIsIDI6ICkgICAgICAgICAgICAgICAg
ICAgICAgID0gMg0Kd3JpdGUoMiwgIk5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkiLCAyNU5vIHN1
Y2ggZmlsZSBvciBkaXJlY3RvcnkpID0gMjUNCndyaXRlKDIsICJcbiIsIDENCikgICAgICAgICAg
ICAgICAgICAgICAgID0gMQ0KaW9jdGwoMywgUEhOX05PVF9PSCBvciBSVENfVUlFX09GRiwgMCkg
ID0gMA0KY2xvc2UoMykgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMA0KZXhpdF9n
cm91cCg3NCkgICAgICAgICAgICAgICAgICAgICAgICAgID0gPw0KDQoNCg0KDQoNCg0KDQoNClFV
SUNLIGFuYWx5c2VzICAoIGNvdWxkIGJlIHdyb25nKSA/IA0KSXQgc2VlbXMgdGhhdCBod2Nsb2Nr
IGlzIHJlYWRpbmcgdGhlIGN1cnJlbnQtdGltZXN0YW1wIDMgdGltZXMgYW5kIGlmIG5vdCBjaGFu
Z2VkIGluIHRob3NlIDMgcmVhZCBjeWNsZXPigKYgaXQgc2V0cyB1cCBhbiByZWFkLWludGVycnVw
dC1hYm9ydCBhYmxlIHRpbWUgcmVhZGVyIHRoYXQgc2hvdWxkIHJldHVybiBhcyBzb29uIGFzIHRo
ZSBpcnEgZmlyZXPigKYgYnV0IHRoaXMgc2VlbXMgdG8gYmUgbWlzc2luZyAhDQoNCkZZSTogIEni
gJl2ZSBiZWVuIHVzaW5nIGZvbGxvd2luZyBjb21taW50IHRvIGVuYWJsZSBzcnRjLg0KY29tbWl0
IDViNzI1MDU0MTQ3ZGVhZjk2NmIzOTE5ZTEwYTg2YzZiZmU5NDZhMTgNCkF1dGhvcjogUGF0cmlj
ayBCcnVlbm4gPHAuYnJ1ZW5uQGJlY2tob2ZmLmNvbT4NCkRhdGU6wqAgwqBXZWQgSnVsIDI2IDE0
OjA1OjMyIDIwMTcgKzAyMDANCg0KwqAgwqAgQVJNOiBkdHM6IGlteDUzOiBhZGQgc3J0YyBub2Rl
DQrCoCDCoMKgDQrCoCDCoCBUaGUgaS5NWDUzIGhhcyBhbiBpbnRlZ3JhdGVkIHNlY3VyZSByZWFs
IHRpbWUgY2xvY2suIEFkZCBpdCB0byB0aGUgZHRzaS4NCsKgIMKgwqANCsKgIMKgIFNpZ25lZC1v
ZmYtYnk6IFBhdHJpY2sgQnJ1ZW5uIDxwLmJydWVubkBiZWNraG9mZi5jb20+DQrCoCDCoCBTaWdu
ZWQtb2ZmLWJ5OiBTaGF3biBHdW8gPHNoYXduZ3VvQGtlcm5lbC5vcmc+DQoNCmRpZmYgLS1naXQg
YS9hcmNoL2FybS9ib290L2R0cy9pbXg1My5kdHNpIGIvYXJjaC9hcm0vYm9vdC9kdHMvaW14NTMu
ZHRzaQ0KaW5kZXggMmU1MTZmNC4uOGJmMGQ4OSAxMDA2NDQNCi0tLSBhL2FyY2gvYXJtL2Jvb3Qv
ZHRzL2lteDUzLmR0c2kNCisrKyBiL2FyY2gvYXJtL2Jvb3QvZHRzL2lteDUzLmR0c2kNCkBAIC00
MzMsNiArNDMzLDE1IEBADQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCBjbG9jay1uYW1lcyA9ICJpcGciLCAicGVyIjsNCsKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIH07DQrCoA0KK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgc3J0Yzogc3J0Y0A1M2ZhNDAwMCB7DQorwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqBjb21wYXRpYmxlID0gImZzbCxpbXg1My1ydGMiLCAiZnNsLGlteDI1
LXJ0YyI7DQorwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBy
ZWcgPSA8MHg1M2ZhNDAwMCAweDQwMDA+Ow0KK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgaW50ZXJydXB0cyA9IDwyND47DQorwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbnRlcnJ1cHQtcGFyZW50ID0gPCZ0emljPjsN
CivCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNsb2NrcyA9
IDwmY2xrcyBJTVg1X0NMS19TUlRDX0dBVEU+Ow0KK8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgY2xvY2stbmFtZXMgPSAiaXBnIjsNCivCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoH07DQorDQoNCkJlc3QgUmVnYXJkcw0KTm9lbA0KDQoNCg==
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-10-05 14:18 ` Vellemans, Noel
0 siblings, 0 replies; 40+ messages in thread
From: Vellemans, Noel @ 2017-10-05 14:18 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 40+ messages in thread
* RE: DryIce , RTC not working on imx53.
2017-10-05 14:18 ` Vellemans, Noel
@ 2017-10-12 7:50 ` Patrick Brünn
-1 siblings, 0 replies; 40+ messages in thread
From: Patrick Brünn @ 2017-10-12 7:50 UTC (permalink / raw)
To: Vellemans, Noel, linux-arm-kernel; +Cc: linux-rtc
PkZyb206IFZlbGxlbWFucywgTm9lbCBbbWFpbHRvOk5vZWwuVmVsbGVtYW5zQHZpc2lvbkJNUy5j
b21dDQo+U2VudDogRG9ubmVyc3RhZywgNS4gT2t0b2JlciAyMDE3IDE2OjE5DQo+SGVsbG8sDQo+
DQpIaSwNCm5vdCBzdXJlIGlmIEkgY2FuIGhlbHAgb24gdGhpcywgYnV0IGFzIEkgZGlkIHNvbWUg
dGVzdGluZyBteXNlbGYgSSB0aG91Z2h0IEkgc2hvdWxkIHRocm93IGluIG15IHJlc3VsdHMgYXMg
d2VsbC4NCg0KPkRyeUljZSAsIFNSVEMgbm90IHdvcmtpbmcgb24gaW14NTMuICgga2VybmVsIDQu
eCkgICggc2FtZSBoYXJkd2FyZSBydW5uaW5nDQo+b2xkZXIga2VybmVsIHZlcnNpb25zLi4gbWVh
bnMgLCBydGMgaXMgd29ya2luZykNCj4NCklzIGl0IG9ubHkgdGhlIGtlcm5lbCB5b3UgYXJlIGNo
YW5naW5nPyBJIGFtIGFza2luZyBiZWNhdXNlIEkgaGFkIHRoZSBpbXByZXNzaW9uIHRoYXQgaHdj
bG9jayBiZWhhdmVzIGRpZmZlcmVudCBvbiBEZWJpYW4gc3RyZXRjaCAodXRpbC1saW51eCAyLjI5
LjIpIGFuZCBqZXNzaWUgKHV0aWwtbGludXggMi4yNS4yKS4NCkkgYW0gc2F5aW5nIGltcHJlc3Np
b24gYmVjYXVzZSBpdCBzZWVtZWQgb24gamVzc2llIEkgd291bGQgYWx3YXlzIGdldCBhIHJlc3Bv
bnNlIG9mIGh3Y2xvY2ssIGJ1dCBvbiBzdHJldGNoIG5ldmVyLiBXaGVuIEkgZGlkIG1vcmUgc3lz
dGVtYXRpYyB0ZXN0aW5nIGl0IGxvb2tzIGxpa2UgcmlnaHQgYWZ0ZXIgYm9vdCBod2Nsb2NrIC1y
IHdpbGwgYWx3YXlzIGZhaWwuIEJ1dCBpZiBJIHdhaXQgc29tZSBtaW51dGVzLCBhbGwgY2FsbHMg
c3VjY2VlZC4NCj4uLi4NCj5RVUlDSyBhbmFseXNlcyAgKCBjb3VsZCBiZSB3cm9uZykgPw0KPkl0
IHNlZW1zIHRoYXQgaHdjbG9jayBpcyByZWFkaW5nIHRoZSBjdXJyZW50LXRpbWVzdGFtcCAzIHRp
bWVzIGFuZCBpZiBub3QNCj5jaGFuZ2VkIGluIHRob3NlIDMgcmVhZCBjeWNsZXPigKYgaXQgc2V0
cyB1cCBhbiByZWFkLWludGVycnVwdC1hYm9ydCBhYmxlIHRpbWUNCj5yZWFkZXIgdGhhdCBzaG91
bGQgcmV0dXJuIGFzIHNvb24gYXMgdGhlIGlycSBmaXJlc+KApiBidXQgdGhpcyBzZWVtcyB0byBi
ZQ0KPm1pc3NpbmcgIQ0KPg0KSSBhbSBzZWVpbmcgYSBsb3Qgb2YgaW50ZXJydXB0cyB3aXRoIGtl
cm5lbCA0LjE0LXJjNCAoamVzc2llIGFuZCBzdHJldGNoKSwgYnV0IHRoZXkgc2VlbSB0byBiZSB1
bmhhbmRsZWQ6DQpyb290QENYOTAyMDp+IyB1bmFtZSAtYQ0KTGludXggQ1g5MDIwIDQuMTQuMC1y
YzQrICMxNTEgUFJFRU1QVCBXZWQgT2N0IDExIDEwOjQwOjM0IENFU1QgMjAxNyBhcm12N2wgR05V
L0xpbnV4DQpyb290QENYOTAyMDp+IyBod2Nsb2NrIC1EIC1yDQpod2Nsb2NrIGZyb20gdXRpbC1s
aW51eCAyLjI5LjINClVzaW5nIHRoZSAvZGV2IGludGVyZmFjZSB0byB0aGUgY2xvY2suDQpMYXN0
IGRyaWZ0IGFkanVzdG1lbnQgZG9uZSBhdCAxNDkwODg1MDgyIHNlY29uZHMgYWZ0ZXIgMTk2OQ0K
TGFzdCBjYWxpYnJhdGlvbiBkb25lIGF0IDE0OTA4ODUwODIgc2Vjb25kcyBhZnRlciAxOTY5DQpI
YXJkd2FyZSBjbG9jayBpcyBvbiBVVEMgdGltZQ0KQXNzdW1pbmcgaGFyZHdhcmUgY2xvY2sgaXMg
a2VwdCBpbiBVVEMgdGltZS4NCldhaXRpbmcgZm9yIGNsb2NrIHRpY2suLi4NClsgICAyNi43OTU0
MzddIGlycSA0MDogbm9ib2R5IGNhcmVkICh0cnkgYm9vdGluZyB3aXRoIHRoZSAiaXJxcG9sbCIg
b3B0aW9uKQ0KWyAgIDI2LjgwMjY5Nl0gaGFuZGxlcnM6DQpbICAgMjYuODA1MDMxXSBbPGMwNjAy
OWU4Pl0gZHJ5aWNlX2lycQ0KWyAgIDI2LjgwODU4NF0gRGlzYWJsaW5nIElSUSAjNDANCnNlbGVj
dCgpIHRvIC9kZXYvcnRjIHRvIHdhaXQgZm9yIGNsb2NrIHRpY2sgdGltZWQgb3V0Li4uc3luY2hy
b25pemF0aW9uIGZhaWxlZA0Kcm9vdEBDWDkwMjA6fiMgY2F0IC9wcm9jL2ludGVycnVwdHMNCiAg
ICAgICAgICAgQ1BVMA0KIDE3OiAgICAgICA0Mjc2ICAgICAgdHppYyAgIDEgRWRnZSAgICAgIG1t
YzANCiAxODogICAgICAgICA1MiAgICAgIHR6aWMgICAyIEVkZ2UgICAgICBtbWMxDQogMjI6ICAg
ICAgICAgIDAgICAgICB0emljICAgNiBFZGdlICAgICAgc2RtYQ0KIDMwOiAgICAgICAgMTc2ICAg
ICAgdHppYyAgMTQgRWRnZSAgICAgIDUzZjgwMjAwLnVzYg0KIDQwOiAgICAgMTAwMDAwICAgICAg
dHppYyAgMjQgRWRnZSAgICAgIDUzZmE0MDAwLnNydGMNCiA0ODogICAgICAgIDI2OCAgICAgIHR6
aWMgIDMyIEVkZ2UgICAgICA1M2ZjMDAwMC5zZXJpYWwNCiA1NTogICAgICAgMjI4OCAgICAgIHR6
aWMgIDM5IEVkZ2UgICAgICBpLk1YIFRpbWVyIFRpY2sNCiA3NDogICAgICAgICAgMCAgICAgIHR6
aWMgIDU4IEVkZ2UgICAgICA1M2Y5ODAwMC53ZG9nDQogNzk6ICAgICAgICAyNzggICAgICB0emlj
ICA2MyBFZGdlICAgICAgNjNmYzQwMDAuaTJjDQogOTM6ICAgICAgICAgIDAgICAgICB0emljICA3
NyBFZGdlICAgICAgYXJtLXBtdQ0KMTAzOiAgICAgICAgNjYyICAgICAgdHppYyAgODcgRWRnZSAg
ICAgIDYzZmVjMDAwLmV0aGVybmV0DQoxNDU6ICAgICAgICAgIDAgIGdwaW8tbXhjICAgMSBFZGdl
ICAgICAgNTAwMDQwMDAuZXNkaGMgY2QNCjE0ODogICAgICAgICAgMCAgZ3Bpby1teGMgICA0IEVk
Z2UgICAgICA1MDAwODAwMC5lc2RoYyBjZA0KMzY4OiAgICAgICAgNjc0ICAgICAgIElQVSAgMjMg
RWRnZSAgICAgIGlteF9kcm0NCjM2OTogICAgICAgICAgMCAgICAgICBJUFUgIDI4IEVkZ2UgICAg
ICBpbXhfZHJtDQpFcnI6ICAgICAgICAgIDANCg0KSSBhZGRlZCBzb21lIHRyYWNpbmcgdG8gZHJ5
aWNlX2lycSgpIGFuZCBzYXcgdGhhdCBtb3N0IG9mIHRoZSB0aW1lIChpZiBub3QgYWxsIHRoZSB0
aW1lKSBkc3IgPT0gRFNSX01DTyAvKiBtb25vdG9uaWMgY2xvY2sgb3ZlcmZsb3cgKi8gd2l0aCBk
aWVyIHZhcnkgYmV0d2VlbiAweDExMCwgMHgxMCBhbmQgZXZlbiAweDAuDQpJIGRvbid0IGtub3cg
d2hhdCdzIHRoZSByaWdodCB0aGluZyB0byBkbywgdG8gcmVjb3ZlciBmcm9tIERTUl9NQ08uICIg
cmV0dXJuIElSUV9IQU5ETEVEIiB3aWxsIHN0b3AgdGhlIG5vYm9keSBjYXJlZCBtZXNzYWdlIGJ1
dCBod2Nsb2NrIHN0aWxsIHRpbWVzIG91dC4NCg0KQW5kIGZvciBjb21wbGV0ZW5lc3M6DQpyb290
QENYOTAyMDp+IyBkbWVzZyB8IGdyZXAgc3J0Yw0KWyAgICAwLjI5OTA0M10gaW14ZGlfcnRjIDUz
ZmE0MDAwLnNydGM6IFVubG9ja2VkIHVuaXQgZGV0ZWN0ZWQNClsgICAgMC4yOTk1MzldIGlteGRp
X3J0YyA1M2ZhNDAwMC5zcnRjOiBzZWN1cml0eSB2aW9sYXRpb24gaW50ZXJydXB0IG5vdCBhdmFp
bGFibGUuDQpbICAgIDAuMjk5NzU3XSBydGMgcnRjMDogNTNmYTQwMDAuc3J0YzogZGV2ICgyNTM6
MCkNClsgICAgMC4yOTk3NzhdIGlteGRpX3J0YyA1M2ZhNDAwMC5zcnRjOiBydGMgY29yZTogcmVn
aXN0ZXJlZCA1M2ZhNDAwMC5zcnRjIGFzIHJ0YzANClsgICAgMC40MzY3ODVdIGlteGRpX3J0YyA1
M2ZhNDAwMC5zcnRjOiBzZXR0aW5nIHN5c3RlbSBjbG9jayB0byAyMDE3LTEwLTEyIDA2OjM4OjA4
IFVUQyAoMTUwNzc5MDI4OCkNClsgIDQ0NS40ODY2MjRdIGlteGRpX3J0YyA1M2ZhNDAwMC5zcnRj
OiBXcml0ZS13YWl0IHRpbWVvdXQgdmFsID0gMHg1OWRmMGY4ZSByZWcgPSAweDAwMDAwMDA4DQpb
IDMwMjUuMDc2NjEyXSBpbXhkaV9ydGMgNTNmYTQwMDAuc3J0YzogV3JpdGUtd2FpdCB0aW1lb3V0
IHZhbCA9IDB4NTlkZjE5YTIgcmVnID0gMHgwMDAwMDAwOA0KWyAzMDgyLjMxNjYxMl0gaW14ZGlf
cnRjIDUzZmE0MDAwLnNydGM6IFdyaXRlLXdhaXQgdGltZW91dCB2YWwgPSAweDU5ZGYxOWRiIHJl
ZyA9IDB4MDAwMDAwMDgNCg0KTm92aWNlIHF1ZXN0aW9uOiBJcyBod2Nsb2NrIHN0aWxsIHJlcXVp
cmVkIHRoZXNlIGRheXM/IEZvciBtZSBpdCBsb29rcyBsaWtlIHRoZSBrZXJuZWwgaXMgc3luY2hy
b25pemluZyB3aXRoIHJ0YyBvbiBpdCdzIG93bi4gTWF5YmUgc29tZSBrZXJuZWwgY29uZmlnIGlz
IGluY29tcGF0aWJsZSB3aXRoIGh3Y2xvY2s/DQoNClJlZ2FyZHMsDQpQYXRyaWNrDQpCZWNraG9m
ZiBBdXRvbWF0aW9uIEdtYkggJiBDby4gS0cgfCBNYW5hZ2luZyBEaXJlY3RvcjogRGlwbC4gUGh5
cy4gSGFucyBCZWNraG9mZg0KUmVnaXN0ZXJlZCBvZmZpY2U6IFZlcmwsIEdlcm1hbnkgfCBSZWdp
c3RlciBjb3VydDogR3VldGVyc2xvaCBIUkEgNzA3NQ0KDQoNCg==
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-10-12 7:50 ` Patrick Brünn
0 siblings, 0 replies; 40+ messages in thread
From: Patrick Brünn @ 2017-10-12 7:50 UTC (permalink / raw)
To: linux-arm-kernel
>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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-10-12 7:50 ` Patrick Brünn
@ 2017-10-12 9:36 ` Russell King - ARM Linux
-1 siblings, 0 replies; 40+ messages in thread
From: Russell King - ARM Linux @ 2017-10-12 9:36 UTC (permalink / raw)
To: Patrick Brünn; +Cc: Vellemans, Noel, linux-arm-kernel, linux-rtc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-10-12 9:36 ` Russell King - ARM Linux
0 siblings, 0 replies; 40+ messages in thread
From: Russell King - ARM Linux @ 2017-10-12 9:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-10-12 7:50 ` Patrick Brünn
@ 2017-11-09 3:03 ` Alexandre Belloni
-1 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2017-11-09 3:03 UTC (permalink / raw)
To: Patrick Brünn; +Cc: Vellemans, Noel, linux-arm-kernel, linux-rtc
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@CX9020:~# uname -a
> Linux CX9020 4.14.0-rc4+ #151 PREEMPT Wed Oct 11 10:40:34 CEST 2017 armv7l GNU/Linux
> root@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@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
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-09 3:03 ` Alexandre Belloni
0 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2017-11-09 3:03 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: DryIce , RTC not working on imx53.
2017-11-09 3:03 ` Alexandre Belloni
@ 2017-11-09 9:59 ` Patrick Brünn
-1 siblings, 0 replies; 40+ messages in thread
From: Patrick Brünn @ 2017-11-09 9:59 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: Vellemans, Noel, linux-arm-kernel, linux-rtc
>From: Alexandre Belloni [mailto:alexandre.belloni@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
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-09 9:59 ` Patrick Brünn
0 siblings, 0 replies; 40+ messages in thread
From: Patrick Brünn @ 2017-11-09 9:59 UTC (permalink / raw)
To: linux-arm-kernel
>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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-09 9:59 ` Patrick Brünn
@ 2017-11-13 16:15 ` Alexandre Belloni
-1 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2017-11-13 16:15 UTC (permalink / raw)
To: Patrick Brünn
Cc: Vellemans, Noel, Fabio Estevam, linux-arm-kernel, linux-rtc
+Cc Fabio
On 09/11/2017 at 09:59:02 +0000, Patrick Brünn wrote:
>
> >From: Alexandre Belloni [mailto:alexandre.belloni@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
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-13 16:15 ` Alexandre Belloni
0 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2017-11-13 16:15 UTC (permalink / raw)
To: linux-arm-kernel
+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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-13 16:15 ` Alexandre Belloni
@ 2017-11-13 16:54 ` Fabio Estevam
-1 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-13 16:54 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Patrick Brünn, Vellemans, Noel, linux-arm-kernel, linux-rtc
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@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";
};
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-13 16:54 ` Fabio Estevam
0 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-13 16:54 UTC (permalink / raw)
To: linux-arm-kernel
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";
};
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-13 16:54 ` Fabio Estevam
@ 2017-11-13 18:56 ` Fabio Estevam
-1 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-13 18:56 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Patrick Brünn, Vellemans, Noel, linux-arm-kernel, linux-rtc
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@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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-13 18:56 ` Fabio Estevam
0 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-13 18:56 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: DryIce , RTC not working on imx53.
2017-11-13 18:56 ` Fabio Estevam
@ 2017-11-14 5:00 ` Patrick Brünn
-1 siblings, 0 replies; 40+ messages in thread
From: Patrick Brünn @ 2017-11-14 5:00 UTC (permalink / raw)
To: Fabio Estevam, Alexandre Belloni
Cc: Vellemans, Noel, linux-arm-kernel, linux-rtc
PkZyb206IEZhYmlvIEVzdGV2YW0gW21haWx0bzpmZXN0ZXZhbUBnbWFpbC5jb21dDQo+U2VudDog
TW9udGFnLCAxMy4gTm92ZW1iZXIgMjAxNyAxOTo1Nw0KPj4gSSBkb24ndCByZWNhbGwgb2YgYW55
IHJlY2VudCBjaGFuZ2UgaW4gdGhpcyBhcmVhLg0KPj4NCkkgZG9uJ3QgdGhpbmsgdGhlIGJlaGF2
aW9yIGNoYW5nZWQgcmVjZW50bHkuIEkgdHJpZWQgYSBrZXJuZWwgNC40LjY1IGFuZCBpdCBzaG93
cyB0aGUgc2FtZSBzeW1wdG9tcy4gSSBndWVzcyBOb2VsIHJlYWxseSBtZWFucyAzLjE5LT4gNC4w
Lg0KDQo+PiBQYXRyaWNrL05vZWwsDQo+Pg0KPj4gRG9lcyB0aGUgY2hhbmdlIGJlbG93IGhlbHA/
DQpVbmZvcnR1bmF0ZWx5IG5vLiBEaWQgeW91IHJ1biBod2Nsb2NrIG9yIHJ0Y3Rlc3Q/DQpJIHN0
aWxsIHNlZToNCnJvb3RAQ1g5MDIwOn4jIGNhdCAvcHJvYy9pbnRlcnJ1cHRzIHwgZ3JlcCBydGMN
CiA0MDogICAgICAgICAgMCAgICAgIHR6aWMgIDI0IEVkZ2UgICAgICA1M2ZhNDAwMC5zcnRjDQog
NDE6ICAgICAgICAgIDAgICAgICB0emljICAyNSBFZGdlICAgICAgNTNmYTQwMDAuc3J0Yw0Kcm9v
dEBDWDkwMjA6fiMgaHdjbG9jayAtRCAtcg0KaHdjbG9jayBmcm9tIHV0aWwtbGludXggMi4yOS4y
DQpVc2luZyB0aGUgL2RldiBpbnRlcmZhY2UgdG8gdGhlIGNsb2NrLg0KTGFzdCBkcmlmdCBhZGp1
c3RtZW50IGRvbmUgYXQgMTQ5MDg4NTA4MiBzZWNvbmRzIGFmdGVyIDE5NjkNCkxhc3QgY2FsaWJy
YXRpb24gZG9uZSBhdCAxNDkwODg1MDgyIHNlY29uZHMgYWZ0ZXIgMTk2OQ0KSGFyZHdhcmUgY2xv
Y2sgaXMgb24gVVRDIHRpbWUNCkFzc3VtaW5nIGhhcmR3YXJlIGNsb2NrIGlzIGtlcHQgaW4gVVRD
IHRpbWUuDQpXYWl0aW5nIGZvciBjbG9jayB0aWNrLi4uDQpbICAgNDEuMDM1MjY5XSBpcnEgNDA6
IG5vYm9keSBjYXJlZCAodHJ5IGJvb3Rpbmcgd2l0aCB0aGUgImlycXBvbGwiIG9wdGlvbikNClsg
ICA0MS4wNDI1MTRdIGhhbmRsZXJzOg0KWyAgIDQxLjA0NDg0N10gWzxjMDYwMzFlMD5dIGRyeWlj
ZV9pcnENClsgICA0MS4wNDgzOThdIERpc2FibGluZyBJUlEgIzQwDQpzZWxlY3QoKSB0byAvZGV2
L3J0YyB0byB3YWl0IGZvciBjbG9jayB0aWNrIHRpbWVkIG91dC4uLnN5bmNocm9uaXphdGlvbiBm
YWlsZWQNCnJvb3RAQ1g5MDIwOn4jIGNhdCAvcHJvYy9pbnRlcnJ1cHRzIHwgZ3JlcCBydGMNCiA0
MDogICAgIDEwMDAwMCAgICAgIHR6aWMgIDI0IEVkZ2UgICAgICA1M2ZhNDAwMC5zcnRjDQogNDE6
ICAgICAgICAgIDAgICAgICB0emljICAyNSBFZGdlICAgICAgNTNmYTQwMDAuc3J0Yw0KDQoNCm9y
IGlmIEkgcnVuIHJ0Y3Rlc3QgZnJvbSB0b29scy90ZXN0aW5nL3NlbGZ0ZXN0cy90aW1lcnMvIChh
ZnRlciByZWJvb3QpOg0KDQpyb290QENYOTAyMDp+IyBjYXQgL3Byb2MvaW50ZXJydXB0cyB8IGdy
ZXAgcnRjDQogNDA6ICAgICAgICAgIDAgICAgICB0emljICAyNCBFZGdlICAgICAgNTNmYTQwMDAu
c3J0Yw0KIDQxOiAgICAgICAgICAwICAgICAgdHppYyAgMjUgRWRnZSAgICAgIDUzZmE0MDAwLnNy
dGMNCnJvb3RAQ1g5MDIwOn4jIC4vcnRjdGVzdA0KDQogICAgICAgICAgICAgICAgICAgICAgICBS
VEMgRHJpdmVyIFRlc3QgRXhhbXBsZS4NCg0KQ291bnRpbmcgNSB1cGRhdGUgKDEvc2VjKSBpbnRl
cnJ1cHRzIGZyb20gcmVhZGluZyAvZGV2L3J0YzA6WyAgIDM3LjU1MDM5OV0gaXJxIDQwOiBub2Jv
ZHkgY2FyZWQgKHRyeSBib290aW5nIHdpdGggdGhlICJpcnFwb2xsIiBvcHRpb24pDQpbICAgMzcu
NTU3NjQ2XSBoYW5kbGVyczoNClsgICAzNy41NTk5ODBdIFs8YzA2MDMxZTA+XSBkcnlpY2VfaXJx
DQpbICAgMzcuNTYzNTMyXSBEaXNhYmxpbmcgSVJRICM0MA0KXkMNCnJvb3RAQ1g5MDIwOn4jIGNh
dCAvcHJvYy9pbnRlcnJ1cHRzIHwgZ3JlcCBydGMNCiA0MDogICAgIDEwMDAwMCAgICAgIHR6aWMg
IDI0IEVkZ2UgICAgICA1M2ZhNDAwMC5zcnRjDQogNDE6ICAgICAgICAgIDAgICAgICB0emljICAy
NSBFZGdlICAgICAgNTNmYTQwMDAuc3J0Yw0KDQoNCldpdGggdGhlIGF0dGFjaGVkIHBhdGNoIEkg
Z2V0IHJpZCBvZiB0aGUgdW5oYW5kbGVkIGludGVycnVwdHMuIEJ1dCB0aGF0IHBhdGNoIGp1c3Qg
QUNLcyBldmVyeXRoaW5nLg0KIHJvb3RAQ1g5MDIwOn4jIGNhdCAvcHJvYy9pbnRlcnJ1cHRzIHwg
Z3JlcCBydGMNCiA0MDogICAgICAgICAgMCAgICAgIHR6aWMgIDI0IEVkZ2UgICAgICA1M2ZhNDAw
MC5zcnRjDQogNDE6ICAgICAgICAgIDAgICAgICB0emljICAyNSBFZGdlICAgICAgNTNmYTQwMDAu
c3J0Yw0Kcm9vdEBDWDkwMjA6fiMgaHdjbG9jayAtRCAtcg0KaHdjbG9jayBmcm9tIHV0aWwtbGlu
dXggMi4yOS4yDQpVc2luZyB0aGUgL2RldiBpbnRlcmZhY2UgdG8gdGhlIGNsb2NrLg0KTGFzdCBk
cmlmdCBhZGp1c3RtZW50IGRvbmUgYXQgMTQ5MDg4NTA4MiBzZWNvbmRzIGFmdGVyIDE5NjkNCkxh
c3QgY2FsaWJyYXRpb24gZG9uZSBhdCAxNDkwODg1MDgyIHNlY29uZHMgYWZ0ZXIgMTk2OQ0KSGFy
ZHdhcmUgY2xvY2sgaXMgb24gVVRDIHRpbWUNCkFzc3VtaW5nIGhhcmR3YXJlIGNsb2NrIGlzIGtl
cHQgaW4gVVRDIHRpbWUuDQpXYWl0aW5nIGZvciBjbG9jayB0aWNrLi4uDQpzZWxlY3QoKSB0byAv
ZGV2L3J0YyB0byB3YWl0IGZvciBjbG9jayB0aWNrIHRpbWVkIG91dC4uLnN5bmNocm9uaXphdGlv
biBmYWlsZWQNCnJvb3RAQ1g5MDIwOn4jIGNhdCAvcHJvYy9pbnRlcnJ1cHRzIHwgZ3JlcCBydGMN
CiA0MDogICAgIDMwMTg0NCAgICAgIHR6aWMgIDI0IEVkZ2UgICAgICA1M2ZhNDAwMC5zcnRjDQog
NDE6ICAgICAgICAgIDAgICAgICB0emljICAyNSBFZGdlICAgICAgNTNmYTQwMDAuc3J0Yw0KDQpG
cm9tIDQyMjc0NzY4NmY1NzIzYWM3NWI5OGFkNjEwYjNlZjRkOTRlZjI3MWYgTW9uIFNlcCAxNyAw
MDowMDowMCAyMDAxDQpGcm9tOiBQYXRyaWNrIEJydWVubiA8cC5icnVlbm5AYmVja2hvZmYuY29t
Pg0KRGF0ZTogVHVlLCAxNCBOb3YgMjAxNyAwNToyMzoyNCArMDEwMA0KU3ViamVjdDogW1BBVENI
XSBYWFg6IGRpc2FibGUgaW50ZXJydXB0cyBtYW51YWxseQ0KDQotLS0NCiBkcml2ZXJzL3J0Yy9y
dGMtaW14ZGkuYyB8IDI0ICsrKysrKysrKysrKysrKysrKysrKysrKw0KIDEgZmlsZSBjaGFuZ2Vk
LCAyNCBpbnNlcnRpb25zKCspDQoNCmRpZmYgLS1naXQgYS9kcml2ZXJzL3J0Yy9ydGMtaW14ZGku
YyBiL2RyaXZlcnMvcnRjL3J0Yy1pbXhkaS5jDQppbmRleCA4MDkzMTExNGM4OTkuLjRiNjRhNTM1
MGJhYyAxMDA2NDQNCi0tLSBhL2RyaXZlcnMvcnRjL3J0Yy1pbXhkaS5jDQorKysgYi9kcml2ZXJz
L3J0Yy9ydGMtaW14ZGkuYw0KQEAgLTY4Niw2ICs2ODYsMjQgQEAgc3RhdGljIGlycXJldHVybl90
IGRyeWljZV9pcnEoaW50IGlycSwgdm9pZCAqZGV2X2lkKQ0KICAgICAgICBkaWVyID0gcmVhZGwo
aW14ZGktPmlvYWRkciArIERJRVIpOw0KICAgICAgICBkc3IgPSByZWFkbChpbXhkaS0+aW9hZGRy
ICsgRFNSKTsNCg0KKyAgICAgICAvKiBhY2sgbW9ub3RvbmljIGNvdW50ZXIgb3ZlcmZsb3cgKi8N
CisgICAgICAgaWYgKERTUl9NQ08gPT0gZHNyKSB7DQorICAgICAgICAgICAgICAgcmV0dXJuIElS
UV9IQU5ETEVEOw0KKyAgICAgICB9DQorICAgICAgIGlmIChkaWVyICYgRElFUl9XQ0lFKSB7DQor
ICAgICAgICAgICAgICAgaWYgKGRzciAmIERTUl9NQ08pIHsNCisgICAgICAgICAgICAgICAgICAg
ICAgIGRpX2ludF9kaXNhYmxlKGlteGRpLCBESUVSX1dDSUUpOw0KKyAgICAgICAgICAgICAgICAg
ICAgICAgcmV0dXJuIElSUV9IQU5ETEVEOw0KKyAgICAgICAgICAgICAgIH0NCisgICAgICAgfQ0K
Kw0KKyAgICAgICBpZiAoZGllciAmIERJRVJfQ0FJRSkgew0KKyAgICAgICAgICAgICAgIGlmIChk
c3IgJiBEU1JfTUNPKSB7DQorICAgICAgICAgICAgICAgICAgICAgICBkaV9pbnRfZGlzYWJsZShp
bXhkaSwgRElFUl9DQUlFKTsNCisgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiBJUlFfSEFO
RExFRDsNCisgICAgICAgICAgICAgICB9DQorICAgICAgIH0NCisNCiAgICAgICAgLyogaGFuZGxl
IHRoZSBzZWN1cml0eSB2aW9sYXRpb24gZXZlbnQgKi8NCiAgICAgICAgaWYgKGRpZXIgJiBESUVS
X1NWSUUpIHsNCiAgICAgICAgICAgICAgICBpZiAoZHNyICYgRFNSX1NWRikgew0KQEAgLTcxMCw3
ICs3MjgsMTAgQEAgc3RhdGljIGlycXJldHVybl90IGRyeWljZV9pcnEoaW50IGlycSwgdm9pZCAq
ZGV2X2lkKQ0KICAgICAgICAgICAgICAgICAgb3BlcmF0aW9ucy4gSXQgbWVhbnMgdGhlIGludGVy
cnVwdCBpcyBmb3IgRHJ5SWNlIC1TZWN1cml0eS4NCiAgICAgICAgICAgICAgICAgIElSUSBtdXN0
IGJlIHJldHVybmVkIGFzIG5vbmUuKi8NCiAgICAgICAgICAgICAgICBpZiAobGlzdF9lbXB0eV9j
YXJlZnVsKCZpbXhkaS0+d3JpdGVfd2FpdC5oZWFkKSkNCisgICAgICAgICAgICAgICB7DQorICAg
ICAgICAgICAgICAgICAgICAgICBwcmludGsoInJ0YzogWFhYWDogZGllcjogMHgleCBkc3I6IDB4
JXhcbiIsIGRpZXIsIGRzcik7DQogICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gcmM7DQor
ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgLyogRFNSX1dDRiBjbGVhcnMgaXRz
ZWxmIG9uIERTUiByZWFkICovDQogICAgICAgICAgICAgICAgaWYgKGRzciAmIChEU1JfV0NGIHwg
RFNSX1dFRikpIHsNCkBAIC03MzcsNiArNzU4LDkgQEAgc3RhdGljIGlycXJldHVybl90IGRyeWlj
ZV9pcnEoaW50IGlycSwgdm9pZCAqZGV2X2lkKQ0KICAgICAgICAgICAgICAgICAgICAgICAgcmMg
PSBJUlFfSEFORExFRDsNCiAgICAgICAgICAgICAgICB9DQogICAgICAgIH0NCisgICAgICAgaWYg
KHJjICE9IElSUV9IQU5ETEVEKSB7DQorICAgICAgICAgICAgICAgcHJpbnRrKCJydGM6IFhYWFg6
IGRpZXI6IDB4JXggZHNyOiAweCV4XG4iLCBkaWVyLCBkc3IpOw0KKyAgICAgICB9DQogICAgICAg
IHJldHVybiByYzsNCiB9DQoNCi0tDQoyLjExLjANCkJlY2tob2ZmIEF1dG9tYXRpb24gR21iSCAm
IENvLiBLRyB8IE1hbmFnaW5nIERpcmVjdG9yOiBEaXBsLiBQaHlzLiBIYW5zIEJlY2tob2ZmDQpS
ZWdpc3RlcmVkIG9mZmljZTogVmVybCwgR2VybWFueSB8IFJlZ2lzdGVyIGNvdXJ0OiBHdWV0ZXJz
bG9oIEhSQSA3MDc1DQoNCg0K
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 5:00 ` Patrick Brünn
0 siblings, 0 replies; 40+ messages in thread
From: Patrick Brünn @ 2017-11-14 5:00 UTC (permalink / raw)
To: linux-arm-kernel
>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
^ permalink raw reply related [flat|nested] 40+ messages in thread
* RE: DryIce , RTC not working on imx53.
2017-11-14 5:00 ` Patrick Brünn
@ 2017-11-14 6:40 ` Vellemans, Noel
-1 siblings, 0 replies; 40+ messages in thread
From: Vellemans, Noel @ 2017-11-14 6:40 UTC (permalink / raw)
To: Patrick Brünn, Fabio Estevam, Alexandre Belloni
Cc: linux-arm-kernel, linux-rtc
SEkgYWxsLA0KDQpJJ3ZlIGJlZW4gZGlnZ2luZyBhIHdoaWxlIGluIHRoZSBEcnlJY2UgY29kZSAo
c29tZSB0aW1lIGFnbywgaXQgd2FzIGluIGEgaHVycnkgYmVjYXVzZSBJIG5lZWRlZCB0byByZWxl
YXNlKS4NCg0KSSBmaW5hbGx5IGVuZGVkIHVwIGJ5IE5PVCB1c2luZyB0aGUgRHJ5SWNlIGNvZGUg
LCBmb3IgdGhlIElNWDUzICggaW50ZXJuYWwgUlRDKQ0KDQpJZiBJIHJlY2FsbCBjb3JyZWN0bHkg
LCB0aGlzIGlzIG5vdCB0aGUgY29ycmVjdCBkcml2ZXIgZm9yIHRoZSBJbnRlcm5hbCBJTVg1MyBS
VEMsICggZm9yIGV4YW1wbGUgdGhlIHJlZ2lzdGVyIEJBU0UtQWRkcmVzc2VzIC8gb2Zmc2V0cyBh
cmUgbm90IGNvcnJlY3QuLikgDQpyZXN1bHRpbmcgaW4gYWxsIGtpbmQgb2Ygc3RyYW5nZSBiZWhh
dmlvciwgZGVwZW5kaW5nIG9uIHlvdXIgc2l0dWF0aW9uYWwgdXNlLWNhc2VzOi0oDQoNCg0KDQoN
CkJlc3QgUmVnYXJkcw0KTm9lbA0KDQpfX19fX19fX19fX19fX19fX19fX19fXw0KTm9lbCBWZWxs
ZW1hbnMNCkJNUyBidmJhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXRy
aWNrIEJyw7xubiBbbWFpbHRvOlAuQnJ1ZW5uQGJlY2tob2ZmLmNvbV0gDQpTZW50OiBUdWVzZGF5
LCBOb3ZlbWJlciAxNCwgMjAxNyA2OjAwIEFNDQpUbzogRmFiaW8gRXN0ZXZhbTsgQWxleGFuZHJl
IEJlbGxvbmkNCkNjOiBWZWxsZW1hbnMsIE5vZWw7IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5m
cmFkZWFkLm9yZzsgbGludXgtcnRjQHZnZXIua2VybmVsLm9yZw0KU3ViamVjdDogUkU6IERyeUlj
ZSAsIFJUQyBub3Qgd29ya2luZyBvbiBpbXg1My4NCg0KPkZyb206IEZhYmlvIEVzdGV2YW0gW21h
aWx0bzpmZXN0ZXZhbUBnbWFpbC5jb21dDQo+U2VudDogTW9udGFnLCAxMy4gTm92ZW1iZXIgMjAx
NyAxOTo1Nw0KPj4gSSBkb24ndCByZWNhbGwgb2YgYW55IHJlY2VudCBjaGFuZ2UgaW4gdGhpcyBh
cmVhLg0KPj4NCkkgZG9uJ3QgdGhpbmsgdGhlIGJlaGF2aW9yIGNoYW5nZWQgcmVjZW50bHkuIEkg
dHJpZWQgYSBrZXJuZWwgNC40LjY1IGFuZCBpdCBzaG93cyB0aGUgc2FtZSBzeW1wdG9tcy4gSSBn
dWVzcyBOb2VsIHJlYWxseSBtZWFucyAzLjE5LT4gNC4wLg0KDQo+PiBQYXRyaWNrL05vZWwsDQo+
Pg0KPj4gRG9lcyB0aGUgY2hhbmdlIGJlbG93IGhlbHA/DQpVbmZvcnR1bmF0ZWx5IG5vLiBEaWQg
eW91IHJ1biBod2Nsb2NrIG9yIHJ0Y3Rlc3Q/DQpJIHN0aWxsIHNlZToNCnJvb3RAQ1g5MDIwOn4j
IGNhdCAvcHJvYy9pbnRlcnJ1cHRzIHwgZ3JlcCBydGMNCiA0MDogICAgICAgICAgMCAgICAgIHR6
aWMgIDI0IEVkZ2UgICAgICA1M2ZhNDAwMC5zcnRjDQogNDE6ICAgICAgICAgIDAgICAgICB0emlj
ICAyNSBFZGdlICAgICAgNTNmYTQwMDAuc3J0Yw0Kcm9vdEBDWDkwMjA6fiMgaHdjbG9jayAtRCAt
cg0KaHdjbG9jayBmcm9tIHV0aWwtbGludXggMi4yOS4yDQpVc2luZyB0aGUgL2RldiBpbnRlcmZh
Y2UgdG8gdGhlIGNsb2NrLg0KTGFzdCBkcmlmdCBhZGp1c3RtZW50IGRvbmUgYXQgMTQ5MDg4NTA4
MiBzZWNvbmRzIGFmdGVyIDE5NjkgTGFzdCBjYWxpYnJhdGlvbiBkb25lIGF0IDE0OTA4ODUwODIg
c2Vjb25kcyBhZnRlciAxOTY5IEhhcmR3YXJlIGNsb2NrIGlzIG9uIFVUQyB0aW1lIEFzc3VtaW5n
IGhhcmR3YXJlIGNsb2NrIGlzIGtlcHQgaW4gVVRDIHRpbWUuDQpXYWl0aW5nIGZvciBjbG9jayB0
aWNrLi4uDQpbICAgNDEuMDM1MjY5XSBpcnEgNDA6IG5vYm9keSBjYXJlZCAodHJ5IGJvb3Rpbmcg
d2l0aCB0aGUgImlycXBvbGwiIG9wdGlvbikNClsgICA0MS4wNDI1MTRdIGhhbmRsZXJzOg0KWyAg
IDQxLjA0NDg0N10gWzxjMDYwMzFlMD5dIGRyeWljZV9pcnENClsgICA0MS4wNDgzOThdIERpc2Fi
bGluZyBJUlEgIzQwDQpzZWxlY3QoKSB0byAvZGV2L3J0YyB0byB3YWl0IGZvciBjbG9jayB0aWNr
IHRpbWVkIG91dC4uLnN5bmNocm9uaXphdGlvbiBmYWlsZWQgcm9vdEBDWDkwMjA6fiMgY2F0IC9w
cm9jL2ludGVycnVwdHMgfCBncmVwIHJ0Yw0KIDQwOiAgICAgMTAwMDAwICAgICAgdHppYyAgMjQg
RWRnZSAgICAgIDUzZmE0MDAwLnNydGMNCiA0MTogICAgICAgICAgMCAgICAgIHR6aWMgIDI1IEVk
Z2UgICAgICA1M2ZhNDAwMC5zcnRjDQoNCg0Kb3IgaWYgSSBydW4gcnRjdGVzdCBmcm9tIHRvb2xz
L3Rlc3Rpbmcvc2VsZnRlc3RzL3RpbWVycy8gKGFmdGVyIHJlYm9vdCk6DQoNCnJvb3RAQ1g5MDIw
On4jIGNhdCAvcHJvYy9pbnRlcnJ1cHRzIHwgZ3JlcCBydGMNCiA0MDogICAgICAgICAgMCAgICAg
IHR6aWMgIDI0IEVkZ2UgICAgICA1M2ZhNDAwMC5zcnRjDQogNDE6ICAgICAgICAgIDAgICAgICB0
emljICAyNSBFZGdlICAgICAgNTNmYTQwMDAuc3J0Yw0Kcm9vdEBDWDkwMjA6fiMgLi9ydGN0ZXN0
DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFJUQyBEcml2ZXIgVGVzdCBFeGFtcGxlLg0KDQpD
b3VudGluZyA1IHVwZGF0ZSAoMS9zZWMpIGludGVycnVwdHMgZnJvbSByZWFkaW5nIC9kZXYvcnRj
MDpbICAgMzcuNTUwMzk5XSBpcnEgNDA6IG5vYm9keSBjYXJlZCAodHJ5IGJvb3Rpbmcgd2l0aCB0
aGUgImlycXBvbGwiIG9wdGlvbikNClsgICAzNy41NTc2NDZdIGhhbmRsZXJzOg0KWyAgIDM3LjU1
OTk4MF0gWzxjMDYwMzFlMD5dIGRyeWljZV9pcnENClsgICAzNy41NjM1MzJdIERpc2FibGluZyBJ
UlEgIzQwDQpeQw0Kcm9vdEBDWDkwMjA6fiMgY2F0IC9wcm9jL2ludGVycnVwdHMgfCBncmVwIHJ0
Yw0KIDQwOiAgICAgMTAwMDAwICAgICAgdHppYyAgMjQgRWRnZSAgICAgIDUzZmE0MDAwLnNydGMN
CiA0MTogICAgICAgICAgMCAgICAgIHR6aWMgIDI1IEVkZ2UgICAgICA1M2ZhNDAwMC5zcnRjDQoN
Cg0KV2l0aCB0aGUgYXR0YWNoZWQgcGF0Y2ggSSBnZXQgcmlkIG9mIHRoZSB1bmhhbmRsZWQgaW50
ZXJydXB0cy4gQnV0IHRoYXQgcGF0Y2gganVzdCBBQ0tzIGV2ZXJ5dGhpbmcuDQogcm9vdEBDWDkw
MjA6fiMgY2F0IC9wcm9jL2ludGVycnVwdHMgfCBncmVwIHJ0Yw0KIDQwOiAgICAgICAgICAwICAg
ICAgdHppYyAgMjQgRWRnZSAgICAgIDUzZmE0MDAwLnNydGMNCiA0MTogICAgICAgICAgMCAgICAg
IHR6aWMgIDI1IEVkZ2UgICAgICA1M2ZhNDAwMC5zcnRjDQpyb290QENYOTAyMDp+IyBod2Nsb2Nr
IC1EIC1yDQpod2Nsb2NrIGZyb20gdXRpbC1saW51eCAyLjI5LjINClVzaW5nIHRoZSAvZGV2IGlu
dGVyZmFjZSB0byB0aGUgY2xvY2suDQpMYXN0IGRyaWZ0IGFkanVzdG1lbnQgZG9uZSBhdCAxNDkw
ODg1MDgyIHNlY29uZHMgYWZ0ZXIgMTk2OSBMYXN0IGNhbGlicmF0aW9uIGRvbmUgYXQgMTQ5MDg4
NTA4MiBzZWNvbmRzIGFmdGVyIDE5NjkgSGFyZHdhcmUgY2xvY2sgaXMgb24gVVRDIHRpbWUgQXNz
dW1pbmcgaGFyZHdhcmUgY2xvY2sgaXMga2VwdCBpbiBVVEMgdGltZS4NCldhaXRpbmcgZm9yIGNs
b2NrIHRpY2suLi4NCnNlbGVjdCgpIHRvIC9kZXYvcnRjIHRvIHdhaXQgZm9yIGNsb2NrIHRpY2sg
dGltZWQgb3V0Li4uc3luY2hyb25pemF0aW9uIGZhaWxlZCByb290QENYOTAyMDp+IyBjYXQgL3By
b2MvaW50ZXJydXB0cyB8IGdyZXAgcnRjDQogNDA6ICAgICAzMDE4NDQgICAgICB0emljICAyNCBF
ZGdlICAgICAgNTNmYTQwMDAuc3J0Yw0KIDQxOiAgICAgICAgICAwICAgICAgdHppYyAgMjUgRWRn
ZSAgICAgIDUzZmE0MDAwLnNydGMNCg0KRnJvbSA0MjI3NDc2ODZmNTcyM2FjNzViOThhZDYxMGIz
ZWY0ZDk0ZWYyNzFmIE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogUGF0cmljayBCcnVl
bm4gPHAuYnJ1ZW5uQGJlY2tob2ZmLmNvbT4NCkRhdGU6IFR1ZSwgMTQgTm92IDIwMTcgMDU6MjM6
MjQgKzAxMDANClN1YmplY3Q6IFtQQVRDSF0gWFhYOiBkaXNhYmxlIGludGVycnVwdHMgbWFudWFs
bHkNCg0KLS0tDQogZHJpdmVycy9ydGMvcnRjLWlteGRpLmMgfCAyNCArKysrKysrKysrKysrKysr
KysrKysrKysNCiAxIGZpbGUgY2hhbmdlZCwgMjQgaW5zZXJ0aW9ucygrKQ0KDQpkaWZmIC0tZ2l0
IGEvZHJpdmVycy9ydGMvcnRjLWlteGRpLmMgYi9kcml2ZXJzL3J0Yy9ydGMtaW14ZGkuYyBpbmRl
eCA4MDkzMTExNGM4OTkuLjRiNjRhNTM1MGJhYyAxMDA2NDQNCi0tLSBhL2RyaXZlcnMvcnRjL3J0
Yy1pbXhkaS5jDQorKysgYi9kcml2ZXJzL3J0Yy9ydGMtaW14ZGkuYw0KQEAgLTY4Niw2ICs2ODYs
MjQgQEAgc3RhdGljIGlycXJldHVybl90IGRyeWljZV9pcnEoaW50IGlycSwgdm9pZCAqZGV2X2lk
KQ0KICAgICAgICBkaWVyID0gcmVhZGwoaW14ZGktPmlvYWRkciArIERJRVIpOw0KICAgICAgICBk
c3IgPSByZWFkbChpbXhkaS0+aW9hZGRyICsgRFNSKTsNCg0KKyAgICAgICAvKiBhY2sgbW9ub3Rv
bmljIGNvdW50ZXIgb3ZlcmZsb3cgKi8NCisgICAgICAgaWYgKERTUl9NQ08gPT0gZHNyKSB7DQor
ICAgICAgICAgICAgICAgcmV0dXJuIElSUV9IQU5ETEVEOw0KKyAgICAgICB9DQorICAgICAgIGlm
IChkaWVyICYgRElFUl9XQ0lFKSB7DQorICAgICAgICAgICAgICAgaWYgKGRzciAmIERTUl9NQ08p
IHsNCisgICAgICAgICAgICAgICAgICAgICAgIGRpX2ludF9kaXNhYmxlKGlteGRpLCBESUVSX1dD
SUUpOw0KKyAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIElSUV9IQU5ETEVEOw0KKyAgICAg
ICAgICAgICAgIH0NCisgICAgICAgfQ0KKw0KKyAgICAgICBpZiAoZGllciAmIERJRVJfQ0FJRSkg
ew0KKyAgICAgICAgICAgICAgIGlmIChkc3IgJiBEU1JfTUNPKSB7DQorICAgICAgICAgICAgICAg
ICAgICAgICBkaV9pbnRfZGlzYWJsZShpbXhkaSwgRElFUl9DQUlFKTsNCisgICAgICAgICAgICAg
ICAgICAgICAgIHJldHVybiBJUlFfSEFORExFRDsNCisgICAgICAgICAgICAgICB9DQorICAgICAg
IH0NCisNCiAgICAgICAgLyogaGFuZGxlIHRoZSBzZWN1cml0eSB2aW9sYXRpb24gZXZlbnQgKi8N
CiAgICAgICAgaWYgKGRpZXIgJiBESUVSX1NWSUUpIHsNCiAgICAgICAgICAgICAgICBpZiAoZHNy
ICYgRFNSX1NWRikgew0KQEAgLTcxMCw3ICs3MjgsMTAgQEAgc3RhdGljIGlycXJldHVybl90IGRy
eWljZV9pcnEoaW50IGlycSwgdm9pZCAqZGV2X2lkKQ0KICAgICAgICAgICAgICAgICAgb3BlcmF0
aW9ucy4gSXQgbWVhbnMgdGhlIGludGVycnVwdCBpcyBmb3IgRHJ5SWNlIC1TZWN1cml0eS4NCiAg
ICAgICAgICAgICAgICAgIElSUSBtdXN0IGJlIHJldHVybmVkIGFzIG5vbmUuKi8NCiAgICAgICAg
ICAgICAgICBpZiAobGlzdF9lbXB0eV9jYXJlZnVsKCZpbXhkaS0+d3JpdGVfd2FpdC5oZWFkKSkN
CisgICAgICAgICAgICAgICB7DQorICAgICAgICAgICAgICAgICAgICAgICBwcmludGsoInJ0Yzog
WFhYWDogZGllcjogMHgleCBkc3I6IDB4JXhcbiIsIA0KKyBkaWVyLCBkc3IpOw0KICAgICAgICAg
ICAgICAgICAgICAgICAgcmV0dXJuIHJjOw0KKyAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAg
ICAgICAgIC8qIERTUl9XQ0YgY2xlYXJzIGl0c2VsZiBvbiBEU1IgcmVhZCAqLw0KICAgICAgICAg
ICAgICAgIGlmIChkc3IgJiAoRFNSX1dDRiB8IERTUl9XRUYpKSB7IEBAIC03MzcsNiArNzU4LDkg
QEAgc3RhdGljIGlycXJldHVybl90IGRyeWljZV9pcnEoaW50IGlycSwgdm9pZCAqZGV2X2lkKQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgcmMgPSBJUlFfSEFORExFRDsNCiAgICAgICAgICAgICAg
ICB9DQogICAgICAgIH0NCisgICAgICAgaWYgKHJjICE9IElSUV9IQU5ETEVEKSB7DQorICAgICAg
ICAgICAgICAgcHJpbnRrKCJydGM6IFhYWFg6IGRpZXI6IDB4JXggZHNyOiAweCV4XG4iLCBkaWVy
LCBkc3IpOw0KKyAgICAgICB9DQogICAgICAgIHJldHVybiByYzsNCiB9DQoNCi0tDQoyLjExLjAN
CkJlY2tob2ZmIEF1dG9tYXRpb24gR21iSCAmIENvLiBLRyB8IE1hbmFnaW5nIERpcmVjdG9yOiBE
aXBsLiBQaHlzLiBIYW5zIEJlY2tob2ZmIFJlZ2lzdGVyZWQgb2ZmaWNlOiBWZXJsLCBHZXJtYW55
IHwgUmVnaXN0ZXIgY291cnQ6IEd1ZXRlcnNsb2ggSFJBIDcwNzUNCg0KDQo=
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 6:40 ` Vellemans, Noel
0 siblings, 0 replies; 40+ messages in thread
From: Vellemans, Noel @ 2017-11-14 6:40 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-14 5:00 ` Patrick Brünn
@ 2017-11-14 10:12 ` Fabio Estevam
-1 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-14 10:12 UTC (permalink / raw)
To: Patrick Brünn
Cc: Alexandre Belloni, Vellemans, Noel, linux-arm-kernel, linux-rtc
Hi Patrick,
On Tue, Nov 14, 2017 at 3:00 AM, Patrick Br=C3=BCnn <P.Bruenn@beckhoff.com>=
wrote:
>>From: Fabio Estevam [mailto:festevam@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=
=3D 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@CX9020:~# cat /proc/interrupts | grep rtc
> 40: 0 tzic 24 Edge 53fa4000.srtc
> 41: 0 tzic 25 Edge 53fa4000.srtc
> root@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" optio=
n)
> [ 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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 10:12 ` Fabio Estevam
0 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-14 10:12 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-14 6:40 ` Vellemans, Noel
@ 2017-11-14 10:13 ` Fabio Estevam
-1 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-14 10:13 UTC (permalink / raw)
To: Vellemans, Noel
Cc: Patrick Brünn, Alexandre Belloni, linux-arm-kernel, linux-rtc
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?
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 10:13 ` Fabio Estevam
0 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-14 10:13 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-14 10:12 ` Fabio Estevam
@ 2017-11-14 10:26 ` Alexandre Belloni
-1 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2017-11-14 10:26 UTC (permalink / raw)
To: Fabio Estevam
Cc: Patrick Brünn, Juergen Borleis, Vellemans, Noel,
linux-arm-kernel, linux-rtc
+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@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@CX9020:~# cat /proc/interrupts | grep rtc
> > 40: 0 tzic 24 Edge 53fa4000.srtc
> > 41: 0 tzic 25 Edge 53fa4000.srtc
> > root@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
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 10:26 ` Alexandre Belloni
0 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2017-11-14 10:26 UTC (permalink / raw)
To: linux-arm-kernel
+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
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: DryIce , RTC not working on imx53.
2017-11-14 10:13 ` Fabio Estevam
@ 2017-11-14 10:29 ` Vellemans, Noel
-1 siblings, 0 replies; 40+ messages in thread
From: Vellemans, Noel @ 2017-11-14 10:29 UTC (permalink / raw)
To: Fabio Estevam
Cc: Patrick Brünn, Alexandre Belloni, linux-arm-kernel, linux-rtc
SGkgRmFiaW8NCg0KSXQncyBiZWVuIGEgd2hpbGUuLi4gKCBidXQgSSdtIHF1aXRlIHN1cmUpLCBp
ZiB5b3UgbG9vayBjbG9zZWx5IGF0IHRoZSByZWdpc3RlciBkZWZpbmVzICggaW50byB0aGUgRFJZ
SUNFLWRyaXZlci1jb2RlKSB0aGVuIHlvdSB3aWxsIG5vdGljZS4uLiB0aGF0IFNPTUUgcmVnaXN0
ZXJzIG9mZnNldHMgYXJlIGNvcnJlY3QgLCBidXQgb3RoZXJzIGFyZSBub3QgbWF0Y2hpbmcgdGhl
IElOVEVSTkFMIHJ0YyBvZiB0aGUgSU1YNTMuDQoNCldoZW4gSSBub3RpY2VkIHRoYXQgKCBJIHNr
aXBwZWQgUlRDIGRyaXZlciBmdW5jdGlvbmFsaXR5LCB1bmRlciByZWxlYXNlIHByZXNzdXJlLCBJ
IGhhZCBzdGlsbCBtYW55IGl0ZW1zIHRvIHRlc3Qgb24gdGhvc2Uga2VybmVsICwgYW5kIEkgd2Fz
IHVuZGVyIHJlbGVhc2UgcHJlc3N1cmUuLiBzbyBJIHJlbW92ZWQgUlRDIGZvciB0aGUgdGltZSBi
ZWluZy4pDQoNCnsgeW91IGNhbiBnZXQgYmFzaWMgUlRDICwgdGltZXIgb25seSAsIG5vIGFsYXJt
cy9ldmVudHMgd29ya2luZy4uLiBieSBjb21tZW50aW5nIGEgbG90IG9mIHRoaW5ncyBvdXQsICBi
dXQgLi4gSSBkZWNpZGVkIHRvIHNvbHZlIHRoaXMgbGF0ZXIgdGhlIGNvcnJlY3Qgd2F5LCAgd2hl
biBJIGZpbmQgc29tZSB0aW1lICAoIGFuZCB0byByZXBvcnQgYmFjayB3aGVuIHNvbHZlZCwgZGlk
bid0IHdhbnQgdG8gYm90aGVyIG1hbnkgcGVvcGxlLCBvciBvdGhlcndpc2Ugc2FpZCBkaWRuJ3Qg
d2FudCBtYWtlIHRvbyBtYW55IG5vaXNlIC4uLi4gKCBiZWNhdXNlIHJ0YyBpcyBub3QgY3JpdGlj
YWwgaW4gbXkgYXBwbGljYXRpb24gKSB9DQoNClRoaXMgZHJpdmVyIHdpbGwgbm90IHdvcmsgZm9y
IHRoZSBJTlRFUk5BTC1SVEMgKCBydGMgaW50byB0aGUgSU1YNTMpLCBhbmQgd2lsbCBuZXZlciBo
YXZlIHdvcmtlZCwgSSBjYW4gY29uZmlybSB0aGlzLCBpdCBtaWdodCBoYXZlIHdvcmtlZCBmb3Ig
c29tZSBvdGhlciB2YXJpYW50IG9mIHRoZSBSVEMsIGJ1dCBpdCB3aWxsIG5vdCBkbyB3aGF0IHdl
IGFsbCBleHBlY3RlZCBmb3IgdGhlIFJUQyBsb2NhdGVkIGludG8gSU1YNTMhDQoNCg0KUmVnYXJk
cw0KTm9lbA0KDQoNClBTOiBKdXN0IGZvciBpbmZvLCAgYXQgdGhpcyB0aW1lIEknbSBpbnZlc3Rp
Z2F0aW5nIGEgTk9UIGJvb3RpbmcgcHJvYmxlbSAuLiBhbmQgLi4gaXTigJlzIGEgaGFyZCBvbmUg
KCBrZWVwcyBtZSBidXN5IGZvciBzb21lIGRheSdzIGFscmVhZHkgLi4uIGxldCdzIHNheSBpbiBh
IDUwMCBib290cyB0aGVyZSBpcyBvbmUgaXNzdWUgd2hlcmUgdGhlICdrZXJuZWwnIGxvY2tzLXVw
IGluIGEgdmVyeSB2ZXJ5IGVhcmx5IHN0YWdlLi4gKGludG8gdGhlIGZpcnN0IG1pbGktc2VjIG9m
IHRoZSBib290IGl0IGhhbmdzLCBzb21lLXdoZXJlIGFyb3VuZCBJUlEtaW5pdGlhbGl6YXRpb24g
Li4gYWxsIGJsb2NrcyAsIGJlZm9yZSBDUFUtaWRlbnRpZmljYXRpb24uLi4gbm8gY2x1ZSB5ZXQg
d2hlcmUgZXhhY3RseS4uISkNCnsgaXQncyBvbmx5IGhhcHBlbmluZyBpbiBsYXRlc3Qga2VybmVs
cyA0LjQueCAvIDQuMXgueCAsIG9sZGVyIDIuNi4zNSBkbyBub3Qgc3VmZmVyIHRoaXMgbm9uZSBi
b290IGJlaGF2aW9yICggb24gdGhlIHNhbWUgaGFyZHdhcmUpICwgc28gLi4gZGlnZ2luZyAvIGRl
YnVnZ2luZyAvIHByaW50aW5nLi4gOi0pIGF0IHRoaXMgdGltZSB9DQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX18NCk5vZWwgVmVsbGVtYW5zDQpCTVMgYnZiYQ0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogRmFiaW8gRXN0ZXZhbSBbbWFpbHRvOmZlc3RldmFtQGdtYWlsLmNv
bV0gDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxNCwgMjAxNyAxMToxMyBBTQ0KVG86IFZlbGxl
bWFucywgTm9lbA0KQ2M6IFBhdHJpY2sgQnLDvG5uOyBBbGV4YW5kcmUgQmVsbG9uaTsgbGludXgt
YXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eC1ydGNAdmdlci5rZXJuZWwub3Jn
DQpTdWJqZWN0OiBSZTogRHJ5SWNlICwgUlRDIG5vdCB3b3JraW5nIG9uIGlteDUzLg0KDQpIaSBO
b2VsLA0KDQpPbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCA0OjQwIEFNLCBWZWxsZW1hbnMsIE5vZWwg
PE5vZWwuVmVsbGVtYW5zQHZpc2lvbmJtcy5jb20+IHdyb3RlOg0KPiBISSBhbGwsDQo+DQo+IEkn
dmUgYmVlbiBkaWdnaW5nIGEgd2hpbGUgaW4gdGhlIERyeUljZSBjb2RlIChzb21lIHRpbWUgYWdv
LCBpdCB3YXMgaW4gYSBodXJyeSBiZWNhdXNlIEkgbmVlZGVkIHRvIHJlbGVhc2UpLg0KPg0KPiBJ
IGZpbmFsbHkgZW5kZWQgdXAgYnkgTk9UIHVzaW5nIHRoZSBEcnlJY2UgY29kZSAsIGZvciB0aGUg
SU1YNTMgKCANCj4gaW50ZXJuYWwgUlRDKQ0KPg0KPiBJZiBJIHJlY2FsbCBjb3JyZWN0bHkgLCB0
aGlzIGlzIG5vdCB0aGUgY29ycmVjdCBkcml2ZXIgZm9yIHRoZSANCj4gSW50ZXJuYWwgSU1YNTMg
UlRDLCAoIGZvciBleGFtcGxlIHRoZSByZWdpc3RlciBCQVNFLUFkZHJlc3NlcyAvIA0KPiBvZmZz
ZXRzIGFyZSBub3QgY29ycmVjdC4uKSByZXN1bHRpbmcgaW4gYWxsIGtpbmQgb2Ygc3RyYW5nZSBi
ZWhhdmlvciwgDQo+IGRlcGVuZGluZyBvbiB5b3VyIHNpdHVhdGlvbmFsIHVzZS1jYXNlczotKA0K
DQpDb3VsZCB5b3UgY2xhcmlmeSBhYm91dCB0aGlzPyBXaGljaCBiYXNlIGFkZHJlc3Mgb3Igb2Zm
c2V0cyBhcmUgbm90IGNvcnJlY3Q/DQo=
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 10:29 ` Vellemans, Noel
0 siblings, 0 replies; 40+ messages in thread
From: Vellemans, Noel @ 2017-11-14 10:29 UTC (permalink / raw)
To: linux-arm-kernel
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?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-14 10:26 ` Alexandre Belloni
@ 2017-11-14 10:33 ` Fabio Estevam
-1 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-14 10:33 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Patrick Brünn, Juergen Borleis, Vellemans, Noel,
linux-arm-kernel, linux-rtc
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 10:33 ` Fabio Estevam
0 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-14 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-14 10:33 ` Fabio Estevam
@ 2017-11-14 10:55 ` Alexandre Belloni
-1 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2017-11-14 10:55 UTC (permalink / raw)
To: Fabio Estevam
Cc: Patrick Brünn, Juergen Borleis, Vellemans, Noel,
linux-arm-kernel, linux-rtc
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 10:55 ` Alexandre Belloni
0 siblings, 0 replies; 40+ messages in thread
From: Alexandre Belloni @ 2017-11-14 10:55 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-14 10:55 ` Alexandre Belloni
@ 2017-11-14 12:43 ` Juergen Borleis
-1 siblings, 0 replies; 40+ messages in thread
From: Juergen Borleis @ 2017-11-14 12:43 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Fabio Estevam, Patrick Brünn, Vellemans, Noel,
linux-arm-kernel, linux-rtc
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/ |
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 12:43 ` Juergen Borleis
0 siblings, 0 replies; 40+ messages in thread
From: Juergen Borleis @ 2017-11-14 12:43 UTC (permalink / raw)
To: linux-arm-kernel
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/ ?|
^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: DryIce , RTC not working on imx53.
2017-11-14 12:43 ` Juergen Borleis
@ 2017-11-14 12:56 ` Vellemans, Noel
-1 siblings, 0 replies; 40+ messages in thread
From: Vellemans, Noel @ 2017-11-14 12:56 UTC (permalink / raw)
To: Juergen Borleis, Alexandre Belloni
Cc: Fabio Estevam, Patrick Brünn, linux-arm-kernel, linux-rtc
SGkgYWxsLCANCg0KSnVlcmdlbiBJdCB3b24ndCB3b3JrICggYXMgaXQgaXMpICwgcmVnaXN0ZXJz
IGFyZSBub3Qgb24gdGhlIGNvcnJlY3Qgb2Zmc2V0cyBhbmQgc29tZSBiaXRzIGFyZSBub3Qgb24g
dGhlIHNhbWUgcG9zaXRpb25zICggZm9yIHRoZSBJTVg1MykNClRoaXMgZHJpdmVyIHdpbGwgbm90
IHdvcmsgZm9yIHRoZSBJTlRFUk5BTC1SVEMgKCBydGMgaW50byB0aGUgSU1YNTMpLCBhbmQgd2ls
bCBuZXZlciBoYXZlIHdvcmtlZCAoIG9uIElNWDUzKS4gDQpJIGNhbiBjb25maXJtLCBpdCBtaWdo
dCB3b3JrIGZvciBzb21lIG90aGVyIHZhcmlhbnQgb2YgdGhlIFJUQywgYnV0IGl0IHdpbGwgbm90
IGRvIHdoYXQgd2UgYWxsIGV4cGVjdGVkIGZvciB0aGUgUlRDIGxvY2F0ZWQgaW50byBJTVg1MyEN
Cg0KKCBub3Qgc3VyZSBteSBwcmV2aW91cyBtYWlsIGdvdCB0byB0aGUgZGVzdGluYXRpb24pDQoN
CkJlc3QgUmVnYXJkcw0KTm9lbA0KDQoNCg0KDQo+Pg0KPj4gPiBKdWVyZ2VuIGNhbiBjb25maXJt
LCBidXQgaXQgc2VlbXMgdGhlIGRyeWljZSBkcml2ZXIgd2FzIG9ubHkgdXNlZCBvbg0KPiA+IG14
MjUgaW4gbWFpbmxpbmUuDQo+Pg0KPj4+IE9rLCB0aGF0IHdvdWxkIGV4cGxhaW4gaXQuDQo+Pg0K
Pj5ZZXMuIFRoZSBkZXZlbG9wbWVudCB3YXMgbWFkZSBvbiBhbiBpLk1YMjUuIEJ1dCBjdXJyZW50
bHkgSSBoYXZlIGFuIGkuTVg1MyBvbiBteSBkZXNrIGhlcmUgYW5kIGNvdWxkIHRlc3QuLi4NCj4+
DQo+PmpiDQoNCj4+Pg0KPj4NCj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
Pj5Gcm9tOiBWZWxsZW1hbnMsIE5vZWwgDQo+PlNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE0LCAy
MDE3IDExOjMwIEFNDQo+PlRvOiAnRmFiaW8gRXN0ZXZhbScNCj4+Q2M6IFBhdHJpY2sgQnLDvG5u
OyBBbGV4YW5kcmUgQmVsbG9uaTsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3Jn
OyBsaW51eC1ydGNAdmdlci5rZXJuZWwub3JnDQo+PlN1YmplY3Q6IFJFOiBEcnlJY2UgLCBSVEMg
bm90IHdvcmtpbmcgb24gaW14NTMuDQo+Pg0KPj5IaSBGYWJpbw0KPj4NCj4+SXQncyBiZWVuIGEg
d2hpbGUuLi4gKCBidXQgSSdtIHF1aXRlIHN1cmUpLCBpZiB5b3UgbG9vayBjbG9zZWx5IGF0IHRo
ZSByZWdpc3RlciBkZWZpbmVzICggaW50byB0aGUgRFJZSUNFLWRyaXZlci1jb2RlKSB0aGVuIHlv
dSB3aWxsIG5vdGljZS4uLiB0aGF0IFNPTUUgcmVnaXN0ZXJzIG9mZnNldHMgYXJlIGNvcnJlY3Qg
LCBidXQgb3RoZXJzIGFyZSBub3QgbWF0Y2hpbmcgdGhlIElOVEVSTkFMIHJ0YyBvZiB0aGUgSU1Y
NTMuDQo+Pg0KPj5XaGVuIEkgbm90aWNlZCB0aGF0ICggSSBza2lwcGVkIFJUQyBkcml2ZXIgZnVu
Y3Rpb25hbGl0eSwgdW5kZXIgcmVsZWFzZSBwcmVzc3VyZSwgSSBoYWQgc3RpbGwgbWFueSBpdGVt
cyB0byB0ZXN0IG9uIHRob3NlIGtlcm5lbCAsIGFuZCBJIHdhcyB1bmRlciByZWxlYXNlIHByZXNz
dXJlLi4gc28gSSByZW1vdmVkIFJUQyBmb3IgdGhlIHRpbWUgYmVpbmcuKQ0KPj4NCj4+eyB5b3Ug
Y2FuIGdldCBiYXNpYyBSVEMgLCB0aW1lciBvbmx5ICwgbm8gYWxhcm1zL2V2ZW50cyB3b3JraW5n
Li4uIGJ5IGNvbW1lbnRpbmcgYSBsb3Qgb2YgdGhpbmdzIG91dCwgIGJ1dCAuLiBJIGRlY2lkZWQg
dG8gc29sdmUgdGhpcyBsYXRlciB0aGUgY29ycmVjdCB3YXksICB3aGVuIEkgZmluZCBzb21lIHRp
bWUgICggYW5kIHRvIHJlcG9ydCBiYWNrIHdoZW4gc29sdmVkLCBkaWRuJ3Qgd2FudCB0byBib3Ro
ZXIgbWFueSBwZW9wbGUsIG9yIG90aGVyd2lzZSBzYWlkIGRpZG4ndCB3YW50IG1ha2UgdG9vIG1h
bnkgbm9pc2UgLi4uLiAoIGJlY2F1c2UgcnRjIGlzIG5vdCBjcml0aWNhbCBpbiBteSBhcHBsaWNh
dGlvbiApIH0NCj4+DQo+PlRoaXMgZHJpdmVyIHdpbGwgbm90IHdvcmsgZm9yIHRoZSBJTlRFUk5B
TC1SVEMgKCBydGMgaW50byB0aGUgSU1YNTMpLCBhbmQgd2lsbCBuZXZlciBoYXZlIHdvcmtlZCwg
SSBjYW4gY29uZmlybSB0aGlzLCBpdCBtaWdodCBoYXZlIHdvcmtlZCBmb3Igc29tZSBvdGhlciB2
YXJpYW50IG9mIHRoZSBSVEMsIGJ1dCBpdCB3aWxsIG5vdCBkbyB3aGF0IHdlIGFsbCBleHBlY3Rl
ZCBmb3IgdGhlIFJUQyBsb2NhdGVkIGludG8gSU1YNTMhDQo+Pg0KPj4NCj4+UmVnYXJkcw0KPj5O
b2VsDQo+Pg0KPj5QUzogSnVzdCBmb3IgaW5mbywgIGF0IHRoaXMgdGltZSBJJ20gaW52ZXN0aWdh
dGluZyBhIE5PVCBib290aW5nIHByb2JsZW0gLi4gYW5kIC4uIGl04oCZcyBhIGhhcmQgb25lICgg
a2VlcHMgbWUgYnVzeSBmb3Igc29tZSBkYXkncyBhbHJlYWR5IC4uLiBsZXQncyBzYXkgaW4gYSA1
MDAgYm9vdHMgdGhlcmUgaXMgb25lIGlzc3VlIHdoZXJlIHRoZSAna2VybmVsJyBsb2Nrcy11cCBp
biBhIA0KPj52ZXJ5IHZlcnkgZWFybHkgc3RhZ2UuLiAoaW50byB0aGUgZmlyc3QgbWlsaS1zZWMg
b2YgdGhlIGJvb3QgaXQgaGFuZ3MsIHNvbWUtd2hlcmUgYXJvdW5kIElSUS1pbml0aWFsaXphdGlv
biAuLiBhbGwgYmxvY2tzICwgYmVmb3JlIENQVS1pZGVudGlmaWNhdGlvbi4uLiBubyBjbHVlIHll
dCB3aGVyZSBleGFjdGx5Li4hKSANCj4+eyBpdCdzIG9ubHkgaGFwcGVuaW5nIGluIGxhdGVzdCBr
ZXJuZWxzIDQuNC54IC8gNC4xeC54ICwgb2xkZXIgMi42LjM1IGRvIG5vdCBzdWZmZXIgdGhpcyBu
b25lIGJvb3QgYmVoYXZpb3IgKCBvbiB0aGUgc2FtZSBoYXJkd2FyZSkgLCBzbyAuLiBkaWdnaW5n
IC8gZGVidWdnaW5nIC8gcHJpbnRpbmcuLiA6LSkgYXQgdGhpcyB0aW1lIH0NCg0K
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-14 12:56 ` Vellemans, Noel
0 siblings, 0 replies; 40+ messages in thread
From: Vellemans, Noel @ 2017-11-14 12:56 UTC (permalink / raw)
To: linux-arm-kernel
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 }
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-14 12:43 ` Juergen Borleis
@ 2017-11-15 9:53 ` Juergen Borleis
-1 siblings, 0 replies; 40+ messages in thread
From: Juergen Borleis @ 2017-11-15 9:53 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Alexandre Belloni, Vellemans, Noel, linux-rtc, Fabio Estevam,
Patrick Brünn
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/ |
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-15 9:53 ` Juergen Borleis
0 siblings, 0 replies; 40+ messages in thread
From: Juergen Borleis @ 2017-11-15 9:53 UTC (permalink / raw)
To: linux-arm-kernel
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/ ?|
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: DryIce , RTC not working on imx53.
2017-11-15 9:53 ` Juergen Borleis
@ 2017-11-15 11:42 ` Fabio Estevam
-1 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-15 11:42 UTC (permalink / raw)
To: Juergen Borleis
Cc: linux-arm-kernel, Alexandre Belloni, Vellemans, Noel, linux-rtc,
Patrick Brünn
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* DryIce , RTC not working on imx53.
@ 2017-11-15 11:42 ` Fabio Estevam
0 siblings, 0 replies; 40+ messages in thread
From: Fabio Estevam @ 2017-11-15 11:42 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2017-11-15 11:42 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-05 14:18 DryIce , RTC not working on imx53 Vellemans, Noel
2017-10-05 14:18 ` Vellemans, Noel
2017-10-12 7:50 ` Patrick Brünn
2017-10-12 7:50 ` Patrick Brünn
2017-10-12 9:36 ` Russell King - ARM Linux
2017-10-12 9:36 ` Russell King - ARM Linux
2017-11-09 3:03 ` Alexandre Belloni
2017-11-09 3:03 ` Alexandre Belloni
2017-11-09 9:59 ` Patrick Brünn
2017-11-09 9:59 ` Patrick Brünn
2017-11-13 16:15 ` Alexandre Belloni
2017-11-13 16:15 ` Alexandre Belloni
2017-11-13 16:54 ` Fabio Estevam
2017-11-13 16:54 ` Fabio Estevam
2017-11-13 18:56 ` Fabio Estevam
2017-11-13 18:56 ` Fabio Estevam
2017-11-14 5:00 ` Patrick Brünn
2017-11-14 5:00 ` Patrick Brünn
2017-11-14 6:40 ` Vellemans, Noel
2017-11-14 6:40 ` Vellemans, Noel
2017-11-14 10:13 ` Fabio Estevam
2017-11-14 10:13 ` Fabio Estevam
2017-11-14 10:29 ` Vellemans, Noel
2017-11-14 10:29 ` Vellemans, Noel
2017-11-14 10:12 ` Fabio Estevam
2017-11-14 10:12 ` Fabio Estevam
2017-11-14 10:26 ` Alexandre Belloni
2017-11-14 10:26 ` Alexandre Belloni
2017-11-14 10:33 ` Fabio Estevam
2017-11-14 10:33 ` Fabio Estevam
2017-11-14 10:55 ` Alexandre Belloni
2017-11-14 10:55 ` Alexandre Belloni
2017-11-14 12:43 ` Juergen Borleis
2017-11-14 12:43 ` Juergen Borleis
2017-11-14 12:56 ` Vellemans, Noel
2017-11-14 12:56 ` Vellemans, Noel
2017-11-15 9:53 ` Juergen Borleis
2017-11-15 9:53 ` Juergen Borleis
2017-11-15 11:42 ` Fabio Estevam
2017-11-15 11:42 ` Fabio Estevam
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.