Hi Mark, Marek Vasut writes: > Dear Lothar Waßmann, > > > Hi, > > > > Marek Vasut writes: > > > Hi Lothar, > > > > > > > The timing calculation is rather bogus and gives extremely wrong > > > > results for higher frequencies (on an i.MX28). E.g. instead of 400 kHz > > > > I measured 770 kHz. > > > > > > > > Implement a calculation that adheres to the I2C spec and gives exact > > > > results for I2C frequencies from 12.56 kHz to 960 kHz. > > > > > > > > Also the bus_free and leadin parameters are programmed according to > > > > the I2C spec for standard and fast mode. > > > > > > I suspect the resulting speed is heavily dependent on hardware properties > > > of the bus. Did you have a chance to check it with a scope? I will try > > > to recheck on other boards next week. > > > > Of course I did! I found the DS1339 RTC not working on our hardware > > with the I2C clock frequency set to 400kHz and then checked the bus > > timing. I found the SCL frequency to be 770kHz instead of 400kHz and > > 113kHz instead of 100kHz. > > On what hardware did you do your measurements? > > MX28EVK and M28EVK. > > > The fancy constants -2 and -7 in the calculation were derived from > > measuring the clock low and high time with low_count and high_count > > set to 1 and measuring the actual timing of the signal. > > The clock frequeny in this setup is 2.18 MHz corresponding to 11 clock > > cycles of the 24MHz clock. The LOW time was about 140ns and the HIGH > > time 318ns corresponding to 3 and 8 (instead of 1) clock cycles. > > > > These constants could be different for different SoCs (i.MX23). > > But I don't have any hardware to verify that. > > I can check it for you on MX23 next week, I have two boards with that chip with > well accessible I2C. I am not in the office now, so this will have to wait until > next week. > Did you have time to look into this? And also recheck the timing on the i.MX28? Because there obviously is a fundamental discrepancy between your and my measurements. > btw offtopic, I will at least try to fix the PIO in the meantime. > Did you succeed at this? Because this is the real problem for the DS1339 failing on our board. With DMA only transfers it works, but other chips (TSC2007, PCA9554, SGTL5000) fail. I also tried to get the PIO transfers working but didn't have any success. Interestingly all the chips mentioned above worked flawlessly with the 3.3 kernel. That should exclude any HW deficiencies of our modules or the I2C interface of the i.MX28 in general. What disturbs me most is the sequence of accessing the I2C DATA register and clearing the DMAREQ bit. Normally you should clear the DMAREQ _before_ accessing the DATA reg, because the access will trigger a new assertion of DMAREQ. Thus clearing that bit _after_ the access (like suggested in the i.MX28 Ref Manual and currently implemented in the driver) is racy and potentially leads to inadvertently clearing a fresh DMAREQ condition. But handling it 'the right way' in the driver doesn't improve anything. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info@xxxxxxxxxxxxxxxxxxx ___________________________________________________________ -- 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
