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 <f.suligoi@asem.it> --- 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 <f.suligoi@asem.it> --- 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 <f.suligoi@asem.it> > --- > 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 <f.suligoi@asem.it> > > --- > > 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 <f.suligoi@asem.it> > --- > 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 (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 <f.suligoi@asem.it> > > --- > > 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 <f.suligoi@asem.it> > > > --- > > > 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 (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 <f.suligoi@asem.it> > > > > --- > > > > 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 (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 <f.suligoi@asem.it>
> ---
> 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 <f.suligoi@asem.it> > > --- > > 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 <f.suligoi@asem.it>
> > > ---
> > > 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 <f.suligoi@asem.it> 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 <f.suligoi@asem.it> > > > > --- > > > > 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 <f.suligoi@asem.it> 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 <f.suligoi@asem.it> > > > > > --- > > > > > 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.