All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	Charles Keepax <ckeepax@opensource.cirrus.com>,
	angelogioacchino.delregno@collabora.corp-partner.google.com,
	Shengjiu Wang <shengjiu.wang@nxp.com>,
	Takashi Iwai <tiwai@suse.com>,
	linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>,
	Ajye Huang <ajye_huang@compal.corp-partner.google.com>
Subject: Re: [PATCH v1 1/2] ASoC: dt-bindings: Document dmic_sel-gpios optional prop for two DMICs case
Date: Mon, 31 Oct 2022 13:43:43 -0500	[thread overview]
Message-ID: <20221031184343.GA3235956-robh@kernel.org> (raw)
In-Reply-To: <Y1vDYNOwZNOco1hq@sirena.org.uk>

On Fri, Oct 28, 2022 at 12:56:16PM +0100, Mark Brown wrote:
> On Fri, Oct 28, 2022 at 06:24:49PM +0800, Ajye Huang wrote:
> > Document dmic_sel-gpios optional prop for switching between two DMICs.
> > Ex, the GPIO can control a MUX to select Front or Rear dmic.
> 
> > +  dmic_sel-gpios:

s/_/-/

> > +    maxItems: 1
> > +    description: GPIO for switching between DMICs, ex Front/Rear dmic
> > +
> 
> If we're going to do this we should also allow the bindings to label the
> mics appropriately so that the control presented can reflect the actual
> hardware.  It does feel like it might fit better to do this separately
> to the DMIC driver as a mux between the DMIC and the DAI it's connected
> to but equally with the way things are at the minute that feels like
> it's probably disproportionate effort.

Are there other needs for DAI muxes? We already have a mux binding, so 
defining a DAI mux would work for any type of muxing control, not just 
GPIO.

Rob

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Ajye Huang <ajye_huang@compal.corp-partner.google.com>,
	linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Shengjiu Wang <shengjiu.wang@nxp.com>,
	Charles Keepax <ckeepax@opensource.cirrus.com>,
	Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>,
	Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>,
	angelogioacchino.delregno@collabora.corp-partner.google.com,
	devicetree@vger.kernel.org, alsa-devel@alsa-project.org
Subject: Re: [PATCH v1 1/2] ASoC: dt-bindings: Document dmic_sel-gpios optional prop for two DMICs case
Date: Mon, 31 Oct 2022 13:43:43 -0500	[thread overview]
Message-ID: <20221031184343.GA3235956-robh@kernel.org> (raw)
In-Reply-To: <Y1vDYNOwZNOco1hq@sirena.org.uk>

On Fri, Oct 28, 2022 at 12:56:16PM +0100, Mark Brown wrote:
> On Fri, Oct 28, 2022 at 06:24:49PM +0800, Ajye Huang wrote:
> > Document dmic_sel-gpios optional prop for switching between two DMICs.
> > Ex, the GPIO can control a MUX to select Front or Rear dmic.
> 
> > +  dmic_sel-gpios:

s/_/-/

> > +    maxItems: 1
> > +    description: GPIO for switching between DMICs, ex Front/Rear dmic
> > +
> 
> If we're going to do this we should also allow the bindings to label the
> mics appropriately so that the control presented can reflect the actual
> hardware.  It does feel like it might fit better to do this separately
> to the DMIC driver as a mux between the DMIC and the DAI it's connected
> to but equally with the way things are at the minute that feels like
> it's probably disproportionate effort.

Are there other needs for DAI muxes? We already have a mux binding, so 
defining a DAI mux would work for any type of muxing control, not just 
GPIO.

Rob

  reply	other threads:[~2022-10-31 18:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-28 10:24 [PATCH v1 0/2] Add optional dmic selection for two DMICs Ajye Huang
2022-10-28 10:24 ` Ajye Huang
2022-10-28 10:24 ` [PATCH v1 1/2] ASoC: dt-bindings: Document dmic_sel-gpios optional prop for two DMICs case Ajye Huang
2022-10-28 10:24   ` Ajye Huang
2022-10-28 11:56   ` Mark Brown
2022-10-28 11:56     ` Mark Brown
2022-10-31 18:43     ` Rob Herring [this message]
2022-10-31 18:43       ` Rob Herring
2022-10-31 20:47       ` Mark Brown
2022-10-31 20:47         ` Mark Brown
2022-11-01  1:04         ` Ajye Huang
2022-11-01  1:04           ` Ajye Huang
2022-11-01  1:07           ` Ajye Huang
2022-11-01  1:07             ` Ajye Huang
2022-10-28 10:24 ` [PATCH v1 2/2] ASoC: dmic: Add optional dmic selection Ajye Huang
2022-10-28 10:24   ` Ajye Huang
2022-10-28 11:44   ` Amadeusz Sławiński
2022-10-28 12:54     ` Ajye Huang
2022-10-28 12:54       ` Ajye Huang
2022-10-28 12:58       ` Mark Brown
2022-10-28 12:58         ` Mark Brown
2022-10-28 11:57   ` Mark Brown
2022-10-28 11:57     ` Mark Brown
2022-10-28 12:59     ` Ajye Huang
2022-10-28 12:59       ` Ajye Huang
2022-10-28 13:01       ` Mark Brown
2022-10-28 13:01         ` Mark Brown
2022-10-28 13:09         ` Ajye Huang
2022-10-28 13:09           ` Ajye Huang

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=20221031184343.GA3235956-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=ajye_huang@compal.corp-partner.google.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=angelogioacchino.delregno@collabora.corp-partner.google.com \
    --cc=arnaud.pouliquen@foss.st.com \
    --cc=broonie@kernel.org \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shengjiu.wang@nxp.com \
    --cc=tiwai@suse.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.