All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: alsa-devel@alsa-project.org, Stephen Warren <swarren@nvidia.com>,
	Liam Girdwood <lrg@ti.com>
Subject: Re: [PATCH] ASoC: wm8903: disable mic detect irqs until jack registered
Date: Sat, 9 Jun 2012 09:31:58 +0800	[thread overview]
Message-ID: <20120609013154.GA3924@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1339177075-20506-1-git-send-email-swarren@wwwdotorg.org>


[-- Attachment #1.1: Type: text/plain, Size: 1551 bytes --]

On Fri, Jun 08, 2012 at 11:37:54AM -0600, Stephen Warren wrote:

> This problem can be triggered by fully initializing an audio card, then
> removing and re-inserting the machine driver module. This would leave
> mic detection enabled in HW, and mic_jack set to a stale value.

This isn't a good fix for this issue, - the fact that it works is more a
sign that nobody got round to moving the interrupt registration to the
I2C probe() function than anything else.

> As an aside, I wondered instead about modifying wm8903_remove() to disable
> mic detection, and clear any status. However, even if we do that, I think
> we still want to make this change too, since I think we want probe() to
> work the first time without relying on previous HW state?

It does currently work without relying on previous hardware state, the
first thing that we do with the chip as soon as we get control of it is
a hard reset.

In terms of the mic detection itself it's really the responsibility of
the machine driver to say that the jack doesn't exist any more when it's
being removed - it should be calling wm8903_mic_detect() again during
unregistration to disable the interrupt.  Otherwise there's always going
to be an interval where the jack object has been discarded but the CODEC
driver is still active and could get an interrupt.  That fix should be
enough for 3.5.

Normally nobody cares about this because for most systems there's no
realistic use case for removing a driver like this, it's something
you're only going to run into during driver development.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2012-06-09  1:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 17:37 [PATCH] ASoC: wm8903: disable mic detect irqs until jack registered Stephen Warren
2012-06-09  1:31 ` Mark Brown [this message]
2012-06-09  4:31   ` Stephen Warren

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=20120609013154.GA3924@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@ti.com \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.