[i2c] mixed-speed I2C system

[Nishanth Menon]

Hi Jean,

Appreciate your views.
Jean Delvare stated on 4/3/2007 3:27 AM:
>>>
>>> max supported clock may be an attribute of i2c clients and i2c masters
>>> so the i2c framework can find out the correct clock for the whole i2c
>>> bus.
>>>       
>
> Not really. For a given hardware setup, the max speed is a physical
> attribute of the whole bus, basically defined as the minimum of the
> maximum speed supported by each device. This holds whether or not a
>   
spec says:"13.5 Mixed speed modes on one serial bus system
If a system has a combination of Hs-, Fast- and/or
Standard-mode devices, it’s possible, by using an
interconnection bridge, to have different bit rates between
different devices (see Figs 24 and 25)."

Hmm... I don't agree in one specific scenario: HS and FS and STD speed
devices divided by a bridge on the same I2C bus (ref: :i2cspec as given
above). Defining it as a minimum of the max speed supported by all
devices would not be optimal. In such cases, we'd need to swap speeds at
xfer based, since we will have xfers for both devices which can arrive
consecutively, we'd need to differentiate bus clock speeds at xfer
level. if we all agree on this, it is just a matter of how..
> device has been created in the device driver model. So attaching a
> speed value to the devices will not cover all the possible cases. It
> will fail as soon as there are additional devices connected on the bus
> for which Linux doesn't have/need a driver, and in particular in the
> multi-master case.
>   
Proposal I suggested is that we need information of speed capability in
client and adaptor drivers. With this, i2c framework can intelligently
manipulate speeds. the scenario mentioned of additional devices added on
the bus once a configuration is compiled in is something i'd say invalid
configuration-resolved atleast with a re-compile.
> So I don't think that there is any way to enable fast-mode I2C
> automatically. Instead I believe we need to default to standard I2C (as
> we do now) and let the user explicitly switch to fast-mode I2C if
> he/she knows that his/her bus setup will support it. I was thinking of
> a sysfs attribute. I don't know if we also need an in-kernel interface.
>   
The main reason i am not infavour of this approach is due to
co-existance of multispeed devices on the same bus. as i described
previously.. i dont want to endup calling set_i2c_speed (xyz) before
every call, and inviting all kind of race conditions where my speed gets
re-set to an unsupported speed by other client drivers. by providing the
speed as a flag (as in the patch i had posted), it can handle most of
the scenarios.
>> hmm.. two considerations:
>> 1. How can a client tell the adapter of a maximum supported transfer
>> speed? esp since i2c-dev would use a direct i2c_msg transfer.
>> this could be an argument for having speed as a i2c_msg param..just a
>> suggestion..
>>     
>
> i2c-dev uses clients, it does not do direct i2c_msg transfers. Thus any
> attribute attached to regular clients can be attached to i2c-dev as
> well, using ioctls. We already do that for 10-bit addresses and SMBus
> PEC support, and I think this is also how HS-mode would be supported.
>   
yes, this approximately how I did in my patch too..
> Note that i2c-dev may need some rework to fit better in the new model
> implemented by David Brownell.
>   
I agree, this is another thing we can look at a later point of
discussion.. :)
>> As a specific example of OMAP(the controller can support all
>> frequencies), I was thinking more of using resource array
>> (flags=IORESOURCE_IO) while registering a platform_device in the board
>> specific file.
>> a) if the adapter is capable, a range defined by .start and .end
>> b) specific speed support only (with a .end=400 or .end=3400).
>> This shall give the adaptor driver a means to limit msg speed requests.
>>     
>
> This looks like an abuse of struct resource. Speed is an attribute, not
> a resource.
>
>   
The trouble i have is with exteremely intelligent h/w folks who love to
use the same controller on multiple SOCs (other than having multiple
instances of the controller), with varied device speeds on each
platform.. i have board specific files which can cater to this need..
and calling speed a i2c resource I think is a matter of looking at it
and saying it is a resource defining the bus characteristic.
scenarios:
a) single speed memory mapped controllers
something similar to this was done:
http://linux.omap.com/pipermail/linux-omap-open-source/attachments/20070402/506956db/0001-Move-i2c-adaptor-speed-from-a-module-parameter-to-pl-0001.obj
b) range of devices, memory mapped controllers:
start to end giving each speed.
c) io mapped controllers
use bus specific flags bits (0-7) to state that resource with IORESOURCE
is speed..

> I think we need to focus on the actual needs. Is there any practical
> reason to run at lower frequencies, except for the boundaries between
> modes? The only case I can think of is masters which cannot sense the
> SCL line and thus cannot support SCL line stretching. Some i2c-algo-bit
> adapters are like that, which is one of the reasons why the speed of
> i2c-algo-bit-based adapters can be chosen freely. For these, I don't
>   
this is one area i cant comment on...
> think we want to consider fast-mode nor HS-mode anyway. I don't know if
> there are hardware implementations with the same problem. For the other
> cases, it sounds like all we need to know is:
> * For slaves, can they do HS-mode?
>   
yes. There are many devices which can do it. TWL4030 from TI is one of them.
> * For masters, can they do HS-mode and can they to fast-mode?
>   
yes. at least OMAP i2c masters are capable of 100-3300khz range. I
recollect couple of discussions on U-boot list with similar
characteristics on other controllers also. but TI's I2C controller can
work in slave mode also.. only we dont have the infrastructure to
support this mode :(.

> And always pick the highest frequency that fits into a given mode.
> HS-mode can be selected automatically, fast-mode cannot.
>   
I am not entirely clear on "automatically"..
> So we can do fine-grained, half-automatic speed selection, or we can
> simplify things down to two flags. Until I see real-world scenarii, I
> just don't know what will work best.
>   
I am not convinced that a two flag approach is good, esp if i would like
to have a scenario like this:
HS devices BRIDGE FS devices BRIDGE std devices
each bridge filters out higher speed frequencies.. that should take care
of a STD speed device not understanding FS clock rate..
in this case, i think discrete speed levels should be good.
>   
>>> Russell King has added I2C slave support at least for PXA...
>>>       
>
> I'm curious. How does it work? Does this means that there is no need
> for cooperation from i2c-core to implement I2C slave support in I2C bus
> drivers? Or is i2c-pxa implementing things which should be moved to
> i2c-core? This discussion probably belongs to a different thread
> though, I doesn't seem to be related to bus speed issues at all.
>   

with a google, i think i see
http://marc.info/?l=linux-arm-kernel&m=116207345621115&w=2 as a patch to
fix slave enable for pxa.
basically should be here: drivers/i2c/busses/i2c-pxa.c

Regards,
Nishanth Menon