[alsa-devel] [PATCH 1/3] ASoC: soc_jack - add function to determine jack type
This patch adds a helper function that determines the jack type given the mic bias value. For any codec that would give the mic bias value on a jack insertion, this function would return the type of jack based on mic bias range
Signed-off-by: Harsha Priya priya.harsha@intel.com Signed-off-by: Vinod Koul vinod.koul@intel.com --- include/sound/soc.h | 15 +++++++++++++++ sound/soc/soc-jack.c | 18 ++++++++++++++++++ 2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h index 7ecdaef..afe98eb 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -246,6 +246,19 @@ typedef int (*hw_write_t)(void *,const char* ,int);
extern struct snd_ac97_bus_ops soc_ac97_ops;
+enum soc_mic_bias_zones { + /* mic bias volutage range for Headphones*/ + SND_SOC_JACK_HP_START = 0, + SND_SOC_JACK_HP_END = 400, + /* mic bias volutage range for American Headset*/ + SND_SOC_JACK_AM_HS_START = 400, + SND_SOC_JACK_AM_HS_END = 650, + /* mic bias volutage range for Headset*/ + SND_SOC_JACK_HS_START = 650, + SND_SOC_JACK_HS_END = 2000, + SND_SOC_UNDEFINED, +}; + enum snd_soc_control_type { SND_SOC_CUSTOM, SND_SOC_I2C, @@ -307,6 +320,8 @@ void snd_soc_jack_notifier_register(struct snd_soc_jack *jack, struct notifier_block *nb); void snd_soc_jack_notifier_unregister(struct snd_soc_jack *jack, struct notifier_block *nb); +int snd_soc_jack_get_type(int mic_bias); + #ifdef CONFIG_GPIOLIB int snd_soc_jack_add_gpios(struct snd_soc_jack *jack, int count, struct snd_soc_jack_gpio *gpios); diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c index ac5a5bc..462965a 100644 --- a/sound/soc/soc-jack.c +++ b/sound/soc/soc-jack.c @@ -186,6 +186,24 @@ void snd_soc_jack_notifier_unregister(struct snd_soc_jack *jack, } EXPORT_SYMBOL_GPL(snd_soc_jack_notifier_unregister);
+/** + * snd_soc_jack_get_type - Based on the mic bias value, this function returns + * the type of jack + * + * @mic_bias: mic bias value detected + * + * Based on the mic bias value passed, this function helps identify + * the type of jack as either SND_JACK_HEADSET or SND_JACK_HEADPHONE. + */ +int snd_soc_jack_get_type(int mic_bias) +{ + if (mic_bias >= SND_SOC_JACK_HP_START && mic_bias < SND_SOC_JACK_HS_END) + return SND_JACK_HEADSET; + else + return SND_JACK_HEADPHONE; +} +EXPORT_SYMBOL_GPL(snd_soc_jack_get_type); + #ifdef CONFIG_GPIOLIB /* gpio detect */ static void snd_soc_jack_gpio_detect(struct snd_soc_jack_gpio *gpio)
On Fri, 2011-01-28 at 22:39 +0530, Harsha Priya wrote:
This patch adds a helper function that determines the jack type given the mic bias value. For any codec that would give the mic bias value on a jack insertion, this function would return the type of jack based on mic bias range
Signed-off-by: Harsha Priya priya.harsha@intel.com Signed-off-by: Vinod Koul vinod.koul@intel.com
Acked-by: Liam Girdwood lrg@slimlogic.co.uk
On Fri, Jan 28, 2011 at 10:39:39PM +0530, Harsha Priya wrote:
given the mic bias value. For any codec that would give the mic bias value on a jack insertion, this function would return the type of jack based on mic bias range
I think this is too minimal as an API for this. There's two things I'm missing here. The major one is that there's no handling of debounce - jack insertion is a very slow and very analogue process relative to CPUs so taking a single reading is likely to give false measurements.
The other is that there's no facility for either scaling the voltages with micbias (obviously the specific voltages read are going to vary depending on what the micbias voltage on a given system is) or for adding other things that can be detected. For example, some systems have buttons on their headset which pull micbias to ground via varying resistances with individual buttons being detected by measuring the different voltages resulting from the different resistances.
It'd be worth taking a look at the sec_jack stuff that Samsung have used in at least some of their Android devices:
http://android.git.kernel.org/?p=kernel/samsung.git;a=blob;f=include/linux/s...
It's quite hard coded in code terms but it covers things like the debounce.
given the mic bias value. For any codec that would give the mic bias value on a jack insertion, this function would return the type of jack based on mic bias range
I think this is too minimal as an API for this. There's two things I'm missing here. The major one is that there's no handling of debounce - jack insertion is a very slow and very analogue process relative to CPUs so taking a single reading is likely to give false measurements.
I believe this should be part of codec driver that would make sure that it has determined the right adc value and then call the function to find the jack type. In the sn95031 codec, this is handled in hardware with programmable debounce values. The default value takes care of ensuring that the adc value is read is for right jack event. Later, I will add a kcontrol for the same to enable programming it.
The other is that there's no facility for either scaling the voltages with micbias (obviously the specific voltages read are going to vary depending on what the micbias voltage on a given system is)
I can add a field "system_micbias" field and the ranges fields to snd_soc_jack structure. The machine driver can set these details when it creates a jack. The new API can give the jack or button type based on this range. This way its scalable. Will this help? Let us know, if there is a better way
adding other things that can be detected. For example, some systems have buttons on their headset which pull micbias to ground via varying resistances with individual buttons being detected by measuring the different voltages resulting from the different resistances.
It'd be worth taking a look at the sec_jack stuff that Samsung have used in at least some of their Android devices:
http://android.git.kernel.org/?p=kernel/samsung.git;a=blob;f=include/linux/s...
It's quite hard coded in code terms but it covers things like the debounce.
Thanks for the link.
-Harsha
On Tue, Feb 01, 2011 at 06:49:11PM +0530, Harsha, Priya wrote:
I think this is too minimal as an API for this. There's two things I'm missing here. The major one is that there's no handling of debounce - jack insertion is a very slow and very analogue process relative to CPUs so taking a single reading is likely to give false measurements.
I believe this should be part of codec driver that would make sure that it has determined the right adc value and then call the function to find the jack type.
This is not in general possible - there are generally AUXADCs in many devices, CPUs and PMICs both commonly have them, and the majority of them just take a reading when asked to do so. Generic software needs to be able to handle this.
In the sn95031 codec, this is handled in hardware with programmable debounce values. The default value takes care of ensuring that the adc value is read is for right jack event.
That's great, but we can't rely on this in generic code.
Later, I will add a kcontrol for the same to enable programming it.
Hrm?
I can add a field "system_micbias" field and the ranges fields to snd_soc_jack structure. The machine driver can set these details when it creates a jack. The new API can give the jack or button type based on this range. This way its scalable. Will this help? Let us know, if there is a better way
Probably.
I believe this should be part of codec driver that would make sure that it has determined the right adc value and then call the function to find the jack type.
This is not in general possible - there are generally AUXADCs in many devices, CPUs and PMICs both commonly have them, and the majority of them just take a reading when asked to do so. Generic software needs to be able to handle this.
What if I add a field debouce to snd_soc_jack and machine driver needs to program the value. The codec driver should wait for that time before reading the adc values Will this help
On Tue, Feb 01, 2011 at 07:05:26PM +0530, Harsha, Priya wrote:
Please fix the word wrapping in your MUA to wrap at less than 80 columns.
What if I add a field debouce to snd_soc_jack and machine driver needs to program the value. The codec driver should wait for that time before reading the adc values Will this help
The driver providing the ADC (which may not be part of a CODEC at all) shouldn't have to worry about this stuff unless it's done the debouncing - we should avoid having to open code functionality in individual drivers. It feels like we should have actual code for managing the process of detecting what's connected, with flexibility to handle things like pre-debouncing. If some of it is left sketchy in the first instance that's OK but we should have an idea what the overall picture is.
participants (4)
-
Harsha Priya -
Harsha, Priya
-
Liam Girdwood -
Mark Brown