[i2c] [PATCH] Is review of AT91 patch pending?

arasv at magtech.com.au arasv at magtech.com.au
Wed Nov 7 23:37:37 CET 2007


> On Wed, 7 Nov 2007 12:35:17 -0800
> David Brownell <david-b at pacbell.net> wrote:
>
>> > Users that know what they are doing can adjust this
>> > value themselves, or should it be in Kconfig?
>>
>> One suggestion to Haavard (maintainer of i2c-gpio) is to
>> switch the platform data so it can use ndelay() ... that
>> way it can support higher clock rates (e.g. 1Mbit Fm+).
>
> Yeah, but it would involve changing i2c_algo_bit, and all the other
> drivers that depend on it, since the i2c-gpio driver simply passes the
> udelay parameter along without looking much at it.
>
>> I tend to think Kconfig here would be confusing overkill.
>
> Yeah. Why not add a module parameter while we're at it? ;-)

Why not make it dynamic?

A while ago I thought that the i2c-gpio driver was a good substitute for an
i2c mux chip. I think this makes the driver a very attractive option and I
may need to do this in the future with our own product.

How would the driver handle the situation where each i2c bus might require a
different speed?

e.g if one i2c bus was used for a local i2c device that could be run at
100KHz+ while a second bus was a very long cable with a much lower bandwidth?


Aras


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



More information about the i2c mailing list