Re: [PATCH 2/4] ASoC: core: Adds support for cpu loopback dai_link

[Vinod Koul <vinod.koul@intel.com>]

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

On Wed, Dec 30, 2015 at 06:03:44PM +0000, Mark Brown wrote:
> On Wed, Dec 16, 2015 at 08:18:06PM +0530, Vinod Koul wrote:
> > On Wed, Dec 02, 2015 at 10:32:41AM +0000, Mark Brown wrote:
> 
> > > But neither of these is a CODEC so why would the CODEC flag be set in
> > > the DAI?  Unless your "Codec" here is genuinely the CODEC rather than
> > > the CPU DAI connected to the CODEC in which case surely this is just a
> > > normal DAI link?
> 
> > Sorry Mark for late reply..
> 
> > You are right this is like a normal link, and yes that is _exactly_ we need,
> > but we also need parameters to be specified for this as this is hostless.
> 
> > The moment I add 'params" core will do different connections which do not
> > work for us.
> 
> > I am okay if you have something else in mind which solves our problem :)
> 
> Isn't this what the DPCM fixup() is supposed to handle?

Yes you are right but it doesn't. Fixup will be invoked only when
someone invoked hw_params, but for the loop in this case since we
register a PCM and not a dai-link widget the DAPM trigger for loop
patch does not find any dailink widgets and does not invoke hw_params
or fixup.

Looking at this I think we should modify the snd_soc_dapm_new_dai_widgets()
and add template.event, but not sure if it was cause other issues..

> As I keep
> saying I really think these systems would work a lot better if they were
> representing the DSP as a CODEC, that makes everything much more
> consistent and less riddled with special cases.

The problem is manging DMAs and params, today codec approach does not
help me with these, but yes I will keep looking for ways to enhnace to
core as discussed in the ELC with you :)

Thanks
-- 
~Vinod

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

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