| Message ID | 3BB206AB2B1BD448954845CE6FF69A8E01CB52F4BE@NT-Mail07.beckhoff.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. > 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.
+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.
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.
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.
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
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@lists.infradead.org; linux-rtc@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 }
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
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
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; }