[alsa-devel] [PATCH 0/3] ASoC: DPCM can care FE/BE merged format

[Mark Brown]

On Wed, Apr 22, 2015 at 12:13:31AM +0000, Kuninori Morimoto wrote:

> >> Maybe I'm misunderstanding, but if this feature
> >> refines above all hw_params, it will conflicts
> >> with .be_hw_params_fixup ?

> >Yeah, there it'll need to clear the flag.

> .dpcm_merged_foramt is using bit field, like this

> 	unsigned int dpcm_merged_foramt:1;

Note that you've misspelt this - should be "format".

> I think we don't need flag control, but should I ?
> (many other options are same style in struct snd_soc_dai_link)

Not quite sure what "flag control" is here, sorry?

> > > There are indeed cases where a BE takes incompatible hw configuration,
> > > which needs be_hw_params_fixup.  But, in general, the FE's hw_params
> > > is just copied to BE.  That is, we assume here blindly that FE's
> > > configuration is compatible with BE's.  And, now this assumption isn't
> > > true in rcar's case, so we face the issue.

> > Well, it's as much that we're assuming there's rewriting going on which
> > handles things - in many of these systems everything will be going
> > through a DSP which rewrites everything on the way.

> I guess we can use .be_hw_params_fixup if it is
> "special rewrite" (ex 48kHz -> 44.1kHz, 8ch -> 2ch etc...).
> But like this case (= it needs rewrite but normally we assume it)
> using general method is useful.

> I'm happy to create/send v2 patch, but, it will be "flag" fixup ?

I'm having a bit of a hard time following, sorry.  If what you're saying
here is that if we have a fixup method we should by default assume that
only the front end constraints are relevant and ignore the back end then
that does actually seem reasonable.
-------------- 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/20150427/d195b5b6/attachment.sig>