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

[Chen-Yu Tsai <wens@csie.org>]

On Thu, Jul 7, 2016 at 12:50 PM, Stephan Roslen <stephan@roslen.de> 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 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.
>
>>
>>> +
>>> +    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=
");
>>> +            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

>
>>
>> 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.