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.
Attachment:
signature.asc
Description: PGP signature
