From: Nicolin Chen <nicoleotsuka@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: jdelvare@suse.com, linux-hwmon@vger.kernel.org,
linux-kernel@vger.kernel.org, corbet@lwn.net,
linux-doc@vger.kernel.org
Subject: Re: [PATCH 2/2] hwmon: (ina3221) Add operating mode support
Date: Wed, 10 Oct 2018 16:09:07 -0700 [thread overview]
Message-ID: <20181010230906.GB1706@Asurada-Nvidia.nvidia.com> (raw)
In-Reply-To: <32c22986-544e-aca1-12bf-9080667cf499@roeck-us.net>
Hello Guenter,
On Wed, Oct 10, 2018 at 06:22:39AM -0700, Guenter Roeck wrote:
> > The hwmon core now has a new optional mode interface. So this patch
> > just implements this mode support so that user space can check and
> > configure via sysfs node its operating modes: power-down, one-shot,
> > and continuous modes.
> One-shot mode on its own does not make sense or add value: It would require
> explicit driver support to trigger a reading, wait for the result, and
> report it back to the user. If the intent here is to have the user write the
> mode (which triggers the one-shot reading), wait a bit, and then read the
> results, that doesn't make sense because standard userspace applications
> won't know that. Also, that would be unsynchronized - one has to read the
> CVRF bit in the mask/enable register to know if the reading is complete.
I think I oversimplified the one-shot mode here and you are right:
there should be a one-shot reading routine; the conversion time in
the configuration register also needs to be taken care of.
> The effort to do all this using CPU cycles would in most if not all cases
> outweigh any perceived power savings. As such, I just don't see the
> practical use case.
It really depends on the use case and how often the one-shot gets
triggered. For battery-powered devices, running in the continuous
mode does consume considerable power based on the measurement from
our power folks. If a system is running in a power sensitive mode,
while it still needs to occasionally check the inputs, it could be
a use case for one-shot mode, though it's purely a user decision.
> power-down mode effectively reinvents runtime power management (runtime
> suspend/resume support) and is thus simply unacceptable.
Similar to one-shot, if a system is in a low power mode where it
doesn't want to check the inputs anymore, I feel the user space
could at least make the decision to turn on/off the chips, I am
not quite sure if the generic runtime PM system already has this
kind of support though.
> I am open to help explore adding support for runtime power management
> to the hwmon subsystem, but that would be less than straightforward and
> require an actual use case to warrant the effort.
Is there any feasible solution from your point of view?
Thanks
Nicolin
----
>
> As such, NACK, sorry.
>
> Thanks,
> Guenter
>
> > Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
> > ---
> > drivers/hwmon/ina3221.c | 64 +++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 64 insertions(+)
> >
> > diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
> > index d61688f04594..5218fd85506d 100644
> > --- a/drivers/hwmon/ina3221.c
> > +++ b/drivers/hwmon/ina3221.c
> > @@ -77,6 +77,28 @@ enum ina3221_channels {
> > INA3221_NUM_CHANNELS
> > };
> > +enum ina3221_modes {
> > + INA3221_MODE_POWERDOWN,
> > + INA3221_MODE_ONESHOT,
> > + INA3221_MODE_CONTINUOUS,
> > + INA3221_NUM_MODES,
> > +};
> > +
> > +static const char *ina3221_mode_names[INA3221_NUM_MODES] = {
> > + [INA3221_MODE_POWERDOWN] = "power-down",
> > + [INA3221_MODE_ONESHOT] = "one-shot",
> > + [INA3221_MODE_CONTINUOUS] = "continuous",
> > +};
> > +
> > +static const u16 ina3221_mode_val[] = {
> > + [INA3221_MODE_POWERDOWN] = INA3221_CONFIG_MODE_POWERDOWN,
> > + [INA3221_MODE_ONESHOT] = INA3221_CONFIG_MODE_SHUNT |
> > + INA3221_CONFIG_MODE_BUS,
> > + [INA3221_MODE_CONTINUOUS] = INA3221_CONFIG_MODE_CONTINUOUS |
> > + INA3221_CONFIG_MODE_SHUNT |
> > + INA3221_CONFIG_MODE_BUS,
> > +};
> > +
> > /**
> > * struct ina3221_input - channel input source specific information
> > * @label: label of channel input source
> > @@ -386,9 +408,51 @@ static const struct hwmon_ops ina3221_hwmon_ops = {
> > .write = ina3221_write,
> > };
> > +static int ina3221_mode_get_index(struct device *dev, unsigned int *index)
> > +{
> > + struct ina3221_data *ina = dev_get_drvdata(dev);
> > + u16 mode = ina->reg_config & INA3221_CONFIG_MODE_MASK;
> > +
> > + if (mode == INA3221_CONFIG_MODE_POWERDOWN)
> > + *index = INA3221_MODE_POWERDOWN;
> > + if (mode & INA3221_CONFIG_MODE_CONTINUOUS)
> > + *index = INA3221_MODE_CONTINUOUS;
> > + else
> > + *index = INA3221_MODE_ONESHOT;
> > +
> > + return 0;
> > +}
> > +
> > +static int ina3221_mode_set_index(struct device *dev, unsigned int index)
> > +{
> > + struct ina3221_data *ina = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + ret = regmap_update_bits(ina->regmap, INA3221_CONFIG,
> > + INA3221_CONFIG_MODE_MASK,
> > + ina3221_mode_val[index]);
> > + if (ret)
> > + return ret;
> > +
> > + /* Cache the latest config register value */
> > + ret = regmap_read(ina->regmap, INA3221_CONFIG, &ina->reg_config);
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > +static const struct hwmon_mode ina3221_hwmon_mode = {
> > + .names = ina3221_mode_names,
> > + .list_size = INA3221_NUM_MODES,
> > + .get_index = ina3221_mode_get_index,
> > + .set_index = ina3221_mode_set_index,
> > +};
> > +
> > static const struct hwmon_chip_info ina3221_chip_info = {
> > .ops = &ina3221_hwmon_ops,
> > .info = ina3221_info,
> > + .mode = &ina3221_hwmon_mode,
> > };
> > /* Extra attribute groups */
> >
>
next prev parent reply other threads:[~2018-10-10 23:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-10 4:33 [PATCH 0/2] hwmon: Add operating mode support for core and ina3221 Nicolin Chen
2018-10-10 4:33 ` [PATCH 1/2] hwmon: (core) Add hwmon_mode structure and mode sysfs node Nicolin Chen
2018-10-10 13:08 ` Guenter Roeck
2018-10-10 21:13 ` Nicolin Chen
2018-10-10 21:31 ` Guenter Roeck
2018-10-10 4:33 ` [PATCH 2/2] hwmon: (ina3221) Add operating mode support Nicolin Chen
2018-10-10 13:22 ` Guenter Roeck
2018-10-10 23:09 ` Nicolin Chen [this message]
2018-10-10 23:43 ` Guenter Roeck
2018-10-11 0:24 ` Nicolin Chen
2018-10-11 19:31 ` Guenter Roeck
2018-10-11 19:36 ` Nicolin Chen
2018-10-11 19:50 ` Guenter Roeck
2018-10-11 19:53 ` Nicolin Chen
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=20181010230906.GB1706@Asurada-Nvidia.nvidia.com \
--to=nicoleotsuka@gmail.com \
--cc=corbet@lwn.net \
--cc=jdelvare@suse.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).