On Thu, Aug 19, 2021 at 10:06:43PM -0500, Samuel Holland wrote:
> On 8/18/21 9:32 PM, Samuel Holland wrote:
> > On 8/18/21 4:15 AM, Icenowy Zheng wrote:
> >> 于 2021年8月18日 GMT+08:00 下午5:01:39, Maxime Ripard <maxime@xxxxxxxxxx> 写到:
> >>> On Mon, Aug 02, 2021 at 02:22:10PM +0800, Icenowy Zheng wrote:
> >>>> + ccu: clock@2001000 {
> >>>> + compatible = "allwinner,sun50i-r329-ccu";
> >>>> + reg = <0x02001000 0x1000>;
> >>>> + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
> >>>> + clock-names = "hosc", "losc", "iosc";
> >>>
> >>> Do we have a clock tree for the RTC? Is it the same than the H616?
> >>
> >> Nope, it's the same with H6 because of external LOSC crystal is
> >> possible. (Although production M2A SoMs has it NC for cost control.)
> >
> > It is not the same as the H6, either. The clock tree _is_ identical to the D1,
> > which has three diagrams on pages 363-364 of its user manual here:
> >
> > https://dl.linux-sunxi.org/D1/D1_User_Manual_V0.1_Draft_Version.pdf
> >
> > Compared to the H6, the R329/D1:
> > - Loses the LOSC calibration circuit
> > - Gains a third mux input for LOSC (not external 32k) to fanout
> > - Gains a mux to choose between LOSC and HOSC/750 for the RTC clock
> > - Gains an SPI bus clock input divided from the PRCM AHB
> >
> > Compared to the H616, the R329/D1:
> > - Has an external 32k crystal input
> > - Gains the IOSC vs. external 32k crystal mux for LOSC
> > - Switches fanout mux input #1 from pll_periph0/N to external 32k
> > - Gains a mux to choose between LOSC and HOSC/750 for the RTC clock
> > - Gains an SPI bus clock input divided from the PRCM AHB
> >
> > So the R329/D1 RTC has three^Wfour inputs:
> > - SPI clock from PRCM
> > - 24 MHz DCXO crystal
> > - 32 kHz external crystal (optional)
>
> Whoops, I missed one here:
> - Bus clock from PRCM
>
> The SPI clock is new for R329, but the bus clock has been around since H6.
>
> > and four outputs:
> > - 16 MHz "IOSC" RC oscillator
> > - 32 kHz "LOSC"
> > - ~1 kHz for RTC timekeeping
>
> Even though this is internal to the RTC, it is still useful to model, as it can
> be used to correct for known RTC drift. (For example, HOSC/750 is 32000 Hz
> instead of 32768 Hz, so 2.34375% slow. But that is better than IOSC, which has
> unknown error.)
If it's not useful to any other device, there's no real reason to model
it in the clock framework. We should still force the source of the RTC
to the most accurate option we have, but we can do that without the CCF.
Maxime
Attachment:
signature.asc
Description: PGP signature
