i.MX Processors中的主题 MCC kernel driver for Linux (IMX6x)

MCC kernel driver for Linux (IMX6x)

tcmichals — Thu, 31 Dec 2015 13:37:52 GMT

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

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.
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?

Re: MCC kernel driver for Linux (IMX6x)

readonly — Fri, 05 Feb 2016 16:57:19 GMT

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.

Re: MCC kernel driver for Linux (IMX6x)

tcmichals — Fri, 05 Feb 2016 17:45:39 GMT

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.

Re: MCC kernel driver for Linux (IMX6x)

dry — Sat, 19 Aug 2017 05:41:02 GMT

Tim,

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