From: jeffy <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dgreid-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org,
briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
Jaroslav Kysela <perex-/Fr2/VpizcU@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Takashi Iwai <tiwai-IBi9RG/b67k@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v3 2/9] ASoC: rockchip: Remove obsolete dmic-delay
Date: Fri, 18 Aug 2017 22:41:44 +0800 [thread overview]
Message-ID: <5996FCA8.9090909@rock-chips.com> (raw)
In-Reply-To: <20170818115223.pyfqji5jkplt6isx-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Hi Mark,
On 08/18/2017 07:52 PM, Mark Brown wrote:
> On Fri, Aug 18, 2017 at 09:41:54AM +0800, jeffy wrote:
>> On 08/18/2017 01:11 AM, Mark Brown wrote:
>>> On Thu, Aug 17, 2017 at 12:44:10PM +0800, Jeffy Chen wrote:
>
>>>> -Optional properties:
>>>> -- dmic-wakeup-delay-ms : specify delay time (ms) 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
>
>>> Why would nobody ever want to use this in future?
>
>> hmmm, check again, rt5514 fixed this issue in there driver instead in:
>> a5461fd6c8f7 ASoC: rt5514: Add the DMIC initial delay to wait it ready.
>
>> so we don't need this...
>
> You don't need it on your board for new DTs but why is it not possible
> that another board might need it?
>
this property is added in:
3a6f9dce6116 ASoC: rk3399_gru_sound: fix recording pop at first attempt
to fix pop noise by performing a delay after set dmic clk.
the binding said "dmic-wakeup-delay-ms", but actually driver parses
"dmic-delay":
+ /* Set DMIC delay */
+ ret = device_property_read_u32(&pdev->dev, "dmic-delay",
+ &rt5514_dmic_delay);
@@ -123,6 +125,9 @@ static int rockchip_sound_rt5514_hw_params(struct
snd_pcm_subst
ream *substream,
return ret;
}
+ /* Wait for DMIC stable */
+ msleep(rt5514_dmic_delay); <-- perform a delay after set dmic clk
+
return 0;
}
then realtek guys fixed this issue in the rt5514 codec driver:
a5461fd6c8f7 ASoC: rt5514: Add the DMIC initial delay to wait it ready.
+ device_property_read_u32(dev, "realtek,dmic-init-delay-ms",
+ &rt5514->pdata.dmic_init_delay);
@@ -452,6 +452,9 @@ static int rt5514_set_dmic_clk(struct
snd_soc_dapm_widget *w,
RT5514_CLK_DMIC_OUT_SEL_MASK,
idx << RT5514_CLK_DMIC_OUT_SEL_SFT);
+ if (rt5514->pdata.dmic_init_delay)
+ msleep(rt5514->pdata.dmic_init_delay); <-- perform a
delay after set dmic clk
so we don't need to deal with it in every boards' drivers which using
rt5514 codec, and we are using this new property now:
ag dmic arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
620: realtek,dmic-init-delay = <20>; <---- oops, seems
missing "-ms" at the end, guess due to realtek patch ends up differently
on upstream. will send a patch to fix it later.
anyway, i think it's ok to remove that out-dated property in our driver :)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: jeffy.chen@rock-chips.com (jeffy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/9] ASoC: rockchip: Remove obsolete dmic-delay
Date: Fri, 18 Aug 2017 22:41:44 +0800 [thread overview]
Message-ID: <5996FCA8.9090909@rock-chips.com> (raw)
In-Reply-To: <20170818115223.pyfqji5jkplt6isx@sirena.org.uk>
Hi Mark,
On 08/18/2017 07:52 PM, Mark Brown wrote:
> On Fri, Aug 18, 2017 at 09:41:54AM +0800, jeffy wrote:
>> On 08/18/2017 01:11 AM, Mark Brown wrote:
>>> On Thu, Aug 17, 2017 at 12:44:10PM +0800, Jeffy Chen wrote:
>
>>>> -Optional properties:
>>>> -- dmic-wakeup-delay-ms : specify delay time (ms) 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
>
>>> Why would nobody ever want to use this in future?
>
>> hmmm, check again, rt5514 fixed this issue in there driver instead in:
>> a5461fd6c8f7 ASoC: rt5514: Add the DMIC initial delay to wait it ready.
>
>> so we don't need this...
>
> You don't need it on your board for new DTs but why is it not possible
> that another board might need it?
>
this property is added in:
3a6f9dce6116 ASoC: rk3399_gru_sound: fix recording pop at first attempt
to fix pop noise by performing a delay after set dmic clk.
the binding said "dmic-wakeup-delay-ms", but actually driver parses
"dmic-delay":
+ /* Set DMIC delay */
+ ret = device_property_read_u32(&pdev->dev, "dmic-delay",
+ &rt5514_dmic_delay);
@@ -123,6 +125,9 @@ static int rockchip_sound_rt5514_hw_params(struct
snd_pcm_subst
ream *substream,
return ret;
}
+ /* Wait for DMIC stable */
+ msleep(rt5514_dmic_delay); <-- perform a delay after set dmic clk
+
return 0;
}
then realtek guys fixed this issue in the rt5514 codec driver:
a5461fd6c8f7 ASoC: rt5514: Add the DMIC initial delay to wait it ready.
+ device_property_read_u32(dev, "realtek,dmic-init-delay-ms",
+ &rt5514->pdata.dmic_init_delay);
@@ -452,6 +452,9 @@ static int rt5514_set_dmic_clk(struct
snd_soc_dapm_widget *w,
RT5514_CLK_DMIC_OUT_SEL_MASK,
idx << RT5514_CLK_DMIC_OUT_SEL_SFT);
+ if (rt5514->pdata.dmic_init_delay)
+ msleep(rt5514->pdata.dmic_init_delay); <-- perform a
delay after set dmic clk
so we don't need to deal with it in every boards' drivers which using
rt5514 codec, and we are using this new property now:
ag dmic arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
620: realtek,dmic-init-delay = <20>; <---- oops, seems
missing "-ms"@the end, guess due to realtek patch ends up differently
on upstream. will send a patch to fix it later.
anyway, i think it's ok to remove that out-dated property in our driver :)
WARNING: multiple messages have this Message-ID (diff)
From: jeffy <jeffy.chen@rock-chips.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-kernel@vger.kernel.org, dgreid@chromium.org,
heiko@sntech.de, briannorris@chromium.org, mka@chromium.org,
dianders@chromium.org, Jaroslav Kysela <perex@perex.cz>,
devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
linux-rockchip@lists.infradead.org,
Liam Girdwood <lgirdwood@gmail.com>,
Takashi Iwai <tiwai@suse.com>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 2/9] ASoC: rockchip: Remove obsolete dmic-delay
Date: Fri, 18 Aug 2017 22:41:44 +0800 [thread overview]
Message-ID: <5996FCA8.9090909@rock-chips.com> (raw)
In-Reply-To: <20170818115223.pyfqji5jkplt6isx@sirena.org.uk>
Hi Mark,
On 08/18/2017 07:52 PM, Mark Brown wrote:
> On Fri, Aug 18, 2017 at 09:41:54AM +0800, jeffy wrote:
>> On 08/18/2017 01:11 AM, Mark Brown wrote:
>>> On Thu, Aug 17, 2017 at 12:44:10PM +0800, Jeffy Chen wrote:
>
>>>> -Optional properties:
>>>> -- dmic-wakeup-delay-ms : specify delay time (ms) 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
>
>>> Why would nobody ever want to use this in future?
>
>> hmmm, check again, rt5514 fixed this issue in there driver instead in:
>> a5461fd6c8f7 ASoC: rt5514: Add the DMIC initial delay to wait it ready.
>
>> so we don't need this...
>
> You don't need it on your board for new DTs but why is it not possible
> that another board might need it?
>
this property is added in:
3a6f9dce6116 ASoC: rk3399_gru_sound: fix recording pop at first attempt
to fix pop noise by performing a delay after set dmic clk.
the binding said "dmic-wakeup-delay-ms", but actually driver parses
"dmic-delay":
+ /* Set DMIC delay */
+ ret = device_property_read_u32(&pdev->dev, "dmic-delay",
+ &rt5514_dmic_delay);
@@ -123,6 +125,9 @@ static int rockchip_sound_rt5514_hw_params(struct
snd_pcm_subst
ream *substream,
return ret;
}
+ /* Wait for DMIC stable */
+ msleep(rt5514_dmic_delay); <-- perform a delay after set dmic clk
+
return 0;
}
then realtek guys fixed this issue in the rt5514 codec driver:
a5461fd6c8f7 ASoC: rt5514: Add the DMIC initial delay to wait it ready.
+ device_property_read_u32(dev, "realtek,dmic-init-delay-ms",
+ &rt5514->pdata.dmic_init_delay);
@@ -452,6 +452,9 @@ static int rt5514_set_dmic_clk(struct
snd_soc_dapm_widget *w,
RT5514_CLK_DMIC_OUT_SEL_MASK,
idx << RT5514_CLK_DMIC_OUT_SEL_SFT);
+ if (rt5514->pdata.dmic_init_delay)
+ msleep(rt5514->pdata.dmic_init_delay); <-- perform a
delay after set dmic clk
so we don't need to deal with it in every boards' drivers which using
rt5514 codec, and we are using this new property now:
ag dmic arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
620: realtek,dmic-init-delay = <20>; <---- oops, seems
missing "-ms" at the end, guess due to realtek patch ends up differently
on upstream. will send a patch to fix it later.
anyway, i think it's ok to remove that out-dated property in our driver :)
next prev parent reply other threads:[~2017-08-18 14:41 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-17 4:44 [PATCH v3 0/9] ASoC: rockchip: Parse dai links from dts Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
2017-08-17 4:44 ` [PATCH v3 1/9] ASoC: rt5514: Switch to snd_soc_register_codec Jeffy Chen
2017-08-17 17:11 ` Mark Brown
2017-08-18 2:48 ` jeffy
2017-08-18 2:48 ` jeffy
2017-08-17 4:44 ` [PATCH v3 2/9] ASoC: rockchip: Remove obsolete dmic-delay Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
2017-08-17 17:11 ` Mark Brown
2017-08-17 17:11 ` Mark Brown
2017-08-18 1:41 ` jeffy
2017-08-18 1:41 ` jeffy
2017-08-18 1:41 ` jeffy
[not found] ` <599645E2.4020402-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2017-08-18 11:52 ` Mark Brown
2017-08-18 11:52 ` Mark Brown
2017-08-18 11:52 ` Mark Brown
[not found] ` <20170818115223.pyfqji5jkplt6isx-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2017-08-18 14:41 ` jeffy [this message]
2017-08-18 14:41 ` jeffy
2017-08-18 14:41 ` jeffy
2017-08-17 4:44 ` [PATCH v3 3/9] ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
2017-08-17 4:44 ` [PATCH v3 4/9] arm64: dts: rockchip: Add rt5514 dsp for Gru Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
[not found] ` <20170817044417.22069-1-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2017-08-17 4:44 ` [PATCH v3 5/9] arm64: dts: rockchip: Update rt5514 devices' compatible " Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
2017-08-17 4:44 ` [PATCH v3 6/9] ASoC: rockchip: Parse dai links from dts Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
2017-08-17 4:44 ` [PATCH v3 7/9] ASoC: rockchip: Add support for DP codec Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
2017-08-29 19:26 ` Applied "ASoC: rockchip: Add support for DP codec" to the asoc tree Mark Brown
2017-08-29 19:26 ` Mark Brown
2017-08-29 19:26 ` Mark Brown
2017-08-29 19:26 ` Mark Brown
2017-08-17 4:44 ` [PATCH v3 8/9] ASoC: rockchip: Add support for DMIC codec Jeffy Chen
2017-08-17 4:44 ` Jeffy Chen
2017-08-17 4:44 ` [PATCH v3 9/9] dt-bindings: ASoC: rockchip: Update description of rockchip,codec Jeffy Chen
2017-08-17 4:44 ` [PATCH v3 9/9] dt-bindings: ASoC: rockchip: Update description of rockchip, codec Jeffy Chen
2017-08-17 22:20 ` [PATCH v3 9/9] dt-bindings: ASoC: rockchip: Update description of rockchip,codec Rob Herring
2017-08-17 22:20 ` Rob Herring
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=5996FCA8.9090909@rock-chips.com \
--to=jeffy.chen-tnx95d0mmh7dzftrwevzcw@public.gmane.org \
--cc=alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org \
--cc=briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dgreid-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=perex-/Fr2/VpizcU@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=tiwai-IBi9RG/b67k@public.gmane.org \
/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.