From: Lars-Peter Clausen <lars@metafoo.de>
To: Daniel Mack <daniel@zonque.org>
Cc: Cliff Cai <cliff.cai@analog.com>,
ALSA development <alsa-devel@alsa-project.org>
Subject: Re: Enhance support for SigmaDSP chips
Date: Thu, 11 Apr 2013 12:51:10 +0200 [thread overview]
Message-ID: <5166959E.7010008@metafoo.de> (raw)
In-Reply-To: <516688D4.9040700@zonque.org>
On 04/11/2013 11:56 AM, Daniel Mack wrote:
> Hi Lars,
> Hi Cliff,
>
> I'm looking into the SigmaDSP AD1701 support, as a new prospective
> project will use it. What's going to be used on this chip is not the
> DAC/ADC features though, but the internal, programmable DSP things, and
> designers will use the SigmaStudio IDE to generate the firmware.
>
> So I'm wondering how to support this kind of chip properly in ALSA,
> which is not straight-forward, as the controls exported by it are
> specific to the loaded firmware of course. Also, the IDE is free to
> re-allocate every sub-addresses of its controls when something changes
> in the layout of the building blocks.
>
> One idea I have in mind is to have a little parser script that reads the
> generated sources of the IDE and dump a device-tree node snippet which
> can then be put into the final DT. The driver would need to learn about
> how to interpret that DT nodes, which will most likely just contain a
> name, a sub-address, along with some mask and shift values.
>
> I wanted to ask for your opinion on that before I start. Have you ever
> used any of the DSP features from ALSA/ASoC? Are there any pitfalls I
> should be aware of? Is anyone actively working on improvements on the
> driver?
>
> An alternative approach is to write a userspace library of course, but
> that's going to be problematic once anybody wants to use the DSP
> features in parallel to the DAC/ADC.
Hi,
I just yesterday wrote a small post how you can program the DSP registers.
http://ez.analog.com/message/83094#83094
I'd like to be able to put the information about the different algorithms
into the DSP firmware file itself, so we can auto instantiate the controls
from the driver. The problem is that it is not so easy to generalize the
export of the algorithms from SigmaStudio.
Another problem is that you don't know how to calculate the algorithm
parameters at runtime for some of the more complex algorithms.
I don't think it's a good idea to put the control info into the devicetree
and would rather prefer to see them go into the firmware. But as I said
auto-generating this from exported SigmaStudio files is not so easy. So
maybe manually creating the control info table might be an option.
Btw. in case you haven't seen it the SigmaTcp tools is quite useful during
the development of the firmware since it allows you to connect SigmaStudio
directly to the DSP on the board.
http://wiki.analog.com/resources/tools-software/linux-software/sigmatcp
- Lars
next parent reply other threads:[~2013-04-11 10:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <516688D4.9040700@zonque.org>
2013-04-11 10:51 ` Lars-Peter Clausen [this message]
2013-04-11 12:02 ` Enhance support for SigmaDSP chips Daniel Mack
2013-04-11 12:53 ` Lars-Peter Clausen
2013-04-17 8:21 ` Sample rates above 192000 Mike Looijmans
2013-04-17 11:44 ` Mike Looijmans
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=5166959E.7010008@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=cliff.cai@analog.com \
--cc=daniel@zonque.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 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.