Messages in this thread | | | From | Robin Getz <> | Subject | Re: [RFC] Staging: IIO: New ABI V2 | Date | Tue, 16 Feb 2010 14:18:27 -0500 |
| |
On Tue 16 Feb 2010 06:03, Jonathan Cameron pondered: > On 02/16/10 02:49, Greg KH wrote: > > On Mon, Feb 15, 2010 at 07:58:12PM -0500, Mike Frysinger wrote: > >> On Mon, Feb 15, 2010 at 15:26, Robin Getz wrote: > >>> [snip] > >>> What exists today still requires a copy_[to|from]_user when using > >>> the ring buffer (and then another cache_flush if you are dma'ing > >>> things). These seems pretty expensive and will consume extra cycles > >>> that will limit throughput. > >>> > >>> Any thoughts to a mmaped interface directly to the IIO ring buffer, > >>> so the system could avoid some of the above overhead? (This is what > >>> we had to do for some other drivers - which were able to handle a 40 > >>> MSample/second data processed by userspace for a soft radio). > >> > >> does sysfs currently support mmap-ing of files in there ? > > > > For binary files, yes. If you are going to use mmap, use a character > > device node instead please, that's not what sysfs is for. > All the buffer access is done via character device nodes anyway. > > For anyone entering the discussion at this point: > Only really simple IIO drivers (for typically very slow devices) > are principally accessed through sysfs. For these fast devices we > probably wouldn't provide that route at all, merely using sysfs to > describe the parameters of the device and buffer being used.
Can we be a little more specific - what in your mind is "very slow"? and "fast"?
Is it designated by samples per second? (and bits per sample doesn't matter?) or is it the result (bits per sample * samples per second/8 == bytes/second?)
Many people I know would call a 1Mega sample per second converter very slow, but the kernel handling a memcpy of a continuous 2Mbyte/second (16-bits per sample), stream seems a little wasteful.
Thanks -Robin
| |