Re: [PATCH v8 19/22] ASoC: tegra: Enable audio mclk during tegra_asoc_utils_init

[Dmitry Osipenko]

20.01.2020 07:10, Sameer Pujar ÐÐÑÐÑ:
> 
> On 1/19/2020 8:44 PM, Dmitry Osipenko wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> 14.01.2020 10:24, Sowjanya Komatineni ÐÐÑÐÑ:
>>> Tegra PMC clock clk_out_1 is dedicated for audio mclk from Tegra30
>>> through Tegra210 and currently Tegra clock driver keeps the audio
>>> mclk enabled.
>>>
>>> With the move of PMC clocks from clock driver into pmc driver,
>>> audio mclk enable from clock driver is removed and this should be
>>> taken care by the audio driver.
>>>
>>> tegra_asoc_utils_init calls tegra_asoc_utils_set_rate and audio mclk
>>> rate configuration is not needed during init and set_rate is actually
>>> done during hw_params callback.
>>>
>>> So, this patch removes tegra_asoc_utils_set_rate call and just leaves
>>> the audio mclk enabled.
>>>
>>> Signed-off-by: Sowjanya Komatineni <skomatineni@xxxxxxxxxx>
>>> ---
>>> Â sound/soc/tegra/tegra_asoc_utils.c | 11 +++++++++--
>>> Â 1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/sound/soc/tegra/tegra_asoc_utils.c
>>> b/sound/soc/tegra/tegra_asoc_utils.c
>>> index 1dce5ad6e665..99584970f5f4 100644
>>> --- a/sound/soc/tegra/tegra_asoc_utils.c
>>> +++ b/sound/soc/tegra/tegra_asoc_utils.c
>>> @@ -216,9 +216,16 @@ int tegra_asoc_utils_init(struct
>>> tegra_asoc_utils_data *data,
>>> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ data->clk_cdev1 = clk_out_1;
>>> ÂÂÂÂÂÂ }
>>>
>>> -ÂÂÂÂ ret = tegra_asoc_utils_set_rate(data, 44100, 256 * 44100);
>>> -ÂÂÂÂ if (ret)
>>> +ÂÂÂÂ /*
>>> +ÂÂÂÂÂ * FIXME: There is some unknown dependency between audio mclk
>>> disable
>>> +ÂÂÂÂÂ * and suspend-resume functionality on Tegra30, although audio
>>> mclk is
>>> +ÂÂÂÂÂ * only needed for audio.
>>> +ÂÂÂÂÂ */
>>> +ÂÂÂÂ ret = clk_prepare_enable(data->clk_cdev1);
>>> +ÂÂÂÂ if (ret) {
>>> +ÂÂÂÂÂÂÂÂÂÂÂÂ dev_err(data->dev, "Can't enable cdev1: %d\n", ret);
>>> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ return ret;
>>> +ÂÂÂÂ }
>>>
>>> ÂÂÂÂÂÂ return 0;
>>> Â }
>>>
>> Shouldn't the clock be disabled on driver's removal?
> 
> I am not sure if we really need to do in this series as it does not
> change the behavior from what was there earlier. Also there is already a
> FIXME item here and we end up adding clock disable in remove() path of
> multiple drivers, which is going to be removed once we address FIXME.
> 

Well, perhaps this is indeed good enough for the time being.

BTW, I didn't spot any suspend-resume problems using v8.

Tested-by: Dmitry Osipenko <digetx@xxxxxxxxx>
Reviewed-by: Dmitry Osipenko <digetx@xxxxxxxxx>