25.12.2019 20:57, Mark Brown ÐÐÑÐÑ:currently, audio mclk and its parent clocks enabling are from clock driver init and not from tegra_asoc_utils_init.
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
material.
- clk_disable_unprepare(data->clk_cdev1);The root of the problem is that you removed clocks enabling from
- clk_disable_unprepare(data->clk_pll_a_out0);
- clk_disable_unprepare(data->clk_pll_a);
+ if (__clk_is_enabled(data->clk_cdev1))
+ clk_disable_unprepare(data->clk_cdev1);
tegra_asoc_utils_init().
plla rate change through tegra_asoc_utils_set_rate() happens only when there is not active playback or record corresponding to this sound device.I 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
be used.
If nobody knows for sure, then will be better to keep
tegra_asoc_utils_set_rate() unchanged.