All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [RFC PATCH] Allow the configuration register to be
Date: Tue, 14 Sep 2010 08:08:33 +0000	[thread overview]
Message-ID: <20100914100833.4f4270b5@hyperion.delvare> (raw)
In-Reply-To: <1284386867-21650-1-git-send-email-shubhrajyoti@ti.com>

On Mon, 13 Sep 2010 11:09:06 -0700, Guenter Roeck wrote:
> On Mon, Sep 13, 2010 at 01:41:21PM -0400, Jean Delvare wrote:
> > On Mon, 13 Sep 2010 09:51:09 -0700, Guenter Roeck wrote:
> > > I found the following attributes used for the update inverval.
> > > 
> > > adt7470.c	auto_update_interval
> > > lm95241.c	rate
> > > adm1031.c	update_rate
> > > 
> > > Not sure about adt7470.c, ince it reflects an automatic interval, but would it make sense
> > > to update lm95241.c to use the standard attribute ?
> > 
> > Yes it would.
> > 
> > > On a side note, update_rate (or rate) doesn't really reflect its use. A "rate"
> > > would be measured in updates/time, not in absolute time. Or, in other words,
> > > it reflects a frequency, not an interval. So we are really talking about intervals.
> > > Not sure if that is worth bitching about, but since the attribute is quite new
> > > it might make sense to think about it.
> > 
> > Jonathan Cameron (Cc'd) had a similar concern:
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2010-May/028596.html
> > 
> > Nobody seemed to care back then. I can't disagree with both of you, but
> > OTOH I don't feel too strongly about it either. So if someone submits a
> > patch making things better, that's fine with me, but I won't spend my
> > own time on it.
>
> I'll submit a set of patches. update_interval ok ? It reflects the time between
> events, while period tends to reflect a duration.

Yes, I would be fine with update_interval. Jonathan, OK with you too?

> > > Resolution would have to be sensor dependent, since each sensor can have its own resolution.
> > > Would be nice to have an attribute for that.
> > 
> > Not too sure about that. I had the same reaction at first, but do we
> > actually know of devices where the resolution isn't global?
>
> Yes, in the lm90 driver. Only max6657/58/59 and max6646 have extended local
> temperatures, all other chips have only 8 bit resolution for the local temperature.
> Remote temperatures are all extended, ie have higher resoution.

But resolution can't be changed on these chips, can it? I think the
main purpose of these files is to let the user change the resolution
for chips which support this (usually this is an update speed /
resolution trade-off). Or do you believe that having read-only
attributes exposing fixed resolutions would be valuable?

I'm a little worried because resolution as a bit number isn't too
informative and doesn't quite work as a device-independent value. If
you really want the information to be exposed to user-space for all
devices, then we'd rather use actual sensor units (mV, m°C, whatever)
for resolution, and possibly add other attributes for the range. But
this means adding a whole lot of attribute files for some devices (if
we do it on a per-channel basis), so we first have to determine whether
it is really worth it. I don't think it is, but you can try and
convince me.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  parent reply	other threads:[~2010-09-14  8:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-13 14:19 [lm-sensors] [RFC PATCH] Allow the configuration register to be Shubhrajyoti D
2010-09-13 14:27 ` Jean Delvare
2010-09-13 14:55 ` Datta, Shubhrajyoti
2010-09-13 15:33 ` Jean Delvare
2010-09-13 16:51 ` Guenter Roeck
2010-09-13 17:41 ` Jean Delvare
2010-09-13 18:09 ` Guenter Roeck
2010-09-14  8:08 ` Jean Delvare [this message]
2010-09-14 12:01 ` Guenter Roeck
2010-09-14 14:57 ` Jean Delvare
2010-09-14 16:04 ` 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=20100914100833.4f4270b5@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=lm-sensors@vger.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 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.