Hi Takashi, Mark
Thank you for your feedback
.dpcm_merged_foramt .dpcm_merged_rate .dpcm_merged_chanBetter to have bit flags.
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;
I think we don't need flag control, but should I ? (many other options are same style in struct snd_soc_dai_link)
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 ?