Date:   Fri, 9 Aug 2019 11:16:26 +0200
From:   Ondřej Jirman <megous@...ous.com>
To:     Alexandre Belloni <alexandre.belloni@...tlin.com>
Cc:     Chen-Yu Tsai <wens@...e.org>, Mark Rutland <mark.rutland@....com>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        devicetree <devicetree@...r.kernel.org>,
        Maxime Ripard <maxime.ripard@...tlin.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-rtc@...r.kernel.org
Subject: Re: [linux-sunxi] [PATCH 0/3] Add basic support for RTC on Allwinner
 H6 SoC

On Fri, Aug 09, 2019 at 01:39:30AM +0200, Alexandre Belloni wrote:
> On 08/08/2019 14:12:37+0200, Ondřej Jirman wrote:
> > On Wed, Aug 07, 2019 at 12:55:02PM +0200, Alexandre Belloni wrote:
> > > Hi,
> > > 
> > > On 06/08/2019 20:30:45+0200, Ondřej Jirman wrote:
> > > > Maybe whether XO or DCXO is used also matters if you want to do some fine
> > > > tunning of DCXO (control register has pletny of options), but that's probably
> > > > better done in u-boot. And there's still no need to read HOSC source from DT.
> > > > The driver can just check compatible, and if it is H6 and OSC_CLK_SRC_SEL is 1,
> > > > it can do it's DCXO tunning, or whatever. But neither OS nor bootloader will
> > > > be using this info to gate/disable the osciallator.
> > > > 
> > > 
> > > It is actually useful to be able to tweak the crystal tuning at
> > > runtime to be able to reduce clock drift and compare with a reliable
> > > source (e.g. NTP).
> > 
> > I don't think there's a Linux kernel API that you can use to achieve that, so
> > that's a rather theoretical concern at the moment.
> > 
> 
> There is /sys/class/rtc/rtcX/offset which is even properly documented.
> 
> The reason I asked is that some RTCs have both analog (changing the
> oscillator capacitance) and digital (changing the RTC counter) so I'm
> wondering whether this interface should be extended.

As I wrote below, that can't be achieved by tuning DCXO.

> > Also there are multiple clocks, that can drive the RTC, and you usually don't
> > drive it from 24MHz DCXO oscillator. The reason is that you'd have to deal with
> > the fact that the clock for RTC then becomes 24000000/750 (750 is fixed
> > divider), which is 32000.
> > 
> > So if you want to get 32768Hz for RTC by tuning the DCXO, it would have to have
> > 24 576 000 Hz. And even if you could achieve that (doubtful), it would throw off
> > timings in the rest of the system (say UART, USB, CPU, display ctl) in a major way.
> > 
> > I guess you can try tuning 24MHz oscillator so that it's closer to the
> > real-world 24MHz via NTP reference for other reasons. But it would be
> > complicated, and require precise interaction with other components, like using
> > HW timers sourced from 24MHz HOSC clock, because you can't use CPU's timers,
> > because of inaccuracies introduced during DVFS, for example.
> > 
> > regards,
> > 	o.
> > 
> > > I'm curious, what kind of options does this RTC have?
> > > 
> > > -- 
> > > Alexandre Belloni, Bootlin
> > > Embedded Linux and Kernel engineering
> > > https://bootlin.com
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@...ts.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> -- 
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists