From: Christopher Freeman <cfreeman@nvidia.com>
To: Christopher Freeman <cfreeman@nvidia.com>,
Mark Brown <broonie@kernel.org>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>
Subject: Re: [PATCH] ASoC: jack: export gpio detect
Date: Thu, 10 Apr 2014 16:24:58 -0700 [thread overview]
Message-ID: <CF6C7514.3DC69%cfreeman@nvidia.com> (raw)
In-Reply-To: <CF69AC38.3C92E%cfreeman@nvidia.com>
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
next prev parent reply other threads:[~2014-04-10 23:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-03 22:03 [PATCH] ASoC: jack: export gpio detect cfreeman
2014-04-03 22:07 ` Mark Brown
2014-04-08 20:40 ` Christopher Freeman
2014-04-10 23:24 ` Christopher Freeman [this message]
2014-04-11 10:12 ` Mark Brown
2014-04-14 19:55 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2014-03-26 21:38 cfreeman
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=CF6C7514.3DC69%cfreeman@nvidia.com \
--to=cfreeman@nvidia.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.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