On Tue, Apr 08, 2008 at 09:50:27AM +1000, David McCullough wrote: > > > I am just acking the interrupt, but as this driver is only capable of > > I2C master anyways, there is no reason for a new interrupt to be generated > > without driver intervention on the HW. > > > Some hardware will continue to interrupt until the condition causing the > interrupt is removed (ie., you pull the data from the chip or fix an > error condition). > > Whatever is happening in this case, it won't hurt to add trace to the > code and make 100% sure it is behaving as you would expect.
Maybe sometime I will have the time to do this. Currently I am just happy that I finally have a reliable I2C driver and can focus on the other application problems I still have... > > and I can not see a timeout on I2C hardware level it is obvious to me that > > the original problem is related to the waitqueue failing from time to time. > > Then you need to prove this, go looking for why it is happening, try and > find a way to describe in more detail what is going wrong so that others > may be able to spot what is causing your problems. > > Mostly, problems are in the drivers, generic stuff like waitqueue is much > less likely to be broken, but it is possible. If it is broken you need > to focus on the arch portion of it, it would be quite unlikely for any > generic waitqueue code to be causing the problem. I know it is unlikely, and if there were not the QSPI driver also having this problem when using waitqueues I would never have brought up this topic. I just used the I2C driver as an example because with this driver, I looked into it a bit deeper because the original one was plain unusable, while the qspi driver could be used by simply switching it to polled mode. Regards, Wolfgang _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
