I am working on a embedded system which has a ARM core and a DSP core. The ARM core acts as an application processor and DSP does the usual number-crunching stuff, such as FFT. We have a Linux OS running on top of ARM. A Linux process just treat DSP as a Linux device. Once a process want to do a FFT, it writes the command to the device. After DSP finishes with FFT, it interrupts the ARM and triggers the device to notify the requesting process.

This can be implemented by a typical "write/read" device model if DSP is used by only one process. However, there may have multiple processes trying to use FFT at the same time, which means device driver has to be able to handle multiple "write/read" requests. The "write" part can be easily implemented. However, once DSP finishes the request, how could the driver find out and notify the requesting process?

You'd want to allow multiple processes to open the device at the same time, and this would give you a per-process individual passage through which to send and receive the information, wake up the correct process and so-on.

sundialsvcs:

Thanks for the hint. Do you mind to refer to me any example driver code that implement process-based read/write?

The interrupts could come back in any order, not necessarily in the order that the DSP received the writes. One way to keep track would be for the driver to pass a request number (PID?) to the DSP with each write and the DSP to return the request number with each interrupt so that the driver could match the interrupt to the corresponding write.

A much less desirable way to solve the problem would be for the ARM to use locks so that only one ARM thread at a time had a request outstanding in the DSP.

----------------
Steve Stites