All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: About the platform_name field in snd_soc_dai_link
Date: Tue, 10 Aug 2010 14:47:55 +0100	[thread overview]
Message-ID: <20100810134755.GC6416@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <20100810133818.GL27749@pengutronix.de>

On Tue, Aug 10, 2010 at 03:38:18PM +0200, Sascha Hauer wrote:

> I'm wondering what exactly a snd_soc_platform is. Apparently the
> snd_pcm_ops/pcm_new/pcm_free are specific to a platform. For my
> understanding these operations are more specific to a cpu_dai. Looking
> at the tree it seems that each cpu_dai has exactly one possible
> platform, which seems logical to me because the cpu_dai knows how to
> transfer the data.

They're for the DMA bit of the CPU.  While most platforms have a single
DMA controller (though some have more than one) it's moderately common
to have more than one DAI (eg, dedicated I2S and DSP mode controllers
rather than a programmable serial port, or an AC'97 controller) so it's
useful to share the DMA code.

> My problem on i.MX is that I currently have two possible cpu dais
> (imx-ssi.[01]) and each can be configured to use dma or fiq depending
> on the dma capabilities. So the cpu_dai knows which pcm_ops we have
> to use, but currently it's the soc glue code which has to decide in
> platform_name. Am I understanding something wrong here?

This is mostly a holdover from the existing (current mainline) ASoC
structuring at the minute, that also has the DMA configured per machine.
This may change depending on future hardware requirements, though.

  reply	other threads:[~2010-08-10 13:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-10 13:38 About the platform_name field in snd_soc_dai_link Sascha Hauer
2010-08-10 13:47 ` Mark Brown [this message]
2010-08-10 14:09   ` Sascha Hauer
2010-08-10 14:16   ` Liam Girdwood
2010-08-10 14:42     ` Mark Brown
2010-08-10 14:49       ` Liam Girdwood
2010-08-11 11:39     ` Sascha Hauer

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=20100810134755.GC6416@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=s.hauer@pengutronix.de \
    /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.