On Fri, Apr 02, 2010 at 10:13:41AM +0200, Jean Delvare wrote:
> Hi Ira,
>
> On Tue, 30 Mar 2010 15:57:04 -0700, Ira W. Snyder wrote:
> > The GPIO registers on the ltc4245 behave in a strage way. Every time the
> > ADC updates the values for one GPIO, it updates all three GPIO registers to
> > the same value.
>
> This is not how I read the datasheet. The datasheet says that only one
> of the GPIO pins can be routed to the 13th input of the ADC and thus
> used as an extra analog voltage input. It also says that there is ONE
> register (U) holding the result of the conversion. Apparently many
> registers can be access using more than one address, and register U can
> be accessed using 4 different addresses (0x1c, 0x1d, 0x1e, 0x1f) but
> this is still only one register. So the fact that all addresses return
> the same value is not a surprise.
>
Ok, re-reading tables 6 and 15 in the datasheet, this makes sense now.
> > To read all three GPIO registers correctly, we cache copies of each
> > register and update the GPIO MUX to read the next GPIO register. Each GPIO
> > sample will take 3 * HZ to read, but at least we are returning the correct
> > values to userspace.
>
> I think this is wrong. You should not expose 3 values to user-space,
> you should only expose one. The two other GPIOs are supposed to be used
> in digital mode. It's not even clear to me that you should always expose
> it, as the application may be using all 3 GPIO pins in digital mode and
> not be interested in sampling an analog voltage value from any of them.
> I admit I am a little surprised that there is no way to disable ADC
> operation on the GPIO pin.
>
If I do this, how do I make userspace work?
On my board, I have three different devices hooked up to the three GPIO
pins. They're all analog voltages. From userspace, I currently read
in{9,10,11}_input and report those in volts. It works fine, and was
pretty easy to implement.
If I only report a single GPIO value to userspace, then I can only read
one device. How do I switch which GPIO pin is routed to the ADC? I could
open the /dev/i2c-0 device and poke the LTC4245_CONTROL register
directly, but that seems very anti-hwmon, doesn't it?
> > Signed-off-by: Ira W. Snyder <iws@xxxxxxxxxxxxxxxx>
> > ---
> >
> > When I implemented the ltc4245 driver, I did not have the ability to test
> > the GPIO pins. I now have devices hooked up, and they don't work exactly as
> > the datasheet describes (though it is vague in this section). See the patch
> > description for more detail.
>
> I think it does behave as the datasheet describes, I'm not sure what
> you think is vague, it looks clear to me.
>
> > I'd really like to see this picked up. I hunch I am the only user of the
> > driver, or others would have complained. :) I wish the code wasn't as ugly
> > as it is, but it is the best I can come up with.
>
> I agree the driver is broken currently, but I don't agree with the
> proposed fix. Please just drop the LTC4245_GPIOADC2 and
> LTC4245_GPIOADC3 commands, which do not exist, and rename
> LTC4245_GPIOADC1 to LTC4245_GPIOADC.
>
Ok, so I should use LTC4245_GPIOADC (0x1c) to read all of the GPIO
values. That seems fine to me, I can implement that.
See above about how to report this to userspace. I don't know how you
want this exposed in sysfs.
Ira
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
