todo

I2C总线LINUX驱动程序

I2C / SMBus TODO list
Contact us if you have comments or wish to help.
------------------------------------------------

* Only chip driver modules are locked in memory when one accesses their
  /proc entries. Bus drivers are never locked (i.e. no reference count
  is done). Bus drivers should be locked by the simple fact that a client
  uses them (which would make it impossible to unload them before
  all using client drivers have been unloaded themselves). This might be
  restricted to clients that actually have /proc entries.

* "uninstall" Makefile target.

* i2c-algo-bit problems, and unfinished i2c-algo-biths
  See the following two entries marked D.E. (Dori Eldar's suggestions),
  and see the email thread at the bottom of this file.

* Timing considerations in SMBus emulation with i2c-algo-bit (D.E.):
  (Note that some of these changes are implemented in i2c-algo-biths)
  The Smbus defines a minimum frequency of 10 KHZ for driving the bus, while
  the I2C does not define any minimum frequency.
  furthermore the maximum time a master is allowed to keep the CLK line high
  is 50 usec. this is required so masters can detect an idle bus
  (the CLK line is high for at least 50 usec), again the I2C does not impose
  this restriction.
  It's crucial that masters will obey the last timing consideration, since:
	1. Slaves may otherwise hang the transaction.
	2. Other masters will assume the bus is idle, initiate their own Smbus
	   transaction, which will lead to corruption of data
	   carried over the Smbus.
  Note that a correct arbitration procedure can take
  place only if masters are "synchronized" meaning, they initiate the
  transaction at the _same_ time.

  Now when implementing the Smbus protocol in SW one has to make sure that in
  the critical sections in which the CLK is held high, SW is not preempted.
  Or more simply: SW must disable interrupts at this period of time.
  This critical periods are:
	a. Waiting for an idle bus before starting the transaction until the
	   CLK is driven low after generating the START signal.
	b. For each clock cycle in the transaction: before the CLK is set
	   to HIGH till after the CLK is set LOW.

  Looking at the i2c-algo-bit.c it's very problematic to add the interrupt
  disabling code since the code may sleep in the critical period at the
  "sclhi" function.
  You would also need to add a "wait for idle bus" before the driving the
  START signal. 

* Arbitration in SMBus emulation with i2c-algo-bit (D.E.):
  Although the I2C disallows arbitration between masters while one is sending
  a restart signal & another sending a data signal, this situation is
  theoretically possible on an Smbus.
  So you would need to check for arbitration when driving the restart signal
  too. BTW why is the arbitration check code disabled in the i2c_outb?

* Dynamic data length read on BlockRead & BlockProcess calls
  in SMBus emulation with i2c-algo-bit (D.E.): 
  These 2 Smbus commands digest the read data in-order to decide on the fly
  how many data bytes to read.
  Such a requirement is not described by the I2C protocol and is not
  implemented in the i2c-algo-bit.c.
  Perhaps we could add a flag which will turn on some digesting code in
  "readbytes" routine which will mimic the Smbus behavior.

* Pre-Post routines with i2c-algo-bit (D.E.): 
  Before & after driving an Smbus transaction, if HW must be accessed, such
  access is not possible with current algo-bit design. It's possible to allow
  such access by doing
  an EXPORT_SYMBOL(i2c_bit_xfer) therefore making the algo-bit available as a
  library function only. Or by adding a post & pre function pointers to the
  algo-bit structure.

* 16-bit Register Addresses
  There is no support for 16-bit register addresses (used by serial
  eeproms larger than 16K bit, such as the Atmel 24C32) in i2c-core.c
  or i2c-dev.c.
  Emulation support is required.
  General 16-bit support for all transaction types will require
  many changes. Support for 16-bit address block
  accesses only can be added more easily, and the
  functionality #defines I2C_FUNC_SMBUS_READ_I2C_BLOCK_2 and
  I2C_FUNC_SMBUS_WRITE_I2C_BLOCK_2 have been added to i2c.h.
  This may be enough to begin with for these new eeproms.
  The emulation layer has not been implemented.
  Note that writes with an arbitrary number of address bytes
  are actually supported now by treating the extra bytes as
  the beginning of the data.
  There is an alternate proposal from Wolfgang Denk <[e-mail]>
  for a driver 'i2c-simple' that supports a generalized address
  length of 1-4 bytes and accesses via ioctls on /dev.

* Host-as-slave mode in i2c adapters may need to be integrated
  with the adapter host code, because the lm_sensors-type chip driver
  architecture is not well suited to implementing a chip slave,
  the slave mode will require locking with the master mode, and
  specialized commmunication such as "Notify ARP Master".
  Adapters may respond to one or more host-as-slave addresses. The
  functionality bits and the rest of the API will have to be extended
  to support slaves embedded in host adapters.

* 64-bit functionality values may be required to represent all
  the new capabilities described above.

* The Maximum SMBus block transfer size is 32 bytes,
  as defined in the SMBus specification, and
  assumption is scattered throughout the code. Replace hardcoded '32'
  throughout the code with I2C_SMBUS_BLOCK_MAX to be clear.

* Emulation layer i2c block reads are fixed at 32 bytes and there is
  currently no method to change it. You cannot, for example,
  read an entire serial eeprom with a single block read, or read
  only the 7 bytes in a clock chip. There is no i2c limitation on
  block size but the code is designed for the 32 byte limit of
  SMBus.

* Enhance mkpatch so it will patch additional drivers such as
  the Power PC modules to 2.4 kernels that support it. Currently
  these drivers are not patched because it would break 2.2 kernels.

* i2c version strings were added to i2c.h but they are used only
  for printk's. Integers would be better for use in preprocessor
  directives for conditional compiles.

* Alternative i2c implementations in kernel to be converted to
  the standard i2c implementation in this package.
  Most if not all of these are bit-banging algorithms,
  for which the official driver is drivers/i2c/i2c-algo-bit.c.
  For a good example of using i2c-algo-bit, see drivers/acorn/char/i2c.c.
  i2c-old.h was removed in kernel 2.5.1.

	drivers/media/video/i2c-old.c	Used by:
		drivers/media/video/buz.c
		drivers/media/video/i2c-parport.c
		drivers/media/video/saa7110.c
		drivers/media/video/saa7111.c
		drivers/media/video/saa7185.c
		drivers/media/video/stradis.c
		drivers/media/video/zr36120.c
		drivers/media/video/zr36120_i2c.c
	arch/ppc/mbxboot/iic.c
	drivers/media/radio/radio-trust.c
	drivers/media/video/pms.c
	drivers/media/video/stradis.c
	drivers/net/acenic.c
	drivers/net/sk98lin/ski2c.c
	drivers/sbus/char/envctrl.c
	drivers/sbus/char/vfc_i2c.c
	drivers/scsi/cpqfcTSi2c.c
	drivers/usb/ov511.c

* Make sure the /proc registration code in i2c-core uses the same debugging
  code and other conventions as the rest of the file.

* Make especially i2c-core SMP-safe. This means: locks around all global
  variable access, especially during (de)registration activity.

* Check debugging levels in all modules are sane.

* linux/Documentation/devices.txt lists i2c0, i2c1 etc. instead of i2c-0, i2c-1

* At least the bit-lp and bit-velle modules do no detection on loading;
  ask Simon whether this is possible to add.

* Correct all module locking code (see Keith Owens' email about this)

* i2c-algo-bit problems, and unfinished i2c-algo-biths
  Below is a reformatted email thread between Kyosti Malkki and MDS,
  November-December 2002, on the lm_sensors mailing list.
  This discussion identifies timing and multi-master
  problems in i2c-algo-bit. Kyosti wrote a new driver, i2c-algo-biths,
  which attempts to fix these problems. The new driver has not been
  heavily tested and may be incomplete; the old driver still has
  the problems identified below:

=======================================================================
Kyosti Malkki wrote:

> 
> I have no scope around to check this, but looking into i2c-algo-bit.c,
> adap->udelay is used where it is not necessary. As an example, udelay=3
> would look roughly like 25/75 duty cycle:
> 
> SDA: -._________---._________---.------------.-
> SCL: _.___---______.___---______.___---______.-
>         ^     ^  ^   ^     ^  ^   ^     ^  ^
> 
> Dots just point out where sw goes for next bit, others 1 us wide each.
> That is, all bus transitions use adap->udelay, where a rise/fall delay
> of 1 us (or less) would do.
> 
> Removing the unnecessary 2us marked ^ _above_ :
> 
> SDA: -._____-._____-.------.-
> SCL: _._---__._---__._---__.-
>             ^ ^      ^    ^
> 
> When successive bits to put on bus are equal, SDA rise/fall may be
> omitted.
> 
> SDA: -._____.____-.-----.-
> SCL: _._---_.---__.---__.-
> 
> Interrupt service and PCI latency may add to the delay time.  Any
> decrease is not possible, if write-read sequence is used in
> setscl() and setsda(). Right ?
> 
> In the process I tested using nominal 1us delay everywhere, and
> i2c_adap->udelay only to clock bits in and out.  I believe it does not
> violate specs, but will likely fail with higher bus capacitance.
> This changes duty-cycle and might break some support, so I won't commit
> it now. It does improve the speed upto 333 kbps, using adap->udelay=1.
> 

=======================================================================
MDS:

The last time I used a scope on the i2c bus (quite a while ago), I was
surprised to see that
the clock was not a 50/50 duty cycle. But that's what the code does.
I don't think it's correct, or at least it isn't optimal.

If I'm looking at your 2nd picture correctly, it looks like it
implements
a 50/50 duty cycle. That looks right to me.
I don't understand why there are udelays() in the sdalo() and sdahi()
functions.

I just recently added some comments to i2c-algo-bit.h about the units,
(I kept forgetting myself, and others would ask periodically too)
and made some fixes to the drivers to handle HZ != 100.

What the comment I added says, and it isn't strictly true,
is that clock rate = 500,000 / udelay. It does mean that
the minimum half-cycle time (either high _or_ low) is == udelay.

Chip datasheets generally specify maximum I2C clock rate.
They _dont_ specify minimums for clock low or clock high,
it is implied to be == 1 / (2 *  maximum rate).

We don't want to violate that. If udelay == 5, 
(which implies a 100 KHz clock) that should
be the minimum time high _or_ low for the clock.
So I don't think your third picture below should be implemented.

I agree that any latency assurance should be in the setsda() and
setscl() functions.

=======================================================================
KM:

On Wed, 27 Nov 2002, Mark D. Studebaker wrote:

> If I'm looking at your 2nd picture correctly, it looks like it
> implements a 50/50 duty cycle. That looks right to me. I don't
> understand why there are udelays() in the sdalo() and sdahi()
> functions.

It was udelay/3 duty cycle. Some setup and hold time is required,
1 us is around 66 PCI clocks.

> We don't want to violate that. If udelay == 5,
> (which implies a 100 KHz clock) that should
> be the minimum time high _or_ low for the clock.

If we use 1us in sdahi/lo, and udelay=3 for sclhi/lo,
we get duty cycle of udelay/(udelay+2):

SDA: -__--------_______---------
SCL: --__---_____---_____---____

Finally, with SDA half of SCL clock rate and (udelay-1) offset:

SDA: -______________-------------______
SCL: --___---___---___---___---___---___

As for other issues in algo-bit:

At several locations, return code of sclhi() is silently ignored,

I think I replace i2c_start with i2c_repstart -- if SCL is already low,
we may have multi-master or bus stuck. To count for possibility of a
second master, we should read back SDA level on master write slots.

Are return values of i2c_transfer and friends explained somewhere?


=======================================================================
MDS:

I looked carefully at the loops in i2c_outb() and i2c_inb().
These are what set the timing and duty cycle for most of an i2c bus
cycle.
I'm (for the moment) ignoring timing and issues outside these loops.
If any of these statements don't look correct, speak up :)

- i2c_outb generates a 33% duty cycle clock (udelay high, 2 * udelay
low)
- i2c_inb generates a 50/50 clock (udelay high, udelay low)
- Neither function calls sdahi or sdalo inside its loop in normal
operation,
   so changes to sdahi/sdalo won't affect the duty cycle.
- It appears that we can make changes to i2c_outb to get a 50/50 clock.
  The loop from i2c_outb() is annotated below. Note that these
  changes don't correctly handle delays coming into and out of the loop.



	/* assert: scl is low */
	for ( i=7 ; i>=0 ; i-- ) {
		sb = c & ( 1 << i );
		setsda(adap,sb);
// The following udelay ensures setup time to the r.e. of the clock,