Messages in this thread | | | Date | Thu, 9 Sep 2021 15:20:33 +0100 | From | Mark Brown <> | Subject | Re: [PATCH 06/13] ASoC: tegra: Add Tegra210 based MVC driver |
| |
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. [unhandled content-type:application/pgp-signature] | |