Thread (8 messages) 8 messages, 3 authors, 2016-07-07

[rtc-linux] Re: [PATCH] rtc: sunxi: use external oscillator

From: Chen-Yu Tsai <hidden>
Date: 2016-07-07 04:53:52

On Thu, Jul 7, 2016 at 12:50 PM, Stephan Roslen [off-list ref] wrote:
On 06.07.2016 22:20, Maxime Ripard wrote:
quoted
On Wed, Jul 06, 2016 at 10:43:00AM +0200, Stephan Roslen wrote:
quoted
+    writel(loscctrl, chip->base + SUNXI_LOSC_CTRL);
+    udelay(100);
Why is that udelay needed?
I found that studying the sunxi 3.4 kernel code and considered it a neces=
sary delay for the hardware setup and update SUNXI_LOSC_CTRL_SRC_SEL bit. M=
y assumption was wrong, it seems. At least a few reboots show, that it is l=
ikely to work without.
quoted
quoted
+
+    loscctrl =3D readl(chip->base + SUNXI_LOSC_CTRL);
+    if (!(loscctrl & SUNXI_LOSC_CTRL_SRC_SEL)) {
+            dev_err(&pdev->dev, "Error: Set LOSC to external failed.\n=
");
quoted
quoted
+            dev_err(&pdev->dev, "Warning: RTC time will be wrong!\n");
+    }
+
This isn't needed

The issue is actually worse than that.

That register controls the losc source for the whole clock tree, so it
will affect every clock in the system.

In order to have that correctly propagated, you should register a new
mux here in the clock framework, and have all the other clocks using
that mux as a parent.
I agree. Checking the diagram in subsection 1.5.2 of the A20 manual it se=
ems, that LOSC can be a source for clocks like CPU and some SoC busses. So =
my patch could indeed mess with the whole clock tree.

(Please wrap your email)

Within the current sunxi clk structure, the LOSC is registered as a fixed
32.768 KHz clk. So this patch actually makes things right.

ChenYu
quoted
That's going to be tricky, because the clocks usually probe way
earlier than the RTC driver. So I'm guessing you could do a clock
driver that maps the registers, register its clock, and then when the
RTC probes just takes over what has been setup already by the clock
driver. This also means removing the ability for the RTC to be
compiled as a module.
I agree again. Though I think, the RTC should still work as a module. The=
 CLK driver could provide the regmap MFD style and the RTC driver may acces=
s it. Or rather the CLK driver should use an MFD, that is provided early, t=
oo. Eventually even a syscon? Actually the whole bunch described in subsect=
ion 1.9 (including timers, arlarms, rtc and even the watchdog) would have t=
o rely on that MFD. Do I miss a point?
Stephan
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help