I do not see where it says mmap() is not so great. I do see where they
imply that mmap() is slower than mmap() + DMA. Which does, can, or
otherwise makes sense. The block copy idea is also pretty cool, but not
unique to iio.

Here is my take on that set of slides:


   1. It is already written.
   2. It is very probably well thought out.
   3. It *is* yet another abstraction layer - Pluses, and minus.
   4. It is possibly supported. Good if so, bad if not.
   5. built into or can be built into the kernel if supported.
   6. Does use interrupts apparently, so will incur some kind of penalty.


Do I think it would be a cool / good thing to have in the kernel(
optionally ) ? No doubt - Yes. But would I use it ? I'm still not
convinced. But of course I see most, many or potentially all abstraction
layers as initially bad. Bad in that it is something else to learn /
understand. Bad that you get a lot of extra stuff typically built in that
you do not need. Which leads to bloat, and potential performance issues.
Also bad that sometimes it's more convenient to just use such an
abstraction layer, than fully understand it, which can lead to many, many
frustrating problems to solve. Very few abstraction layers convince me
otherwise, but I would guess that iio would be one to do so. If not, well
it is an interesting idea in of it's self to merit a second look, or four.
In fact, I already had thought iio was worth revisiting later, after
learning about it a few days ago -  While exploring the BBB's ADC's.


On Thu, Oct 8, 2015 at 9:57 PM, Rick Mann <rm...@latencyzero.com> wrote:

> There's a good slide presentation on why mmap() isn't so great, and they
> talk about the changes they made to the underlying driver and the ioctl()
> calls they added. libiio wraps those ioctl calls.
>
>
> http://events.linuxfoundation.org/sites/events/files/slides/iio_high_speed.pdf
>
> It's not what I envision a proper user-space API should look like, but
> it's much closer. I'm hoping I can write one on top of it, perhaps
> expanding iio. But when I refer to libiio, I'm also including the necessary
> updates to the iio driver system.
>
> > On Oct 8, 2015, at 21:33 , William Hermans <yyrk...@gmail.com> wrote:
> >
> > Yeah wow, I already said that, hah ! Too much going on . . .
> >
> > On Thu, Oct 8, 2015 at 9:32 PM, William Hermans <yyrk...@gmail.com>
> wrote:
> > Rick, also for what it's worth. Getting it compiled and working on a
> system does seem very straight forward and is shown step by step on that
> landing page you linked to.
> >
> > On Thu, Oct 8, 2015 at 9:30 PM, William Hermans <yyrk...@gmail.com>
> wrote:
> > Not sure I understand what you're getting at, but I've read that iio has
> at least two methods of access. Slow( sysfs ), and fast( mmap()). I'm not
> sure that the "fast" method driver exists for our board here in the context
> of the ADC's but certainly the slow sysfs method does. As for the rest of
> the things mentioned on that landing page you pasted a link to . . . it
> seems that he steps are very straight forward to get working, and indeed
> laid out on that exact page.
> >
> > What are you wanting to do with iio ? The idea of the library does
> intrigue me too. But I'm, not exactly sure I have the time to learn
> yet-another-abstraction-layer . . .
> >
> > On Thu, Oct 8, 2015 at 8:37 PM, Rick Mann <rm...@latencyzero.com> wrote:
> > libiio (along with additional stuff in the kernel that doesn't appear to
> be in 4.1.x-ti) provides for fast ADC access, rather than getting at it
> through sysfs.
> >
> > > On Oct 8, 2015, at 20:07 , William Hermans <yyrk...@gmail.com> wrote:
> > >
> > > I believe the ADC already uses a libiio "driver". Assuming it is the
> same thing I'm thinking of. But for instance when you load the ADC device
> tree file, it in turn loaded the iio:device0 object for the ADC.
> > >
> > > Like demonstrated on my blog post here:
> http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/
> > >
> > > With that said, I do not purport to know very much about it. Just that
> it exists.
> > >
> > > On Thu, Oct 8, 2015 at 7:06 PM, Rick Mann <rm...@latencyzero.com>
> wrote:
> > > What would it take to get libiio:
> > >
> > >
> https://wiki.analog.com/resources/tools-software/linux-software/libiio
> > >
> > > Into the BBB kernels? I think this would be amazing.
> > >
> > >
> > > --
> > > Rick Mann
> > > rm...@latencyzero.com
> > >
> > >
> > > --
> > > For more options, visit http://beagleboard.org/discuss
> > > ---
> > > You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> > >
> > >
> > > --
> > > For more options, visit http://beagleboard.org/discuss
> > > ---
> > > You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > Rick Mann
> > rm...@latencyzero.com
> >
> >
> > --
> > For more options, visit http://beagleboard.org/discuss
> > ---
> > You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> >
> > --
> > For more options, visit http://beagleboard.org/discuss
> > ---
> > You received this message because you are subscribed to the Google
> Groups "BeagleBoard" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to beagleboard+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Rick Mann
> rm...@latencyzero.com
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to