On 1/4/20 5:05 PM, Dmitry Osipenko wrote:
04.01.2020 08:49, Sowjanya Komatineni ÐÐÑÐÑ:Looking into soc_pcm_hw_params, I see dai_link hw_params ops happens prior toÂ platform snd_soc_dai_driver hw_params ops.
On 1/2/20 8:12 AM, Dmitry Osipenko wrote:The I2S driver uses asynchronous pm_runtime_put() and thus there is no
02.01.2020 10:03, Sowjanya Komatineni ÐÐÑÐÑ:Regarding disabling audio mclk during PLLA rate change, no need to
On 12/27/19 1:19 PM, Sowjanya Komatineni wrote:Sounds good, thanks. I'll be happy to review and test it.
On 12/27/19 6:56 AM, Dmitry Osipenko wrote:PLLA is used for both I2S controller clock and also for audio mclk. I2S
25.12.2019 20:57, Mark Brown ÐÐÑÐÑ:currently, audio mclk and its parent clocks enabling are from clock
On Mon, Dec 23, 2019 at 12:14:34AM +0300, Dmitry Osipenko wrote:Ok
21.12.2019 01:26, Sowjanya Komatineni ÐÐÑÐÑ:Please delete unneeded context from mails when replying.Â Doing this
Tegra PMC clock clk_out_1 is dedicated for audio mclk from Tegra30
through Tegra210 and currently Tegra clock driver does initial parent
configuration for audio mclk "clk_out_1" and enables them by default.
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
- clk_disable_unprepare(data->clk_cdev1);The root of the problem is that you removed clocks enabling from
+ÂÂÂ if (__clk_is_enabled(data->clk_cdev1))
driver init and not from tegra_asoc_utils_init.
plla rate change through tegra_asoc_utils_set_rate() happens only whenI don't know details about that hardware either, maybe it is simply notI'm not sure why clocks should be disabled during the rate-changing,I know nothing about this particular device but this is not that
probably this action is not really needed.
unusual a restriction for audio hardware, you often can't
robustly reconfigure the clocking for a device while it's active
due to issues in the hardware.Â You often see issues with FIFOs
glitching or state machines getting stuck. This may not be an
issue here but if it's something that's documented as a
requirement it's probably good to pay attention.
safe to change PLL_A rate dynamically and then CLK_SET_RATE_GATE could
If nobody knows for sure, then will be better to keep
there is not active playback or record corresponding to this sound
So, I don't see reason for disabling clock during rate change and not
sure why we had this from the beginning.
Can you please comment?
Yes, we can use CLK_SET_RATE_GATE for PLLA and remove clock disabling
before rate change.
driver suspend resume implementations takes care of enabling and
disabling I2S clock but audio mclk will be enabled during that time and
PLLA disable might not happen. So using CLK_SET_RATE_GATE prevents rate
change to happen and as rate change happens only when there is no active
audio record/playback, we can perform rate change without disable/enable
during rate change.
So probably below changes should be good.
ÂÂ * remove asoc_utils_set_rate call from asoc_utils_init as set_rate
ÂÂÂÂ happens during existing hw_params callback implementations in sound
ÂÂÂÂ drivers and there is no need to do rate change during asoc_utils_init.
ÂÂ * remove disable/enable clocks during rate change in asoc_utils_set_rate.
ÂÂ * add startup and shutdown snd_soc_ops callbacks to do enable and
ÂÂÂÂ disable audio mclk.
explicitly disable PLLA on asoc utils as clock driver takes care of it
properly during pll rate change.
But the downstream clock divider hardware can malfunction without
recovery when subject to unstable PLL output during locking, unless
clock is gated.
So it is recommended to disable downstream clocks during PLL rate change.
PLLA downstream clocks are I2S and audio mclk (cdev1/clk1 and extern1
clocks) and I2S clock is disabled in I2S driver by PM runtime ops.
guarantee that I2S clock is disabled at the time of changing PLLA rate.
Could this be a problem?
So, PLL rate change thru asoc_utils_set_rate happens during sample rate config of dai_link hw_params ops and during this time I2S will always be in idle state.
Sameer, Please confirm.
For audio mclk, need to make sure mclk are disabled during rate change.
So below are the changes to audio clocks that will be in next version.
ÂÂ * remove tegra_asoc_utils_set_rate call from tegra_asoc_utils_init as
ÂÂÂÂ tegra_asoc_utils_set_rate happens during hw_params callback.
ÂÂ * add shutdown snd_soc_ops callbacks to disable of audio mclk.
ÂÂ * remove disable audio mclk (cdev1) and plla clocks prior to rate
ÂÂÂÂ change in tegra_asoc_utils_set_rate (as audio mclk will always be in
ÂÂÂÂ disabled state every time hw_param callback gets executed) and keep
ÂÂÂÂ audio mclk enable after the rate change in tegra_asoc_utils_set_rate.