Re: [PATCH 1/4] dt-bindings: rtc: add schema for NXP S32G2/S32G3 SoCs

From: Ciprian Marian Costea
Date: Thu Sep 12 2024 - 09:04:23 EST

On 9/12/2024 2:27 PM, Conor Dooley wrote:
On Thu, Sep 12, 2024 at 01:50:25PM +0300, Ciprian Marian Costea wrote:
On 9/11/2024 9:21 PM, Conor Dooley wrote:
On Wed, Sep 11, 2024 at 10:00:25AM +0300, Ciprian Costea wrote:
From: Ciprian Marian Costea <ciprianmarian.costea@xxxxxxxxxxx>

+ nxp,clksel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Input clock selector. Choose between 0-SIRC and 2-FIRC.
+ The reason for these IDs not being consecutive is because
+ they are hardware coupled.
+ enum:
+ - 0 # SIRC
+ - 2 # FIRC

Could you please explain why, given both clocks must be provided by
the hardware for there to be a choice, why choosing between them is a
property of the hardware?



According to RTC module's clocking scheme for S32G2/S32G3 SoCs, it has three
potential clock sources to select between:
1. FIRC:
- fast clock - ~48 MHz output
- chosen by default because it is proven to be more reliable (e.g:
temperature drift).
2. SIRC:
- slow clock - ~32 kHz output
- When in Standby mode, SIRC_CLK is the only available clock for RTC.
This is important because RTC module is used as a wakeup source from Suspend
to RAM on S32G2/S32G3 SoC. Therefore, a temporary switch to SIRC clock is
performed when entering Suspend to RAM.

3. EXT_CLK:
- has not been tested/validated for those SoCs within NXP's downstream
Linux. Therefore, I did not treat it, nor mention it, for the moment.

Now to answer your question, all above clocks are entering a RTCC[CLKSEL]
(RTCC - RTC Control Register) mux. Therefore, a selection can be made,
according to one's needs.

Given both clocks must be provided, what is the benefit of using the
slow clock outside of standby mode? Why would someone not just always
use the fast clock outside of standby and slow in standby?


Hello Conor,

I cannot find any benefit of using the slow clock outside of standby mode. Hence, I see the reasons for removing CLKSEL support and defaulting to a static configuration.

On the other hand, having the CLKSEL mux support implemented and available would help if RTC external clock would want to be added, as the RTC hardware module supports it.

I will add a shorter version of above information in the bindings
documentation in the V2 of this patchset.

+
+ nxp,dividers:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ An array of two u32 elements, the former encoding DIV512,
+ the latter encoding DIV32. These are dividers that can be enabled
+ individually, or cascaded. Use 0 to disable the respective divider,
+ and 1 to enable it.

Please explain to me what makes this a property of the hardware and how
someone would go about choosing the divider settings for their hardware.


As per hardware RTC module clocking scheme, the output of the clock mux can
be optionally divided by a combination of 512 and 32 (via other two input
cascaded muxes) to give various count periods for different clock sources.

With respect to choosing the divider settings for custom hardware, it

What do you mean by "custom" hardware? I assume that you mean on a per
board basis?

Indeed, I was considering the same S32G2 or S32G3 SoC but on different boards/different scenarios. I just wanted to expose the ability to reach lower frequencies by using those available hardware divisors.


depends on the clock source being selected and the desired rollover time.
For example, on S32G2 or S32G3 SoC based boards, using FIRC (~48-51 MHz)
with DIV512 enabled results in a rollover time of aprox. 13 hours.

So a different user of the same board might want a different rollover
time? If so, this doesn't really seem like something that should be
controlled from devicetree.

Cheers,
Conor.

I understand your point, indeed it does not seem to fit the devicetree, but maybe exposing them via sysfs would be a better approach. I will remove these bindings for now and consider an alternative, in V2 of this patchset.


Regards,
Ciprian