devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: jdelvare@suse.com, robh+dt@kernel.org, mark.rutland@arm.com,
	linux-hwmon@vger.kernel.org, corbet@lwn.net,
	devicetree@vger.kernel.org, patches@opensource.cirrus.com
Subject: Re: [PATCH v2 2/2] hwmon: lochnagar: Add Lochnagar 2 hardware monitoring driver
Date: Tue, 26 Mar 2019 10:05:51 +0000	[thread overview]
Message-ID: <20190326100551.GI46536@ediswmail.ad.cirrus.com> (raw)
In-Reply-To: <20190325184711.GA3195@roeck-us.net>

On Mon, Mar 25, 2019 at 11:47:11AM -0700, Guenter Roeck wrote:
> On Mon, Mar 25, 2019 at 05:10:54PM +0000, Charles Keepax wrote:
> > On Mon, Mar 25, 2019 at 09:46:22AM -0700, Guenter Roeck wrote:
> > > On Mon, Mar 25, 2019 at 01:16:51PM +0000, Charles Keepax wrote:
> > > > On Mon, Mar 25, 2019 at 04:17:31AM -0700, Guenter Roeck wrote:
> > > > > On 3/25/19 4:00 AM, Charles Keepax wrote:
> > > > > >From: Lucas Tanure <tanureal@opensource.cirrus.com>
> > > There is another possibility which might meet your requirements: If the
> > > important attribute is power consumption, you might consider providing
> > > power attributes. Those _are provided in micro-units. That isn't exactly
> > > as expected, as drivers should only provide power attributes if actually
> > > reported by the HW, but there is an argument to make that it makes sense
> > > here. You could then even provide powerX_average and make the number
> > > of samples indirectly configurable with powerX_average_interval.
> > > 
> > 
> > Thank you for the suggestions I will investigate them and see
> > where I get to. The power option does sound tempting as the
> > ability to configure the number of samples feels like something
> > that could be handy in the future. But on the flip side adding
> > high accuracy APIs might be useful for others in the future.
> > 
> Agreed, but we would have to think about it more before jumping into
> it. There would be several possible solutions. Adding new sysfs files
> might be one. Another might be "scale" attributes or similar. Or get rid
> of the sysfs ABI entirely and use something similar to iio. Or go further
> and create a hwmon->iio bridge and use iio to report high resolution
> information.
> 

Ok I think I will have a look at the using the power entries
first and we can see what that looks like. I am leaning in that
direction as it would be nice to get something merged in the not
too distant future and having configuration for the averaging
does seem like it protects against the hardware guys going "for
this project we need to average over this many samples".

On another note I have not really done a lot with hwmon/iio
before, my assumption was this should really be an hwmon device
since it is monitoring the state of the hardware and only
supports simple single readings, no buffering etc. Are you also
comfortable that this is the sub-system this device belongs in?

Thanks,
Charles

  reply	other threads:[~2019-03-26 10:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25 11:00 [PATCH v2 1/2] hwmon: lochnagar: Add device tree binding document Charles Keepax
2019-03-25 11:00 ` [PATCH v2 2/2] hwmon: lochnagar: Add Lochnagar 2 hardware monitoring driver Charles Keepax
2019-03-25 11:17   ` Guenter Roeck
2019-03-25 13:16     ` Charles Keepax
2019-03-25 16:46       ` Guenter Roeck
2019-03-25 17:10         ` Charles Keepax
2019-03-25 18:47           ` Guenter Roeck
2019-03-26 10:05             ` Charles Keepax [this message]
2019-03-26 13:31               ` Guenter Roeck

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=20190326100551.GI46536@ediswmail.ad.cirrus.com \
    --to=ckeepax@opensource.cirrus.com \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=jdelvare@suse.com \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mark.rutland@arm.com \
    --cc=patches@opensource.cirrus.com \
    --cc=robh+dt@kernel.org \
    /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).