I considered polling. I'll give it a shot. I am at current removed from DSOs and logic analyzers (just ordered one, it will be in tomorrow night) so I can't be absolutely sure of my current solution, since printks tend to slow things down to a crawl in my driver, but I think setting SCHED_FIFO in the kernel configuration might be sufficient (with the appropriate values set in /proc/sys/ kernel/sched_rt_period_us and /proc/sys/kernel/sched_rt_runtime_us).
Thank you Rob On Apr 20, 10:19 am, mike digioia <mpd...@gmail.com> wrote: > 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 <gre...@gmail.com> wrote: > > On Sat, Apr 16, 2011 at 12:30 PM, robstoddard <r...@robstoddard.com> 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: android-kernel+unsubscr...@googlegroups.com > > website:http://groups.google.com/group/android-kernel- Hide quoted text - > > - Show quoted text - -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
