DMA sampling and IIO

DMA sampling and IIO

[John Syn]

I¹m working on a project that uses the ADE7878 Energy Measurement part
from Analog Devices. Currently there is an IIO device driver in the
staging/iio/meter folder, but I would like to extend this by adding high
speed sampling of the AC waveforms. The ADE7878 will continuously output
samples (8 Khz) of the voltage/current waveforms via an I2S interface. I
plan to use DMA to store these values in a buffer and then use IIO Ring
Buffer to access these values from User Space.

Was this considered in the IIO framework and does anyone have any
suggestions on how I might proceed?

Jonathan Cameron suggested I include Lars-Peter Clausen and Mark Brown in
this discussion.

Regards,

John 

Re: DMA sampling and IIO

[Lars-Peter Clausen]

On 02/05/2014 07:42 PM, John Syn wrote:
> I¹m working on a project that uses the ADE7878 Energy Measurement part
> from Analog Devices. Currently there is an IIO device driver in the
> staging/iio/meter folder, but I would like to extend this by adding high
> speed sampling of the AC waveforms. The ADE7878 will continuously output
> samples (8 Khz) of the voltage/current waveforms via an I2S interface. I
> plan to use DMA to store these values in a buffer and then use IIO Ring
> Buffer to access these values from User Space.
>
> Was this considered in the IIO framework and does anyone have any
> suggestions on how I might proceed?

Hi,

We do have patches for better integration of DMA (especially for high speed 
devices) into the IIO framework[1]. This is not yet upstream since it is 
still a bit WIP, but I'm confident that it will find it's way into upstream 
soon. The patches are pretty isolated, so they can easily be applied on top 
of a upstream tree.

But with DMA you'll need a host component that supports this. The ADE7878 
driver on it's own can not do any DMA since it doesn't know how it is 
connected to the host system. I2S is typically used for audio and all I2S 
host driver reside in the audio subsystem. The tricky part will now be - if 
there is already a I2S driver for your host system - how to bridge the audio 
driver with the ADE7878 driver and expose the result as a DMA capable IIO 
device.

- Lars

[1] 
https://github.com/analogdevicesinc/linux/commit/4edb9c9cbaf88047355c86e421690262406d5eae

Re: DMA sampling and IIO

[John Syn]

On 2/6/14, 1:56 AM, "Lars-Peter Clausen" <lars@metafoo.de> wrote:

>On 02/05/2014 07:42 PM, John Syn wrote:
>> I¹m working on a project that uses the ADE7878 Energy Measurement part
>> from Analog Devices. Currently there is an IIO device driver in the
>> staging/iio/meter folder, but I would like to extend this by adding high
>> speed sampling of the AC waveforms. The ADE7878 will continuously output
>> samples (8 Khz) of the voltage/current waveforms via an I2S interface. I
>> plan to use DMA to store these values in a buffer and then use IIO Ring
>> Buffer to access these values from User Space.
>>
>> Was this considered in the IIO framework and does anyone have any
>> suggestions on how I might proceed?
>
>Hi,
>
>We do have patches for better integration of DMA (especially for high
>speed 
>devices) into the IIO framework[1]. This is not yet upstream since it is
>still a bit WIP, but I'm confident that it will find it's way into
>upstream 
>soon. The patches are pretty isolated, so they can easily be applied on
>top 
>of a upstream tree.
I’d like to have a look at your DMA patch. Hopefully it will help point me
in the right direction.
>
>But with DMA you'll need a host component that supports this. The ADE7878
>driver on it's own can not do any DMA since it doesn't know how it is
>connected to the host system. I2S is typically used for audio and all I2S
>host driver reside in the audio subsystem. The tricky part will now be -
>if 
>there is already a I2S driver for your host system - how to bridge the
>audio 
>driver with the ADE7878 driver and expose the result as a DMA capable IIO
>device.
I’ll never understand why I2S is so integrated into the sound subsystem.
There are plenty applications of I2S that have nothing to do with sound. I
think I can make this work via an SPI interface, but with some patch work
because the ADE7878 will drive the SPI clock. I also plan to use EDMA to
store each measurement in a separate buffer (Voltage A, Voltage B, Voltage
C, Current A, etc) which will make processing each measurement channel
much easier. Question is, how to use IIO Ring Buffer given multiple
channels? 

Regards,
John
>
>- Lars
>
>[1] 
>https://github.com/analogdevicesinc/linux/commit/4edb9c9cbaf88047355c86e42
>1690262406d5eae
>

Re: DMA sampling and IIO

[Lars-Peter Clausen]

On 02/06/2014 08:43 PM, John Syn wrote:
> 
> 
> On 2/6/14, 1:56 AM, "Lars-Peter Clausen" <lars@metafoo.de> wrote:
> 
>> On 02/05/2014 07:42 PM, John Syn wrote:
>>> I¹m working on a project that uses the ADE7878 Energy Measurement part
>>> from Analog Devices. Currently there is an IIO device driver in the
>>> staging/iio/meter folder, but I would like to extend this by adding high
>>> speed sampling of the AC waveforms. The ADE7878 will continuously output
>>> samples (8 Khz) of the voltage/current waveforms via an I2S interface. I
>>> plan to use DMA to store these values in a buffer and then use IIO Ring
>>> Buffer to access these values from User Space.
>>>
>>> Was this considered in the IIO framework and does anyone have any
>>> suggestions on how I might proceed?
>>
>> Hi,
>>
>> We do have patches for better integration of DMA (especially for high
>> speed
>> devices) into the IIO framework[1]. This is not yet upstream since it is
>> still a bit WIP, but I'm confident that it will find it's way into
>> upstream
>> soon. The patches are pretty isolated, so they can easily be applied on
>> top
>> of a upstream tree.
> I’d like to have a look at your DMA patch. Hopefully it will help point me
> in the right direction.

I posted a link to the main patch at the bottom of the last email.

>>
>> But with DMA you'll need a host component that supports this. The ADE7878
>> driver on it's own can not do any DMA since it doesn't know how it is
>> connected to the host system. I2S is typically used for audio and all I2S
>> host driver reside in the audio subsystem. The tricky part will now be -
>> if
>> there is already a I2S driver for your host system - how to bridge the
>> audio
>> driver with the ADE7878 driver and expose the result as a DMA capable IIO
>> device.
> I’ll never understand why I2S is so integrated into the sound subsystem.

I guess this is because it is the traditional area where I2S is used and nobody
cared so far about using it somewhere else in the context of the Linux kernel.
Not having to have a extra layer of abstraction in the middle between ALSA/ASoC
and the I2S peripheral driver helped to keep things simple.

> There are plenty applications of I2S that have nothing to do with sound. I
> think I can make this work via an SPI interface, but with some patch work
> because the ADE7878 will drive the SPI clock.

There is nothing conceptually wrong with using I2S for for this.  The thing is
just that it might require some work since you are the first one to try this.
You have to do all the R&D. But something similar is true for SPI since the SPI
framework has no support for continuous SPI transfers.

> I also plan to use EDMA to store each measurement in a separate buffer
> (Voltage A, Voltage B, Voltage C, Current A, etc) which will make
> processing each measurement channel much easier. Question is, how
> to use IIO Ring Buffer given multiple channels?

Do you want to store each channel in it's own buffer? This would also be a new
thing within the IIO framework, so far we have only worked with interleaved
streams. Again this is not a conceptual problem, just something that hasn't
been done before and will require some work.

- Lars

Re: DMA sampling and IIO

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Thu, Feb 06, 2014 at 10:15:26PM +0100, Lars-Peter Clausen wrote:

> I guess this is because it is the traditional area where I2S is used and nobody
> cared so far about using it somewhere else in the context of the Linux kernel.
> Not having to have a extra layer of abstraction in the middle between ALSA/ASoC
> and the I2S peripheral driver helped to keep things simple.

Plus many of the uses actually found that the audio APIs were doing
useful things for them anyway - the DMA bit is reasonably useful way of
transferring continuous streams of data and nothing much cares if that
data is actually audio or not so long as the application on top doesn't
mind.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: DMA sampling and IIO

[John Syn]

On 2/7/14, 5:20 AM, "Mark Brown" <broonie@kernel.org> wrote:

>On Thu, Feb 06, 2014 at 10:15:26PM +0100, Lars-Peter Clausen wrote:
>
>> I guess this is because it is the traditional area where I2S is used
>>and nobody
>> cared so far about using it somewhere else in the context of the Linux
>>kernel.
>> Not having to have a extra layer of abstraction in the middle between
>>ALSA/ASoC
>> and the I2S peripheral driver helped to keep things simple.
>
>Plus many of the uses actually found that the audio APIs were doing
>useful things for them anyway - the DMA bit is reasonably useful way of
>transferring continuous streams of data and nothing much cares if that
>data is actually audio or not so long as the application on top doesn't
>mind.
Hi Mark,

That is interesting. The ADE7878 transmits the measurements as 16
sequential measurements (Voltage A, Voltage B, Voltage C, Current A, etc)
and uses a frame to denote a new set of measurements. Can the audio API
cope with 16 channels and how do I prevent any modification (equalization,
etc) to the measurement data? Also, is it possible to break out these
measurements into separate buffers (Voltage A buffer, Voltage B buffer,
etc)? I guess I would access these measurement in the same way as an audio
application like aplay?

What I don¹t like about this solution is the possibility of missing
samples. In an audio app, this isn¹t so critical, but in my app this would
be a big problem. 

Regards,
John
>

Re: DMA sampling and IIO

[John Syn]

I¹m following Mark¹s suggestion and using the audio API to stream the
samples from the ADE7878. I created a small circuit that translates the
ADE7878 HSDC (SPI style interface) to I2S type interface so that the
ADE7878 samples can be treated like samples from a codec. The ADE7878
outputs 16 samples which I treat as 16 slots in a traditional audio
channel. 

My platform is a BeagleBoneBlack (BBB) so I¹m using a McASP interface for
I2S. 

Next, I used the SPDIF RX codec as a template to create a ade78xx type
codec and then modified davinci-evm.c link in the ade78xx codec.
Everything seems to load OK and I see a /dev/snd/pcmC0D0c device. Now when
I try to use arecord, it simply hangs and I think the problem occurs
because the ade7854-i2c driver is in the IIO folder and my ade78xx driver
is in the audio folder and currently there is no coordination to start and
stop streaming, which probably causes under runs, over run errors. In a
traditional Codec, the I2C and I2S functionality is in the same driver so
it is easy to coordinate start streaming and stop streaming.

What is the best way to handle this problem?

Regards,

John




On 2/7/14, 5:20 AM, "Mark Brown" <broonie@kernel.org> wrote:

>On Thu, Feb 06, 2014 at 10:15:26PM +0100, Lars-Peter Clausen wrote:
>
>> I guess this is because it is the traditional area where I2S is used
>>and nobody
>> cared so far about using it somewhere else in the context of the Linux
>>kernel.
>> Not having to have a extra layer of abstraction in the middle between
>>ALSA/ASoC
>> and the I2S peripheral driver helped to keep things simple.
>
>Plus many of the uses actually found that the audio APIs were doing
>useful things for them anyway - the DMA bit is reasonably useful way of
>transferring continuous streams of data and nothing much cares if that
>data is actually audio or not so long as the application on top doesn't
>mind.

Re: DMA sampling and IIO

[John Syn]

I¹m following Mark¹s suggestion and using the audio API to stream the
samples from the ADE7878. I created a small circuit that translates the
ADE7878 HSDC (SPI style interface) to I2S type interface so that the
ADE7878 samples can be treated like samples from a codec. The ADE7878
outputs 16 samples which I treat as 16 slots in a traditional audio
channel. 

My platform is a BeagleBoneBlack (BBB) so I¹m using a McASP interface for
I2S. 

Next, I used the SPDIF RX codec as a template to create a ade78xx type
codec and then modified davinci-evm.c link in the ade78xx codec.
Everything seems to load OK and I see a /dev/snd/pcmC0D0c device. Now when
I try to use arecord, it simply hangs and I think the problem occurs
because the ade7854-i2c driver is in the IIO folder and my ade78xx driver
is in the audio folder and currently there is no coordination to start and
stop streaming, which probably causes under runs, over run errors. In a
traditional Codec, the I2C and I2S functionality is in the same driver so
it is easy to coordinate start streaming and stop streaming.

What is the best way to handle this problem?

BTW, I used this wiki as a reference:

http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_Audio_DAC_Example


Regards,

John




On 2/7/14, 5:20 AM, "Mark Brown" <broonie@kernel.org> wrote:

>On Thu, Feb 06, 2014 at 10:15:26PM +0100, Lars-Peter Clausen wrote:
>
>> I guess this is because it is the traditional area where I2S is used
>>and nobody
>> cared so far about using it somewhere else in the context of the Linux
>>kernel.
>> Not having to have a extra layer of abstraction in the middle between
>>ALSA/ASoC
>> and the I2S peripheral driver helped to keep things simple.
>
>Plus many of the uses actually found that the audio APIs were doing
>useful things for them anyway - the DMA bit is reasonably useful way of
>transferring continuous streams of data and nothing much cares if that
>data is actually audio or not so long as the application on top doesn't
>mind.

Re: DMA sampling and IIO

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]

On Wed, Sep 10, 2014 at 03:43:50PM -0700, John Syn wrote:
> I¹m following Mark¹s suggestion and using the audio API to stream the
> samples from the ADE7878. I created a small circuit that translates the

Please don't top post; quote relevant context when replying so people
can follow the discussion.

> codec and then modified davinci-evm.c link in the ade78xx codec.
> Everything seems to load OK and I see a /dev/snd/pcmC0D0c device. Now when
> I try to use arecord, it simply hangs and I think the problem occurs
> because the ade7854-i2c driver is in the IIO folder and my ade78xx driver
> is in the audio folder and currently there is no coordination to start and
> stop streaming, which probably causes under runs, over run errors. In a
> traditional Codec, the I2C and I2S functionality is in the same driver so
> it is easy to coordinate start streaming and stop streaming.

The location of the files is not going to have any impact at all, the
callbacks aren't based on link order at all.  If data isn't being
transferred the most likely reason is that the clocks aren't being
started which will be a driver issue.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: DMA sampling and IIO

[John Syn]

On 9/17/14, 12:53 PM, "Mark Brown" <broonie@kernel.org> wrote:

>On Wed, Sep 10, 2014 at 03:43:50PM -0700, John Syn wrote:
>> I¹m following Mark¹s suggestion and using the audio API to stream the
>> samples from the ADE7878. I created a small circuit that translates the
>
>Please don't top post; quote relevant context when replying so people
>can follow the discussion.
>
>> codec and then modified davinci-evm.c link in the ade78xx codec.
>> Everything seems to load OK and I see a /dev/snd/pcmC0D0c device. Now
>>when
>> I try to use arecord, it simply hangs and I think the problem occurs
>> because the ade7854-i2c driver is in the IIO folder and my ade78xx
>>driver
>> is in the audio folder and currently there is no coordination to start
>>and
>> stop streaming, which probably causes under runs, over run errors. In a
>> traditional Codec, the I2C and I2S functionality is in the same driver
>>so
>> it is easy to coordinate start streaming and stop streaming.
>
>The location of the files is not going to have any impact at all, the
>callbacks aren't based on link order at all.  If data isn't being
>transferred the most likely reason is that the clocks aren't being
>started which will be a driver issue.
Hi Mark,

The ADE7878 is the clock master and I enable that clock using a simple
script which uses /sys to write to the ADE7878 registers. I start the
clock after I start my user space capture app. On both my oscilloscope and
protocol analyzer I can see the clock running and I also see the data
streaming from the ADE7878. It looks like the McASP isn’t getting started
because my user space snd_pcm_readi call is failing. It looks like I need
some sort of trigger to start the McASP receive. I have a tlv320aic3106
codec working and I’ve captured the kernel calls using kernel function
tracer which I’m hoping will help me understand how the McASP gets
started. After that I’ll do the same with my ade78xx codec driver and
hopefully I’ll learn what is missing. I’ll keep you updated as I learn
more. 

Thank you for all your help,

Regards,
John

Re: DMA sampling and IIO

[Alessandro Rubini]

> We do have patches for better integration of DMA (especially for high speed 
> devices) into the IIO framework[1]. This is not yet upstream since it is 
> still a bit WIP, but I'm confident that it will find it's way into upstream 
> soon.

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).

/alessandro

Re: DMA sampling and IIO

[Lars-Peter Clausen]

On 02/06/2014 09:53 PM, Alessandro Rubini wrote:
>> We do have patches for better integration of DMA (especially for high speed
>> devices) into the IIO framework[1]. This is not yet upstream since it is
>> still a bit WIP, but I'm confident that it will find it's way into upstream
>> soon.
>
> 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.

- Lars

Re: DMA sampling and IIO

[Alessandro Rubini]

>> 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'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?

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).

/alessandro

Re: DMA sampling and IIO

[Lars-Peter Clausen]

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

Re: DMA sampling and IIO

[John Syn]

On 2/6/14, 1:38 PM, "Lars-Peter Clausen" <lars@metafoo.de> wrote:

>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.
Hi Lars and Alessandro,

I don¹t think this type of discussion helps create a better solution. I¹ve
been reading through IIO and ZIO docs and I was wondering what is it that
the IIO framework offers that the ZIO framework doesn¹t. Clearly ZIO
framework has several features that are not in the IIO framework. I¹m not
talking about the number of devices supported, but rather I would like to
concentrate on the frameworks themselves. Moving forward, I see two
possible solutions:


1) Update the IIO framework to incorporate the features of the ZIO
framework
2) Adopt the ZIO framework and migrate the IIO drivers to the ZIO
framework.

Forget about ownership of any one solution, but rather ask the question,
which solution is the least disruptive in the long term and which solution
gets us to a comprehensive framework soonest. Incrementally updating IIO
to add ZIO features can be very disruptive over time. Updating devices to
the ZIO framework can also be very disruptive. Which solution is the
better way forward? What am I missing here?

Regards,
John
>
>-Lars
>
>[1] https://wiki.analog.com/resources/fpga/xilinx/fmc/ad-fmcjesdadc1-ebz
>