On Thu, Jul 14, 2022 at 10:26:17AM +0800, Zhu Ning wrote:
snd_soc_component_write(comp, ES8326_ANA_MICBIAS_1B, 0x7c);
this ES8326_ANA_MICBIAS_1B register is also modified in the workqueue, could this lead to invalid configurations?
In es8326_irq, MICBIAS is turned on to detect headphone from headset. When an unpluged event is detected, MICBIAS is turned off to minimize pop noise. Maybe a comment/macro for this?
The issue is that both the workqueue and interrupt are modifying the register - what happens if they race with each other?
Generally it's better to manage the MICBIAS as a DAPM widget and then force it on when needed for jack detection (search other drivers for examples) and then let DAPM worry about refcounting.
dev_dbg(comp->dev, "gpio flag %#04x", iface);if ((iface & ES8326_HPINSERT_FLAG) == 0) {dev_dbg(comp->dev, "No headset detected");snd_soc_jack_report(es8326->jack, 0, SND_JACK_HEADSET);
should you check if es8326->jack is set? in the 8316 driver you have a check for a spurious interrupt before set_jack() is called
I haven't seen other codecs (rt5640) handle spurious irq.
A lot of devices have a chip level reset register which they use to get the device into a known state during probe, generally the detection logic is turned off when the device is reset which helps here.
it's rather odd that there's a resume but no suspend?
Since the codec loses power on suspend. It's also odd to write to the registers when they are going to be cleared during suspend. The lost registers need to be written during resume though.
You shouldn't rely on the device loosing power over suspend, a lot of systems will do that but it depends on the physical design (perhaps the power is shared with something needed to detect wakeup). It's best practice to get the device into the lowest power possible state before power is cut, things that don't impact power can generally be left alone though.