All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>, Liam Girdwood <lrg@ti.com>,
	Tony Lindgren <tony@atomide.com>, Dmitry Torokhov <dtor@mail.ru>,
	alsa-devel@alsa-project.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org,
	Benoit Cousson <b-cousson@ti.com>
Subject: Re: [PATCH 04/11] MFD: twl4030-audio: Add DT support
Date: Thu, 9 Aug 2012 11:36:00 +0100	[thread overview]
Message-ID: <20120809103600.GI24328@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <50238E8A.5030902@ti.com>

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.

> 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?  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.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: alsa-devel@alsa-project.org, Samuel Ortiz <sameo@linux.intel.com>,
	Tony Lindgren <tony@atomide.com>, Dmitry Torokhov <dtor@mail.ru>,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
	linux-omap@vger.kernel.org, Liam Girdwood <lrg@ti.com>,
	linux-arm-kernel@lists.infradead.org,
	Benoit Cousson <b-cousson@ti.com>
Subject: Re: [PATCH 04/11] MFD: twl4030-audio: Add DT support
Date: Thu, 9 Aug 2012 11:36:00 +0100	[thread overview]
Message-ID: <20120809103600.GI24328@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <50238E8A.5030902@ti.com>

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.

> 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?  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.

WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/11] MFD: twl4030-audio: Add DT support
Date: Thu, 9 Aug 2012 11:36:00 +0100	[thread overview]
Message-ID: <20120809103600.GI24328@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <50238E8A.5030902@ti.com>

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.

> 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?  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.

  reply	other threads:[~2012-08-09 10:36 UTC|newest]

Thread overview: 82+ 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 ` Peter Ujfalusi
2012-08-08  9:41 ` 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   ` 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   ` Peter Ujfalusi
2012-08-08  9:41   ` 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   ` Peter Ujfalusi
2012-08-08  9:41 ` [PATCH 04/11] MFD: twl4030-audio: Add DT support Peter Ujfalusi
2012-08-08  9:41   ` Peter Ujfalusi
2012-08-08  9:41   ` Peter Ujfalusi
2012-08-08 11:50   ` Benoit Cousson
2012-08-08 11:50     ` Benoit Cousson
2012-08-08 11:50     ` Benoit Cousson
2012-08-08 12:43     ` Peter Ujfalusi
2012-08-08 12:43       ` Peter Ujfalusi
2012-08-08 12:43       ` Peter Ujfalusi
2012-08-08 12:52     ` Mark Brown
2012-08-08 12:52       ` Mark Brown
2012-08-08 14:35       ` Peter Ujfalusi
2012-08-08 14:35         ` Peter Ujfalusi
2012-08-08 14:35         ` Peter Ujfalusi
2012-08-08 14:39         ` Mark Brown
2012-08-08 14:39           ` Mark Brown
2012-08-08 14:39           ` Mark Brown
2012-08-08 15:41         ` Benoit Cousson
2012-08-08 15:41           ` Benoit Cousson
2012-08-08 15:41           ` Benoit Cousson
2012-08-08 13:13   ` Mark Brown
2012-08-08 13:13     ` Mark Brown
2012-08-08 13:43     ` Peter Ujfalusi
2012-08-08 13:43       ` Peter Ujfalusi
2012-08-08 13:43       ` Peter Ujfalusi
2012-08-08 13:52       ` Mark Brown
2012-08-08 13:52         ` Mark Brown
2012-08-08 13:52         ` Mark Brown
2012-08-08 14:16         ` Peter Ujfalusi
2012-08-08 14:16           ` Peter Ujfalusi
2012-08-08 14:16           ` Peter Ujfalusi
2012-08-08 14:18           ` Mark Brown
2012-08-08 14:18             ` Mark Brown
2012-08-08 14:18             ` Mark Brown
2012-08-08 14:31             ` Peter Ujfalusi
2012-08-08 14:31               ` Peter Ujfalusi
2012-08-08 14:49               ` Mark Brown
2012-08-08 14:49                 ` Mark Brown
2012-08-08 14:49                 ` Mark Brown
2012-08-09 10:18                 ` Peter Ujfalusi
2012-08-09 10:18                   ` Peter Ujfalusi
2012-08-09 10:18                   ` Peter Ujfalusi
2012-08-09 10:36                   ` Mark Brown [this message]
2012-08-09 10:36                     ` Mark Brown
2012-08-09 10:36                     ` Mark Brown
2012-08-09 13:53                     ` Peter Ujfalusi
2012-08-09 13:53                       ` Peter Ujfalusi
2012-08-09 13:53                       ` Peter Ujfalusi
2012-08-12 18:50                       ` Mark Brown
2012-08-12 18:50                         ` Mark Brown
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   ` Peter Ujfalusi
2012-08-08  9:41   ` 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   ` Peter Ujfalusi
2012-08-08  9:41   ` 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-08  9:41   ` Peter Ujfalusi
2012-08-08  9:41   ` Peter Ujfalusi
2012-08-10  6:28   ` Tony Lindgren
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   ` Peter Ujfalusi
2012-08-08  9:41   ` Peter Ujfalusi
2012-08-08  9:41 ` [PATCH 09/11] ASoC: twl4030: Convert to use devm_kzalloc Peter Ujfalusi
2012-08-08  9:41   ` Peter Ujfalusi
2012-08-08  9:41   ` 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   ` Peter Ujfalusi
2012-08-08  9:41 ` [PATCH 11/11] ASoC: twl4030: Support for DT booted kernel Peter Ujfalusi
2012-08-08  9:41   ` 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=20120809103600.GI24328@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=b-cousson@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dtor@mail.ru \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=sameo@linux.intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.