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.