Linux Sound subsystem development
 help / color / mirror / Atom feed
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


  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