Some RTC devices have a battery-low automatic detection circuit.
The battery-low event is usually reported with:
- a bit change in a RTC status register
- a hw signaling (generally using an interrupt generation), changing
the hw level of a specific pin;
The new property "battery-low-hw-alarm" enable the RTC to generate the
hw signaling in case of battery-low event.
Signed-off-by: Flavio Suligoi <[email protected]>
---
Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt b/Documentation/devicetree/bindings/rtc/rtc.txt
index a97fc6a..f93a44d 100644
--- a/Documentation/devicetree/bindings/rtc/rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc.txt
@@ -31,6 +31,9 @@ below.
expressed in femto Farad (fF).
The default value shall be listed (if optional),
and likewise all valid values.
+- battery-low-hw-alarm : Enable the "battery-low" output pin. This function
+ is available on the following devices:
+ - pcf2127 - pin used for alarm: INTn
Trivial RTCs
------------
--
2.7.4
The pcf2127 has an automatic battery-low detection function.
In case of battery-low event, an interrupt generation through
the pin INTn (active low) can be enabled, setting the flag BLIE
in the register Control_3.
This function is activated by the "battery-low-hw-alarm" DT property.
Example of use for an NXP i.MX7D board:
&i2c3 {
clock-frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
pcf2127@51 {
compatible = "nxp,pcf2127";
reg = <0x51>;
battery-low-hw-alarm;
status = "okay";
};
};
Signed-off-by: Flavio Suligoi <[email protected]>
---
drivers/rtc/rtc-pcf2127.c | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index 7cb786d..e3805c8 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -228,6 +228,10 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
const char *name, bool has_nvmem)
{
struct pcf2127 *pcf2127;
+ struct device_node *np;
+ struct i2c_client *client = to_i2c_client(dev);
+ unsigned char buf[2];
+ int err;
int ret = 0;
dev_dbg(dev, "%s\n", __func__);
@@ -245,6 +249,35 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
if (IS_ERR(pcf2127->rtc))
return PTR_ERR(pcf2127->rtc);
+ /*
+ * The pcf2127 has an automatic battery-low detection function.
+ *
+ * In case of battery-low event, an interrupt generation through
+ * the pin INTn (active low) can be enabled, setting the flag BLIE
+ * in the register Control_3.
+ */
+ np = of_node_get(dev->of_node);
+ if (!np) {
+ dev_err(dev, "failed to find the RTC pcf2127 node\n");
+ return -ENOENT;
+ }
+ if (of_get_property(np, "battery-low-hw-alarm", NULL)) {
+ dev_info(dev, "enable battery-low hw alarm on INTn pin\n");
+
+ /*
+ * Set BLIE bit in register Control_3 (override is possible
+ * because this register is fully zero after reset)
+ */
+ buf[0] = PCF2127_REG_CTRL3;
+ buf[1] = 0x01;
+ /* write register's data */
+ err = i2c_master_send(client, buf, 2);
+ if (err != 2) {
+ dev_err(dev, "%s: err=%d", __func__, err);
+ return -EIO;
+ }
+ }
+
if (has_nvmem) {
struct nvmem_config nvmem_cfg = {
.priv = pcf2127,
--
2.7.4
Hi,
On 03/04/2019 16:52:44+0200, Flavio Suligoi wrote:
> Some RTC devices have a battery-low automatic detection circuit.
> The battery-low event is usually reported with:
>
> - a bit change in a RTC status register
> - a hw signaling (generally using an interrupt generation), changing
> the hw level of a specific pin;
>
> The new property "battery-low-hw-alarm" enable the RTC to generate the
> hw signaling in case of battery-low event.
>
> Signed-off-by: Flavio Suligoi <[email protected]>
> ---
> Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt b/Documentation/devicetree/bindings/rtc/rtc.txt
> index a97fc6a..f93a44d 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> @@ -31,6 +31,9 @@ below.
> expressed in femto Farad (fF).
> The default value shall be listed (if optional),
> and likewise all valid values.
> +- battery-low-hw-alarm : Enable the "battery-low" output pin. This function
I would name that voltage-low-alarm as not all the secondary voltages
are batteries.
> + is available on the following devices:
> + - pcf2127 - pin used for alarm: INTn
>
> Trivial RTCs
> ------------
> --
> 2.7.4
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Alexandre,
> Hi,
>
> On 03/04/2019 16:52:44+0200, Flavio Suligoi wrote:
> > Some RTC devices have a battery-low automatic detection circuit.
> > The battery-low event is usually reported with:
> >
> > - a bit change in a RTC status register
> > - a hw signaling (generally using an interrupt generation), changing
> > the hw level of a specific pin;
> >
> > The new property "battery-low-hw-alarm" enable the RTC to generate the
> > hw signaling in case of battery-low event.
> >
> > Signed-off-by: Flavio Suligoi <[email protected]>
> > ---
> > Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt
> b/Documentation/devicetree/bindings/rtc/rtc.txt
> > index a97fc6a..f93a44d 100644
> > --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> > @@ -31,6 +31,9 @@ below.
> > expressed in femto Farad (fF).
> > The default value shall be listed (if
> optional),
> > and likewise all valid values.
> > +- battery-low-hw-alarm : Enable the "battery-low" output pin. This
> function
>
> I would name that voltage-low-alarm as not all the secondary voltages
> are batteries.
You have right. So we can also name the property a: "voltage-low-hw-alarm".
I prefer to have the word "hw" in the property name, since the "sw" voltage
low alarm is already present is some RTC drivers.
In this way, with the word "hw", is more clear that we are speaking about
an hw pin signaling.
>
> > + is available on the following devices:
> > + - pcf2127 - pin used for alarm: INTn
> >
> > Trivial RTCs
> > ------------
> > --
> > 2.7.4
> >
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Thanks,
Flavio Suligoi
On 03/04/2019 16:52:45+0200, Flavio Suligoi wrote:
> The pcf2127 has an automatic battery-low detection function.
>
> In case of battery-low event, an interrupt generation through
> the pin INTn (active low) can be enabled, setting the flag BLIE
> in the register Control_3.
>
> This function is activated by the "battery-low-hw-alarm" DT property.
>
> Example of use for an NXP i.MX7D board:
>
> &i2c3 {
> clock-frequency = <100000>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_i2c3>;
> status = "okay";
>
> pcf2127@51 {
> compatible = "nxp,pcf2127";
> reg = <0x51>;
> battery-low-hw-alarm;
> status = "okay";
> };
> };
>
So I'm curious, how do you then use that signal? I have a (not yet sent)
series adding alarm support for the pcf2127. The issue having BLIE is
that then this will prevent the alarm to work properly.
So my guess is that you have nINT connected to an LED or something that
the user can see?
> Signed-off-by: Flavio Suligoi <[email protected]>
> ---
> drivers/rtc/rtc-pcf2127.c | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
> index 7cb786d..e3805c8 100644
> --- a/drivers/rtc/rtc-pcf2127.c
> +++ b/drivers/rtc/rtc-pcf2127.c
> @@ -228,6 +228,10 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
> const char *name, bool has_nvmem)
> {
> struct pcf2127 *pcf2127;
> + struct device_node *np;
> + struct i2c_client *client = to_i2c_client(dev);
> + unsigned char buf[2];
> + int err;
> int ret = 0;
>
> dev_dbg(dev, "%s\n", __func__);
> @@ -245,6 +249,35 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
> if (IS_ERR(pcf2127->rtc))
> return PTR_ERR(pcf2127->rtc);
>
> + /*
> + * The pcf2127 has an automatic battery-low detection function.
> + *
> + * In case of battery-low event, an interrupt generation through
> + * the pin INTn (active low) can be enabled, setting the flag BLIE
> + * in the register Control_3.
> + */
> + np = of_node_get(dev->of_node);
> + if (!np) {
> + dev_err(dev, "failed to find the RTC pcf2127 node\n");
> + return -ENOENT;
> + }
> + if (of_get_property(np, "battery-low-hw-alarm", NULL)) {
> + dev_info(dev, "enable battery-low hw alarm on INTn pin\n");
> +
> + /*
> + * Set BLIE bit in register Control_3 (override is possible
> + * because this register is fully zero after reset)
> + */
> + buf[0] = PCF2127_REG_CTRL3;
> + buf[1] = 0x01;
> + /* write register's data */
> + err = i2c_master_send(client, buf, 2);
This has to use regmap_update_bits because this also has to work on spi.
(I don't know where you get the client pointer from anyway).
> + if (err != 2) {
> + dev_err(dev, "%s: err=%d", __func__, err);
> + return -EIO;
> + }
> + }
> +
> if (has_nvmem) {
> struct nvmem_config nvmem_cfg = {
> .priv = pcf2127,
> --
> 2.7.4
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Alexandre,
> On 03/04/2019 16:52:45+0200, Flavio Suligoi wrote:
> > The pcf2127 has an automatic battery-low detection function.
> >
> > In case of battery-low event, an interrupt generation through
> > the pin INTn (active low) can be enabled, setting the flag BLIE
> > in the register Control_3.
> >
> > This function is activated by the "battery-low-hw-alarm" DT property.
> >
> > Example of use for an NXP i.MX7D board:
> >
> > &i2c3 {
> > clock-frequency = <100000>;
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_i2c3>;
> > status = "okay";
> >
> > pcf2127@51 {
> > compatible = "nxp,pcf2127";
> > reg = <0x51>;
> > battery-low-hw-alarm;
> > status = "okay";
> > };
> > };
> >
>
> So I'm curious, how do you then use that signal? I have a (not yet sent)
> series adding alarm support for the pcf2127. The issue having BLIE is
> that then this will prevent the alarm to work properly.
>
> So my guess is that you have nINT connected to an LED or something that
> the user can see?
>
I'm working on our custom embedded board with an NXP i.MX7D,
developed here, in Asem (http://www.asem.it).
The nINT pin is connected to a GPIO of the MX7 and then
used by an applicative sw, to generate an alarm for the user.
> > Signed-off-by: Flavio Suligoi <[email protected]>
> > ---
> > drivers/rtc/rtc-pcf2127.c | 33 +++++++++++++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
> > index 7cb786d..e3805c8 100644
> > --- a/drivers/rtc/rtc-pcf2127.c
> > +++ b/drivers/rtc/rtc-pcf2127.c
> > @@ -228,6 +228,10 @@ static int pcf2127_probe(struct device *dev, struct
> regmap *regmap,
> > const char *name, bool has_nvmem)
> > {
> > struct pcf2127 *pcf2127;
> > + struct device_node *np;
> > + struct i2c_client *client = to_i2c_client(dev);
> > + unsigned char buf[2];
> > + int err;
> > int ret = 0;
> >
> > dev_dbg(dev, "%s\n", __func__);
> > @@ -245,6 +249,35 @@ static int pcf2127_probe(struct device *dev, struct
> regmap *regmap,
> > if (IS_ERR(pcf2127->rtc))
> > return PTR_ERR(pcf2127->rtc);
> >
> > + /*
> > + * The pcf2127 has an automatic battery-low detection function.
> > + *
> > + * In case of battery-low event, an interrupt generation through
> > + * the pin INTn (active low) can be enabled, setting the flag BLIE
> > + * in the register Control_3.
> > + */
> > + np = of_node_get(dev->of_node);
> > + if (!np) {
> > + dev_err(dev, "failed to find the RTC pcf2127 node\n");
> > + return -ENOENT;
> > + }
> > + if (of_get_property(np, "battery-low-hw-alarm", NULL)) {
> > + dev_info(dev, "enable battery-low hw alarm on INTn pin\n");
> > +
> > + /*
> > + * Set BLIE bit in register Control_3 (override is possible
> > + * because this register is fully zero after reset)
> > + */
> > + buf[0] = PCF2127_REG_CTRL3;
> > + buf[1] = 0x01;
> > + /* write register's data */
> > + err = i2c_master_send(client, buf, 2);
>
> This has to use regmap_update_bits because this also has to work on spi.
> (I don't know where you get the client pointer from anyway).
>
> > + if (err != 2) {
> > + dev_err(dev, "%s: err=%d", __func__, err);
> > + return -EIO;
> > + }
> > + }
> > +
> > if (has_nvmem) {
> > struct nvmem_config nvmem_cfg = {
> > .priv = pcf2127,
> > --
> > 2.7.4
> >
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Flavio Suligoi
On 03/04/2019 15:06:17+0000, Flavio Suligoi wrote:
> Hi Alexandre,
>
> > Hi,
> >
> > On 03/04/2019 16:52:44+0200, Flavio Suligoi wrote:
> > > Some RTC devices have a battery-low automatic detection circuit.
> > > The battery-low event is usually reported with:
> > >
> > > - a bit change in a RTC status register
> > > - a hw signaling (generally using an interrupt generation), changing
> > > the hw level of a specific pin;
> > >
> > > The new property "battery-low-hw-alarm" enable the RTC to generate the
> > > hw signaling in case of battery-low event.
> > >
> > > Signed-off-by: Flavio Suligoi <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt
> > b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > index a97fc6a..f93a44d 100644
> > > --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> > > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > @@ -31,6 +31,9 @@ below.
> > > expressed in femto Farad (fF).
> > > The default value shall be listed (if
> > optional),
> > > and likewise all valid values.
> > > +- battery-low-hw-alarm : Enable the "battery-low" output pin. This
> > function
> >
> > I would name that voltage-low-alarm as not all the secondary voltages
> > are batteries.
>
> You have right. So we can also name the property a: "voltage-low-hw-alarm".
> I prefer to have the word "hw" in the property name, since the "sw" voltage
> low alarm is already present is some RTC drivers.
> In this way, with the word "hw", is more clear that we are speaking about
> an hw pin signaling.
>
Well, the device tree always describes the hardware so there is no point
in specifying hw.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 03/04/2019 15:14:24+0000, Flavio Suligoi wrote:
> Hi Alexandre,
>
> > On 03/04/2019 16:52:45+0200, Flavio Suligoi wrote:
> > > The pcf2127 has an automatic battery-low detection function.
> > >
> > > In case of battery-low event, an interrupt generation through
> > > the pin INTn (active low) can be enabled, setting the flag BLIE
> > > in the register Control_3.
> > >
> > > This function is activated by the "battery-low-hw-alarm" DT property.
> > >
> > > Example of use for an NXP i.MX7D board:
> > >
> > > &i2c3 {
> > > clock-frequency = <100000>;
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&pinctrl_i2c3>;
> > > status = "okay";
> > >
> > > pcf2127@51 {
> > > compatible = "nxp,pcf2127";
> > > reg = <0x51>;
> > > battery-low-hw-alarm;
> > > status = "okay";
> > > };
> > > };
> > >
> >
> > So I'm curious, how do you then use that signal? I have a (not yet sent)
> > series adding alarm support for the pcf2127. The issue having BLIE is
> > that then this will prevent the alarm to work properly.
> >
> > So my guess is that you have nINT connected to an LED or something that
> > the user can see?
> >
>
> I'm working on our custom embedded board with an NXP i.MX7D,
> developed here, in Asem (http://www.asem.it).
> The nINT pin is connected to a GPIO of the MX7 and then
> used by an applicative sw, to generate an alarm for the user.
>
Then, you should probably not enable BLIE because this will cause issues
with the alarm functionnality.. It is certainly enough to use
RTC_VL_READ periodically.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi,
> On 03/04/2019 15:06:17+0000, Flavio Suligoi wrote:
> > Hi Alexandre,
> >
> > > Hi,
> > >
> > > On 03/04/2019 16:52:44+0200, Flavio Suligoi wrote:
> > > > Some RTC devices have a battery-low automatic detection circuit.
> > > > The battery-low event is usually reported with:
> > > >
> > > > - a bit change in a RTC status register
> > > > - a hw signaling (generally using an interrupt generation), changing
> > > > the hw level of a specific pin;
> > > >
> > > > The new property "battery-low-hw-alarm" enable the RTC to generate
> the
> > > > hw signaling in case of battery-low event.
> > > >
> > > > Signed-off-by: Flavio Suligoi <[email protected]>
> > > > ---
> > > > Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt
> > > b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > index a97fc6a..f93a44d 100644
> > > > --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > @@ -31,6 +31,9 @@ below.
> > > > expressed in femto Farad (fF).
> > > > The default value shall be listed (if
> > > optional),
> > > > and likewise all valid values.
> > > > +- battery-low-hw-alarm : Enable the "battery-low" output pin.
> This
> > > function
> > >
> > > I would name that voltage-low-alarm as not all the secondary voltages
> > > are batteries.
> >
> > You have right. So we can also name the property a: "voltage-low-hw-
> alarm".
> > I prefer to have the word "hw" in the property name, since the "sw"
> voltage
> > low alarm is already present is some RTC drivers.
> > In this way, with the word "hw", is more clear that we are speaking
> about
> > an hw pin signaling.
> >
>
> Well, the device tree always describes the hardware so there is no point
> in specifying hw.
Right, so I rename the property in "voltage-low-alarm"
>
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Flavio Suligoi
> > > On 03/04/2019 16:52:45+0200, Flavio Suligoi wrote:
> > > > The pcf2127 has an automatic battery-low detection function.
> > > >
> > > > In case of battery-low event, an interrupt generation through
> > > > the pin INTn (active low) can be enabled, setting the flag BLIE
> > > > in the register Control_3.
> > > >
> > > > This function is activated by the "battery-low-hw-alarm" DT
> property.
> > > >
> > > > Example of use for an NXP i.MX7D board:
> > > >
> > > > &i2c3 {
> > > > clock-frequency = <100000>;
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <&pinctrl_i2c3>;
> > > > status = "okay";
> > > >
> > > > pcf2127@51 {
> > > > compatible = "nxp,pcf2127";
> > > > reg = <0x51>;
> > > > battery-low-hw-alarm;
> > > > status = "okay";
> > > > };
> > > > };
> > > >
> > >
> > > So I'm curious, how do you then use that signal? I have a (not yet
> sent)
> > > series adding alarm support for the pcf2127. The issue having BLIE is
> > > that then this will prevent the alarm to work properly.
> > >
> > > So my guess is that you have nINT connected to an LED or something
> that
> > > the user can see?
> > >
> >
> > I'm working on our custom embedded board with an NXP i.MX7D,
> > developed here, in Asem (http://www.asem.it).
> > The nINT pin is connected to a GPIO of the MX7 and then
> > used by an applicative sw, to generate an alarm for the user.
> >
>
> Then, you should probably not enable BLIE because this will cause issues
> with the alarm functionnality.. It is certainly enough to use
> RTC_VL_READ periodically.
We use the nINT signaling solution because of this pin, in addition
to be used by the CPU, can be also connected to an external connector,
available for the final user.
Anyway, even if the BLIE is set, the sw low voltage alarm works,
with the message (displayed about every 12 minutes):
rtc-pcf2127-i2c 2-0051: low voltage detected, check/replace RTC battery.
What kind of issues did you find with BLIE enabled?
Flavio
On 03/04/2019 15:49:03+0000, Flavio Suligoi wrote:
> > Then, you should probably not enable BLIE because this will cause issues
> > with the alarm functionnality.. It is certainly enough to use
> > RTC_VL_READ periodically.
>
> We use the nINT signaling solution because of this pin, in addition
> to be used by the CPU, can be also connected to an external connector,
> available for the final user.
> Anyway, even if the BLIE is set, the sw low voltage alarm works,
> with the message (displayed about every 12 minutes):
>
I agree the DT property makes sense when the nINT pin is not connected
to the CPU. But if it is, then you have an issue that nINT will be
pulled low until the user changes the battery, meaning that you will
not get any alarm interrupt anymore, possibly leading to a system that
is not waking up anymore.
> rtc-pcf2127-i2c 2-0051: low voltage detected, check/replace RTC battery.
>
You get that message every 11minutes because you are using ntp and
systohc (which I would discourage you to use as it is inaccurate).
> What kind of issues did you find with BLIE enabled?
>
> Flavio
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Hi,
> On 03/04/2019 15:49:03+0000, Flavio Suligoi wrote:
> > > Then, you should probably not enable BLIE because this will cause
> issues
> > > with the alarm functionnality.. It is certainly enough to use
> > > RTC_VL_READ periodically.
> >
> > We use the nINT signaling solution because of this pin, in addition
> > to be used by the CPU, can be also connected to an external connector,
> > available for the final user.
> > Anyway, even if the BLIE is set, the sw low voltage alarm works,
> > with the message (displayed about every 12 minutes):
> >
>
> I agree the DT property makes sense when the nINT pin is not connected
> to the CPU. But if it is, then you have an issue that nINT will be
> pulled low until the user changes the battery, meaning that you will
> not get any alarm interrupt anymore, possibly leading to a system that
> is not waking up anymore.
Ah, ok, thanks for the info.
I know this, but in our specific case, this is not a problem,
since we don't use the nINT for other purposes, but only for
a battery low indicator. On the contrary, in our case, it's better
that the alarm signal remains low until the battery is changed.
Anyway, I can specify this collateral effect in a specific file for the
Pcf2127 in the DT bindings Documentation. What do you think?
Flavio Suligoi
On 03/04/2019 16:09:14+0000, Flavio Suligoi wrote:
> Hi,
>
> > On 03/04/2019 15:49:03+0000, Flavio Suligoi wrote:
> > > > Then, you should probably not enable BLIE because this will cause
> > issues
> > > > with the alarm functionnality.. It is certainly enough to use
> > > > RTC_VL_READ periodically.
> > >
> > > We use the nINT signaling solution because of this pin, in addition
> > > to be used by the CPU, can be also connected to an external connector,
> > > available for the final user.
> > > Anyway, even if the BLIE is set, the sw low voltage alarm works,
> > > with the message (displayed about every 12 minutes):
> > >
> >
> > I agree the DT property makes sense when the nINT pin is not connected
> > to the CPU. But if it is, then you have an issue that nINT will be
> > pulled low until the user changes the battery, meaning that you will
> > not get any alarm interrupt anymore, possibly leading to a system that
> > is not waking up anymore.
>
> Ah, ok, thanks for the info.
> I know this, but in our specific case, this is not a problem,
> since we don't use the nINT for other purposes, but only for
> a battery low indicator. On the contrary, in our case, it's better
> that the alarm signal remains low until the battery is changed.
>
> Anyway, I can specify this collateral effect in a specific file for the
> Pcf2127 in the DT bindings Documentation. What do you think?
>
This is fine as-is, I'll handle that in my series adding alarm support
because there will be no issues until then.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
> On 03/04/2019 16:09:14+0000, Flavio Suligoi wrote:
> > Hi,
> >
> > > On 03/04/2019 15:49:03+0000, Flavio Suligoi wrote:
> > > > > Then, you should probably not enable BLIE because this will cause
> > > issues
> > > > > with the alarm functionnality.. It is certainly enough to use
> > > > > RTC_VL_READ periodically.
> > > >
> > > > We use the nINT signaling solution because of this pin, in addition
> > > > to be used by the CPU, can be also connected to an external
> connector,
> > > > available for the final user.
> > > > Anyway, even if the BLIE is set, the sw low voltage alarm works,
> > > > with the message (displayed about every 12 minutes):
> > > >
> > >
> > > I agree the DT property makes sense when the nINT pin is not connected
> > > to the CPU. But if it is, then you have an issue that nINT will be
> > > pulled low until the user changes the battery, meaning that you will
> > > not get any alarm interrupt anymore, possibly leading to a system that
> > > is not waking up anymore.
> >
> > Ah, ok, thanks for the info.
> > I know this, but in our specific case, this is not a problem,
> > since we don't use the nINT for other purposes, but only for
> > a battery low indicator. On the contrary, in our case, it's better
> > that the alarm signal remains low until the battery is changed.
> >
> > Anyway, I can specify this collateral effect in a specific file for the
> > Pcf2127 in the DT bindings Documentation. What do you think?
> >
>
> This is fine as-is, I'll handle that in my series adding alarm support
> because there will be no issues until then.
Ok, thanks
Flavio Suligoi
On Wed, Apr 03, 2019 at 04:52:44PM +0200, Flavio Suligoi wrote:
> Some RTC devices have a battery-low automatic detection circuit.
> The battery-low event is usually reported with:
>
> - a bit change in a RTC status register
> - a hw signaling (generally using an interrupt generation), changing
> the hw level of a specific pin;
>
> The new property "battery-low-hw-alarm" enable the RTC to generate the
> hw signaling in case of battery-low event.
>
> Signed-off-by: Flavio Suligoi <[email protected]>
> ---
> Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt b/Documentation/devicetree/bindings/rtc/rtc.txt
> index a97fc6a..f93a44d 100644
> --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> @@ -31,6 +31,9 @@ below.
> expressed in femto Farad (fF).
> The default value shall be listed (if optional),
> and likewise all valid values.
> +- battery-low-hw-alarm : Enable the "battery-low" output pin. This function
> + is available on the following devices:
> + - pcf2127 - pin used for alarm: INTn
Boolean? If there's cases where which pin is selectable, then we'd need
this to take a value. Not sure how likely that is?
Rob
On 06/04/2019 01:07:13-0500, Rob Herring wrote:
> On Wed, Apr 03, 2019 at 04:52:44PM +0200, Flavio Suligoi wrote:
> > Some RTC devices have a battery-low automatic detection circuit.
> > The battery-low event is usually reported with:
> >
> > - a bit change in a RTC status register
> > - a hw signaling (generally using an interrupt generation), changing
> > the hw level of a specific pin;
> >
> > The new property "battery-low-hw-alarm" enable the RTC to generate the
> > hw signaling in case of battery-low event.
> >
> > Signed-off-by: Flavio Suligoi <[email protected]>
> > ---
> > Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt b/Documentation/devicetree/bindings/rtc/rtc.txt
> > index a97fc6a..f93a44d 100644
> > --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> > @@ -31,6 +31,9 @@ below.
> > expressed in femto Farad (fF).
> > The default value shall be listed (if optional),
> > and likewise all valid values.
> > +- battery-low-hw-alarm : Enable the "battery-low" output pin. This function
> > + is available on the following devices:
> > + - pcf2127 - pin used for alarm: INTn
>
> Boolean? If there's cases where which pin is selectable, then we'd need
> this to take a value. Not sure how likely that is?
>
Indeed, there is at least the pcf85363 that has two possible pins for
that interrupt. How would you select the pin then? a zero based index? a
string?
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
HI,
> On 06/04/2019 01:07:13-0500, Rob Herring wrote:
> > On Wed, Apr 03, 2019 at 04:52:44PM +0200, Flavio Suligoi wrote:
> > > Some RTC devices have a battery-low automatic detection circuit.
> > > The battery-low event is usually reported with:
> > >
> > > - a bit change in a RTC status register
> > > - a hw signaling (generally using an interrupt generation), changing
> > > the hw level of a specific pin;
> > >
> > > The new property "battery-low-hw-alarm" enable the RTC to generate the
> > > hw signaling in case of battery-low event.
> > >
> > > Signed-off-by: Flavio Suligoi <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt
> b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > index a97fc6a..f93a44d 100644
> > > --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> > > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > @@ -31,6 +31,9 @@ below.
> > > expressed in femto Farad (fF).
> > > The default value shall be listed (if
> optional),
> > > and likewise all valid values.
> > > +- battery-low-hw-alarm : Enable the "battery-low" output pin. This
> function
> > > + is available on the following devices:
> > > + - pcf2127 - pin used for alarm: INTn
> >
> > Boolean? If there's cases where which pin is selectable, then we'd need
> > this to take a value. Not sure how likely that is?
> >
>
> Indeed, there is at least the pcf85363 that has two possible pins for
> that interrupt. How would you select the pin then? a zero based index? a
> string?
I think the string could be clearer for the final user and would give
more freedom for future changes.
For example, we can call this property, instead of "battery-low-alarm" or
"low-voltage-alarm", simply: "alarm-pin_1" and then the string argument
can describe the function used; for example:
alarm-pin_1 = "backup-supply-low-voltage-alarm";
alarm-pin_2 = "......";
Flavio Suligoi
On Mon, Apr 8, 2019 at 2:22 AM Flavio Suligoi <[email protected]> wrote:
>
> HI,
>
> > On 06/04/2019 01:07:13-0500, Rob Herring wrote:
> > > On Wed, Apr 03, 2019 at 04:52:44PM +0200, Flavio Suligoi wrote:
> > > > Some RTC devices have a battery-low automatic detection circuit.
> > > > The battery-low event is usually reported with:
> > > >
> > > > - a bit change in a RTC status register
> > > > - a hw signaling (generally using an interrupt generation), changing
> > > > the hw level of a specific pin;
> > > >
> > > > The new property "battery-low-hw-alarm" enable the RTC to generate the
> > > > hw signaling in case of battery-low event.
> > > >
> > > > Signed-off-by: Flavio Suligoi <[email protected]>
> > > > ---
> > > > Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt
> > b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > index a97fc6a..f93a44d 100644
> > > > --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > @@ -31,6 +31,9 @@ below.
> > > > expressed in femto Farad (fF).
> > > > The default value shall be listed (if
> > optional),
> > > > and likewise all valid values.
> > > > +- battery-low-hw-alarm : Enable the "battery-low" output pin. This
> > function
> > > > + is available on the following devices:
> > > > + - pcf2127 - pin used for alarm: INTn
> > >
> > > Boolean? If there's cases where which pin is selectable, then we'd need
> > > this to take a value. Not sure how likely that is?
> > >
> >
> > Indeed, there is at least the pcf85363 that has two possible pins for
> > that interrupt. How would you select the pin then? a zero based index? a
> > string?
I prefer an index.
> I think the string could be clearer for the final user and would give
> more freedom for future changes.
> For example, we can call this property, instead of "battery-low-alarm" or
> "low-voltage-alarm", simply: "alarm-pin_1" and then the string argument
> can describe the function used; for example:
>
> alarm-pin_1 = "backup-supply-low-voltage-alarm";
> alarm-pin_2 = "......";
How many pins and functions then? And how does this relate to any interrupts?
Rob
Hi Rob,
> On Mon, Apr 8, 2019 at 2:22 AM Flavio Suligoi <[email protected]> wrote:
> >
> > HI,
> >
> > > On 06/04/2019 01:07:13-0500, Rob Herring wrote:
> > > > On Wed, Apr 03, 2019 at 04:52:44PM +0200, Flavio Suligoi wrote:
> > > > > Some RTC devices have a battery-low automatic detection circuit.
> > > > > The battery-low event is usually reported with:
> > > > >
> > > > > - a bit change in a RTC status register
> > > > > - a hw signaling (generally using an interrupt generation),
> changing
> > > > > the hw level of a specific pin;
> > > > >
> > > > > The new property "battery-low-hw-alarm" enable the RTC to generate
> the
> > > > > hw signaling in case of battery-low event.
> > > > >
> > > > > Signed-off-by: Flavio Suligoi <[email protected]>
> > > > > ---
> > > > > Documentation/devicetree/bindings/rtc/rtc.txt | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.txt
> > > b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > > index a97fc6a..f93a44d 100644
> > > > > --- a/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > > +++ b/Documentation/devicetree/bindings/rtc/rtc.txt
> > > > > @@ -31,6 +31,9 @@ below.
> > > > > expressed in femto Farad (fF).
> > > > > The default value shall be listed (if
> > > optional),
> > > > > and likewise all valid values.
> > > > > +- battery-low-hw-alarm : Enable the "battery-low" output pin.
> This
> > > function
> > > > > + is available on the following
> devices:
> > > > > + - pcf2127 - pin used for alarm: INTn
> > > >
> > > > Boolean? If there's cases where which pin is selectable, then we'd
> need
> > > > this to take a value. Not sure how likely that is?
> > > >
> > >
> > > Indeed, there is at least the pcf85363 that has two possible pins for
> > > that interrupt. How would you select the pin then? a zero based index?
> a
> > > string?
>
> I prefer an index.
Ok, so we can call this property as:
low-voltage-alarm
and we can select the pin using a zero-base index,
also for future developments.
>
> > I think the string could be clearer for the final user and would give
> > more freedom for future changes.
> > For example, we can call this property, instead of "battery-low-alarm"
> or
> > "low-voltage-alarm", simply: "alarm-pin_1" and then the string argument
> > can describe the function used; for example:
> >
> > alarm-pin_1 = "backup-supply-low-voltage-alarm";
> > alarm-pin_2 = "......";
>
> How many pins and functions then? And how does this relate to any
> interrupts?
If we use index, we don't use strings any more.