Changeset 4356 for i2c/trunk/TODO
- Timestamp:
- 04/01/07 14:29:24 (2 years ago)
- Files:
-
- i2c/trunk/TODO (modified) (9 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
i2c/trunk/TODO
r4158 r4356 18 18 * Timing considerations in SMBus emulation with i2c-algo-bit (D.E.): 19 19 (Note that some of these changes are implemented in i2c-algo-biths) 20 The S mbus defines a minimum frequency of 10 KHZfor driving the bus, while20 The SMBus defines a minimum frequency of 10 kHz for driving the bus, while 21 21 the I2C does not define any minimum frequency. 22 22 furthermore the maximum time a master is allowed to keep the CLK line high … … 26 26 It's crucial that masters will obey the last timing consideration, since: 27 27 1. Slaves may otherwise hang the transaction. 28 2. Other masters will assume the bus is idle, initiate their own S mbus28 2. Other masters will assume the bus is idle, initiate their own SMBus 29 29 transaction, which will lead to corruption of data 30 carried over the S mbus.30 carried over the SMBus. 31 31 Note that a correct arbitration procedure can take 32 32 place only if masters are "synchronized" meaning, they initiate the 33 33 transaction at the _same_ time. 34 34 35 Now when implementing the S mbus protocol in SW one has to make sure that in35 Now when implementing the SMBus protocol in SW one has to make sure that in 36 36 the critical sections in which the CLK is held high, SW is not preempted. 37 37 Or more simply: SW must disable interrupts at this period of time. … … 51 51 Although the I2C disallows arbitration between masters while one is sending 52 52 a restart signal & another sending a data signal, this situation is 53 theoretically possible on an S mbus.53 theoretically possible on an SMBus. 54 54 So you would need to check for arbitration when driving the restart signal 55 55 too. BTW why is the arbitration check code disabled in the i2c_outb? 56 57 * Dynamic data length read on BlockRead & BlockProcess calls58 in SMBus emulation with i2c-algo-bit (D.E.):59 These 2 Smbus commands digest the read data in-order to decide on the fly60 how many data bytes to read.61 Such a requirement is not described by the I2C protocol and is not62 implemented in the i2c-algo-bit.c.63 Perhaps we could add a flag which will turn on some digesting code in64 "readbytes" routine which will mimic the Smbus behavior.65 56 66 57 * Pre-Post routines with i2c-algo-bit (D.E.): … … 114 105 block size but the code is designed for the 32 byte limit of 115 106 SMBus. 116 117 * Enhance mkpatch so it will patch additional drivers such as118 the Power PC modules to 2.4 kernels that support it. Currently119 these drivers are not patched because it would break 2.2 kernels.120 107 121 108 * i2c version strings were added to i2c.h but they are used only … … 150 137 drivers/usb/ov511.c 151 138 152 * Make sure the /proc registration code in i2c-core uses the same debugging153 code and other conventions as the rest of the file.154 155 139 * Make especially i2c-core SMP-safe. This means: locks around all global 156 140 variable access, especially during (de)registration activity. … … 240 224 241 225 We don't want to violate that. If udelay == 5, 242 (which implies a 100 KHz clock) that should226 (which implies a 100 kHz clock) that should 243 227 be the minimum time high _or_ low for the clock. 244 228 So I don't think your third picture below should be implemented. … … 261 245 262 246 > We don't want to violate that. If udelay == 5, 263 > (which implies a 100 KHz clock) that should247 > (which implies a 100 kHz clock) that should 264 248 > be the minimum time high _or_ low for the clock. 265 249 … … 468 452 Start", "Low period of SCL" and "SCL clock frequency". 469 453 With 1us resolution best we can do within fast mode specs is 470 udelay=2 and get 250 kHz. I think stock kernel tree doesn't export454 udelay=2 and get 250 kHz. I think stock kernel tree doesn't export 471 455 anything to improve the resolution, so I will settle for udelay. 472 456 … … 540 524 > > Start", "Low period of SCL" and "SCL clock frequency". 541 525 > > With 1us resolution best we can do within fast mode specs is 542 > > udelay=2 and get 250 kHz. I think stock kernel tree doesn't export526 > > udelay=2 and get 250 kHz. I think stock kernel tree doesn't export 543 527 > > anything to improve the resolution, so I will settle for udelay. 544 528 > >
