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 <javascript:>> > 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. For more options, visit https://groups.google.com/d/optout.
