So did you use the low latency Patch and threads with Sched_FIFO? Did your system slow down to noticable amounts?
I built a driver for an intersil light sensor and this one has some issues with the amount of time that elapses between succesive reads of the reg values. So I may or may not need these but would like to know what the effects will be like. /mpd On Thu, Apr 28, 2011 at 9:04 AM, robstoddard <r...@robstoddard.com> wrote: > 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 > -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
