Hi, After recovreing few hours of sleep during the weekend I am back to the I2C stuff. I was wrong that the interrupt routine was never called (in i2c-algo-8xx.c). Somehow cpm_debug > 1 became cpm_debug == 1 to my eyes. Anyways after incresingddd the debug level, i.e. setting cpm_debug = 2 I verify that the interrupt is indead called and that everyting is working perfectly, i.e. I am reading and writing to the memory witout errors. So I lower the debug level again (cpm_debug = 1) and then I am getting the previous behavior, i.e. I am unable to read. So I put debug level to 0 but force a printk() inside the interrupt handler. And voila evrything works perfectly. Commenting out the printk and putting a small delay in the interrupt handler (for(i = 0; i <1000 ; i++);) has the same effect as keeping the printk.
This raises the question: Is it possible that the CPM is raising the interrupt to early, i.e. before the bd is filled? It should not be a cache coherency problem because the bd's are all decleared volatile. Thanks, K.D. P.S. This is happening on MPC823e. > -----Original Message----- > From: K?ri Dav??sson > Sent: 26. okt?ber 2001 22:56 > To: Linux Embedded ppc (E-mail) > Subject: More I2C stuff > > > > Hi, > > I got the I2C stuff working (kind off), i.e. the drivers > compile and run > without crashing. > Writing and reading seem to work, i.e. by looking with scope on the > signals everyting looks looks normal > (I have a microchip i2c memory on the i2c bus for testing). > > The interrupt handler is never called, so I assume the CPM is never > raising an I2C interrupt. > The interrupt handler is installed correctly and the interrupt is > enabled (verified by looking at > the CIMR). > > But the read method always fails because the bd is not filled in > properly by the CPM, i.e. BD_SC_EMPTY > is never cleared and cbd_datalen is always 0. > > I could not find any mentioning of any special hardware > tricks needed to > be done to get correct behaviour > of the I2C, but then again the mot.com site seem to be > seriously broken > at the moment. > > Also If the interrupt handler is never called, should, e.g. the read > method ever get past the > interruptable_sleep_on() call? Isn't the the interrupt handler > (cpm_iic_interrupt) the only one able to > wake the application by calling wake_up_interruptible() > > Anyway, > > Pussled, tired and a littlebit annoyed, > > K.D. > > P.S. The file refered to is drivers/i2x/i2x-algo-8xx.c. > I am using drivers/i2c/i2c-rpx.c for initialization of bd's and port. > The kernel is linuxppc_2_4_devel pulled via rsync few days ago (monday > or tuesday). > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
