On Sun, May 31, 2015 at 12:51:17PM -0400, Jeremy Trimble wrote: > > 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. Yes but you are missing one key point that already application do this with variety of scenarios, audio, spi, i2c, nand etc But in all these cases we have a client susbstem which gets the data from usermode and is able to do the transfer, so we dont need userspace API Some subsystems are not design for usermode API and ideally we should restrict to kernel interfaces only Since initial motivation was test only, dmatest suits that better > > 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. But certainly you will have a driver for radio right? That guy should be invoking dmaengine.. > > 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. example please... > > 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. Thats hardly an issue, distros might turn it on. When we have a API for usermode it needs to fit into dmaengine semantics and API with security and ABI considerations as well -- ~Vinod -- 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
