On Wed, Mar 22, 2023 at 11:01:48PM +0200, Marian Postevca wrote: > Mark Brown <broonie@xxxxxxxxxx> writes: > > The usual mechanism for doing this is with the standard kernel delay > > functions. Why not use them in the DAPM event? > I just followed the logic from sof_es8336.c, the reason for the change > there is given in commit log of 89cdb224f2abe37ec: > commit 89cdb224f2abe37ec4ac21ba0d9ddeb5a6a9cf68 > Author: Zhu Ning <zhuning0077@xxxxxxxxx> > Date: Fri Oct 28 10:04:56 2022 +0800 > ASoC: sof_es8336: reduce pop noise on speaker > The Speaker GPIO needs to be turned on slightly behind the codec turned on. > It also need to be turned off slightly before the codec turned down. > Current code uses delay in DAPM_EVENT to do it but the mdelay delays the > DAPM itself and thus has no effect. A delayed_work is added to turn on the > speaker. > The Speaker is turned off in .trigger since trigger is called slightly > before the DAPM events. This just sounds like a complicated way of implementing a DAPM POST event? Or now I think about it possibly we just need to tweak the current sorting such that speakers aren't run in parallel with headphones and line outputs, that should cover any issues with external speaker amplifiers. AFAICT the issue here is a speaker driver amplifying a pop in a line output from the CODEC?
Attachment:
signature.asc
Description: PGP signature
