What is the proper way to read RTC battery voltage

What is the proper way to read RTC battery voltage

[Lei YU]

This email is to ask about a proper way to read RTC battery voltage.

Background:
* Usually RTC battery voltage could be read from an ADC channel.
* Usually there is a GPIO to enable/disable the connection between battery
   and ADC, e.g.
   * When GPIO is pulled low, the channel is disconnected and reading is 0.
   * When GPIO is pulled high, the channel is connected and the reading is OK.
* So to read the voltage, the GPIO shall be pulled high.
* When the GPIO is pulled high, it drains the battery.

The problem: How to properly read the voltage, without affecting the battery
life?

1. If the GPIO is simply hogged high in device tree, the ADC channel always get
   the correct reading, but it affects the battery life.
2. We could leave the GPIO for user space to control, e.g. let phosphor-hwmon
   to control the GPIO while reading a sensor, it resolves the problem.
   This is done by Google and the patch for phosphor-hwmon is at
   (https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-hwmon/+/11697/)
3. We could use gpio-mux and io-channel-mux driver, that let kernel to
   automatically pull the GPIO while reading the sensor. (See
   https://github.com/mine260309/linux/commit/8e60647389e5400a85c705685ca2f6b875856c99
   for example).
   However, it requires some delay between GPIO pulled high and reading the ADC
   channel, if the delay is too small, the ADC channel reading becomes
   incorrect, e.g. it gets 0 or a lower value than expected.

In the above 3 ways:
1 is not acceptable;
2 is OK, but it is not as clean as handle the GPIO in kernel;
3 is more preferred, but it requires a delay in kernel. To upstream this
   change, the delay shall be put in a proper place, e.g. in iio-mux driver,
   or in adc driver?
   I do not think either place is proper for the delay...

So my question is, which is the proper way to handle the case, or is there any
other way?

Thanks!

Re: What is the proper way to read RTC battery voltage

[Ed Tanous]

On 08/02/2018 11:14 PM, Lei YU wrote:
> 
> 2. We could leave the GPIO for user space to control, e.g. let phosphor-hwmon
>     to control the GPIO while reading a sensor, it resolves the problem.
>     This is done by Google and the patch for phosphor-hwmon is at
>     (https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-hwmon/+/11697/)

In previous codebases, this is the option we've gone with.  In practice, 
there is some lag time so some sleeps are needed to wait for the FET to 
charge the line before initiating the reading on the ADC.  In the past 
we've simply done this with blocking sleeps, but there are likely better 
options.

> 3. We could use gpio-mux and io-channel-mux driver, that let kernel to
>     automatically pull the GPIO while reading the sensor. (See
>     https://github.com/mine260309/linux/commit/8e60647389e5400a85c705685ca2f6b875856c99
>     for example).
>     However, it requires some delay between GPIO pulled high and reading the ADC
>     channel, if the delay is too small, the ADC channel reading becomes
>     incorrect, e.g. it gets 0 or a lower value than expected.
> 

This sounds like a cleaner solution, but more difficult to execute in 
practice.  I think either 2 or 3 would solve it.  Is there an easy way 
to delay in the driver without blocking?  It doesn't need to be terribly 
deterministic to work correctly.


Another thing to note is that even with this, your battery life is 
affected by how often you poll the voltage, so in general we reduce the 
scan rate of the battery voltage readings compared to other sensors to 
keep the battery life more sustainable over the long term.

Re: What is the proper way to read RTC battery voltage

[Lei YU]

> > 3. We could use gpio-mux and io-channel-mux driver, that let kernel to
> >     automatically pull the GPIO while reading the sensor. (See
> >     https://github.com/mine260309/linux/commit/8e60647389e5400a85c705685ca2f6b875856c99
> >     for example).
> >     However, it requires some delay between GPIO pulled high and reading the ADC
> >     channel, if the delay is too small, the ADC channel reading becomes
> >     incorrect, e.g. it gets 0 or a lower value than expected.
> >
>
> This sounds like a cleaner solution, but more difficult to execute in
> practice.  I think either 2 or 3 would solve it.  Is there an easy way
> to delay in the driver without blocking?  It doesn't need to be terribly
> deterministic to work correctly.

I did not know a way to delay without blocking, I was thinking:
1. Is it reasonable to do udelay/mdelay in driver?
2. If yes, which driver should use the delay? The io-channel-mux driver,
   or adc driver?

> Another thing to note is that even with this, your battery life is
> affected by how often you poll the voltage, so in general we reduce the
> scan rate of the battery voltage readings compared to other sensors to
> keep the battery life more sustainable over the long term.

Yup, current phosphor-hwmon is able to config the sensor read interval, in
practice we probably read the battery voltage once every day.