linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phil Reid <preid@electromag.com.au>
To: Lars-Peter Clausen <lars@metafoo.de>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: iio: Non multiplexed ADC Data
Date: Tue, 24 Nov 2015 08:17:07 +0800	[thread overview]
Message-ID: <5653AC83.9020201@electromag.com.au> (raw)
In-Reply-To: <5652D931.8000205@metafoo.de>

G'day Lars,

On 23/11/2015 5:15 PM, Lars-Peter Clausen wrote:
> 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?
Multiple parallel ADC's with common clock and control.

>
>> 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?
It's a port of an existing system and each channels data is serialised independently.
There could be multiple devices collecting data with any number of channels active.
It's probably best to say the source data typically isn't multiplexed. Though with
some hardware it is streamed from the ADC as TDM stream and then de-multiplexed, other
hardware the streams are independent..
>
>> 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.
>
I'll have a look to see if if that concept works for us. I was also thinking of something
like this by making some hardcoded assumptions about our data.


-- 
Regards
Phil Reid


      reply	other threads:[~2015-11-24  0:17 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
2015-11-24  0:17   ` Phil Reid [this message]

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=5653AC83.9020201@electromag.com.au \
    --to=preid@electromag.com.au \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).