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.