All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ira W. Snyder" <iws@ovro.caltech.edu>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH 2/2] hwmon: (ltc4245) expose all GPIO pins
Date: Wed, 26 May 2010 19:39:03 +0000	[thread overview]
Message-ID: <20100526193902.GC17367@ovro.caltech.edu> (raw)
In-Reply-To: <1271199569-3880-3-git-send-email-iws@ovro.caltech.edu>

On Wed, May 26, 2010 at 08:42:22PM +0200, Jean Delvare wrote:
> On Wed, 26 May 2010 10:22:44 -0700, Ira W. Snyder wrote:
> > On Wed, May 26, 2010 at 06:36:59PM +0200, Jean Delvare wrote:
> > > Sorry for not being clear. I wasn't objecting to the stub's existence,
> > > but to the fact that it was doing something. I expected it to do
> > > nothing at all, and ltc4245_show_voltage() would be used for in9.
> > 
> > Oh, ok. The ltc4245_show_voltage() function reads the voltage register
> > values directly from data->vregs[]. When the extra GPIO inputs are
> > enabled, I have two choices:
> > 
> > 1) store them in the new data->gpios[] array
> > 2) store them in data->vregs[]
> > 
> > For #1, ltc4245_show_voltage() doesn't work anymore, since it reads
> > voltage register values from data->vregs[].
> > 
> > For #2, I would have to re-expand data->vregs[] to include all of the
> > GPIO inputs, like it was before. Also, I would need to make
> > ltc4245_get_voltage() handle the -EAGAIN error code.
> > 
> > I think the code is easier to understand if all the GPIOs are treated in
> > the same way, and not completely special for GPIOADC1 vs GPIOADC[23].
> > That's why I chose #1.
> > 
> > If I do a hybrid approach (store GPIOADC1 in data->vregs[] and
> > GPIOADC[23] in data->gpios[]), then I have to make ltc4245_get_voltage()
> > robust against errors too. Is this what you're suggesting?
> 
> No. But let's wait and see if you move to OF platform data, the whole
> question will be moot. If you keep the config option approach, I'll
> propose an iterative patch and we can discuss it then.
> 
> > (...)
> > Any thoughts about the kernel config option vs. platform data, and how
> > it relates to the OF bindings?
> 
> I would prefer platform-data-based. But I fear I don't know anything
> about OF bindings. Better ask the embedded folks (e.g. Grant Likely),
> they will know.
> 

Grant, you're listed in MAINTAINERS as the OF bindings maintainer. Is it
currently possible for the i2c OF binding to pass platform_data to hwmon
drivers that are probed via the device tree? If so, can you point me to
an example. If not, can you suggest what I should do?

Here is a short example from my device tree (a lightly modified 834x_mds
device tree):

i2c@3100 {
	#address-cells = <1>;
	#size-cells = <0>;
	cell-index = <1>;
	compatible = "fsl-i2c";
	reg = <0x3100 0x100>;
	interrupts = <15 0x8>;
	interrupt-parent = <&ipic>;
	clock-frequency = <400000>;

	ltc4245@XX {
		compatible = "LLTC,ltc4245";
		reg = <0>;	// from bootloader
	};
};

I'd like to be able to send platform data to the drivers/hwmon/ltc4245.c
driver. On my platform, this is probed automatically using the device
tree snippet above.

Thanks,
Ira

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

  parent reply	other threads:[~2010-05-26 19:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-13 22:59 [lm-sensors] [PATCH 2/2] hwmon: (ltc4245) expose all GPIO pins as Ira W. Snyder
2010-05-26 11:31 ` [lm-sensors] [PATCH 2/2] hwmon: (ltc4245) expose all GPIO pins Jean Delvare
2010-05-26 15:42 ` Ira W. Snyder
2010-05-26 16:36 ` Jean Delvare
2010-05-26 17:22 ` Ira W. Snyder
2010-05-26 18:42 ` Jean Delvare
2010-05-26 19:39 ` Ira W. Snyder [this message]
2010-05-26 20:37 ` Grant Likely
2010-05-26 20:56 ` Ira W. Snyder
2010-05-26 21:00 ` Jean Delvare
2010-05-26 21:10 ` Grant Likely

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=20100526193902.GC17367@ovro.caltech.edu \
    --to=iws@ovro.caltech.edu \
    --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.