[alsa-devel] [PATCH 0/3] ASoC: DPCM can care FE/BE merged format
Kuninori Morimoto
kuninori.morimoto.gx at renesas.com
Mon May 11 06:14:47 CEST 2015
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
More information about the Alsa-devel
mailing list