From: jiwang <jiada_wang@mentor.com>
To: Liam Girdwood <lgirdwood@gmail.com>,
broonie@kernel.org, tiwai@suse.de, perex@perex.cz,
Joshua_Frkuska@mentor.com
Cc: ALSA development <alsa-devel@alsa-project.org>
Subject: Re: question about two ASoC commits
Date: Wed, 10 Sep 2014 14:17:50 +0900 [thread overview]
Message-ID: <540FDEFE.5000600@mentor.com> (raw)
In-Reply-To: <857E9EDCA6C0904DB3357321AA9123EBE61DF1E9@NA-MBX-01.mgc.mentorg.com>
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
next prev parent reply other threads:[~2014-09-10 5:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 8:36 question about two ASoC commits jiwang
2014-09-09 10:19 ` Mark Brown
[not found] ` <857E9EDCA6C0904DB3357321AA9123EBE61DF1E9@NA-MBX-01.mgc.mentorg.com>
2014-09-10 5:17 ` jiwang [this message]
2014-09-10 10:11 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=540FDEFE.5000600@mentor.com \
--to=jiada_wang@mentor.com \
--cc=Joshua_Frkuska@mentor.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=perex@perex.cz \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.