On Thu, Jul 7, 2016 at 12:50 PM, Stephan Roslen <[email protected]> wrote: > On 06.07.2016 22:20, Maxime Ripard wrote: >> On Wed, Jul 06, 2016 at 10:43:00AM +0200, Stephan Roslen wrote: >>> + 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 necessary > delay for the hardware setup and update SUNXI_LOSC_CTRL_SRC_SEL bit. My > assumption was wrong, it seems. At least a few reboots show, that it is > likely to work without. > >> >>> + >>> + loscctrl = readl(chip->base + SUNXI_LOSC_CTRL); >>> + if (!(loscctrl & SUNXI_LOSC_CTRL_SRC_SEL)) { >>> + dev_err(&pdev->dev, "Error: Set LOSC to external failed.\n"); >>> + 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 seems, > 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 > >> >> 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 access it. > Or rather the CLK driver should use an MFD, that is provided early, too. > Eventually even a syscon? Actually the whole bunch described in subsection > 1.9 (including timers, arlarms, rtc and even the watchdog) would have to rely > on that MFD. Do I miss a point? > > Stephan -- 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. --- 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 email to [email protected]. For more options, visit https://groups.google.com/d/optout.
