> But in that case they would go thru the client subsystem. Like audio sends > buffers to kernel and then the respective subsystem (sound) uses dmaengine. > > Do we have a real world example where we would want to DMA without a kernel > client, IOW a usermode client? I understand your concern about why a userspace interface is useful. I think that the use case I encountered in my thesis is not that uncommon for embedded system development, especially as built-in reconfigurable logic becomes more prevalent in systems-on-chip. I mentioned using ezdma for testing (where I used it to send data both to and from the programmable logic), but it is equally useful as part of my finished product, where data is sent only from the programmable logic to userspace. In my case, I was implementing a protocol demodulator for a software-defined radio, which was implemented partially in an FPGA core in the Zynq's programmable logic and partially in userspace software on the Zynq's ARM processor. The core in the programmable logic detects when the desired signal is received and sends packets containing demodulated bits to the software running on the ARM. ezdma provides a simple data transport mechanism without the need to find a way to "fit" my design into a kernel subsystem that was not designed for my use case. I've talked with other researchers who have said they would find ezdma useful for their work as well. In the past, they've been deterred from using Linux in their (Zynq/FPGA-related) research because of the learning curve required to implement a kernel driver. For this reason alone, I think it's worth maintaining in-tree to ensure it remains usable for future research and development. Of course, in this type of use case some kernel programming might still be required (for instance, writing a small driver to provide access to the device's register interface for configuration). ezdma can easily be used in conjunction with a small driver that provides this access -- we could even consider adding an in-kernel API that allows other drivers to instantiate an ezdma device directly as part of its own interface. Not every task requires the use or invention of a kernel subsystem. Sometimes, you just want to get send data to/from a device from userspace. I expect we'd leave ezdma turned off by default in Kconfig -- users who won't use it don't need to bother with it, but providing a simple userspace interface on top of dmaengine might provide some useful flexibility to those developing new "co-designed" hardware/software systems, and ensure that Linux is helping to enable these developers, not hold them back. -Jeremy Trimble -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
