linux-kernel - Re: [PATCH 4/5] ASoC: atmel_ssc_dai/atmel-pcm: adapt to dmaengine usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110629175905.GC13051@opensource.wolfsonmicro.com>
Date:	Wed, 29 Jun 2011 10:59:09 -0700
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Nicolas Ferre <nicolas.ferre@...el.com>
Cc:	alsa-devel@...a-project.org, lrg@...com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Subject: Re: [PATCH 4/5] ASoC: atmel_ssc_dai/atmel-pcm: adapt to dmaengine
 usage

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/