Hi Mark
unsigned int dpcm_merged_foramt:1;
Note that you've misspelt this - should be "format".
Ahh.. will fix in v2
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?
Sorry for my confusable words. Takashi mentioned
> .dpcm_merged_foramt > .dpcm_merged_rate > .dpcm_merged_chan
Better to have bit flags.
I guess Takashi means like this
u32 xxx_flags #define DPCM_xxxx_FORMAT (1 << 0) #define DPCM_xxxx_RATE (1 << 1) #define DPCM_xxxx_CHAN (1 << 2)
But, this .dpcm_merged_xxx is defined as
unsigned int dpcm_merged_foramt:1;
"flag control" here means #defined DPCM_xxxx_CHAN flag, and I think we don't need it.
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.
Yes it is !!
Best regards --- Kuninori Morimoto