devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Dahl <ada@thorsis.com>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-clk@vger.kernel.org, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	Codrin Ciubotariu <codrin.ciubotariu@microchip.com>,
	Sandeep Sheriker Mallikarjun
	<sandeepsheriker.mallikarjun@microchip.com>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Tudor Ambarus <tudor.ambarus@linaro.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks
Date: Thu, 22 Aug 2024 12:25:26 +0200	[thread overview]
Message-ID: <20240822-mute-ruby-fc8c86240f3c@thorsis.com> (raw)
In-Reply-To: <20240822081746db0ce2bb@mail.local>

Hello Alexandre,

Am Thu, Aug 22, 2024 at 10:17:46AM +0200 schrieb Alexandre Belloni:
> On 22/08/2024 08:53:59+0200, Alexander Dahl wrote:
> > Hello Alexandre,
> > 
> > Am Thu, Aug 22, 2024 at 01:52:05AM +0200 schrieb Alexandre Belloni:
> > > On 21/08/2024 07:51:36+0200, Alexander Dahl wrote:
> > > > The RTC and RTT peripherals use the "timing domain slow clock (TD_SLCK),
> > > > sourced from the 32.768 kHz crystal oscillator.
> > > > 
> > > > (The previously used Monitoring domain slow clock (MD_SLCK) is sourced
> > > > from an internal RC oscillator which is most probably not precise enough
> > > > for real time clock purposes.)
> > > > 
> > > > Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board")
> > > > Fixes: 5f6b33f46346 ("ARM: dts: sam9x60: add rtt")
> > > > Signed-off-by: Alexander Dahl <ada@thorsis.com>
> > > > ---
> > > > 
> > > > Notes:
> > > >     Picked the wrong patch in the first try.  This v2 one has a slightly
> > > >     adapted commit message and more context below.
> > > >     
> > > >     This obviously requires a 32.768 kHz crystal oscillator to be present,
> > > >     but the sam9x60.dtsi does contain that, and the clock-controllers
> > > >     reference that, so I assume it's always present.
> > > 
> > > The crystal is optional so this is going to break the boards that don't
> > > have one. I don't really mind but this should probably be part of the
> > > commit message.
> > 
> > Okay right, according to the datasheet (Figure 27.1 SCKC Block
> > Diagram) you don't need that crystal, you can clear TD_OSCSEL and
> > td_slck runs from the internal rc then.  However, td_slck is always
> > present, it either sources from the internal slow rc oscillator or the
> > crystal oscillator.  And the datasheet says in section 29.1 (PMC):
> > 
> >     "The Slow Clock Controller (SCKC) selects the source of TD_SLCK
> >     (drives the real-time part (RTT/RTC)).  The source of MD_SLCK
> >     (drives the rest of the system controller: wake-up logic,
> >     watchdog, PMC, etc.) is always the slow RC oscillator."
> > 
> > md_slck and td_slck are both registered by the at91 sckc driver, and
> > the td_slck gets two parents in of_sam9x60_sckc_setup() when
> > registered by at91_clk_register_sam9x5_slow().  The parent can be
> > switched by clk_sam9x5_slow_set_parent() from sam9x5_slow_ops then,
> > correctly setting the OSCSEL bit.
> > 
> > The whole idea of the patch is giving the rtc/rtt td_slck as a parent
> > as documented in the datasheet.  I don't see how this should be
> > affected by the parents of td_slck?  Am I missing something?
> > 
> 
> You are right, I got confused because you were referring t the 32768 Hz
> crystal in your commit message and though you aimed at selected the
> parent of td_slck (and also, I didn't really work on the sam9x60).

Thanks for confirming.

Should I reword the commit message then to make it easier to
understand?

> > > This makes me realise that we always assumed the RC oscillator was
> > > running at 32768 while the sam9x60 datasheet refers to it has a 32kHz
> > > oscillator. However the RTC only has a 32768 divider...
> > 
> > When sourced from the internal rc oscillator, this would mean the
> > output would be incorrect, right?  How could one prove this?
> 
> 
> I guess you could have a look at how the RTC is drifting when selecting
> the RC osc as the parent but it will anyway be way less precise than the
> crystal so i'm not sure how you could get a conclusive result.

I would have to look deeper into rtc for that.
Maybe in a calm minute. ;-)

Greets
Alex

> 
> > 
> > Greets
> > Alex
> > 
> > > 
> > > >     
> > > >     /sys/kernel/debug/clk/clk_summary content excerpt before:
> > > >     
> > > >          slow_rc_osc                         1       1        0        32768       93750000   0     50000      Y   deviceless                      no_connection_id
> > > >             md_slck                          4       4        0        32768       0          0     50000      Y      fffffea8.rtc                    no_connection_id
> > > >                                                                                                                       fffffe20.rtc                    no_connection_id
> > > >                                                                                                                       fffffe10.poweroff               no_connection_id
> > > >                                                                                                                       fffffe00.reset-controller       no_connection_id
> > > >                                                                                                                       timer@f8008000                  slow_clk
> > > >                                                                                                                       deviceless                      no_connection_id
> > > >     …
> > > >          slow_xtal                           0       0        0        32768       0          0     50000      Y   deviceless                      no_connection_id
> > > >             slow_osc                         0       0        0        32768       0          0     50000      Y      deviceless                      no_connection_id
> > > >                td_slck                       0       0        0        32768       0          0     50000      Y         deviceless                      no_connection_id
> > > >     
> > > >     And after:
> > > >     
> > > >          slow_rc_osc                         1       1        0        32768       93750000   0     50000      Y   deviceless                      no_connection_id
> > > >             md_slck                          2       2        0        32768       0          0     50000      Y      fffffe10.poweroff               no_connection_id
> > > >                                                                                                                       fffffe00.reset-controller       no_connection_id
> > > >                                                                                                                       timer@f8008000                  slow_clk
> > > >                                                                                                                       deviceless                      no_connection_id
> > > >     …
> > > >          slow_xtal                           1       1        0        32768       0          0     50000      Y   deviceless                      no_connection_id
> > > >             slow_osc                         1       1        0        32768       0          0     50000      Y      deviceless                      no_connection_id
> > > >                td_slck                       2       2        0        32768       0          0     50000      Y         fffffea8.rtc                    no_connection_id
> > > >                                                                                                                          fffffe20.rtc                    no_connection_id
> > > >                                                                                                                          deviceless                      no_connection_id
> > > > 
> > > >  arch/arm/boot/dts/microchip/sam9x60.dtsi | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/boot/dts/microchip/sam9x60.dtsi b/arch/arm/boot/dts/microchip/sam9x60.dtsi
> > > > index 291540e5d81e..d077afd5024d 100644
> > > > --- a/arch/arm/boot/dts/microchip/sam9x60.dtsi
> > > > +++ b/arch/arm/boot/dts/microchip/sam9x60.dtsi
> > > > @@ -1312,7 +1312,7 @@ rtt: rtc@fffffe20 {
> > > >  				compatible = "microchip,sam9x60-rtt", "atmel,at91sam9260-rtt";
> > > >  				reg = <0xfffffe20 0x20>;
> > > >  				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
> > > > -				clocks = <&clk32k 0>;
> > > > +				clocks = <&clk32k 1>;
> > > >  			};
> > > >  
> > > >  			pit: timer@fffffe40 {
> > > > @@ -1338,7 +1338,7 @@ rtc: rtc@fffffea8 {
> > > >  				compatible = "microchip,sam9x60-rtc", "atmel,at91sam9x5-rtc";
> > > >  				reg = <0xfffffea8 0x100>;
> > > >  				interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
> > > > -				clocks = <&clk32k 0>;
> > > > +				clocks = <&clk32k 1>;
> > > >  			};
> > > >  
> > > >  			watchdog: watchdog@ffffff80 {
> > > > 
> > > > base-commit: 47ac09b91befbb6a235ab620c32af719f8208399
> > > > -- 
> > > > 2.39.2
> > > > 
> > > 
> > > -- 
> > > Alexandre Belloni, co-owner and COO, Bootlin
> > > Embedded Linux and Kernel engineering
> > > https://bootlin.com
> 
> -- 
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 

  reply	other threads:[~2024-08-22 10:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-20 13:27 [PATCH] ARM: dts: microchip: sam9x60: Fix rtc/rtt clock parent Alexander Dahl
2024-08-21  5:51 ` [PATCH v2] ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks Alexander Dahl
2024-08-21 23:52   ` Alexandre Belloni
2024-08-22  6:53     ` Alexander Dahl
2024-08-22  8:17       ` Alexandre Belloni
2024-08-22 10:25         ` Alexander Dahl [this message]
2024-08-24 17:28   ` claudiu beznea

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=20240822-mute-ruby-fc8c86240f3c@thorsis.com \
    --to=ada@thorsis.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=codrin.ciubotariu@microchip.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=robh@kernel.org \
    --cc=sandeepsheriker.mallikarjun@microchip.com \
    --cc=tudor.ambarus@linaro.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;
as well as URLs for NNTP newsgroup(s).