[i2c] Do we have High Speed I2C Support now ?

Nishanth Menon menon.nishanth at gmail.com
Thu Nov 16 10:09:47 CET 2006


Hi Jean,

Jean Delvare stated on 11/16/2006 1:04 PM:
> If you want to contact Nishanth, you better explicitely send your post
> to him, I'm not certain he is subscribed to the i2c list. I'm adding
> him to the list of recipients now.
> 
>> http://lists.lm-sensors.org/pipermail/i2c/2006-August/000199.html
Thanks. Yup, i am part of the list.. only i have been traveling and been
lazy in opening my thunderbird.. :)

>>
>> I didn't find any further discussion on this topic. I was interested to
>> know if this patch was considered/being-considered.
> 
> I admit I didn't have the time to review it back then, although it was
> still on my todo list.
> 
> The main problem I see with this patch is that it is based on i2c-SVN,
> which is an out-of-tree i2c implementation for Linux 2.4. It is in
> maintenance mode, no new features are being added to this tree. The I2C
> high-speed mode efforts belong to the Linux 2.6 kernel tree, where all
> the development is done now.
The flag based approach works on SVN and also on the linux 2.6 tree.
> 
> I also notice the use of backslashes in file paths, where slashes are
> expected, so I wouldn't even be able to apply this patch if I tried.
yup.. my mistake, i did create the patch off window based diff util,
hence the slash mess up.. the code source however was on linux.. so
slash-the-backslash and it should be up and running.
> 
>> Do we have any other way of handling HS I2C now?
> 
> No, we don't.
> 
>> Please suggest.
> 
> I would like to see a discussion about this implementation. We need to
> know the exact needs. What system does need it and why? Which bus
> masters are high-speed capable out there? Not that many, if any.
> 
there are at least two to my knowledge.. HSI2C IP is the crux.. am not
sure how many folks have capability to do it.. but it is hellua lot
faster than full speed in my experience.. :)

> This proposal adds a message-based high-speed flag, this seems to be
> finer-grained than what we need. I don't think we want to mix
> high-speed and normal messages in a single transaction. The high-speed
> capability is an attribute of the I2C slave (and I2C master), so the
> flag should be an i2c client flag, as PEC is. In fact it should be
Not true completely, u can have mixed mode devices. hsi2c devices can
support fs mode, and what if u put a hsi2c device on a fs bus, or on a
hs bus, but have connectivity problems (board level - say someone forgot
to put a i2c bridge to isolate fs devices on the same bus), and then ur
forced to run messages on fs.. so the flag capability is required in
client,controller and message level - to provide flexibility and sanity.

> handled the exact same way PEC is handled in Linux 2.6, as far as I can
> tell. That is, i2c clients advertise their high-speed support, and i2c
> bus drivers check for the flag and use high speed if they can.
not flexible enough. it might need hacks in the future if the board
misbehaves (at 3.4mhz, things can and have gone wrong).
here is another reason:
At hs, u incurr the overhead of a MCODE at FS (=8 bits) followed by HS
transactions, now why would i want to do a HS transaction for just a
single byte write operation? it would be unoptimal even if the device
was an HS device.

> 
> I also have one question about high speed. Are there I2C chips which
> only support high speed, or must they all support at least normal mode
> as a fall-back? Same question applies to fast mode, BTW, maybe we
the ones I have seen do support fallback. the simple market reason: not
all controllers are HS capable.. so u dont want to make a chip which is
HSonly without a good enough reason.. the protocol differs ever so
slightly..
> should handle all three speeds while we are here. If some chips only
> support faster speeds, then the flag-based approach is not correct and
> we need a bit-vector for the speed.
That sounds better idea than flags i introduced. the problem is worse:
some devices state max T-high, T-low values for thier clocks, which is
usually not symettric and can cause problems if the controllers do a
symettric config, how do we handle it?
> 
> So if you are interested in adding high-speed support, please answer
> the questions above, from there we can decide what implementation would
> be correct, and after that you'll have to provide a patch against Linux
> 2.6 (latest). And we'll need in-tree users of the new feature, too,
> else we can't push the change upstream.
> 

we did something flexible in u-boot, however, uboot is too simple a
architecture to pull over here.. bit-vectors sound plausible, yet is not
flexible enough to handle all the devices in the market.. i think we
need to meet the following reqirements:

*) granularity for speed for a single transaction
*) should have capability to set low and high times for a clock
*) should have capability for device and controller configs
*) sanity checks to handle the same
*) changes to lm-sensor utils to test these..burst support etc.. will
need tweaking of i2c-dev   too.

I dont know how much sane the concept of flexible t-high t-low is per
device, the setup overheads are bad... but that is my 1 cent worth of
views :)

Regards,
Nishanth Menon



More information about the i2c mailing list