Hi, FYI, recent remoteproc RPMSG versions have moved from mailboxes to interrupts for communication: https://git.ti.com/pru-software-support-package/pru-software-support-package/commit/69805828df0f262fb60363c2db189d1b8d0b693c
A race-free algorithm would require the interrupts simply to wake the peer, and rely on shared memory FIFO for handling events. AFAIK, that's the idea used by virtio/RPMSG. In pseudo-code: 1. Wait for interrupt. 2. Clear interrupt. 3. Drain the events-FIFO located in shared memory. Regards, Dimitar On Tuesday, November 7, 2017 at 4:09:33 AM UTC+2, Ken Shirriff wrote: > > I'm trying to send information back and forth between the processor and > the PRU, and I'm looking for suggestions on the best way to do this. > > Currently I'm using PRU_EVTOUT0 to send events from the PRU. The processor > code does a select() on the PRU_EVTOUT_0 fd to find out when an event has > happened. Then I do a prussdrv_pru_wait_event() and > prussdrv_pru_clear_event() to get rid of the event. (The select is because > I also want to wait for network data.) > > However, this is kind of a mess of race conditions, since an event can > come in between the select and the clear. Or two events can happen before > the select. So I have various status flags that the PRU sets in memory. But > that leads to other race conditions. > > So, I'm wondering if there's a better way to handle events back and forth. > Other people must have dealt with this and come up with good solutions. > > I've seen stuff about Remoteproc - is that the cool new technology? Its > mailboxes seem like a good model. However, I'd rather stick with the UIO > model instead of moving to a new kernel and rewriting everything if > possible. > > My application, in case it's relevant: I'm building a network gateway with > the PRU bit-banging a 3 megabit/second Ethernet. So the processor sends > packets to the PRU to transmit, and the PRU tells the processor about > incoming packets. The PRU needs to tell the processor when a send is > completed, or when a packet has arrived. > > Thanks for any help, > Ken > -- 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/1d770722-5d3e-4be2-89e3-5e0385cc03d9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
