From: Lars-Peter Clausen <lars@metafoo.de>
To: Phil Reid <preid@electromag.com.au>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: iio: Non multiplexed ADC Data
Date: Mon, 23 Nov 2015 10:15:29 +0100 [thread overview]
Message-ID: <5652D931.8000205@metafoo.de> (raw)
In-Reply-To: <5652CEC5.7080804@electromag.com.au>
On 11/23/2015 09:31 AM, Phil Reid wrote:
> I'm in th eprocess of writing a driver for a custom ADC controller.
> It's an FPGA based ADC controller with multiple ADC channels with a built in
> DMA master.
Is it a single ADC with a sequencer or multiple ADCs?
> All channels share some attributes, eg Sample rate, with other per channel
> attributes, eg Gain.
> The DMA controller de-multiplexes the ADC data by having a separate target
> buffer for each channel.
I'm curious, why?
> Look at the libiio interface this configuration doesn't seem to be catered for.
> eg: iio_device_create_buffer creates a single buffer for all enabled
> channels to share.
>
> The best way I can see is to create an iio device per channel and have them
> share a common data block.
> Not sure what interesting behaviour this may cause.
Yes, you are right, this is not supported at the moment. But we'll have to
add support for this at some point. In my opinion the best way to address
this is to add multi-planar buffers, similar like you can for example find
the in the video world[1], where different components can be in different
buffers, rather than being interleaved in a single buffer.
In addition to having a scan_index a channel would have a plane_index and
for each unique plane_index for the enabled channels one buffer would need
to be allocated.
Since using this with the read()/write() API still requires multiplexing
over a single stream its probably not the best suited API for this and I
guess it will work much better with the (not yet upstream) mmap[2] support.
The workaround with multiple devices might work somewhat but I think it will
be very cumbersome to use, e.g. all your buffers can be enabled/disabled
independently through the API, which probably doesn't really match the hardware.
- Lars
[1] http://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html
[2]
http://events.linuxfoundation.org/sites/events/files/slides/iio_high_speed.pdf#page=18
next prev parent reply other threads:[~2015-11-23 9:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 8:31 iio: Non multiplexed ADC Data Phil Reid
2015-11-23 9:15 ` Lars-Peter Clausen [this message]
2015-11-24 0:17 ` Phil Reid
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=5652D931.8000205@metafoo.de \
--to=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=preid@electromag.com.au \
/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.