[alsa-devel] question about two ASoC commits

[jiwang]

Hi Mark

From: Mark Brown [mailto:broonie at kernel.org] Sent: Tuesday, September 
09, 2014 7:20 PM To: Wang, Jiada (ESD) Cc: Liam Girdwood; Jaroslav 
Kysela; Takashi Iwai; Frkuska, Joshua; alsa-devel at alsa-project.org; 
linux-kernel at vger.kernel.org Subject: Re: question about two ASoC 
commits On Tue, Sep 09, 2014 at 05:36:36PM +0900, jiwang wrote:
>> Can anyone tell me what is the reasoning of the following two commits
>> commit: 5d16333 ASoC: SND_SOC_DAIFMT_NB_NF become 0 as default
>> settings
>> commit: eef28e1 ASoC: SND_SOC_DAIFMT_GATED become 0 as default
>> settings
>> with these two commits, now we have
>> #define SND_SOC_DAIFMT_GATED            (0 << 4)
>> #define SND_SOC_DAIFMT_NB_NF            (0 << 8)
>> in soc-dai.h
>> what's the good to shift 0 with different numbers?
>> no matter the number, they both equal to 0.
>> IMO all bit flags which share same variable (in this case
>> SND_SOC_DAIFMT) should have different value, isn't it?
> As the commit message says this is so that we have a default value which does something sensible.
Yes I can read this from commit message,
But I am not very sure why not initialize dai format variable in driver 
itself.

further more, by having

commit: 5d16333 ASoC: SND_SOC_DAIFMT_NB_NF become 0 as default

DAI hardware signal inversions Macros are declared as following
#define SND_SOC_DAIFMT_NB_NF            (0 << 8) /* normal bit clock + frame */
#define SND_SOC_DAIFMT_NB_IF            (2 << 8) /* normal BCLK + inv FRM */
#define SND_SOC_DAIFMT_IB_NF            (3 << 8) /* invert BCLK + nor FRM */
#define SND_SOC_DAIFMT_IB_IF            (4 << 8) /* invert BCLK + FRM */

Now we are having undefined hole between NB_NF and NB_IF,
don't you think it's better to shift all the others down by 1, to keep them coherent?
so that when new mode (although it's likely there won't be) needs to be added,
it can be appended to the last,otherwise it may cause confuse, either to choose (1 << 8)
or (5 << 8)


Thanks,
Jiada