[PATCH 06/13] ASoC: tegra: Add Tegra210 based MVC driver

[Sameer Pujar]

On 9/9/2021 7:50 PM, Mark Brown wrote:
> On Thu, Sep 09, 2021 at 06:33:33PM +0530, Sameer Pujar wrote:
>> On 9/7/2021 1:35 PM, Sameer Pujar wrote:
>>> On 9/3/2021 11:43 PM, Mark Brown wrote:
>>>> On Fri, Aug 27, 2021 at 03:03:52PM +0530, Sameer Pujar wrote:
>>>>> +	/* SW reset */
>>>>> +	regmap_write(mvc->regmap, TEGRA210_MVC_SOFT_RESET, 1);
>>>> What about all the cached values in the regmap, won't they get out of
>>>> sync?  Especially things like volume and mute, it looks like the mute
>>>> just gets written directly to the regmap and not otherwise saved.
>>> 1. I think original idea was to disable MVC (forcefully) before new
>>> configurations are applied and eventually it gets enabled via DAPM path.
>>> DAPM path handles disable also, but sometimes MVC may get stuck in
>>> enable state (due to a previous usage) when all the data in pipeline is
>>> not processed. My understanding is that reset is restricted to this
>>> alone. The volume/mute registers seem not to be affected by reset.
>>> However I will confirm with HW about the reset behavior and affected
>>> register map. Thanks for pointing this.
>> I confirmed the behavior with HW folk here. The reset above clears all FSM,
>> flushes flow control of FIFO and resets the state registers. It also brings
>> module back to disabled state (without flushing the data in the pipe). There
>> is no impact on the register cache, as state registers are anyway volatile
>> and module disable is applicable only when it was hung in previous usage.
>> Otherwise DAPM would disable the module during session close.
> This needs to be*much*  clearer in the code, it looks like a bug at the
> minute.  It's very surprising that some of the registers wouldn't be
> affected by a reset.

I will put additional comments to make it more clear and tag it as a 
'soft reset' instead of 'reset' as HW spec defines it.