From: Xing Zheng <zhengxing@rock-chips.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-rockchip@lists.infradead.org, woojoo.lee@samsung.com,
dianders@chromium.org, heiko@sntech.de, smbarber@google.com,
hychao@google.com, cychiang@google.com,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: rk3399_gru_sound: fix recording pop at first attempt
Date: Thu, 22 Sep 2016 21:50:42 +0800 [thread overview]
Message-ID: <7d3cce2f-bda3-292f-cb3f-223c26b5ced3@rock-chips.com> (raw)
In-Reply-To: <20160919144404.GA18734@leverpostej>
Hi Mark,
On 2016年09月19日 22:44, Mark Rutland wrote:
> On Mon, Sep 19, 2016 at 10:29:39PM +0800, Xing Zheng wrote:
>> From: Wonjoon Lee <woojoo.lee@samsung.com>
>>
>> Pop happens when mclk applied but dmic's own boot-time
>> Specify dmic delay times in dt to make sure
>> clocks are ready earlier than dmic working
>>
>> Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
>> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
>> ---
>>
>> .../bindings/sound/rockchip,rk3399-gru-sound.txt | 6 ++++++
>> sound/soc/rockchip/rk3399_gru_sound.c | 14 ++++++++++++++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
>> index f19b6c8..b7dd3ab 100644
>> --- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
>> +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
>> @@ -6,6 +6,12 @@ Required properties:
>> connected to the codecs
>> - rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
>>
>> +Optional properties:
>> +- dmic-delay : specify delay time for DMIC ready.
>> + If this option is specified, which means it's required dmic need
>> + delay for DMIC to ready so that rt5514 can avoid recording before
>> + DMIC send valid data
> What units is this in? Per the code it looks like ms, so if we follow
> Documentation/devicetree/bindings/property-units.txt, thous should be
> named something like dmic-enable-delay-ms.
OK, the "dmic-wakeup-delay-ms" have been done.
> That said, do we even need a property for this? Does this vary much in
> practice?
>
> If it does, can we not derive this delay from other information (e.g.
> the rates of input clocks and so on)? What exactly determines the
> necessary delay?
Yeah, the DMIC spec indicates wake-up time as 15ms max, so we need to
start recording 15ms after MCLK after testing.
@Woojoo, please correct me if I was wrong.
Thanks.
>
> Thanks,
> Mark.
>
>>
>> sound {
>> diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
>> index 164b6da..6ab838b 100644
>> --- a/sound/soc/rockchip/rk3399_gru_sound.c
>> +++ b/sound/soc/rockchip/rk3399_gru_sound.c
>> @@ -37,6 +37,8 @@
>>
>> #define SOUND_FS 256
>>
>> +unsigned int rt5514_dmic_delay;
>> +
>> static struct snd_soc_jack rockchip_sound_jack;
>>
>> static const struct snd_soc_dapm_widget rockchip_dapm_widgets[] = {
>> @@ -122,6 +124,9 @@ static int rockchip_sound_rt5514_hw_params(struct snd_pcm_substream *substream,
>> return ret;
>> }
>>
>> + /* Wait for DMIC stable */
>> + msleep(rt5514_dmic_delay);
>> +
>> return 0;
>> }
>>
>> @@ -334,6 +339,15 @@ static int rockchip_sound_probe(struct platform_device *pdev)
>> return -ENODEV;
>> }
>>
>> + /* Set DMIC delay */
>> + ret = device_property_read_u32(&pdev->dev, "dmic-delay",
>> + &rt5514_dmic_delay);
>> + if (ret) {
>> + rt5514_dmic_delay = 0;
>> + dev_dbg(&pdev->dev,
>> + "no optional property 'dmic-delay' found, default: no delay\n");
>> + }
>> +
>> rockchip_dailinks[DAILINK_RT5514_DSP].cpu_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
>> rockchip_dailinks[DAILINK_RT5514_DSP].cpu_dai_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
>> rockchip_dailinks[DAILINK_RT5514_DSP].platform_name = kstrdup_const(dev_name(dev), GFP_KERNEL);
>> --
>> 1.7.9.5
>>
>>
>
>
--
- Xing Zheng
prev parent reply other threads:[~2016-09-22 13:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 14:29 Xing Zheng
2016-09-19 14:44 ` Mark Rutland
2016-09-22 13:50 ` Xing Zheng [this message]
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=7d3cce2f-bda3-292f-cb3f-223c26b5ced3@rock-chips.com \
--to=zhengxing@rock-chips.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cychiang@google.com \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=heiko@sntech.de \
--cc=hychao@google.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=perex@perex.cz \
--cc=robh+dt@kernel.org \
--cc=smbarber@google.com \
--cc=tiwai@suse.com \
--cc=woojoo.lee@samsung.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®