From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: alsa-devel@alsa-project.org,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
lrg@ti.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/5] ASoC: atmel_ssc_dai/atmel-pcm: adapt to dmaengine usage
Date: Wed, 29 Jun 2011 10:59:09 -0700 [thread overview]
Message-ID: <20110629175905.GC13051@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <7fd26c605d5cfa422d0fc37a7b790fb9a837d7e3.1309368631.git.nicolas.ferre@atmel.com>
On Wed, Jun 29, 2011 at 08:00:18PM +0200, Nicolas Ferre wrote:
> +static const struct snd_pcm_hardware atmel_pcm_dma_hardware = {
> + .info = SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_MMAP_VALID |
The naming here looks a bit undescriptive but I'm not sure what a better
name would be - obviously both DMA controllers are DMA controllers. It
feels like it would be more sensible to just write a separate DMA driver
as I'm not sure how much code actually ends up being shared here but it
looks pretty small from the diff...
> +static bool filter(struct dma_chan *chan, void *slave)
> +{
> + struct at_dma_slave *sl = slave;
> +
Odd whitespace here.
> +static int atmel_pcm_dma_alloc(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params)
> +{
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + struct atmel_runtime_data *prtd = runtime->private_data;
> + struct ssc_device *ssc = prtd->params->ssc;
> + struct at_dma_slave *sdata = NULL;
> +
> + if (ssc->pdev)
> + sdata = ssc->pdev->dev.platform_data;
Why wouldn't we have a device, and why is there a separate copy of the
device?
> + if (!prtd->dma_chan) {
> + pr_err("atmel-pcm: "
> + "DMA channel not available, unable to use SSC-audio\n");
> + return -EBUSY;
dev_err() and don't split strings over lines.
> + switch (prtd->params->data_xfer_size) {
> + case 1:
> + buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
> + break;
> + case 2:
> + buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
> + break;
> + case 4:
> + buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + break;
> + default:
> + return;
> + }
It strikes me that this mapping of bytes to DMA_SLAVE_ is likely to be
quite common and might be nice as a helper in dmaengine.
I'd also expect to see something complain (even if just with BUG()) if we
hit the default case.
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/5] ASoC: atmel_ssc_dai/atmel-pcm: adapt to dmaengine usage
Date: Wed, 29 Jun 2011 10:59:09 -0700 [thread overview]
Message-ID: <20110629175905.GC13051@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <7fd26c605d5cfa422d0fc37a7b790fb9a837d7e3.1309368631.git.nicolas.ferre@atmel.com>
On Wed, Jun 29, 2011 at 08:00:18PM +0200, Nicolas Ferre wrote:
> +static const struct snd_pcm_hardware atmel_pcm_dma_hardware = {
> + .info = SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_MMAP_VALID |
The naming here looks a bit undescriptive but I'm not sure what a better
name would be - obviously both DMA controllers are DMA controllers. It
feels like it would be more sensible to just write a separate DMA driver
as I'm not sure how much code actually ends up being shared here but it
looks pretty small from the diff...
> +static bool filter(struct dma_chan *chan, void *slave)
> +{
> + struct at_dma_slave *sl = slave;
> +
Odd whitespace here.
> +static int atmel_pcm_dma_alloc(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params)
> +{
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + struct atmel_runtime_data *prtd = runtime->private_data;
> + struct ssc_device *ssc = prtd->params->ssc;
> + struct at_dma_slave *sdata = NULL;
> +
> + if (ssc->pdev)
> + sdata = ssc->pdev->dev.platform_data;
Why wouldn't we have a device, and why is there a separate copy of the
device?
> + if (!prtd->dma_chan) {
> + pr_err("atmel-pcm: "
> + "DMA channel not available, unable to use SSC-audio\n");
> + return -EBUSY;
dev_err() and don't split strings over lines.
> + switch (prtd->params->data_xfer_size) {
> + case 1:
> + buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
> + break;
> + case 2:
> + buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
> + break;
> + case 4:
> + buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + break;
> + default:
> + return;
> + }
It strikes me that this mapping of bytes to DMA_SLAVE_ is likely to be
quite common and might be nice as a helper in dmaengine.
I'd also expect to see something complain (even if just with BUG()) if we
hit the default case.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: alsa-devel@alsa-project.org, lrg@ti.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH 4/5] ASoC: atmel_ssc_dai/atmel-pcm: adapt to dmaengine usage
Date: Wed, 29 Jun 2011 10:59:09 -0700 [thread overview]
Message-ID: <20110629175905.GC13051@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <7fd26c605d5cfa422d0fc37a7b790fb9a837d7e3.1309368631.git.nicolas.ferre@atmel.com>
On Wed, Jun 29, 2011 at 08:00:18PM +0200, Nicolas Ferre wrote:
> +static const struct snd_pcm_hardware atmel_pcm_dma_hardware = {
> + .info = SNDRV_PCM_INFO_MMAP |
> + SNDRV_PCM_INFO_MMAP_VALID |
The naming here looks a bit undescriptive but I'm not sure what a better
name would be - obviously both DMA controllers are DMA controllers. It
feels like it would be more sensible to just write a separate DMA driver
as I'm not sure how much code actually ends up being shared here but it
looks pretty small from the diff...
> +static bool filter(struct dma_chan *chan, void *slave)
> +{
> + struct at_dma_slave *sl = slave;
> +
Odd whitespace here.
> +static int atmel_pcm_dma_alloc(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params)
> +{
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + struct atmel_runtime_data *prtd = runtime->private_data;
> + struct ssc_device *ssc = prtd->params->ssc;
> + struct at_dma_slave *sdata = NULL;
> +
> + if (ssc->pdev)
> + sdata = ssc->pdev->dev.platform_data;
Why wouldn't we have a device, and why is there a separate copy of the
device?
> + if (!prtd->dma_chan) {
> + pr_err("atmel-pcm: "
> + "DMA channel not available, unable to use SSC-audio\n");
> + return -EBUSY;
dev_err() and don't split strings over lines.
> + switch (prtd->params->data_xfer_size) {
> + case 1:
> + buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
> + break;
> + case 2:
> + buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
> + break;
> + case 4:
> + buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + break;
> + default:
> + return;
> + }
It strikes me that this mapping of bytes to DMA_SLAVE_ is likely to be
quite common and might be nice as a helper in dmaengine.
I'd also expect to see something complain (even if just with BUG()) if we
hit the default case.
next prev parent reply other threads:[~2011-06-29 20:57 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-29 18:00 use dmaengine for atmel ssc/pcm dai drivers Nicolas Ferre
2011-06-29 18:00 ` Nicolas Ferre
2011-06-29 18:00 ` Nicolas Ferre
2011-06-29 18:00 ` [PATCH 1/5] ASoC: wm8731: rework power management Nicolas Ferre
2011-06-29 18:00 ` Nicolas Ferre
2011-06-29 18:00 ` Nicolas Ferre
2011-06-29 17:11 ` Mark Brown
2011-06-29 17:11 ` Mark Brown
2011-06-29 17:11 ` Mark Brown
2011-06-30 13:57 ` Nicolas Ferre
2011-06-30 13:57 ` Nicolas Ferre
2011-06-30 13:57 ` Nicolas Ferre
2011-06-30 15:04 ` [alsa-devel] " Nicolas Ferre
2011-06-30 15:04 ` Nicolas Ferre
2011-06-30 15:04 ` Nicolas Ferre
2011-06-30 15:22 ` Mark Brown
2011-06-30 15:22 ` Mark Brown
2011-06-30 15:22 ` Mark Brown
2011-07-01 9:31 ` Nicolas Ferre
2011-07-01 9:31 ` Nicolas Ferre
2011-07-01 9:31 ` Nicolas Ferre
2011-06-29 18:00 ` [PATCH 2/5] ASoC: atmel-ssc: add phybase in device structure Nicolas Ferre
2011-06-29 18:00 ` Nicolas Ferre
2011-06-29 17:48 ` Mark Brown
2011-06-29 17:48 ` Mark Brown
2011-07-01 14:46 ` [PATCH V2 " Nicolas Ferre
2011-07-01 14:46 ` Nicolas Ferre
2011-07-01 14:46 ` Nicolas Ferre
2011-06-29 18:00 ` [PATCH 3/5] ASoC: atmel-ssc: dmaengine usage switch depending on cpu Nicolas Ferre
2011-06-29 18:00 ` Nicolas Ferre
2011-06-29 18:00 ` [PATCH 4/5] ASoC: atmel_ssc_dai/atmel-pcm: adapt to dmaengine usage Nicolas Ferre
2011-06-29 18:00 ` Nicolas Ferre
2011-06-29 17:59 ` Mark Brown [this message]
2011-06-29 17:59 ` Mark Brown
2011-06-29 17:59 ` Mark Brown
2011-06-30 0:54 ` Koul, Vinod
2011-06-30 0:54 ` Koul, Vinod
2011-06-30 0:54 ` Koul, Vinod
2011-06-29 18:00 ` [PATCH 5/5] ASoC: atmel_ssc_dai: PM: actually stopping clock on suspend/resume Nicolas Ferre
2011-06-29 18:00 ` Nicolas Ferre
2011-07-01 10:43 ` [PATCH] ASoC: wm8731: set the ACTIVE bit if bias ON entered Nicolas Ferre
2011-07-01 10:43 ` Nicolas Ferre
2011-07-01 10:43 ` Nicolas Ferre
2011-07-01 14:18 ` Liam Girdwood
2011-07-01 14:18 ` Liam Girdwood
2011-07-01 14:18 ` Liam Girdwood
2011-07-01 16:15 ` Mark Brown
2011-07-01 16:15 ` Mark Brown
2011-07-04 9:46 ` Nicolas Ferre
2011-07-04 9:46 ` Nicolas Ferre
2011-07-04 9:46 ` Nicolas Ferre
2011-07-04 17:29 ` Mark Brown
2011-07-04 17:29 ` Mark Brown
2011-07-04 17:29 ` Mark Brown
2011-07-04 17:34 ` Liam Girdwood
2011-07-04 17:34 ` Liam Girdwood
2011-07-04 17:34 ` Liam Girdwood
2011-07-05 7:58 ` Nicolas Ferre
2011-07-05 7:58 ` Nicolas Ferre
2011-07-05 7:58 ` Nicolas Ferre
2011-07-05 20:27 ` [alsa-devel] " Mark Brown
2011-07-05 20:27 ` Mark Brown
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=20110629175905.GC13051@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=nicolas.ferre@atmel.com \
--cc=u.kleine-koenig@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.