[i2c] mixed-speed I2C system
menon.nishanth at gmail.com
Thu Apr 12 03:15:44 CEST 2007
Jean Delvare stated on 4/8/2007 12:22 PM:
> > Interconnection bridges, just as multiplexers, define bus segments,
> > what matters as far as Standard mode vs. Fast mode I2C is concerned is
> > exactly that: bus segments. We don't yet fully support multiplexing,
> > but when we do, the idea will be to have one struct i2c_adapter for
> > every bus segment. This is what the motherboard-specific
> > i2c-amd756-s4882 driver does, for example.
I must admit I am a novice at the multiplexing I2C concept. A bit of
googling and digging through source, my understanding is as follows..
for a multiplexer, the bus segments are pre-defined. The adapter knows
before hand the capability of the muxer - in terms of num segments that
it can support. The implementation as in i2c-amd756-s4882 makes sense.
The "virtual channel" concept makes sense for muxers which need to do
special programming, and ofcourse there are muxers which act
transparently - in which case a normal adapter driver will suffice.
Now, for an adapter which is capable of working in a range b/w 100Khz to
3.3Mhz(both as a master and slave), the bus can have bridges which
isolate clock ranges. Also, the same adapter driver needs to handle n
different instances on SOC(each with its own bus segments). This is bus
segments. However, based on the board, the number of segments can vary.
I am hoping to write an adapter driver which I don't need to
"adapt" to every single board. If I look at an implementation like that
done for muxer driver, it will not work out as I need the segment
characteristics to be defined at board file level. And this is the crux
of the issue I face - there is no agreed upon way to do this.
In short, I am convinced, from the discussion, that the best approach is
considering them as bus-segments. How this is to be done is the matter
of interest to me.
> > So if we ever enable some form of automatic speed selection between
> > Standard mode and Fast mode, this will have to be enabled on a
> > voluntary basis, this can't be the default.
I agree to your view.
> > I am totally fine with a flag to handle the HS mode, it should work
> > fine.
> > Calling set_i2c_speed() before every transaction is not going to
> > happen. HS mode is a per-device attribute, the master can switch to HS
> > mode automatically. Fast mode is a per-bus-segment attribute, you
> > change it.
The Master needs to know if the transaction is to be done in HS/FS/LS.
This can be pulled from bus segment characteristic. However, some
co-relation needs to be done b/w bus-segment characteristics vs
capability of the device. HS devices normally would have a range of
supported speeds (based on Tlow and Thigh values), and adapters would
have their restrictions. Some sanity check will need to be done - and
this'd be common for all adapters and makes sense to move it up to core
level. Ideally, a port effort should only include defining the device
->bus segment, bussegment characteristics, the rest automagically taken
> > No, speed isn't a resource, no matter how you look at it.
:) yup.. convinced ;) .
> > You can't say "this was done", given that this is your own patch, and
> > it is only a proposal, your patch isn't upstream.
> > I think that we don't need these. The I2C specification says that
> > devices should stretch the clock if the master is faster than they
> > would like. So if, say, a slave can run at 300 kHz and the master runs
> > at 400 kHz, it should work just fine, the slave should stretch the
> > clock line to slow it down to 300 kHz. If it doesn't work, it means
> > that either the master device or the slave device does not fully
> > implement the I2C specification.
Real-life h/w is filled with spec-compliant capable and
spec-near-compliant devices unfortunately. But overall, segment concept
should solve this. If the adapter cant talk, then bus segment needs to
be at a lower speed(provided the adapter supports).
> > I know where the file is, thank you. My question was: how does it
> > If i2c-pxa already implements slave support without the help of
> > i2c-core, then what infrastructure are you asking for?
:) this driver is compile time slave/master. Now, I have an i2c
controller which is capable of master /slave - ofcourse only one at a
time for one controller instance. But, I have n instances of the same.
Each capable of being slave or master based on board. The framework wont
let me do it unless I create two drivers - one for slave and other for
master - define separate adapters for them.. Not exactly efficient, but
could work. Can we do this with a cleaner support from i2c-core(like
able to write a single adapter driver which can be used as both
slave/master based ofcourse on board defns)? Maybe a seperate thread of
More information about the i2c