On 11/15/2018 09:04 PM, Mark Brown wrote:
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. ... 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.
Thanks for clarifying about idle_bias_off/ignore_pmdown_time. As far as I can see, idle_bias_off seems to be set by default, as the pcm512x driver is now a component driver and idle_bias_on is not set to true. I've also tried to explicitly set it to false, as well as setting use_pmdown_time to false. As far as ignore_pmdown_time is concerned, it seems to be settable at the dai_link level now, which is convenient for my use case. Unfortunately none of this helps. Although the chip is turned off without delay, it's turned off only while the device is closed. As soon as the device is opened, it is turned on and kept on during all subsequent hw_params calls, where clock switching takes place. The pops always get through.
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.
Regarding your suggestion to do the bounce as part of set_sysclk() in the CODEC driver, I'm unsure how to proceed. The set_sysclk callback is virtually undocumented, as far as I could see, and not supported by the pcm512x component driver. Even if I could support it, either my somehow filling in the component driver callbacks from the machine driver, or by patching the pcm512x component driver itself, if such a patch would be acceptable, I don't see how it could help with my problem. Since both set_sysclk callbacks seem to operate at the CODEC or CODEC DAI level, which knows nothing about how to switch clocks on this particular card, I don't see how I can do the switch there, where I can safely wrap it inside a bounce. Maybe I'm just missing something, but as far as I can see, there's no way to get around the need to synchronize access to the POWER register, so as to be able to reliably power bounce the chip while the clock selection takes place outside the CODEC/component driver. If such synchronization is impossible, I'm forced to accept that the pop will be generated and rely on suppressing it via a mute. This can be done by implementing the .digital_mute callback in the pcm512x component driver, for which I have a patch, which seems to work reliably for suppressing both the loud pop, as well as various other lower volume clicks and pops generated by the chip. I still feel that not generating the pop in the first place would be preferable though. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
