Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Zhu Ning <zhuning0077@gmail.com>
Cc: zhuning@everest-semi.com, alsa-devel@alsa-project.org,
	pierre-louis.bossart@linux.intel.com,
	yangxiaohua@everest-semi.com, tiwai@suse.com
Subject: Re: [PATCH 1/2] ASoC: codecs: add support for ES8326
Date: Thu, 14 Jul 2022 12:53:07 +0100	[thread overview]
Message-ID: <YtADo0TJccwLRmKC@sirena.org.uk> (raw)
In-Reply-To: <20220714022617.6345-1-zhuning0077@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

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.

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

  reply	other threads:[~2022-07-14 11:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-12 14:41 [PATCH 1/2] ASoC: codecs: add support for ES8326 Zhu Ning
2022-07-12 14:41 ` [PATCH 2/2] dt-bindings: sound: es8326: Add dtbindings documentation Zhu Ning
2022-07-12 15:17 ` [PATCH 1/2] ASoC: codecs: add support for ES8326 Pierre-Louis Bossart
2022-07-14  2:26   ` Zhu Ning
2022-07-14 11:53     ` Mark Brown [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-07-14  2:42 Zhu Ning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YtADo0TJccwLRmKC@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.com \
    --cc=yangxiaohua@everest-semi.com \
    --cc=zhuning0077@gmail.com \
    --cc=zhuning@everest-semi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox