I'm working on a kernel driver to expose multiple MCC ports to user space and having the following issues:
Linux side (A9):
I've had similar issues with the mcc driver. mcc_recv() isn't thread safe. If one thread is waiting on mcc_recv() and another thread does anything else mcc related - mcc_recv(), mcc_send(), mcc_create_endpoint(), etc - the driver locks up.
I've had to collapse all mcc traffic to a single process and single thread, alternate between send and receive with short timeouts, and bridge the data to other processes over ipc - terribly inefficient and keeps the CPU busy.
A true epoll-compliant driver is needed. I looked into this as well. It seems feasible since MCC_SIGNAL identifies the destination node and port for a received buffer; the isr just isn't using this info to distribute the buffer anywhere specific.
If you have a github project for this effort, I'll gladly contribute.
I stopped using MCC and moved to rpmsg. I ported rpmsg to MQX, I think the udoo Neo project might use it the code. But, I'm now only using FreeRTOS for the M4.
For the Linux side I'm using GitHub - tcmichals/rpmsg-neo: General rpmsg for TTY and usr space interface using multiple endpoints...
The idea being TTY endpnt a "clear" interface, for general Apps and working on a LwIP one also. So, now the M4 can use sockets to do file transfers, NTP , etc.