From: Stephen Gordon <gordoste@iinet.net.au>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Mark Brown <broonie@kernel.org>
Cc: Shenghao Ding <shenghao-ding@ti.com>, Kevin Lu <kevin-lu@ti.com>,
Baojun Xu <baojun.xu@ti.com>, Liam Girdwood <lgirdwood@gmail.com>,
linux-sound@vger.kernel.org
Subject: Re: [PATCH v2] ASoC: pcm3168a: Add option to force clock consumer
Date: Thu, 12 Dec 2024 12:54:01 +1100 [thread overview]
Message-ID: <e17b11ac-bd78-42e0-8fd9-272fb5a41bbe@iinet.net.au> (raw)
In-Reply-To: <87o71kjm66.wl-kuninori.morimoto.gx@renesas.com>
> From "Sound Card" point of view, setup directly Bx_Fx base instead of
> CBx_CFx base is not a big deal. But if we do it, we need to have such
> setting for each DAI, instead of common dai_link.
>
> Now dai_link->dai_fmt is including 4 type of info
>
> 1. DAI hardware audio formats
> 2. DAI Clock gating
> 3. DAI hardware signal polarity
> 4. DAI hardware clock providers/consumers
>
> I think we want to separate 4 (and maybe 2 too ?) from it to support
> more flexible system ?
>
> Legacy system
> dai_link->dai_fmt // include all 1, 2, 3, 4
>
> New system
> dai_link->dai_fmt // include 1, 2, 3 (or 1, 3)
> dai_link->cpus[idx].fmt // include 4 (or 2, 4)
>
> fmt = dai_link->dai_fmt | dai_link->cpus[i].fmt
>
> "flip" has effect to 4 only, so New system has no issue with flipping
> on dai_link->dai_fmt.
Hi Morimoto-san,
This is a great idea. I'd add that #4 could still be in
dai_link->dai_fmt, but the new field in CPU/codec
(snd_soc_dai_link_component.fmt) should override the setting (not a
simple OR). This would preserve backward compatibility (I think). It
greatly improves support for multiple codecs sharing clock lines, where
1 codec is the producer and others are consumers. The bit/frame logic in
simple/graph cards should be able to be changed to handle this properly too.
Without this type of override, the original patch is needed (or the card
driver needs to write registers directly, which seems bad).
I will wait to hear Mark's opinion.
Stephen
next prev parent reply other threads:[~2024-12-12 1:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 12:01 [PATCH] ASoC: pcm3168a: Add option to force clock consumer Stephen Gordon
2024-12-06 11:54 ` [PATCH v2] " Stephen Gordon
2024-12-06 12:07 ` Mark Brown
2024-12-06 12:22 ` Mark Brown
2024-12-06 13:16 ` Stephen Gordon
2024-12-06 14:13 ` Mark Brown
2024-12-07 1:52 ` Stephen Gordon
2024-12-09 1:58 ` Kuninori Morimoto
2024-12-09 12:12 ` Stephen Gordon
2024-12-10 2:40 ` Kuninori Morimoto
2024-12-12 1:54 ` Stephen Gordon [this message]
2024-12-13 5:10 ` Kuninori Morimoto
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=e17b11ac-bd78-42e0-8fd9-272fb5a41bbe@iinet.net.au \
--to=gordoste@iinet.net.au \
--cc=baojun.xu@ti.com \
--cc=broonie@kernel.org \
--cc=kevin-lu@ti.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-sound@vger.kernel.org \
--cc=shenghao-ding@ti.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