Re: i2c and indirect vs. direct config

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Jason Thorpe <thorpej%me.com@localhost> writes:

[snip]

> NOW.  i2c_scan defaults to doing a “quick write”, HOWEVER, that code has the comment about the “quick write” method corrupting the EEPROM on Thinkpads.  But it also has a comment about the “receive byte” method possibly causing problems with write-only devices?
>
> So, I’m a little perplexed about what to do… perhaps the “receive byte” method is the best for now?
>
>
[snip]

Unfortunate behavior.  Looking back over the sensor driver I worked on,
it appears that I always read something to determine if the device was
actually there.

I note that the gpioow, a onewire bus, may have simular ghost issues as
i2c:

[    7.496848] gpioow1 at gpio0 pins 25: can't map pins
[    7.516852] gpioow2 at gpio0 pins 25: can't map pins
[    7.536858] gpioow3 at gpio0 pins 25: can't map pins

There is only one device present, and it is wired down in the config
file to a particular gpio parent and pin, but it manages to ghost 3
times anyway.  [Unrelated topic, gpioow is a module, onewire is a
module, but owtemp isn't, so you really end up not being able to modload
the them into place with the "generic" RPI kernel, hence a config file]


I wonder if the i2c bus attachments should have the option of being
treated like gpio attachements with a new command... probably a lot of
work:

iicctl iic2 attach dstrc 0x68 3231

> -- thorpej



-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org