Maquefel
(Nikita Shubin)
October 25, 2021, 2:48pm
1
Hello All!
I see da9063 RTC is firing nIRQ just once.
[ 2.841628] da9063-rtc da9063-rtc: registered as rtc0
[ 2.847116] da9063-rtc da9063-rtc: setting system clock to 2021-10-25T14:28:35 UTC (1635172115)
and later hwclock called once from init scripts...
...
cat /proc/interrupts
...
63: 1 0 0 0 sifive-gpio 1 da9063-irq
65: 0 0 0 1 da9063-irq 1 ALARM
The EVENT_A register is clear
i2cget -f -y 0 0x58 0x06
0x00
If i issue hwclock again i get timeout despite EVENT_A register holds E_ALARM bit and all other events are cleared:
+ i2cget -f -y 0 0x58 0x06
0x02
+ i2cget -f -y 0 0x58 0x07
0x00
+ i2cget -f -y 0 0x58 0x08
0x00
+ i2cget -f -y 0 0x58 0x09
0x00
However nIRQ hasn’t been fired. Moreover the MASK seems to be set correctly :
i2cget -f -y 0 0x58 0x0A
0x1d
Maquefel
(Nikita Shubin)
October 28, 2021, 11:24am
3
It turns out to be a bug in SiFive PLIC irqchip driver, see for detail:
https://patchwork.kernel.org/project/linux-riscv/patch/20211024013303.3499461-4-guoren@kernel.org/
I think Guo Ren will provide a quickfix.
For the impatient :
committed 11:12AM - 28 Oct 21 UTC
enable the da9063 RTC and Watchdog.
Signed-off-by: Nikita Shubin <nikita.shubin… @maquefel.me>
committed 11:15AM - 28 Oct 21 UTC
This is a quickfix based on Guo Ren's work:
https://patchwork.kernel.org/projec… t/linux-riscv/patch/20211024013303.3499461-4-guoren@kernel.org/
> When using "devm_request_threaded_irq(,,,,IRQF_ONESHOT,,)" in the driver,
> only the first interrupt could be handled, and continue irq is blocked by
> hw. Because the thead,c900-plic couldn't complete masked irq source which
> has been disabled in enable register. Add thead_plic_chip which fix up
> c906-plic irq source completion problem by unmask/mask wrapper.
>
> Here is the description of Interrupt Completion in PLIC spec [1]:
>
> The PLIC signals it has completed executing an interrupt handler by
> writing the interrupt ID it received from the claim to the claim/complete
> register. The PLIC does not check whether the completion ID is the same
> as the last claim ID for that target. If the completion ID does not match
> an interrupt source that is currently enabled for the target, the
> ^^ ^^^^^^^^^ ^^^^^^^
> completion is silently ignored.
Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
I can claim that the da9063 RTC is fully operational.
Maquefel
(Nikita Shubin)
November 3, 2021, 7:29am
4
Setting RTC clock to wakeup shutdowned system:
committed 02:09PM - 01 Nov 21 UTC
in case if threaded irq registered successfully - add da9063
as a wakeup source … if "wakeup-source" node present in device tree,
set as wakeup capable otherwise.
Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
sh -c "echo `date '+%s' -d '+ 1 minutes'` > /sys/class/rtc/rtc0/wakealarm"
shutdown
This will do a full “reset”, actually it’s shutdown + wakeup later.
davidlt
(David Abdurachmanov)
November 5, 2021, 3:49pm
5
@Maquefel Do you have plans to submit changes to drivers/rtc/rtc-da9063.c upstream?
Maquefel
(Nikita Shubin)
November 6, 2021, 1:18pm
6
Hello David!
I’ve already submitted this particular patch:
https://lkml.org/lkml/2021/11/1/800
Not sure everything is correct and waiting for feedback.
davidlt
(David Abdurachmanov)
November 15, 2021, 10:11am
7
I see there is no reply (unless I missed something) for 2 weeks now. You might want to wait a week and ping the patch. Kernel merge window is now closed thus people should start replying.
I assume this is separate work from your OpenSBI patches to support reset on FU740?
Side note: we should really rename sifive_fu740
→ sifive_unmatched
, like we did in U-Boot. This rest is not FU740 specific, it’s platform specific and that’s Unmatched.
Maquefel
(Nikita Shubin)
November 15, 2021, 10:29am
8
Yes surprisingly long response time, i always thought that this particular subsystem is not overwhelmed so much. I’ll ping them before the end of the week, may be earlier.
Yes indeed, the method proposed in OpenSBI patches is different - i am currently experimenting with TICK ALARM, with no recent progress, i get weird results with board being powered off and then preventing the onKEY power it back again (turns off shortly after key pressed), until cable plugged/unplugged (the BATTERY is missing).
That’s not a problem, i ll keep it in mind and introduce patch together with I2C minor reworks, in case you don’t have time for this.
Maquefel
(Nikita Shubin)
November 26, 2021, 10:26am
9
@davidlt , as Adam Thomson pointed out we don’t need the sysfs entry - we can simply set alarm via:
rtcwake -m no -s 60
It comes from util-linux package so it’s hard to miss it.
davidlt
(David Abdurachmanov)
December 9, 2021, 9:12am
10
@Maquefel now that [PATCH v3] rtc: da9063: add as wakeup source
is merged a few days ago could you also send a DT change patch for Unmatched? IIRC we will need wakeup-source
in DT to use sysfs knob.
Maquefel
(Nikita Shubin)
December 9, 2021, 9:50am
11
@davidlt Hello David!
No we don’t need the dts entry to make “/sys/class/rtc/rtc0/wakealarm” available.
https://patchwork.ozlabs.org/project/rtc-linux/patch/20211129072650.22686-1-nikita.shubin@maquefel.me/
As we always have the IRQ we just add it as a wakeup source.