MCC kernel driver for Linux (IMX6x)

[tcmichals]

I'm working on a kernel driver to expose multiple MCC ports to user space and having the following issues:

1. mcc_recv not waking up the the receive thread  when M4 writes a packet to A9 Port:
   • The driver is designed to have a thread per port calling the mcc_recv API for each port with a infinite time out. 
   • If the mcc_recv timeout is changed to say 255ms; then the receive rate increases to the delay time.   Some times a packet does wake the thread.
2. If two threads are accessing the API MCC API (mcc_recv and mcc_write) at the same time it seems there is a race condition locking up the A9 side.

Linux side (A9):

• Driver
  • (1) thread for each port; there are currently only 2 threads running.
    • When a packet is received via mcc_recv, it is put into a queue different queue for each port. 
  • API for poll, read, write.
    • Poll :checks if there is any packets in a queue, if empty assigns a wait for a callback
    • Write: writes to the MCC port via mcc_write
    • Read: Allows using O_NONBLOCK, no calls to mcc_recv, in this function.  If there is no packet return -EAGAIN
• User app
  • loop that writes a packet and waits on a read using epoll

MQX (M4)

• two threads for each MCC port
  • Thread
    • Waits of a mcc_recv when a packet is received sends it back on the sender port.

Any suggestions?

[readonly]

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.

[tcmichals]

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.  

[dry]

Tim,

Is the rpmsg to MQX port code available somewhere? I'm interested in trying it out on MQX 4.2