It seems that the SCHED_FIFO and 'low latency desktop' fixed the situation. Now I have 200uS latency, which is sufficient.
Thank you Rob On Apr 20, 11:53 am, robstoddard <r...@robstoddard.com> wrote: > 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 theinterrupt. 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 > > > >latencyinterrupthandling. 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 theinterrupthandler (allocated with > > > > request_threaded_irq()) is running almost 20 ms after theinterrupt. > > > > 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
