public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ChiYuan Huang <cy_huang@richtek.com>
To: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Allen Lin <allen_lin@richtek.com>, <alsa-devel@alsa-project.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ASoC: codecs: rtq9128: Add TDM data source selection
Date: Thu, 28 Sep 2023 10:03:00 +0800	[thread overview]
Message-ID: <20230928020300.GA18024@linuxcarl2.richtek.com> (raw)
In-Reply-To: <ZRQDzZG7PPovUIsf@finisterre.sirena.org.uk>

On Wed, Sep 27, 2023 at 12:28:29PM +0200, Mark Brown wrote:
> On Wed, Sep 27, 2023 at 06:19:48PM +0800, ChiYuan Huang wrote:
> > On Wed, Sep 27, 2023 at 11:59:31AM +0200, Mark Brown wrote:
> 
> > > Sure, but is that actually a practical design - or if someone is doing
> > > this shouldn't it be joined up with the TDM configuration since with
> > > just the control it'd only be possible to switch the pins but not change
> > > the TDM layout?  I'm not sure that this control works as a standalone
> > > thing.
> 
> > I think if two data source input for different scenarios, then the data source
> > switch will become practical. For the standalone usage, keep a device property
> > to decide this may be enough. But consider the future application, to keep this
> > in general mixer control is still usable to meet the complex design.
> 
> My concern is that the control might not actually be usable without also
> changing the TDM mode so we might need the machine driver to add a
> control which flips the input and also changes the TDM mode - it feels
> likley that if there are two inputs they won't have identical formats.

Yap, your concern may be correct. This change is really becuase our default register
is badly defined. it choose TDM CH12 from 'DATA1' and CH34 from 'DATA2'. If it can
choose both default to either one, this doesn't make it confused. Also, there's the
another option is 'to tell user if TDM will be used, plase connect 'DATA1' and 'DATA2'
together'. But our datasheet did not directly define this.

I'll prepare another patch to define a device property, parsing at probe function and
configure this input source source directly in 'set_tdm_slot' API when TDM is chosen
to use.

Thanks for all the comment.

      reply	other threads:[~2023-09-28  2:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27  2:06 [PATCH] ASoC: codecs: rtq9128: Add TDM data source selection cy_huang
2023-09-27  9:13 ` Mark Brown
2023-09-27  9:46   ` ChiYuan Huang
2023-09-27  9:59     ` Mark Brown
2023-09-27 10:19       ` ChiYuan Huang
2023-09-27 10:28         ` Mark Brown
2023-09-28  2:03           ` ChiYuan Huang [this message]

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=20230928020300.GA18024@linuxcarl2.richtek.com \
    --to=cy_huang@richtek.com \
    --cc=allen_lin@richtek.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox