Hi Ben Dooks, Thanks very much for your excellent reply. ;-) 2009/5/4 Ben Dooks <ben-linux@xxxxxxxxx>: > On Mon, Apr 27, 2009 at 11:32:26PM +0800, ?????? wrote: >> Hi, >> >> As a compromise,we hope make the phone system free to run even the i2c >> subsystem become busy already.Then there maybe time to choose some >> useful way to solve that. The console can not input when phone hang >> now. >> >> So we try to make the sleep time in i2c layer long enough,but the >> result not well,because there are many threads waiting for i2c bus >> operation.The key threads such as serial console could not get chance >> to run,or cannot interact with user timely. >> >> Anyone could give a hand about this? > > Generally, if you're increasing sleep times, then you've either got > an electrical issue with the bus, or there is a device on there which > is causing the bus to be slowed down. > > Firstly, electrical issues: > > 1) Verify by measuring the clock pulses on the bus that it is > running at the rate you expcet it to be. It can be very > embarasing stating that your bus is 100KHz, when your hardware > engineer's scope is saying 100Hz. > > 2) Are the rise times on either of SCL or SCA excessive? The bus > relies on something pulling these lines inactive, and if there > is either insufficient pull-up resitance (4.7 - 10K for 100KHz > is iirc recommend) or too much capacitance then the bus can be > held up waiting for these signals to reach inactive after they > have been asserted > > 3) Are all the chips soldered on correctly and in the correct > orientation? > > 4) Has the board been tested and known to work? > Yeah,it works most of the time.And i2c unit become busy very random. > 5) Get a logic analyser and watch the traffic, look for how long > it takes to complete a transaction and how often they are being > issued. > > I would ask our hardware engineers for help about your other good suggestions. > Another issue is are there any 'soft' devices on the bus, such as > a power management microcontroller. If there are any devices that > have (or have to) have firmware to work, do they have the correct > firmware and has this firmware been verified to work? No,we donot. > > My last real PXA work was ~2.6.9, but it was working fine then. I > currently don't have any PXA devices with working kernels to do > any testing of a current kernel. Thanks again. :-) --Yize > >> Thanks in advance again. >> >> --Yize >> >> 2009/4/27 ?????? <wxc200@xxxxxxxxx> >> > >> > thanks your reply ,Jean and Mike >> > >> > Winston Churchill ??- "The best argument against democracy is a five-minute conversation with the average voter." >> > >> > 2009/4/27 Mike Rapoport <mike@xxxxxxxxxxxxxx> >> >> >> >> >> >> Jean Delvare wrote: >> >> > On Mon, 27 Apr 2009 15:57:45 +0800, ?????? wrote: >> >> >> We use Marvell's pxaXXX chip,and the i2c unit often become BUSY status .As >> >> >> normal operation,the Unit-Busy will become free quickly,but sometimes >> >> >> UNIT-BUSY forever.For there are very frequent i2c operations,the cell-phone >> >> >> become hang soon,nothing could be done but remove the battery and reboot. >> >> >> >> >> >> So could you give a suggestion? ??Is there any useful way to protect from >> >> >> entering this abnormal UNIT-BUSY i2c status or recover from that? >> >> >> >> PXA I2C controller often reports BUSY when one of the I2C lines are held low. >> >> Verify you have proper pull-ups and that devices connected to I2C bus behave in >> >> a sane way. >> > >> > Yes,we do.The unrecoverable problem is UNIT-BUSY,we still be confused by the root cause.Now we guess there are two types of answers: >> > >> > 1) Another master left I2C busy in abnormal status after operation >> > 2) Protocol conflict violation caused by messages transfer,such as the?? too large?? message or wrong operation.Most of the time,I2C works fine. >> > >> > We thought there would be some reset mechasim in that bad situation,but not. >> > There are many threads waiting for the mutex lock while the current operating one is trying,trying,and trying,,,but I2C Unit Busy block all. >> > >> > -- Yize >> >> >> >> > I don't know anything about PXA platforms, there's nothing I can do for >> >> > you, sorry. >> >> > >> >> >> >> -- >> >> Sincerely yours, >> >> Mike. >> >> >> > >> -- >> 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 > > -- > Ben (ben@xxxxxxxxx, http://www.fluff.org/) > > 'a smiley only costs 4 bytes' > -- 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
