OK, one more time. All userspace interrupts work the same, pru, network driver, *anything*. The process blocks until the interrupt handler unblocks the process with a semaphore or completion in the kernel. For example, when you read data for a socket connection, it blocks. When data comes in, the data is copied to userspace, the read function unblocks. Again, this is all explained in that LDD3 chapter I linked. There's no other way to do it, except going around the kernel and polling memory.
1. This isn't a realtime kernel. You will always have jitter. Does it matter? I don't know what you're doing. You don't need to use polling. UIO and select doesn't use polling. 2. Using select (and even poll() since it's just a wrapper for select()) on the gpio doesn't poll. It's interrupt driven. Same method as described. 3. Same method as described. If you use the PRU, it will be the same method to notify your userspace application with the same shortcomings, unless you put all of your code into the pru. If you want deterministic timing, you either need a realtime kernel, or put all your code on the pru. But, I can guarantee you don't need deterministic timing, and I can guess that you're worrying about nothing Seriously, do some benchmarks with sysfs. It's only a few lines of code. And, there are all sorts of userspace hardware drivers that use userspace interrupts out there including graphics and network. If you only need to know when a gpio event happened, and process it later (it will always be later since this isn't a realtime kernel or in the pru), you can timestamp the event. I believe you can do this with the enhanced timers, and I know you can do this in the pru. So it would go, event happens, pru/etimer hardware timestamps the event, sends interrupt, userspace gets interupt using "the only way possible", userspace reads timestamp from hardware, pretends that the event happened at the timestamp for any calculations. If you explained what you were doing, we could advise you better. Good luck! On Thursday, September 11, 2014, neo <prag.in...@gmail.com> wrote: > Hi Brandon > > 1. I agree with jitter involved with processing interrupts and 100% > cpu usage during polling for the same, so is there no way to let the > user-space know that interrupt has occurred apart from polling ? > 2. The reason why i said pseudo-interrupt is because we are polling > and waiting there which is same as watching a flag in a UART register for > RX flag to set. > 3. I am curious as to how interrupts for Ethernet and usb are written. > I am guessing that the ISR will use the DMA to transfer bytes to > user-space. But even in that case the userspace should know that a new data > has arrived. Then hoe to synchronize the kernel space and user-space if > there are to share a data ? > > Thanks... > > On Thursday, September 11, 2014 2:26:15 AM UTC+5:30, Brandon I wrote: >> >> > pseudo-interrupt from user space >> >> There's nothing pseudo about it. Again, any usual way to have a userspace >> application respond to an interrupt will be the exact same. The kernel will >> block the userspace process until the interrupt is seen. The only real >> alternative is burning up the cpu with memory polling, which appears to be >> what the BBIOlib method uses. So, your latency is limited to your poll >> speed (which can be faster than interrupts). But, if you have a constant >> poll for minimum latency, lets hope you're not trying to do something >> important elsewhere since your cpu usage will be at 100%, and you'll be >> maximizing process to process context switching! >> >> For 4, The only difference between a userspace and kernel space interrupt >> handler is where the code is that responds to the interrupt. You will only >> benefit from writing your own interrupt handler if you put all of your code >> that does something with that interrupt in the kernel. Otherwise, you're >> back to process blocked by kernel, interrupt occurs, kernel unblocks >> process, process does something after seeing the interrupt....back to the >> sysfs/UIO method. >> >> I would try some benchmarks. See if the regular UIO/sysfs interrupt >> method gives you sufficient performance. And definitely keep in mind John's >> statement. You're going to see a massive amount of jitter for anything in >> userspace or kernel space (better jitter since you can disable interrupts >> and whatnot, but if you don't finish quickly in kernel space, you'll crash >> the kernel). >> >> If something like a precise timestamp is needed for an async event, then >> there are other ways to approach this. If you're looking for fixed low >> latency, you're doomed. >> >> On Wed, Sep 10, 2014 at 5:13 AM, neo <prag....@gmail.com> wrote: >> >>> pseudo-interrupt from user space >> >> >> >> -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/eNX0CU7-noE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
