[alsa-devel] [PATCH 1/4] ASoC: compress: Pass error out of soc_compr_pointer

Charles Keepax ckeepax at opensource.wolfsonmicro.com
Fri Mar 11 11:04:25 CET 2016


On Fri, Mar 11, 2016 at 01:18:43PM +0530, Vinod Koul wrote:
> On Thu, Mar 10, 2016 at 10:44:51AM +0000, Charles Keepax wrote:
> > The soc_compr_pointer does not correctly pass any errors returned by the
> > driver callback back up the stack. This patch corrects this issue.
> 
> Should we do that :) I am not too sure. Pointer query is supposed to read
> the current value and return. You are trying to indicate that stream has
> gone bad which is not the same as read faced an error...
> 
> Also please use cover letter for these things to describe problem you are
> trying to solve.

Apologies for not doing so, I had been viewing this as more of a
simple oversight in the framework rather than a design choice.

The problem I am looking at is the DSP suffers an unrecoverable
error. We can find out about this error in our driver because the
DSP returns some error status to us.  This is fine if user-space
is doing a read as reads return error status back to user-space
so the user can find out that things have gone bad. However, if
user-space is doing an avail request there is no path for the
error to come back up to user-space. The pointer request returns
zero available data, so a read never happens and we basically
just end up sitting waiting for data on a stream that we know
full well has died.

I will have a look at other options for propagating this error,
I guess it should also be possible to push it through the poll so
I can look at why that isn't happening.

I guess my return question would be I can imagine many reasons
why a pointer query might fail, especially for off chip DSPs.
What is the reasoning for wanting to hide those errors from the
rest of the system? It seems to me it would be best to handle an
error as soon as it is noticed, and if a particular system has a
pointer request that never fails then it can just not return an
error.

Thanks,
Charles


More information about the Alsa-devel mailing list