On Sunday 25 September 2016 03:11 PM, Jonathan Cameron wrote: > On 21/09/16 17:11, Mugunthan V N wrote: >> > The ADC has a 64 work depth fifo length which holds the ADC data >> > till the CPU reads. So when a user program needs a large ADC data >> > to operate on, then it has to do multiple reads to get its >> > buffer. Currently if the application asks for 4 samples per >> > channel with all 8 channels are enabled, kernel can provide only >> > 3 samples per channel when all 8 channels are enabled (logs at >> > [1]). So with DMA support user can request for large number of >> > samples at a time (logs at [2]). >> > >> > Tested the patch on AM437x-gp-evm and AM335x Boneblack with the >> > patch [3] to enable ADC and pushed a branch for testing [4] >> > >> > [1] - http://pastebin.ubuntu.com/23211490/ >> > [2] - http://pastebin.ubuntu.com/23211492/ >> > [3] - http://pastebin.ubuntu.com/23211494/ >> > [4] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git iio-dma > Just curious. How fast is the ADC sampling at in these? Never that > obvious for this driver! > > I'm also curious as to whether you started to hit the limits of the > kfifo based interface. Might be worth considering adding alternative > support for the dma buffers interface which is obviously much lower > overhead. > > Good to have this work prior to that as the kfifo stuff is somewhat > easier to use. Currently ADC clock is 3MHz, which can produce a data rate of 225KBps per channel with no open delay and no averaging of samples. So when all 8 Channels are enables the data rate will be 1.75MBps ADC can be operated at 24MHz, which can generate a data rate of 28MBps with all 8 channels enabled and no open delay and averaging, but our target is to get 800K samples per second per channel which has a data rate of 12.5MBps I think with this data rate, DMA will be the best option to implement without any data loss and less cpu overload to read the ADC samples. Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html