Re: Need help fixing pop/click artifacts in an ASOC driver

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1851 bytes --]

On Thu, Nov 15, 2018 at 01:25:28PM +0200, Dimitris Papavasiliou wrote:

> Unless I misunderstand, I can't change the CODEC driver's settings
> (such as ignore_pmdown_time) from the machine driver.  Even if I

You can get to the CODEC driver from the machine driver, and for
idle_bias_off there's probably a good case for just setting it
unconditionally given the lack of delays.

> could, I'm not entirely sure it would consistently fix the problem.
> For instance, if the auto-mute is set to 21ms, the DAC output is muted
> automatically by the chip after 21ms of no input and the pop still
> manages to get through before that on occasion.

That's why I'm suggesting ignore_pmdown_time as a first thing to try -
it should cause the powerdown to happen synchronously so there's no
chance for anything else to go in and change the clocking to cause a
pop.

> It also seems like a roundabout solution, that depends on proper
> sequencing, i.e. it is assumed that the device is always biased
> off before the hw_params callback of the machine driver is
> called, something which might change in the future and cause a
> regression.

The whole goal with the combination of idle_bias_off and
ignore_pmdown_time is to ensure that this happens in an orderly
fashion in a way that the core knows about.

> afterwards.  Isn't there some way to lock the component/CODEC's
> regmap, so as to perform an operation involving more than one
> register change atomically? Something like
> snd_soc_component_lock/unlock_regmap sounds like it might be
> generally useful, to synchronize access to a chip's registers
> across CODE/machine/etc. drivers.

No, there's no facility for that and it's such a niche case that I'm not
convinced it's a good idea to do it.  Another thing you could do here
though is to do the bounce as part of set_sysclk() in the CODEC driver.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]