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] [PATCH] hwmon: (ltc4245) Read GPIO registers
Date: Fri, 02 Apr 2010 17:11:24 +0000	[thread overview]
Message-ID: <20100402191124.0c6d440d@hyperion.delvare> (raw)
In-Reply-To: <20100330225704.GF20635@ovro.caltech.edu>

Hi Ira,

On Fri, 2 Apr 2010 09:45:07 -0700, Ira W. Snyder wrote:
> On Fri, Apr 02, 2010 at 06:24:38PM +0200, Jean Delvare wrote:
> > You wired your chip in a way it was not meant to be. You shouldn't have.
> 
> Why do you think it is wired incorrectly?

Just look at the code you had to write to get it to work... (And it's
not even covering all use cases, see below.)

> Nothing I've found in the
> datasheet suggests that. If you can provide some insight into why you
> think this is, maybe we can come to an agreement, instead of just making
> me very frustrated.
> 
> On Page 24, "General Purpose Input/Outputs", the text says that any of
> the three GPIO pins can be connected to the ADC. Page 32, Table 13 "GPIO
> Register G" supports this. Each of the three GPIO pins has exactly the
> same configurable settings as all the others.
> 
> Page 13 "Configuration, GPIO, and Precharge" also states: The GPIO1 to
> GPIO3 pins can be used as general purpose inputs or outputs. One of the
> pins can also be multiplexed to the GPIO channel of the ADC.
> 
> The way I read this, it means: only one of the pins can be multiplexed
> onto the ADC ***at a single moment in time***.

The way I read this, it means: you get to choose one GPIO pin to be
routed to the ADC, by configuring register G at initialization time. Of
course nothing prevents you from changing configuration settings later,
but same holds for every other configuration bit, still most of them
make no sense changing after initialization.

> Why else would the GPIO
> register (0x6) exist, other than to let the user switch between them at
> runtime?

Maybe to give some flexibility with wire routing on the board. Or
because GPIO1 has extra features (so that wouldn't be the best choice
for routing to ADC) but GPIO2 and 3 aren't available on the UHF part, so
there was no one-fits-all decision. Or maybe just for maketing, 'cause
now they can claim the part lets you monitor N+2 voltages, so it looks
very cool.

> This kind of design sucks, but it is common in the embedded
> world, where we are always trying to use fewer parts to do the same job.

Of course, it is possible to change the GPIO routing to ADC at
run-time. But then you get a reading for each every 3 refresh cycles.
You say it means every 3 seconds, but you can get much older results if
you do not read the values every second. Someone running "sensors"
manually at a given point in time to get the current state of the
system would end up seeing 2 values which might be hours or days old,
or even zero values if it is the first use since the driver was loaded.
This is very confusing and I certainly don't want any of our drivers to
behave that way.

-- 
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-04-02 17:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-30 22:57 [lm-sensors] [PATCH] hwmon: (ltc4245) Read GPIO registers correctly Ira W. Snyder
2010-04-02  8:13 ` [lm-sensors] [PATCH] hwmon: (ltc4245) Read GPIO registers Jean Delvare
2010-04-02 16:12 ` Ira W. Snyder
2010-04-02 16:24 ` Jean Delvare
2010-04-02 16:45 ` Ira W. Snyder
2010-04-02 17:11 ` Jean Delvare [this message]
2010-04-02 18:09 ` Ira W. Snyder
2010-04-03 18:08 ` Jean Delvare
2010-04-05 18:41 ` Ira W. Snyder
2010-04-13 12:00 ` Jean Delvare
2010-04-13 12:01 ` Jean Delvare

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=20100402191124.0c6d440d@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.