On 10/04/2015 05:57 PM, Jonathan Cameron wrote: > On 02/10/15 15:45, Lars-Peter Clausen wrote: >> Add a DMA buffer implementation to the IIO dummy driver. Similar to the >> existing kfifo based dummy buffer implementation the buffer is not >> connected to any real hardware, but rather emulates its behavior. >> >> The dummy DMA buffer is meant to be used as a template for implementing DMA >> buffer support and can also be used to test the generic IIO DMA buffer >> infrastructure without having access to hardware that has DMA capabilities. >> >> The dummy driver is split into two parts. The first part emulates the >> behavior of a typical DMA controller and converter while the second part >> implement a typical device driver for such a system. The separation of the >> two parts is intentionally kept very strict to be to make it clear which >> parts will be found in a driver for real hardware and which parts will be >> performed by the hardware and will not be part of the driver. >> >> The type of the buffer used by the IIO dummy device has to be chosen at >> compile time and can either be the old FIFO based software triggered buffer >> or the DMA buffer. Given that the dummy device driver is mainly intended >> for testing the framework and providing a simple example to be used as a >> template for new drivers it is not critical that the buffer type can be >> chosen or changed at runtime. > I almost wonder if it's worth building two modules. One with the kfifo and > one with the dma buffer. > > This is mainly to avoid confusing the distros who will wonder which > 'fake' option to chose. Ideally distros shouldn't ship this at all. But we could allow to built both and then use a module parameter to choose which one to use when both are built into the module. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
