You may want to use polling if possible with this device in loops less than 10ms. This will require removing the interrupt. The only question is what app or element in the system will use this data in 10ms cycles? So in this case you would need to know when to start your poll (based on the current HW interrupt) or just do it every 10ms.
On Mon, Apr 18, 2011 at 5:01 PM, Greg KH <[email protected]> wrote: > On Sat, Apr 16, 2011 at 12:30 PM, robstoddard <[email protected]> wrote: > > I am currently working on a few device drivers which require low > > latency interrupt handling. This driver needs to communicate via I2C > > with the chip after the chip hits the IRQ line, and needs to complete > > its work in less than 10 ms. I am using a Beagleboard (OMAP 3530) > > running Rowboat Android to develop these drivers. The problem that I > > see here is that the interrupt handler (allocated with > > request_threaded_irq()) is running almost 20 ms after the interrupt. > > When I try to run the I2C commands to communicate with the chip within > > the hard IRQ function, it obviously complains/panics. > > > > Is there a faster way of handling the IRQ which will allow me to fetch > > data from the chip within my time constraints? > > Get faster hardware :) > > Why are you stuck with such tight requirements? You will never achieve > this > on such a platform, especially with a "stock" Android kernel release as the > real-time patches are not part of it, which is what you are requiring. > > I would push back on the hardware designers who created such a monster > and tell them that this is impossible. > > best of luck, > > greg k-h > > -- > unsubscribe: [email protected] > website: http://groups.google.com/group/android-kernel > -- unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel
