Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: i2cocore_wb16.vhd Type: application/octet-stream Size: 4559 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20081029/ea03ae71/i2cocore_wb16-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: i2c-ocores-pod.h Type: text/x-chdr Size: 706 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20081029/ea03ae71/i2c-ocores-pod-0001.h -------------- next part -------------- A non-text attachment was scrubbed... Name: i2c-ocores-pod.c Type: text/x-csrc Size: 15867 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20081029/ea03ae71/i2c-ocores-pod-0001.c

>>>>> "FM" == Fabien Marteau fabien.marteau at laposte.net> writes: FM> Hello, FM> I integrated i2c-ocore IP with a wrapper to convert wb8 to wb16 (see FM> attached) FM> and that work well with a simple driver test program. Good. FM> First, I tried to integrate the driver provided in linux kernel source FM> "i2c-ocore.c" and I found some bug. When I load the module, i2c components FM> already loaded in kernel probe the bus with SMBus Write Quick command : New-style i2c drivers no longer do unsafe probing. FM> A Addr Rd/Wr [A] P FM> To send this smbus command with ocore, it's necessary to set START bit FM> and STOP bit together, the driver doesn't do that and block the bus. Hmm, I haven't ever seen that issue, and we've been using the hw/driver for years... Strange. FM> Second, ocore interrupt is generated just before the ACK, then if driver FM> read the status register too fast, it can read no ACK instead of ACK. FM> A Addr Rd/Wr |interrupt| [A] Data |interrupt| [A] ... I think I once saw that on a design, but I don't remember the details here - Could be that the irq latency simply masks it away. FM> I know that i2c-ocore is an old IP, then maybe these problem is just my FM> misunderstanding of code, but I re-wrote the drivers to support SMBus FM> commands FM> separately and its work well with two components : DS1621 (temperature) and FM> LIS3LV02DL (accelero). Could you send the changes as patches (unified diff) to i2c-ocores? It's easier to review like that. FM> For this moment, SMBus commands supported (see FM> linux/Documentation/i2c/smbus-protocol) are ,SMBus Write Quick, SMBus Byte, FM> SMBus Byte Data, SMBus Word Data. Aren't those automatically emulated by the I2C core without the driver having to do anything? -- Bye, Peter Korsgaard