From: peter.ujfalusi@ti•com (Peter Ujfalusi)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 04/11] MFD: twl4030-audio: Add DT support
Date: Thu, 09 Aug 2012 16:53:26 +0300 [thread overview]
Message-ID: <5023C0D6.8040600@ti.com> (raw)
In-Reply-To: <20120809103600.GI24328@opensource.wolfsonmicro.com>
On 08/09/2012 01:36 PM, Mark Brown wrote:
> On Thu, Aug 09, 2012 at 01:18:50PM +0300, Peter Ujfalusi wrote:
>> On 08/08/2012 05:49 PM, Mark Brown wrote:
>
>>> That makes sense if the GPIO is actively driven, open drain should be
>>> better here, but it's still a generic thing which it'd be nice to
>>> extract.
>
>> To cover all of this in a generic way is not that straight forward IMHO.
>
> The sequence is just:
>
> 1. Enable mutes (at _PRE time)
> 2. Do whatever the device needs
> 3. Disable the mutes (at _POST time)
>
> I'm not sure there's any reason for you not to use the internal mute
> even if the external mute is present but if there is that's the only
> thing that's weird here. If there's no reason not to do it it just goes
> into step 2 and then it's fine, even if there is you can make it
> conditional in step 2.
Not sure, but it should not cause issues. The PIN is multiplexed between
GPIO6/PWM0/MUTE functionality.
For that matter probably I could just don't care about flags here and
configure the extmute (the internal one) all the time. Not sure, it has been a
long time I have dealt with the twl4030...
>> Sure I could do this:
>> hs_extmute: if only this is set we shall use the chip built in functionality
>> hs_extmute_gpio: if this is set we use the extmute feature but with external
>> GPIO.
>
>> But both need to be documented and supported.
>
> Is there any actual case where an external mute is supplied via a
> mechanism other than a GPIO, and if there is would it not either need
> its own DT property or already need to interact with the driver from
> code, making the DT property redundant?
Not with my knowledge. The only board using it is the zoom2 upstream. I know
other boards (not in upstream) which either uses the internal mute or GPIO.
> My thinking here is that the
> flag should be redundant because we already need to specify how we do
> the mute, what I'd expect is that we activate the external mute
> functionality as a result of being given another way of doing it so we
> don't need to provide a flag.
I perfectly understand your point. However how would you imagine this in the core?
We should have something similar to DAPM_SUPPLY which we can attach to the
widget which needs this sort of mute, but how big change we would need in the
core to do this I'm not sure.
I can take a look at this, but I would do it as a follow up series.
--
P?ter
next prev parent reply other threads:[~2012-08-09 13:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-08 9:41 [PATCH 00/11] MFD/ASoC/Input: twl4030-audio submodule DT support Peter Ujfalusi
2012-08-08 9:41 ` [PATCH 01/11] MFD: twl4030-audio: Clean up MODULE_* and platform_driver part Peter Ujfalusi
2012-08-08 9:41 ` [PATCH 02/11] MFD: twl4030-audio: Convert to use devm_kzalloc Peter Ujfalusi
2012-08-08 9:41 ` [PATCH 03/11] MFD: twl4030-audio: Rearange and clean-up the probe function Peter Ujfalusi
2012-08-08 9:41 ` [PATCH 04/11] MFD: twl4030-audio: Add DT support Peter Ujfalusi
2012-08-08 11:50 ` Benoit Cousson
2012-08-08 12:43 ` Peter Ujfalusi
2012-08-08 12:52 ` Mark Brown
2012-08-08 14:35 ` Peter Ujfalusi
2012-08-08 14:39 ` Mark Brown
2012-08-08 15:41 ` Benoit Cousson
2012-08-08 13:13 ` Mark Brown
2012-08-08 13:43 ` Peter Ujfalusi
2012-08-08 13:52 ` Mark Brown
2012-08-08 14:16 ` Peter Ujfalusi
2012-08-08 14:18 ` Mark Brown
2012-08-08 14:31 ` Peter Ujfalusi
2012-08-08 14:49 ` Mark Brown
2012-08-09 10:18 ` Peter Ujfalusi
2012-08-09 10:36 ` Mark Brown
2012-08-09 13:53 ` Peter Ujfalusi [this message]
2012-08-12 18:50 ` Mark Brown
2012-08-08 9:41 ` [PATCH 05/11] Input: twl4030-vibra: Support for DT booted kernel Peter Ujfalusi
2012-08-08 9:41 ` [PATCH 06/11] ASoC: twl4030: Move hs_extmute GPIO handling to driver Peter Ujfalusi
2012-08-08 9:41 ` [PATCH 07/11] ARM: OMAP/ASoC: Zoom2: Let the codec to handle the hs_extmute GPIO Peter Ujfalusi
2012-08-10 6:28 ` Tony Lindgren
2012-08-08 9:41 ` [PATCH 08/11] ASoC/MFD: twl4030: Remove set_hs_extmute callback from platform data Peter Ujfalusi
2012-08-08 9:41 ` [PATCH 09/11] ASoC: twl4030: Convert to use devm_kzalloc Peter Ujfalusi
2012-08-08 9:41 ` [PATCH 10/11] ASoC: twl4030: Add pointer to pdata within the private data Peter Ujfalusi
2012-08-08 9:41 ` [PATCH 11/11] ASoC: twl4030: Support for DT booted kernel Peter Ujfalusi
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=5023C0D6.8040600@ti.com \
--to=peter.ujfalusi@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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