So, there is a driver, although I do not know the name of this driver that populates /proc/irq/ , but if you cat /proc/interrupts, you'll easily see which number correlates to what.
root@beaglebone:~# cat /proc/interrupts CPU0 16: 39266767 INTC 68 Level gp_timer 20: 118529 INTC 12 Level 49000000.edma_ccint 22: 97 INTC 14 Level 49000000.edma_ccerrint 23: 0 INTC 96 Level 44e07000.gpio 30: 0 44e07000.gpio 6 Edge 48060000.mmc cd 56: 0 INTC 98 Level 4804c000.gpio 89: 0 INTC 32 Level 481ac000.gpio 122: 0 INTC 62 Level 481ae000.gpio 155: 18 INTC 72 Level 44e09000.serial 156: 1431 INTC 70 Level 44e0b000.i2c 157: 33 INTC 30 Level 4819c000.i2c 158: 13 INTC 64 Level mmc0 159: 587731 INTC 28 Level mmc1 167: 0 INTC 75 Level rtc0 168: 0 INTC 76 Level rtc0 172: 2117580 INTC 41 Level 4a100000.ethernet 173: 218976 INTC 42 Level 4a100000.ethernet 181: 0 INTC 111 Level 48310000.rng 183: 41 INTC 18 Level musb-hdrc.0.auto 184: 1 INTC 19 Level musb-hdrc.1.auto 185: 0 INTC 17 Level 47400000.dma-controller 186: 0 INTC 7 Level tps65217 187: 0 INTC 16 Level TI-am335x-adc The reason why there are no userspace interrupts, is that this would create context switching between userspace->kernel space->userspace. Needless to say, this would create a system wide performance problem. Now, concerning setting a bit flag in memory *somwhere*. I ran into a similar problem that was all in userspace, where I was decoding a custom CANBUS protocol, and all of the so called "non-blocking" mechanisms available through the std Linux libc API, being too slow by far. The reason I needed this mechanism, was that I have two separate processes, communicate between each other, in real-time. The CANBUS side of things decoding messages at 1Mbit/s, the other half, being a web server, displaying the decoded data, in real-time through web sockets. Anyway, with traditional non-blocking methods I was able to switch between these two apps at around 5-8 messages a second. But when I switched to using mmap() + a structure in memory + a bit in this structure as a locking mechanism. My message count max shot up to around 1000 messages / second. Granted, actual new message values were only around 20 a second. SO basically how I did this was again, I had a structure where one member was a single bit( 8 bits in storage, but I only used 1 ). After that, this bit would be either 0 or 1(of course ), and depending what value this bit was, indicated which process had access to the file. Which access rotation was a real factor in this given situation. Basically, the first half process would decode, and write, then set the access bit to allow the second half access. The second half would read this value, then change the value back to 0. As implied above, this turned out to be the fastest mechanism possible by a long shot. Using the PRU's you would not be able to use POSIX IPC shard memory as I did, but you can still use mmap() + /dev/mem/ on the user space side of the application. Which would allow you to communicate with the PRU's through a specified location in memory. If this is not clear enough, I can elaborate further. In either case, I'd be interested in how you dealt with your problem here, and would really love to see some simplified example code. On Tue, Mar 7, 2017 at 10:44 PM, ags <alfred.g.schm...@gmail.com> wrote: > I see what you are saying. But (from what I've read) it seems that many > would also say that you can't *receive* interrupts in userspace. I guess > that's technically true, but uio does provide a way, through sysfs, to > determine if an interrupt was fired. > > Also from what I've read (I've been doing a lot of reading...) I thought > that remoteproc was using mailboxes to communicate from userspace to the > PRU - and was wondering if this "reverse-direction" interrupt mechanism > couldn't also be supported by drivers (say, by writing to /dev/uio<n> - > analogous to select()/poll() on /dev/uio<n> to detect an interrupt. > > Granted, after going through all that machinery, it may well be faster to > just set a bit in PRU memory and have PRU poll. > > If this is just nonsense, even in theory, then I'd welcome an education as > to why. > > On Tuesday, March 7, 2017 at 8:52:27 PM UTC-8, William Hermans wrote: >> >> >> >> On Tue, Mar 7, 2017 at 9:45 PM, ags <alfred.g...@gmail.com> wrote: >> >>> The mechanism for generating an interrupt from a PRU to the A8 (host) is >>> well-documented. Is there a way to send an interrupt (one of the 64 system >>> interrupt events documented in the PRU-ICSS literature) from userspace? >>> >> >> No, there are no such things as userspace interrupts, period. >> >>> >>> From reading the TI documentation, the only two that seem to be >>> candidates are two "mailbox" interrupts. I recall reading something about >>> a version of the remoteproc (or RPMsg, or virtio) drivers that utilized >>> these mailboxes, but ultimately abandoned them as they are not available on >>> all platforms. (that may be incorrect). >>> >>> Setting a flag in PRU DRAM or shared RAM is clearly a method that will >>> work. However, it appears that polling DRAM or shared RAM is a multi-clock >>> task; if a PRU system interrupt can be generated, it can be polled in one >>> clock by examining R31 bits 30/31 (if configured correctly). Is this >>> possible? >>> >> >> I get the feeling however that you're misunderstanding the purpose of an >> interrupt. An interrupt is a way for hardware to let software know, >> something has happen that may require attention. Either way you wold >> probably be better off thinking in the context of setting a bitfield, or in >> this case, a single bit. >> > -- > 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. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beagleboard/f49b6ac0-7cc8-467c-8fcf-3060b65dec05%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/f49b6ac0-7cc8-467c-8fcf-3060b65dec05%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORr58VKn6FGJbSP4WaUyQ0-c2p-%3DN-EZ_2zGbPEh1Yq%3DhA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.