diff mbox

ASoC: jack: export gpio detect

Message ID 1396562635-9753-1-git-send-email-cfreeman@nvidia.com (mailing list archive)
State New, archived
Headers show

Commit Message

Christopher Freeman April 3, 2014, 10:03 p.m. UTC
From: Christopher Freeman <cfreeman@nvidia.com>

Export the gpio detect function so machine drivers
may call it.  Interrupts for the jack may be disabled
during sleep, so this allows a machine driver to have
the jack status updated during resume.

Signed-off-by: Christopher Freeman <cfreeman@nvidia.com>
---
 include/sound/soc.h  | 1 +
 sound/soc/soc-jack.c | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

Comments

Mark Brown April 3, 2014, 10:07 p.m. UTC | #1
On Thu, Apr 03, 2014 at 03:03:55PM -0700, cfreeman@nvidia.com wrote:
> From: Christopher Freeman <cfreeman@nvidia.com>
> 
> Export the gpio detect function so machine drivers
> may call it.  Interrupts for the jack may be disabled
> during sleep, so this allows a machine driver to have
> the jack status updated during resume.

It seems better to have explicit callbacks for this doesn't it, ideally
ones that get triggered by the core without the machine driver having to
do anything?  This is a common need so having to open code it would be a
bit depressing.
Christopher Freeman April 8, 2014, 8:40 p.m. UTC | #2
On 4/3/14 3:07 PM, "Mark Brown" <broonie@kernel.org> wrote:

>* PGP Signed by an unknown key
>
>On Thu, Apr 03, 2014 at 03:03:55PM -0700, cfreeman@nvidia.com wrote:
>> From: Christopher Freeman <cfreeman@nvidia.com>
>> 
>> Export the gpio detect function so machine drivers
>> may call it.  Interrupts for the jack may be disabled
>> during sleep, so this allows a machine driver to have
>> the jack status updated during resume.
>
>It seems better to have explicit callbacks for this doesn't it, ideally
>ones that get triggered by the core without the machine driver having to
>do anything?  This is a common need so having to open code it would be a
>bit depressing.

Mark, do you have a suggestion on how to plumb this up?  The way I see it,
the machine drivers own the context for the gpios and soc-jack acts as a
helper library.  I don't see a way to do this from the core.


>
>* Unknown Key
>* 0x7EA229BD

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
Christopher Freeman April 10, 2014, 11:24 p.m. UTC | #3
On 4/8/14 1:40 PM, "Christopher Freeman" <cfreeman@nvidia.com> wrote:

>
>
>On 4/3/14 3:07 PM, "Mark Brown" <broonie@kernel.org> wrote:
>
>>* PGP Signed by an unknown key
>>
>>On Thu, Apr 03, 2014 at 03:03:55PM -0700, cfreeman@nvidia.com wrote:
>>> From: Christopher Freeman <cfreeman@nvidia.com>
>>> 
>>> Export the gpio detect function so machine drivers
>>> may call it.  Interrupts for the jack may be disabled
>>> during sleep, so this allows a machine driver to have
>>> the jack status updated during resume.
>>
>>It seems better to have explicit callbacks for this doesn't it, ideally
>>ones that get triggered by the core without the machine driver having to
>>do anything?  This is a common need so having to open code it would be a
>>bit depressing.
>
>Mark, do you have a suggestion on how to plumb this up?  The way I see it,
>the machine drivers own the context for the gpios and soc-jack acts as a
>helper library.  I don't see a way to do this from the core.
>
Any thoughts?  One idea would be to change things such that jacks are
registered with the core and the core is then allowed access to the gpio
detect functionŠ  This would make things common, but we're still opening
up a function in the jack code.  I don't see another way.  (using the
existing interface, we could free and add gpios on suspend/resumeŠ :-P)
>
>>
>>* Unknown Key
>>* 0x7EA229BD
>
>--------------------------------------------------------------------------
>---------
>This email message is for the sole use of the intended recipient(s) and
>may contain
>confidential information.  Any unauthorized review, use, disclosure or
>distribution
>is prohibited.  If you are not the intended recipient, please contact the
>sender by
>reply email and destroy all copies of the original message.
>--------------------------------------------------------------------------
>---------
>_______________________________________________
>Alsa-devel mailing list
>Alsa-devel@alsa-project.org
>http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Mark Brown April 11, 2014, 10:12 a.m. UTC | #4
On Thu, Apr 10, 2014 at 04:24:58PM -0700, Christopher Freeman wrote:
> On 4/8/14 1:40 PM, "Christopher Freeman" <cfreeman@nvidia.com> wrote:

> >Mark, do you have a suggestion on how to plumb this up?  The way I see it,
> >the machine drivers own the context for the gpios and soc-jack acts as a
> >helper library.  I don't see a way to do this from the core.

> Any thoughts?  One idea would be to change things such that jacks are
> registered with the core and the core is then allowed access to the gpio
> detect functionŠ  This would make things common, but we're still opening
> up a function in the jack code.  I don't see another way.  (using the
> existing interface, we could free and add gpios on suspend/resumeŠ :-P)

Please allow a reasonable time for replies, especially during the merge
window.
Mark Brown April 14, 2014, 7:55 p.m. UTC | #5
On Tue, Apr 08, 2014 at 01:40:10PM -0700, Christopher Freeman wrote:
> On 4/3/14 3:07 PM, "Mark Brown" <broonie@kernel.org> wrote:

> >It seems better to have explicit callbacks for this doesn't it, ideally
> >ones that get triggered by the core without the machine driver having to
> >do anything?  This is a common need so having to open code it would be a
> >bit depressing.

> Mark, do you have a suggestion on how to plumb this up?  The way I see it,
> the machine drivers own the context for the gpios and soc-jack acts as a
> helper library.  I don't see a way to do this from the core.

Both the ALSA core and ASoC know that the jacks exist and at least ASoC
already gets callbacks from the machine drivers during suspend (usually
just through providing default PM operations for them).  We'd need to
add code to actually keep track of them but if that's done then the core
can walk the list of jacks at resume time and give them a callback.
diff mbox

Patch

diff --git a/include/sound/soc.h b/include/sound/soc.h
index a6a059c..36383cb 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -442,6 +442,7 @@  int snd_soc_jack_add_gpios(struct snd_soc_jack *jack, int count,
 			struct snd_soc_jack_gpio *gpios);
 void snd_soc_jack_free_gpios(struct snd_soc_jack *jack, int count,
 			struct snd_soc_jack_gpio *gpios);
+void snd_soc_jack_gpio_detect(struct snd_soc_jack_gpio *gpio);
 #endif
 
 /* codec register bit access */
diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c
index 0bb5ccc..fd97cc5 100644
--- a/sound/soc/soc-jack.c
+++ b/sound/soc/soc-jack.c
@@ -231,7 +231,7 @@  EXPORT_SYMBOL_GPL(snd_soc_jack_notifier_unregister);
 
 #ifdef CONFIG_GPIOLIB
 /* gpio detect */
-static void snd_soc_jack_gpio_detect(struct snd_soc_jack_gpio *gpio)
+void snd_soc_jack_gpio_detect(struct snd_soc_jack_gpio *gpio)
 {
 	struct snd_soc_jack *jack = gpio->jack;
 	int enable;
@@ -251,6 +251,7 @@  static void snd_soc_jack_gpio_detect(struct snd_soc_jack_gpio *gpio)
 
 	snd_soc_jack_report(jack, report, gpio->report);
 }
+EXPORT_SYMBOL_GPL(snd_soc_jack_gpio_detect);
 
 /* irq handler for gpio pin */
 static irqreturn_t gpio_handler(int irq, void *data)