Hi Jean, thank you for the fast reply. See further comments in your reply: >>> Jean Delvare <khali@xxxxxxxxxxxx> 30.11.2010 18:21 >>> Hi Matthias, On Tue, 30 Nov 2010 11:26:22 +0100, Matthias Zacharias wrote: >> ** High Priority ** > There is no such thing here. People on this list reply to help requests > on their free time. This is best effort, with zero guarantee. Ok, I know this, and am happy for getting your response so quickly. >> we have to use the linux driver "i2c-gpio" because the "i2c-at91" is >> marked as "BROKEN" and for our application it can as well not be used. >> >> Here a brief description of the application: >> >> AT91SAM9261 based embedded system running kernel 2.6.25.4, with Atmel >> and our own BSP patches. This system uses both SPI interfaces, one USART >> (for console), MMC, Sound on SPI and SSC, digital poti for contrast >> control and the an chip Frambuffer for a monochrome LCD (QVGA). >> >> On the TWI interface are attached: >> the AT24C04 SMB EEPROM, (@ 0x50) >> two LM84 Temperature sensors (@ 0x18, 0x19) >> and the Infrared temperature sensor MLX90614 manfactured by >> MELEXIS. (@ 0x5A) >> Note: The LM84 sensors are not yet operated by the linux kernel. >> >> Now the description of the issue we have with the I2C subsystem: >> >> 1. the EEPROM is working fine with "i2c-at91" and the "i2c-gpio" >> modules > So at least the i2c-gpio driver isn't totally broken on your hardware. No it works, but with unpredictable results in the data output (measured temperature) >> 2. for IR-Sensor MLX90614, a hwmon class linux driver was implemented >> by Linutronix on our demand. This driver works fine but delivers >> sporadic the error message "i2c-adapter i2c-0: sendbytes: NAK bailout." >> (this message is thrown by the "i2c-algo-bit" driver), or invalid >> temperature values ( near 0xFFFF). The invalid temperature values and as >> well the error message appear as reponse on bus timeout situations which >> are not correctly handled by the linux driver. This we find out using a >> I2C analyzer. In our opinion these issues come while the i2c >> communication is disturbed by other tasks and/or interrupt service >> routines (ISR) which extend the SMB clock over the permitted timeouts, >> leaving the IR-Sensor in an undefined or erroneous state. > It's difficult to answer here without seeing the source code of the > MLX90614 driver. What I can say is that values "near 0xFFFF" look like > uncaught (negative) error codes carelessly cast to u16. So you should > ensure that your driver properly deals with errors returned by the i2c > layer (i2c_transfer and i2c_smbus_*). And if such errors happen, you > should print them so that you see what exactly is going on and when. I can provide the sources for the MLX90614 driver, but I think it is not a good ideea to attach it to this E-Mail. > If the EEPROM works fine, it may depend on the transaction types. I > can't comment further because you didn't tell us which driver you were > using (eeprom or at24). But it would be interesting to see which > transactions fail, and if there is a pattern. I access the eeprom as generic i2c device (file pointer to i2c-0) without usage of any specific driver. > For your investigation, you may be interested in backporting (the > i2c-algo-bit-part of) the following patch: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=97140342e69d479a3ad82bfd4c154c0b08fe3eea > If you hit unexpected timeout conditions, you may want to try again > after backporting this fix: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0cdba07bb23cdd3e0d64357ec3d983e6b75e541f At first I'll try the suggested patches. > More generally, you may want to change the timeout value and see if it > helps - although the default of 100 ms seem reasonable to me. changing the timeout value has no visible effect on the systems behavoir. > Note that i2c-algo-bit is CPU-driven. It doesn't sleep, so it shouldn't > be preempted by regular code, but nothing can be done against > interrupts. I see that the MLX90614 has a very short timeout when SCL > is high (45 to 55 us), so receiving an interrupt in this state could > indeed be an issue. You may want to try disabling interrupts before > raising SCL (except at the end of the transaction, of course) in > i2c-algo-bit. Please give me an example how the disable interrupts as you suggest. In the i2c-algo-bits there is used the "bit_dbg" makro to print some debug messages to ksys. Removing the makros wich where placed on the main execution line (not on for error messages) helps to get a better behavoir: SCL stretching occure on better reproducable communication times. > And, as Bill already underlined, you have to ensure that you're running > the bus at the right frequency. The MLX90614 is an SMBus compliant > device so it wants a clock between 10 and 100 kHz. This means a udelay > value between 5 and 50. I checked the clock speed, It can be changed in the specified limits for MLX90614 with similar results in the data output. Using an I2C analyzer I was able to see that SCL stretching occures on unpredictable times. If these SCL stretching is on specific point in the communication process or match the one of the SMbus timeout conditions (2 different timeout values) unpredictable data is output, with out any error from the I2C subsystem. Only the "i2c-adapter i2c-0: sendbytes: NAK bailout." message is correctly thrown. I can provide screeshots which ilustrate the behavoir. How can I make these sceenshots available for you? >> The address mentioned in the driver source "Haavard Skinnemoen >> <hskinnemoen@xxxxxxxxx>" invalid (unknown) > I presume Haavard left Atmel meanwhile. Not much we can do about that, > except removing his address from the source tree (I will do.) the last entry @vger.kernel.org was in 2007 -- Jean Delvare http://khali.linux-fr.org/wishlist.html best regards Matthias Zacharias matthias.zacharias@xxxxxxxxxxxxxxxx -------------------- BMK electronic solutions GmbH Werner-von-Siemens-Str. 6, Eingang 18 f D-86159 Augsburg Tel. +49 (0) 821 / 207 88 - 700 Fax +49 (0) 821 / 207 88 - 721 info@xxxxxxxxxxxxxxxx GeschÃftsfÃhrer: Dipl.-oec. Alois KnÃferle Sitz: Augsburg HR-Nr.: B21197 --------------------- Diese E-mail kann vertrauliche Informationen enthalten. Falls Sie diese E-Mail irrtÃmlich erhalten haben, informieren Sie bitte unverzÃglich den Absender und lÃschen Sie diese E-Mail von jedem Rechner, auch von den Mailservern. Jede Verbreitung des Inhalts, auch die teilweise Verbreitung, ist in diesem Fall untersagt. AuÃer bei Vorsatz oder grober FahrlÃssigkeit schliessen wir jegliche Haftung fÃr Verluste oder SchÃden aus, die durch Viren befallene Software oder E-Mails verursacht werden. This e-mail may contain confidential information. If you received this e-mail in error, please contact the sender and delete this e-mail from your computer, including your mailservers. Any dissemination, even partly, is prohibited. Except in case of gross negligence or wilful misconduct we accept no liability for any loss or damage caused by software or e-mail viruses. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
