From: John Syn <john3909@gmail.com>
To: <linux-iio@vger.kernel.org>
Cc: Mark Brown <broonie@kernel.org>, Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: DMA sampling and IIO
Date: Wed, 10 Sep 2014 15:43:50 -0700 [thread overview]
Message-ID: <D036210C.44F7D%john3909@gmail.com> (raw)
In-Reply-To: <20140207132058.GN32298@sirena.org.uk>
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.
next prev parent reply other threads:[~2014-09-10 22:43 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 [this message]
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
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=D036210C.44F7D%john3909@gmail.com \
--to=john3909@gmail.com \
--cc=broonie@kernel.org \
--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).