clkout vs. !int1 on nxp pcf8523

clkout vs. !int1 on nxp pcf8523

[Alexander Dahl]

Hei hei,

my current task is to bring up a new board featuring an at91 sam9x60
SoC and a nxp pcf8523 RTC.  The intention is to get a longer time the
RTC can run on a capacitor because the external RTC draws less current
than the internal RTC of the SoC.

To save boards space and parts the 32768 Hz crystal of the SoC should
be removed and the clkout of the external RTC should be used as a slow
clock input instead.

This is a somewhat known setup, at least I found other drivers
implementing it for certain boards, see commits
v5.15-rc1-16-g4c8a7b80d5f3 ("rtc: pcf85063: add support for fixed
clock") or v5.13-rc1-2-gf765e349c3e1 ("rtc: m41t80: add support for
fixed clock") for reference.

Problem with the pcf8523: it has a shared !INT1 / CLKOUT pin, and you
probably can use only either one or the other function.  Default after
reset is to have CLKOUT providing 32768 Hz, proved that with an
oscilloscope.

The naive way to add support is to just add a node to the dts and
cross fingers like this:

    &flx5 {
            atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
            status = "okay";
    
            i2c5: i2c@600 {
                    pinctrl-0 = <&pinctrl_flx5_default>;
                    status = "okay";
    
                    pcf8523: rtc@68 {
                            compatible = "nxp,pcf8523";
                            reg = <0x68>;
                    };
            };
    };

This actually works, but I suspect this is fragile, because it does
not describe the clock I want to use, nor how to handle the irq.

I noticed commit v5.12-rc2-22-g13e37b7fb75d ("rtc: pcf8523: add alarm
support") and the commit message somehow suggests clkout is always
disabled now?  Well not always, only if some irq was defined in … but
where exactly?  In my setup the clkout is not disabled, I confirmed
that with a scope.

This is where all kinds of questions rise.  The documentation on rtc
and i2c device tree bindings is somewhat sparse.  :-/

From my understanding if I wanted to use the !INT1 pin as an actual
interrupt line, I would probably hook it up to either a GPIO of the
SoC or some wakeup input of the PMIC.  What else is possible and how
would the different ways be expressed in .dts?  I found some .dts and
.dtsi files having an 'interrupts' property in the rtc node, but I did
not find the place in the code where this gets evaluated.

For clkout it is probably like in
arch/arm64/boot/dts/freescale/imx8mq-tqma8mq.dtsi and the driver
changes would be maybe somewhat similar to the changes done in
drivers/rtc/rtc-pcf85063.c right?

Any hints on how to express in dts to _explicitly_ disable use as an
interrupt pin and explicitly as fixed clkout?  And what changes to the
pcf8523 driver would have to be done, if any?

Greets
Alex

Re: clkout vs. !int1 on nxp pcf8523

[Alexandre Belloni]

On 30/05/2024 15:33:11+0200, Alexander Dahl wrote:
> Hei hei,
> 
> my current task is to bring up a new board featuring an at91 sam9x60
> SoC and a nxp pcf8523 RTC.  The intention is to get a longer time the
> RTC can run on a capacitor because the external RTC draws less current
> than the internal RTC of the SoC.
> 
> To save boards space and parts the 32768 Hz crystal of the SoC should
> be removed and the clkout of the external RTC should be used as a slow
> clock input instead.
> 
> This is a somewhat known setup, at least I found other drivers
> implementing it for certain boards, see commits
> v5.15-rc1-16-g4c8a7b80d5f3 ("rtc: pcf85063: add support for fixed
> clock") or v5.13-rc1-2-gf765e349c3e1 ("rtc: m41t80: add support for
> fixed clock") for reference.
> 
> Problem with the pcf8523: it has a shared !INT1 / CLKOUT pin, and you
> probably can use only either one or the other function.  Default after
> reset is to have CLKOUT providing 32768 Hz, proved that with an
> oscilloscope.
> 
> The naive way to add support is to just add a node to the dts and
> cross fingers like this:
> 
>     &flx5 {
>             atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
>             status = "okay";
>     
>             i2c5: i2c@600 {
>                     pinctrl-0 = <&pinctrl_flx5_default>;
>                     status = "okay";
>     
>                     pcf8523: rtc@68 {
>                             compatible = "nxp,pcf8523";
>                             reg = <0x68>;
>                     };
>             };
>     };
> 
> This actually works, but I suspect this is fragile, because it does
> not describe the clock I want to use, nor how to handle the irq.
> 
> I noticed commit v5.12-rc2-22-g13e37b7fb75d ("rtc: pcf8523: add alarm
> support") and the commit message somehow suggests clkout is always
> disabled now?  Well not always, only if some irq was defined in … but
> where exactly?  In my setup the clkout is not disabled, I confirmed
> that with a scope.
> 
> This is where all kinds of questions rise.  The documentation on rtc
> and i2c device tree bindings is somewhat sparse.  :-/
> 
> From my understanding if I wanted to use the !INT1 pin as an actual
> interrupt line, I would probably hook it up to either a GPIO of the
> SoC or some wakeup input of the PMIC.  What else is possible and how
> would the different ways be expressed in .dts?  I found some .dts and
> .dtsi files having an 'interrupts' property in the rtc node, but I did
> not find the place in the code where this gets evaluated.
> 
> For clkout it is probably like in
> arch/arm64/boot/dts/freescale/imx8mq-tqma8mq.dtsi and the driver
> changes would be maybe somewhat similar to the changes done in
> drivers/rtc/rtc-pcf85063.c right?
> 
> Any hints on how to express in dts to _explicitly_ disable use as an
> interrupt pin and explicitly as fixed clkout?  And what changes to the
> pcf8523 driver would have to be done, if any?

I see this email just now. Ideally, we would get a pinmuxing part in the
RTC driver so the device tree can explicitly describe which function is
used. Also, as you point out, this also needs a clock driver part so we
benefit from the CCF for clock enabling and recounting.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: clkout vs. !int1 on nxp pcf8523

[Alexander Dahl]

Hello Alexandre,

Am Wed, Sep 11, 2024 at 02:18:49PM +0200 schrieb Alexandre Belloni:
> On 30/05/2024 15:33:11+0200, Alexander Dahl wrote:
> > Hei hei,
> > 
> > my current task is to bring up a new board featuring an at91 sam9x60
> > SoC and a nxp pcf8523 RTC.  The intention is to get a longer time the
> > RTC can run on a capacitor because the external RTC draws less current
> > than the internal RTC of the SoC.
> > 
> > To save boards space and parts the 32768 Hz crystal of the SoC should
> > be removed and the clkout of the external RTC should be used as a slow
> > clock input instead.
> > 
> > This is a somewhat known setup, at least I found other drivers
> > implementing it for certain boards, see commits
> > v5.15-rc1-16-g4c8a7b80d5f3 ("rtc: pcf85063: add support for fixed
> > clock") or v5.13-rc1-2-gf765e349c3e1 ("rtc: m41t80: add support for
> > fixed clock") for reference.
> > 
> > Problem with the pcf8523: it has a shared !INT1 / CLKOUT pin, and you
> > probably can use only either one or the other function.  Default after
> > reset is to have CLKOUT providing 32768 Hz, proved that with an
> > oscilloscope.
> > 
> > The naive way to add support is to just add a node to the dts and
> > cross fingers like this:
> > 
> >     &flx5 {
> >             atmel,flexcom-mode = <ATMEL_FLEXCOM_MODE_TWI>;
> >             status = "okay";
> >     
> >             i2c5: i2c@600 {
> >                     pinctrl-0 = <&pinctrl_flx5_default>;
> >                     status = "okay";
> >     
> >                     pcf8523: rtc@68 {
> >                             compatible = "nxp,pcf8523";
> >                             reg = <0x68>;
> >                     };
> >             };
> >     };
> > 
> > This actually works, but I suspect this is fragile, because it does
> > not describe the clock I want to use, nor how to handle the irq.
> > 
> > I noticed commit v5.12-rc2-22-g13e37b7fb75d ("rtc: pcf8523: add alarm
> > support") and the commit message somehow suggests clkout is always
> > disabled now?  Well not always, only if some irq was defined in … but
> > where exactly?  In my setup the clkout is not disabled, I confirmed
> > that with a scope.
> > 
> > This is where all kinds of questions rise.  The documentation on rtc
> > and i2c device tree bindings is somewhat sparse.  :-/
> > 
> > From my understanding if I wanted to use the !INT1 pin as an actual
> > interrupt line, I would probably hook it up to either a GPIO of the
> > SoC or some wakeup input of the PMIC.  What else is possible and how
> > would the different ways be expressed in .dts?  I found some .dts and
> > .dtsi files having an 'interrupts' property in the rtc node, but I did
> > not find the place in the code where this gets evaluated.
> > 
> > For clkout it is probably like in
> > arch/arm64/boot/dts/freescale/imx8mq-tqma8mq.dtsi and the driver
> > changes would be maybe somewhat similar to the changes done in
> > drivers/rtc/rtc-pcf85063.c right?
> > 
> > Any hints on how to express in dts to _explicitly_ disable use as an
> > interrupt pin and explicitly as fixed clkout?  And what changes to the
> > pcf8523 driver would have to be done, if any?
> 
> I see this email just now. Ideally, we would get a pinmuxing part in the
> RTC driver so the device tree can explicitly describe which function is
> used. Also, as you point out, this also needs a clock driver part so we
> benefit from the CCF for clock enabling and recounting.

Thanks for taking the time to respond.  Meanwhile we conducted some
measurements of the time the RTC can keep its value, aka how long the
capacitor can supply it.  Compared internal RTC to external, and came
to the conclusion the longer support time of the external RTC is still
not long enough for a meaningful usecase.  So we dropped that approach
and use the internal RTC of the microcontroller now.

But as said, thanks for responding, if someone else needs to go that
way, the direction from driver pov is clearer now. :-)

Greets
Alex