[alsa-devel] [PATCH 4/9] ASoC: Intel: Skylake: Add FE and BE hw_params handling

Mark Brown broonie at kernel.org
Sat Aug 15 16:46:46 CEST 2015


On Sat, Aug 15, 2015 at 07:30:14PM +0530, Vinod Koul wrote:
> On Fri, Aug 14, 2015 at 10:53:10PM +0100, Mark Brown wrote:
> > On Sat, Aug 08, 2015 at 01:06:19AM +0530, Subhransu S. Prusty wrote:

> > > +	/*
> > > +	 * 16 bit is 16 bit container whereas 24 bit is in 32 bit container so
> > > +	 * update bit depth accordingly
> > > +	 */
> > > +	if (format->valid_bit_depth == SKL_DEPTH_16BIT)
> > > +		format->bit_depth = format->valid_bit_depth;
> > > +	else if (format->valid_bit_depth == SKL_DEPTH_24BIT)
> > > +		format->bit_depth = SKL_DEPTH_32BIT;
> > > +

> > What if the depth is neither 16 bit nor 24 bit?  Shouldn't this just be
> > a simple override for the 24 bit case?

> These are the only two DSP supports, so am not sure that overriding will
> work with DSP. I think we should add else and error out.

Then write a switch statement.  :/

> > > +static int skl_tplg_be_set_params(struct snd_soc_dai *dai,
> > > +					struct snd_soc_dapm_widget *w,
> > > +					struct skl_pipe_params *params)
> > > +{
> > > +	if (!w->power) {
> > > +		dev_dbg(dai->dev, "set params for widget=%s\n", w->name);
> > > +		return skl_tplg_be_fill_pipe_params(dai, w->priv, params);
> > > +	}
> > > +
> > > +	return -EINVAL;
> > 
> > Shouldn't that be -EBUSY?  The normal idiom would be to check to see if
> > we were busy and error out rather than writing it as only configuing if
> > not busy (which looks like an error case now).
> 
> Not EBUSY. So here we are trying to set params for the pipe. So we would
> expect that pipe (widget) should be powered up by DAPM, but if that is not
> the case then we are in bad state. I am thinking EIO might suit this one better

Right, that's why I'm saying -EBUSY - we can't configure the pipe
because it is current in use.

> > There's some more common code here and the same patterns as above...  :/

> well the problem here is sink, source. Former was for source pipe using
> p->source, here we have sink pipe and using p->sink.
> Same here too that we either set params or for sink pipe

> Jeeja did try to make this common but it becomes quite hard, if you have
> a trick up your sleeve for this, am all ears :)

Well, I don't have the code any more.

> > > +	if (params->stream == SNDRV_PCM_STREAM_CAPTURE) {
> > > +		w = dai->capture_widget;
> > > +
> > > +		dev_dbg(dai->dev, "Stream name=%s\n", w->name);
> > > +		return skl_tplg_be_set_sink_pipe_params(dai, w, params);
> > > +	}

> > Normally that'd be written as an if/else, and the only difference
> > between the two cases here is which widget we pick...

> Yes we can change to else. Btw should we rather do if and if else, and else
> for error check, in case the value became bad. I am thinking latter.

Either works.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150815/eed35fcb/attachment.sig>


More information about the Alsa-devel mailing list