From: Lei YU <mine260309@gmail.com>
To: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Cc: Patrick Venture <venture@google.com>,
spinler@us.ibm.com, Joel Stanley <joel@jms.id.au>
Subject: What is the proper way to read RTC battery voltage
Date: Fri, 3 Aug 2018 14:14:54 +0800 [thread overview]
Message-ID: <CAARXrtm64qpSkDD31+m9HGa-Bw4k0jkRizHiS9fc73JZHMfmXQ@mail.gmail.com> (raw)
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!
next reply other threads:[~2018-08-03 6:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-03 6:14 Lei YU [this message]
2018-08-03 17:26 ` What is the proper way to read RTC battery voltage Ed Tanous
2018-08-06 5:51 ` Lei YU
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAARXrtm64qpSkDD31+m9HGa-Bw4k0jkRizHiS9fc73JZHMfmXQ@mail.gmail.com \
--to=mine260309@gmail.com \
--cc=joel@jms.id.au \
--cc=openbmc@lists.ozlabs.org \
--cc=spinler@us.ibm.com \
--cc=venture@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.