From: "Pali Rohár" <pali.rohar@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Jarkko Nikula <jarkko.nikula@bitmer.com>,
Liam Girdwood <lgirdwood@gmail.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
Aaro Koskinen <aaro.koskinen@iki.fi>, Nishanth Menon <nm@ti.com>,
Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
joerg Reisenweber <joerg@openmoko.org>,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Nokia N900 headset detection & MIC Bias + TVOUT
Date: Mon, 9 Jan 2017 21:32:51 +0100 [thread overview]
Message-ID: <201701092132.51414@pali> (raw)
In-Reply-To: <20170109193828.rzpyzzl6g3v2nylk@sirena.org.uk>
[-- Attachment #1: Type: Text/Plain, Size: 3495 bytes --]
On Monday 09 January 2017 20:38:28 Mark Brown wrote:
> On Mon, Jan 09, 2017 at 08:29:53PM +0100, Pali Rohár wrote:
> > On Monday 09 January 2017 20:22:01 Mark Brown wrote:
> > > point where you need an actual change. Note that if something
> > > holds the microphone bias on (like something using the
> > > microphone) separately then that'll take effect so if you really
> > > need things to get turned off then that won't work but you
> > > probably have trouble anyway in that situation.
> >
> > This is needed for cable/jack detection at time when jack is
> > inserted. So before it there cannot be any user of (disconnected)
> > microphone.
>
> That's not going to stop userspace, consider what happens if the
> headset gets removed and userspace is slow to stop a recording for
> example.
Ok. But in this case changing mic bias does not introduce any problems
as userspace already trying to record from disconnected microphone.
> > What I need is to enable mic bias, measure ADC of some time period,
> > check status of some GPIOs. Then disable mic bias, measure ADC
> > again and check GPIOs. I in this detection procedure I need to
> > ensure that nobody changes mic bias. So I though that locking the
> > whole procedure could ensure that.
>
> That sounds racy and a bit unusual - what's the actual procedure
> here?
The whole old code for production Nokia N900 devices is there:
https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/misc/nokia-av.c
If it is usual/unusual/crazy/wtf/:-) I can just tell: it is working fine
with that Maemo 2.6.28 production kernel. And there is no documentation
for it, just code. So the best what we can do is reimplement that driver
for mainline kernel and check if it is working. (Then we can maybe start
changing logic if something make sense...).
It is more complicated, but basic idea seems to be:
Use interrupt handler when jack_detection_gpio changes. When 1 --> jack
unplugged (no detection is needed), otherwise plugged and start
detection.
Start: set eci_sw_gpio to 1, enable mic bias, wait 20msec
Detection point 1: if eci0_gpio is 1 then goto Detection point 3
Detection point 2: measure ECI_ADC (thresholds define type) and goto Stop
Detection point 3: set eci_sw_gpio to 0, wait 20msec, if eci1_gpio is 1 then goto Stop (open cable
was inserted)
Detection point 4: set eci_sw_gpio to 1, disable mic bias, measure ECI_ADC until it stabilize
(thresholds define type)
Stop: set eci_sw_gpio to 1, revert mic bias
Thresholds for Detection point 2 are defined as:
#define THRESHOLD_GROUNDED 40 // HEADPHONES or line input cable or external mic
#define THRESHOLD_VIDEO_HI 150 // VIDEO_CABLE
Thresholds for Detection point 4 are defined as:
#define THRESHOLD_HEADSET_HI 1000 // BASIC_HEADSET
(probably threshold for basic headset is not correct)
The whole procedure is repeated 5-10 times. If open cable is detected
then eci_sw_gpio is set to 0 and procedure is periodically repeated
after some interval (looking at the code I think that interrupt for
eci1_gpio could be used instead of busy waiting). Optionally if nothing
(= unknown) after 5-10 times is detected then another procedure for ECI
headsets could be used. As Joerg pointed that nokia-av.c code has
incorrect detection for ECI it first needs to be investigated. But it
will need to disable TVOUT (OMAP3430 TV_OUT1 and TV_VFB1 pins).
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
prev parent reply other threads:[~2017-01-09 20:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 23:07 Nokia N900 headset detection & MIC Bias + TVOUT Pali Rohár
2017-01-09 11:27 ` Mark Brown
2017-01-09 13:13 ` Pali Rohár
2017-01-09 19:22 ` Mark Brown
2017-01-09 19:29 ` Pali Rohár
2017-01-09 19:38 ` Mark Brown
2017-01-09 20:32 ` Pali Rohár [this message]
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=201701092132.51414@pali \
--to=pali.rohar@gmail.com \
--cc=aaro.koskinen@iki.fi \
--cc=broonie@kernel.org \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=jarkko.nikula@bitmer.com \
--cc=joerg@openmoko.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=pavel@ucw.cz \
--cc=peter.ujfalusi@ti.com \
--cc=sre@kernel.org \
--cc=tony@atomide.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