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.
