> > Hugh? I don't think there is a 'spurious' interrupt vector as such at > > the hardware. I didn't fully resync after the last interrupt reorg so > > perhaps they snuck in some new software term. > > Well I was wondering if the spurious interrupts had some meaning besides > being errors, such as a wake-up event instead of real interrupt :) Ok. That is another angle. No, not really. Events should be tied to a real irq. There is a PRCM interrupt which fires on wake up events when programmed to do so. This is routed into the L1 pic. If a pin is setup as a GPIO it might also generate a module interrupt in addition to the wake up one depending on polarity. > Sounds like it still should be dealt for arm linux in general. It may > be worth looking if Catalin already has some patches for that. Yes. > > -b- The other thing which is clear in the TRM is the bit about a false > > interrupt at priority sorting time. If you monkey with masks during > > sorting time you might get a false isr. As all of the source are level > > assertive at the pic, a 2nd gratuitous ACK of the vector number would be > > a hack way of handling that case. I'm not sure it happens that much in > > practice. The recommended programming model is a MASK of all ISRs down, > > handle the source, then ACK, and unmask. The Linux code path doesn't do > > this however, it only masks the 1 irq in play, acks the irq, then unmaks > > all the rest, then handles the device. In the messing with the mask > > around the ack with out dropping the source this small sorting window > > opens up (assuming there are more irs coming in). > > I guess you mean mask each irq bank? Maybe we should try and see what > happens after solving -a- above first, then see if -b- is needed. Seems right. > > > So far interactions with the ISP camera driver seem to have caused the > > most spurious interrupts to occur. However, you do see it with other > > drivers. As that code has matured in our trees issues have been > > dropping off. > > I guess Lauri was getting them in the serial driver. Ok. Long back I had found an error in the watermark handling which showed itself this way. We had a patch we applied to previous release streams. I think it was lost in recent open source sync. A MV person (Dave J) and I had sent it to Russell off line. As I recall, he corrected one error in that patch. And we went with that. Also, case -a- was reproduced in simulation on OMAP16xx on the UART specifically. Timing can mask both of these. A few different changes can be applied to mask it. Perhaps your board has some other new driver just coming up which is stressing the system and activating the timing sensitive failure paths. As system integration happens expect to see this come back with out base fixes. Once the system has stabilized a bit it will likely become a 2nd order failure again. That is what I've observed so far anyway. Regards, Richard W. - To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
