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

Mark Brown
2021-09-09T14:21:43Z

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]