Re: [PATCH v2 1/2] ASoC: Add driver for CLPS711X DAI interface

From: Mark Brown <broonie@kernel.org>
To: Alexander Shiyan <shc_work@mail.ru>
Cc: alsa-devel@alsa-project.org, Arnd Bergmann <arnd@arndb.de>,
	Takashi Iwai <tiwai@suse.de>, Liam Girdwood <lgirdwood@gmail.com>,
	Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH v2 1/2] ASoC: Add driver for CLPS711X DAI interface
Date: Thu, 1 May 2014 11:29:35 -0700	[thread overview]
Message-ID: <20140501182935.GT3245@sirena.org.uk> (raw)
In-Reply-To: <1397283328-633-1-git-send-email-shc_work@mail.ru>

[-- Attachment #1.1: Type: text/plain, Size: 1532 bytes --]

On Sat, Apr 12, 2014 at 10:15:28AM +0400, Alexander Shiyan wrote:

> +static int clps711x_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
> +{
> +	struct snd_soc_pcm_runtime *rtd = substream->private_data;
> +	struct clps711x_dai *dai = snd_soc_platform_get_drvdata(rtd->platform);
> +
> +	switch (cmd) {
> +	case SNDRV_PCM_TRIGGER_START:
> +		atomic_set(&dai->running, 1);
> +		hrtimer_start(&dai->hrt, ns_to_ktime(dai->reload),
> +			      HRTIMER_MODE_REL);
> +		break;
> +	case SNDRV_PCM_TRIGGER_STOP:
> +		atomic_set(&dai->running, 0);
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}

This machinery seems pretty much identical to the FIQ code for i.MX -
I know you don't think anything can be shared but can you please be more
explicit about why?  The contents of the FIQ are different but the
start and stop mechanics don't look so different (and given that the
general idea of what they do is very similar this isn't surprising to
me).

> +static int clps711x_pcm_silence(struct snd_pcm_substream *substream,
> +				int channel, snd_pcm_uframes_t pos,
> +				snd_pcm_uframes_t count)
> +{
> +	/* Silence is provided in the FIQ interrupt routine */
> +	/* This empty function is necessary */
> +	return 0;
> +}

Why is it required?  It seems like what actually happens here is that
the FIQ handles underflow by playing zero bytes but that's not quite the
same thing as what silence does - we can still underflow after sending
silence, this is about sending an explicit amount of silence.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]