[alsa-devel] [PATCH 6/6] ASoC: davinci-mcasp: Add overrun/underrun event handling

Peter Ujfalusi peter.ujfalusi at ti.com
Tue Nov 11 08:47:29 CET 2014


On 11/10/2014 08:58 PM, Mark Brown wrote:
> On Mon, Nov 10, 2014 at 12:32:20PM +0200, Peter Ujfalusi wrote:
> 
>> +	stat = mcasp_get_reg(mcasp, DAVINCI_MCASP_TXSTAT_REG);
>> +	if (stat & XUNDRN) {
>> +		dev_warn(mcasp->dev, "Transmit buffer underflow\n");
>> +		substream = mcasp->substreams[SNDRV_PCM_STREAM_PLAYBACK];
>> +		if (substream) {
>> +			snd_pcm_stream_lock_irq(substream);
>> +			if (snd_pcm_running(substream))
>> +				snd_pcm_stop(substream, SNDRV_PCM_STATE_XRUN);
>> +			snd_pcm_stream_unlock_irq(substream);
>> +		}
>> +	}
>> +
>> +	mcasp_set_reg(mcasp, DAVINCI_MCASP_TXSTAT_REG, stat);
>> +
>> +	return IRQ_HANDLED;
> 
> This will unconditionally report that any interrupt that gets delivered
> is handled and acknowledged regardles of what was reported.  This isn't
> ideal, I'd at least expect a warning to be printed if we're handling
> interrupts we don't understand.

The setup code only enable interrupt generation for XUNDRN for tx or ROVRN for
rx. If we receive the interrupt it is because either of these happened.
We are not yet interested on the other bits in the status register and not all
bits are signaling error.
If for example an XSYNCERR happens, we will not know about it till to point we
have XUNDRN, which is going to trigger the interrupt.
If we would have prints for other bits, we should have at least strategy to
deal with them.
At the end of the function we ack the interrupt to the HW.
Most probably we are going to handle more events, but right now we only care
about under or overruns.

-- 
Péter


More information about the Alsa-devel mailing list