From: Lars-Peter Clausen <lars@metafoo.de>
To: Alessandro Rubini <rubini@gnudd.com>
Cc: john3909@gmail.com, linux-iio@vger.kernel.org,
broonie@kernel.org, flatmax@flatmax.org
Subject: Re: DMA sampling and IIO
Date: Thu, 06 Feb 2014 22:38:31 +0100 [thread overview]
Message-ID: <52F400D7.7050204@metafoo.de> (raw)
In-Reply-To: <20140206211637.GA14525@mail.gnudd.com>
On 02/06/2014 10:16 PM, Alessandro Rubini wrote:
>>> ZIO already supports dma. And mmaping the buffer from user space. It
>>> is in the design since inception, and in the code since Feb 2012 (git
>>> log says).
>>
>> I know. And I did study the ZIO DMA code (among other things),
>> before I implemented the IIO DMA code. As you might remember from
>> our last discussion, my preference is to add the features that are
>> in ZIO but not in IIO to IIO and then ditch ZIO instead of having
>> two frameworks for the class of devices.
>
> I remember. And we both know that the class of devices that ZIO already
> supports cannot be supported by IIO, unless many incompatible changes
> are made (sub-nanosecond timestamps, symmetric input and output,
> hot-swap of buffer and trigger type, ...).
>
I still don't see why it is necessary to make incompatible changes to IIO to
support this. There is nothing wrong with extending the API, while staying
backwards compatible.
> I'm happy all accelerometers have the same interface to user space,
> this is definitely useful. But that's clearly not the same class of
> devices.
>
>> and then ditch ZIO
>
> How can you "ditch" something you don't use? Or is your employer
> currently using zio while helping iio catch up?
I meant in general.
>
> Our users will not stop using it, despite your desire, because it
> already serves them pretty well: 100MS ADC, with DMA and mmap, all
> sysfs-based, completely run-time configurable, and v2.6.24..v3.12 (13
> untested yet).
I have no desire to stop anybody from stopping using ZIO. But my recommendation
is to work towards a unified framework. The sooner the switch is made the
easier the migration path will be.
I think we have systems with 4x 250MS ADCs also doing DMA and mmap and
streaming over the network[1]. All with IIO, so again, there _is_ a huge
overlap of the classes of devices supported by both IIO and ZIO.
-Lars
[1] https://wiki.analog.com/resources/fpga/xilinx/fmc/ad-fmcjesdadc1-ebz
next prev parent reply other threads:[~2014-02-06 21:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-05 18:42 DMA sampling and IIO John Syn
2014-02-06 9:56 ` Lars-Peter Clausen
2014-02-06 19:43 ` John Syn
2014-02-06 21:15 ` Lars-Peter Clausen
2014-02-07 13:20 ` Mark Brown
2014-02-07 22:19 ` John Syn
2014-09-10 22:19 ` John Syn
2014-09-10 22:43 ` John Syn
2014-09-17 19:53 ` Mark Brown
2014-09-18 4:06 ` John Syn
2014-02-06 20:53 ` Alessandro Rubini
2014-02-06 21:02 ` Lars-Peter Clausen
2014-02-06 21:16 ` Alessandro Rubini
2014-02-06 21:38 ` Lars-Peter Clausen [this message]
2014-02-07 18:18 ` John Syn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52F400D7.7050204@metafoo.de \
--to=lars@metafoo.de \
--cc=broonie@kernel.org \
--cc=flatmax@flatmax.org \
--cc=john3909@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=rubini@gnudd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.