If it is for support from a TI SDK, please post a query to E2E.
Can someone clarify meanwhile exactly what the issue is? The kfifo is
used only on the receive path because of the asynchronous callbacks. The
Tx-path is synchronous, the copy is attempted directly on the vring
buffers, and you have a number of vring buffers (dictated by firmware),
and if all of them are busy (implies PRU has either stopped processing
or is overwhelmed), then you get a failure.
regards
Suman
On 6/22/20 8:11 AM, Jason Kridner wrote:
Which repo has the code that is causing problems?
I took a quick look at
https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/lib/src/rpmsg_lib/pru_rpmsg.c
and it seems to be structured a fair bit differently. If the same issue
had been there, I'd recommend posting to e2e.ti.com <http://e2e.ti.com>.
Switching over to the kernel, I see the function you mention:
https://github.com/beagleboard/linux/blob/4.14/drivers/rpmsg/rpmsg_pru.c#L106-L129
The driver isn't upstream yet:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/rpmsg
The post to a public list seems to be here:
* https://patchwork.kernel.org/patch/10795751/
The development tree seems to be here:
* https://git.ti.com/cgit/rpmsg/rpmsg/
The code seems the same in the latest development branch:
* https://git.ti.com/cgit/rpmsg/rpmsg/tree/drivers/rpmsg/rpmsg_pru.c#n108
Er, I guess that is an example of doing it right and the issue is here?
* https://git.ti.com/cgit/rpmsg/rpmsg/tree/drivers/rpmsg/rpmsg_pru.c#n142
Since it isn't upstream, I'd think an e2e post might be OK, but it might
be more productive to reply to the latest post on linux-omap:
*
https://lore.kernel.org/linux-omap/e97f7bfc-a3c2-92a9-953e-572d9438d...@ti.com/
Copy Jason Reeder, Anthony F. Davis and Suman Anna. Not sure why it has
been so long between revision posts.
Personally, I don't see any harm in modifying the _write code with a
fifo check on O_NONBLOCK.
On Mon, Jun 22, 2020 at 2:01 AM Andrew P. Lentvorski <bsd...@gmail.com
<mailto:bsd...@gmail.com>> wrote:
Nobody knows where I should file this bug?
On Saturday, June 6, 2020 at 6:34:26 PM UTC-7, Andrew P. Lentvorski
wrote:
It appears that the problem is in rpmsg_pru.c.
rpmsg_pru_read has the following code:
|
if(kfifo_is_empty(&prudev->msg_fifo)&&
(filp->f_flags &O_NONBLOCK))
return-EAGAIN;
|
rpmsg_pru_write presumably needs a similar piece of code with
kfifo_is_full() or it needs to look for O_NONBLOCK and then use
rpmsg_trysend instead of rpmsg_send.
Unfortunately, I've got nowhere near the Linux kernel
programming chops to debate the implications of that.
Presumably, I need to file a bug somewhere?
Thanks.
--
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
<mailto:beagleboard+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/2c824e98-015d-4471-b787-a8c27ceaae5fo%40googlegroups.com
<https://groups.google.com/d/msgid/beagleboard/2c824e98-015d-4471-b787-a8c27ceaae5fo%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
https://beagleboard.org/about - a 501c3 non-profit educating around open
hardware computing
--
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/33317f41-b499-3d1f-7281-29ac57976f7e%40ti.com.
