public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: maxime.ripard@free-electrons.com (Maxime Ripard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] rtc: sun6i: Switch to the external oscillator
Date: Mon, 16 Jan 2017 17:13:49 +0100	[thread overview]
Message-ID: <20170116161349.5btadrfmqbxhrb2c@lukather> (raw)
In-Reply-To: <20170116153959.7qhahevikxzai664@piout.net>

Hi,

On Mon, Jan 16, 2017 at 04:39:59PM +0100, Alexandre Belloni wrote:
> On 16/01/2017 at 16:21:48 +0100, Maxime Ripard wrote :
> > The RTC is clocked from either an internal, imprecise, oscillator or an
> > external one, which is usually much more accurate.
> > 
> > The difference perceived between the time elapsed and the time reported by
> > the RTC is in a 10% scale, which prevents the RTC from being useful at all.
> > 
> > Fortunately, the external oscillator is reported to be mandatory in the
> > Allwinner datasheet, so we can just switch to it.
> > 
> 
> Still, I'm wondering whether the external clock should be taken.
> 
> We've had issues with at91 and tegra where this external clock was
> suddenly able to be stopped, breaking the RTC because the CCF was not
> aware the RTC was using it.

That's a very good point...

> See:
> http://patchwork.ozlabs.org/patch/502459/
> http://patchwork.ozlabs.org/patch/714517/
> 
> Your reply can be that you don't care now and this has a low probability
> and you'll handle the case when it happens and that will be fine.

This is a bit more complicated for us.

The internal oscillator is running at 667kHz, with a 30% accuracy. The
external oscillator is supposed to run at 32768Hz, with a maximum
tolerance of 50ppm.

The RTC has an internal mux, between the internal and external
oscillators. If the internal is picked, a (variable) divider of 20 is
applied by default.

The output of that mux is also one of the parent of many of our clocks
in our main clock unit (for example the CPU one), so we need to have
that parenthood relationship expressed. I guess we could rework the
driver to first register the clock through the early clock probing
stuff, and then have the rest of the RTC to probe.

However, we also need to do so while remaining backward compatible
from a DT point of view.

I guess we could:
  - Add the two oscillators to the DTSI, with their proper accuracy
  - Put them both as parent clocks of the RTC node
  - Split the clock part and the RTC part in the driver, and have the
    clock part, if there is a clocks property in the node (which
    covers the backward case), register the mux, and pick the clock
    with the best accuracy. We don't change anything at the RTC level.
  - Change the parent clock of the CCU for the RTC.

That would work for you?
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170116/75818342/attachment.sig>

  reply	other threads:[~2017-01-16 16:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16 15:21 [PATCH] rtc: sun6i: Switch to the external oscillator Maxime Ripard
2017-01-16 15:39 ` Alexandre Belloni
2017-01-16 16:13   ` Maxime Ripard [this message]
2017-01-16 17:40     ` Alexandre Belloni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170116161349.5btadrfmqbxhrb2c@lukather \
    --to=maxime.ripard@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox