[PATCH v2] rtc: snvs: add Freescale rtc-snvs driver

[kim.phillips@freescale.com (Kim Phillips)]

On Tue, 10 Jul 2012 10:32:29 +0800
Shawn Guo <shawn.guo@linaro.org> wrote:

> On Mon, Jul 09, 2012 at 07:45:14PM -0500, Kim Phillips wrote:
> > I'm not sure if this is appropriate vs. having common arch code
> > publish SNVS devices; see e.g., the other fsl,* devices in
> > arch/powerpc/platforms/85xx/common.c:mpc85xx_common_ids[].
> > 
> This is completely beyond the scope of the patch, which merely adds
> a driver for snvs-lp-rtc device.  But the driver does not know how
> the device is created, and it does not need to know.
> 
> > Either way, I'd like to get support without having to manually tweak
> > the device tree, i.e., the patch doesn't work as-is.
> > 
> As I already said, the patch only adds a driver for snvs-lp-rtc.  It
> should not care about how snvs-lp-rtc device is created on particular
> platform.  The patch does work as-is for imx6q, which is the target
> of the patch so far.

how, without the "simple-bus" addition to the sec_mon compatibles
list in the imx6 device tree (which isn't present in this patch)?

> > btw, testing on a p4080r2 produces a soft lockup:
> > 
> > root at p4080ds:~# modprobe rtc-snvs
> > snvs_rtc ffe314034.sec_mon_rtc_lp: rtc core: registered ffe314034.sec_mon_r as rtc1
> > root at p4080ds:~# hwclock -w -f /dev/rtc1 
> > BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0:4]
> > Modules linked in: rtc_snvs nfsd exportfs
> > irq event stamp: 54
> > hardirqs last  enabled at (53): [<c04f90dc>] _raw_spin_unlock_irq+0x30/0x58
> > hardirqs last disabled at (54): [<c04f8808>] _raw_spin_lock_irq+0x24/0x70
> > softirqs last  enabled at (0): [<c001eff8>] copy_process+0x2f4/0xde4
> > softirqs last disabled at (0): [<  (null)>]   (null)
> > NIP: f10b80b4 LR: f10b8074 CTR: 00000003
> > REGS: ee071d70 TRAP: 0901   Not tainted  (3.5.0-rc5-00099-gd8715a7-dirty)
> > MSR: 00029002 <CE,EE,ME>  CR: 42042022  XER: 00000000
> > TASK = ee06f470[4] 'kworker/0:0' THREAD: ee070000 CPU: 0
> > GPR00: 00000000 ee071e20 ee06f470 c04f9058 00000001 f10b8074 00000000 00000002 
> > GPR08: 00000001 f10bc054 00000000 00000000 c04f901c 
> > NIP [f10b80b4] snvs_rtc_alarm_irq_enable+0xb4/0xf8 [rtc_snvs]
> > LR [f10b8074] snvs_rtc_alarm_irq_enable+0x74/0xf8 [rtc_snvs]
> > Call Trace:
> > [ee071e20] [f10b8074] snvs_rtc_alarm_irq_enable+0x74/0xf8 [rtc_snvs] (unreliable)
> > [ee071e40] [c038c118] rtc_timer_do_work+0x184/0x20c
> > [ee071f10] [c003fc4c] process_one_work+0x1d4/0x48c
> > [ee071f50] [c0040d4c] worker_thread+0x184/0x358
> > [ee071f90] [c0046458] kthread+0x84/0x88
> > [ee071ff0] [c000d434] kernel_thread+0x4c/0x68
> > Instruction dump:
> > 7c0004ac 7d404c2c 0c0a0000 4c00012c 7c0004ac 7c004c2c 0c000000 4c00012c 
> > 7f8a0000 409effdc 7c0004ac 7c004c2c <0c000000> 4c00012c 7c0004ac 7d604c2c 
> > 
> > I debugged it to the innermost loop of rtc_write_sync_lp(), where
> > count2 and count3 are always equal.  Should there be a timeout in
> > that loop?  Do you know if this is because the machine isn't
> > in trusted mode?  Any other hints appreciated.
> > 
> This is probably because readl/writel does not work on powerpc.
> I experienced the same thing when working on fsl_ssi driver.
> 
> My patch only targets imx6q right now.

interesting.  When I add

+#define readl in_be32
+#define writel(val, addr)             out_be32(addr, val)

to the top of the driver, the soft-lockup moves to
rtc_read_lp_counter().  I'm trying to verify if I have the right h/w
revision.

Kim