All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Alper Nebi Yasak" <alpernebiyasak@gmail.com>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"Banajit Goswami" <bgoswami@quicinc.com>,
	"Bard Liao" <yung-chuan.liao@linux.intel.com>,
	"Brent Lu" <brent.lu@intel.com>,
	"Cezary Rojewski" <cezary.rojewski@intel.com>,
	"Charles Keepax" <ckeepax@opensource.cirrus.com>,
	"Claudiu Beznea" <claudiu.beznea@tuxon.dev>,
	"Cristian Ciocaltea" <cristian.ciocaltea@collabora.com>,
	"Daniel Baluta" <daniel.baluta@nxp.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Jaroslav Kysela" <perex@perex.cz>,
	"Jerome Brunet" <jbrunet@baylibre.com>,
	"Jiawei Wang" <me@jwang.link>, "Jonathan Corbet" <corbet@lwn.net>,
	"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Maso Huang" <maso.huang@mediatek.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Nicolas Ferre" <nicolas.ferre@microchip.com>,
	"Peter Ujfalusi" <peter.ujfalusi@linux.intel.com>,
	"Ranjani Sridharan" <ranjani.sridharan@linux.intel.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Shengjiu Wang" <shengjiu.wang@gmail.com>,
	"Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
	"Sylwester Nawrocki" <s.nawrocki@samsung.com>,
	"Takashi Iwai" <tiwai@suse.com>, "Vinod Koul" <vkoul@kernel.org>,
	"Xiubo Li" <Xiubo.Lee@gmail.com>,
	alsa-devel@alsa-project.org, imx@lists.linux.dev,
	linux-doc@vger.kernel.org, linux-sound@vger.kernel.org
Subject: Re: [PATCH v3 01/23] ASoC: soc-pcm: cleanup soc_get_playback_capture()
Date: Mon, 22 Apr 2024 04:46:24 +0000	[thread overview]
Message-ID: <87edaym2cg.wl-kuninori.morimoto.gx@renesas.com> (raw)
In-Reply-To: <92054f87-dded-4b66-8108-8b2a10909883@linux.intel.com>


Hi Pierre-Louis
Cc Mark

> Your explanation seems to contradict the sentence above "This
> availability check should be available not only for DPCM, but for all
> connections."
>
> Can we actually do this 'availability check' for non-DPCM connections.
>
> > How about this ?
> > 
> > 	If either playback or capture assertion flag was presented,
> > 	not presented direction will be disabled by ASoC even if
> > 	it was available.
> 
> Did you mean
> 
> "
> The playback (resp. capture) direction will be disabled by ASoC if the
> playback_assertion (resp. capture) flag is false - even if this
> direction was available at the DAI level
> "
> > (0, 0) : Both are not must item. available direction is used as-is.
> >          But it will be error if nothing was available.
> 
> That new wording makes me even more confused. What does 'available'
> refer to and at which level is this?
>
> This seems also to contradict the definitions above, "available
> direction is used as-is" is not aligned with "not presented direction
> will be disabled by ASoC even if it was available".

It is complicated by the attempt to merge dpcm_xxx and xxx_only flags.
And I noticed that my one of other attemption was not indicated.

Let's cleanup what does this patch-set want to do

I still wondering why dpcm_xxx flag itself is needed.

(A) Before, it checks channels_min for DPCM, same as current non-DPCM.
This is very clear for me. Let's name this as "validation check"

	if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
		if (cpu_dai->driver->playback.channels_min)
			playback = 1;
		if (cpu_dai->driver->capture.channels_min)
			capture = 1;

(B) commit 1e9de42f4324b91ce2e9da0939cab8fc6ae93893
("Explicitly set BE DAI link supported stream directions") force use to
dpcm_xxx flag

	if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
		playback = rtd->dai_link->dpcm_playback;
		capture = rtd->dai_link->dpcm_capture;

(C) 9b5db059366ae2087e07892b5fc108f81f4ec189
("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported")
checks channels_min (= validation check) again

	if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
		cpu_dai = asoc_rtd_to_cpu(rtd, 0);
		...
		playback = rtd->dai_link->dpcm_playback &&
			snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_PLAYBACK);
		capture = rtd->dai_link->dpcm_capture &&
			snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_CAPTURE);

(D) b73287f0b0745961b14e5ebcce92cc8ed24d4d52
("ASoC: soc-pcm: dpcm: fix playback/capture checks") expanded it to
multi connection.

So, I would say nothing has changed, but become more complicated.
Or if (B) added dpcm_xxx as "option flag", it was understandable for me.
like this

	if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
		playback = (cpu_dai->driver->playback.channels_min > 0) ||
			   rtd->dai_link->dpcm_playback;
		capture  = (cpu_dai->driver->capture.channels_min  > 0) ||
			   rtd->dai_link->dpcm_capture;

So my opinion is this dpcm_xxx is unnecessary flag that only complicate
matters. I guess almost all Card don't need this flag, this means
"validation check" only is veryenough, same as current non-DPCM.

But because of these history, dpcm_xxx flag have been used as
"passage permit" or "gate way". It doesn't try to "validation check" if
dpcm_xxx flag was not set. This is the reason why I try to merge
dpcm_xxx and xxx_only flag. These are doing the same things with
dirrerent flags, IMO.

OTOH, some Card want to detect error if expected direction
(playback/capture) was not valid. I guess this is your commitment (?).

So, let's keep xxx_only flag as-is, and use dpcm_xxx as "available_check".
I'm not sure what is the good naming, but for example
"playback_available_check" flag means "owner is expecting playback is
valid/available, and want to receive error if not".

I'm not sure how many owner want this flag, thus I think "option flag"
is very enough (= not mandatory, as I mentioned in the patch-set).

If we makes these checks generalize,
For DPCM, (for example new DPCM) it can remove/ignore "available_check"
flag if it don't need, same as current non-DPCM.
And for non-DPCM, it can use "available_check" if needed,
same as current DPCM.

What do you think ? what is your opinion ?

Thank you for your help !!

Best regards
---
Renesas Electronics
Ph.D. Kuninori Morimoto

  reply	other threads:[~2024-04-22  4:46 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-18  4:11 [PATCH v3 00/23] ASoC: Replace dpcm_playback/capture to playback/capture_assertion Kuninori Morimoto
2024-04-18  4:12 ` [PATCH v3 01/23] ASoC: soc-pcm: cleanup soc_get_playback_capture() Kuninori Morimoto
2024-04-18 16:20   ` Pierre-Louis Bossart
2024-04-19  1:09     ` Kuninori Morimoto
2024-04-19 13:17       ` Pierre-Louis Bossart
2024-04-22  4:46         ` Kuninori Morimoto [this message]
2024-04-22 20:12           ` Pierre-Louis Bossart
2024-04-23  4:56             ` Kuninori Morimoto
2024-04-25  5:32               ` Kuninori Morimoto
2024-04-25 15:20                 ` Pierre-Louis Bossart
2024-04-25 21:59                   ` Pierre-Louis Bossart
2024-04-26  0:24                     ` Kuninori Morimoto
2024-04-26  4:00                       ` Kuninori Morimoto
2024-04-18  4:12 ` [PATCH v3 02/23] ASoC: soc-pcm: indicate warning if DPCM BE Codec has no settings Kuninori Morimoto
2024-04-18  4:12 ` [PATCH v3 03/23] ASoC: soc-dai: remove snd_soc_dai_link_set_capabilities() Kuninori Morimoto
2024-04-18  4:12 ` [PATCH v3 04/23] ASoC: amd: Replace dpcm_playback/capture to playback/capture_assertion Kuninori Morimoto
2024-04-18  4:13 ` [PATCH v3 05/23] ASoC: fsl: " Kuninori Morimoto
2024-04-18  4:13 ` [PATCH v3 06/23] ASoC: sof: " Kuninori Morimoto
2024-04-18  4:13 ` [PATCH v3 07/23] ASoC: meson: " Kuninori Morimoto
2024-04-18  4:13 ` [PATCH v3 08/23] ASoC: Intel: " Kuninori Morimoto
2024-04-18  4:13 ` [PATCH v3 09/23] ASoC: mediatek: " Kuninori Morimoto
2024-04-18  4:13 ` [PATCH v3 10/23] ASoC: soc-core: " Kuninori Morimoto
2024-04-18  4:14 ` [PATCH v3 11/23] ASoC: soc-topology: " Kuninori Morimoto
2024-04-18  4:14 ` [PATCH v3 12/23] ASoC: soc-compress: " Kuninori Morimoto
2024-04-18  4:14 ` [PATCH v3 13/23] ASoC: Intel: avs: boards: " Kuninori Morimoto
2024-04-18  4:14 ` [PATCH v3 14/23] ASoC: ti: Replace playback/capture_only " Kuninori Morimoto
2024-04-18  4:14 ` [PATCH v3 15/23] ASoC: amd: " Kuninori Morimoto
2024-04-18  4:14 ` [PATCH v3 16/23] ASoC: fsl: " Kuninori Morimoto
2024-04-18  4:14 ` [PATCH v3 17/23] ASoC: mxs: " Kuninori Morimoto
2024-04-18  4:15 ` [PATCH v3 18/23] ASoC: atmel: " Kuninori Morimoto
2024-04-18  4:15 ` [PATCH v3 19/23] ASoC: Intel: " Kuninori Morimoto
2024-04-18 11:19   ` Amadeusz Sławiński
2024-04-18 16:26     ` Pierre-Louis Bossart
2024-04-19  7:31       ` Amadeusz Sławiński
2024-04-18  4:15 ` [PATCH v3 20/23] ASoC: samsung: " Kuninori Morimoto
2024-04-18  4:15 ` [PATCH v3 21/23] ASoC: generic: " Kuninori Morimoto
2024-04-18  4:15 ` [PATCH v3 22/23] ASoC: soc-pcm: remove dpcm_playback/capture and playback/capture_only Kuninori Morimoto
2024-04-18  4:15 ` [PATCH v3 23/23] ASoC: doc: Replace dpcm_playback/capture to playback/capture_assertion Kuninori Morimoto
2024-04-22 21:10 ` [PATCH v3 00/23] ASoC: " Pierre-Louis Bossart

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=87edaym2cg.wl-kuninori.morimoto.gx@renesas.com \
    --to=kuninori.morimoto.gx@renesas.com \
    --cc=Xiubo.Lee@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alpernebiyasak@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bgoswami@quicinc.com \
    --cc=brent.lu@intel.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=corbet@lwn.net \
    --cc=cristian.ciocaltea@collabora.com \
    --cc=daniel.baluta@nxp.com \
    --cc=hdegoede@redhat.com \
    --cc=imx@lists.linux.dev \
    --cc=jbrunet@baylibre.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=khilman@baylibre.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=maso.huang@mediatek.com \
    --cc=matthias.bgg@gmail.com \
    --cc=me@jwang.link \
    --cc=neil.armstrong@linaro.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=perex@perex.cz \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=s.hauer@pengutronix.de \
    --cc=s.nawrocki@samsung.com \
    --cc=shawnguo@kernel.org \
    --cc=shengjiu.wang@gmail.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tiwai@suse.com \
    --cc=vkoul@kernel.org \
    --cc=yung-chuan.liao@linux.intel.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.