question about two ASoC commits

question about two ASoC commits

[jiwang]

Hi

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?

Thanks,
Jiada

Re: question about two ASoC commits

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: question about two ASoC commits

[jiwang]

Hi Mark

From: Mark Brown [mailto:broonie@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@alsa-project.org; 
linux-kernel@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

Re: question about two ASoC commits

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 487 bytes --]

On Wed, Sep 10, 2014 at 02:17:50PM +0900, jiwang wrote:

> Yes I can read this from commit message,
> But I am not very sure why not initialize dai format variable in driver
> itself.

If the user doesn't specify anything we have to pick a default, this is
the quickest and simplest way of doing that.

> 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?

Sure, feel free to submit a patch.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]