[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40f098c8-b9e3-8da6-849a-eb9a39fefdb0@linux.intel.com>
Date: Thu, 30 Sep 2021 14:00:59 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Sameer Pujar <spujar@...dia.com>, broonie@...nel.org,
lgirdwood@...il.com, robh+dt@...nel.org, thierry.reding@...il.com,
jonathanh@...dia.com, catalin.marinas@....com, will@...nel.org,
perex@...ex.cz, tiwai@...e.com, kuninori.morimoto.gx@...esas.com
Cc: devicetree@...r.kernel.org, alsa-devel@...a-project.org,
linux-kernel@...r.kernel.org, sharadg@...dia.com,
linux-tegra@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 01/13] ASoC: soc-pcm: Don't reconnect an already active BE
> 1. The original issue at my end was not just a configuration redundancy.
> I realize now that with more stream addition following error print is seen.
> "ASoC: too many users playback at open 4"
>
> This is because the max DPCM users is capped at 8. Increasing this
> may help (need to see what number is better), but does not address the
> redundancy problem.
Going back to this DPCM_MAX_BE_USERS definition, it seems rather
arbitrary and not so useful indeed.
/* first time the dpcm is open ? */
if (be->dpcm[stream].users == DPCM_MAX_BE_USERS) {
dev_err(be->dev, "ASoC: too many users %s at open %d\n",
stream ? "capture" : "playback",
be->dpcm[stream].state);
continue;
}
The comment is no longer aligned with the code, wondering if this is a
feature or a bug. There's no reason to arbitrarily restrict the number
of users of a BE, or the check would need to use platform-specific
information such as the number of inputs/outputs supported by a mixer/demux.
Maybe Morimoto-san can comment since this was added in:
1db19c151819 ('ASoC: soc-pcm: fixup dpcm_be_dai_startup() user count')
We're not done with soc-pcm.c cleanups :-)
Powered by blists - more mailing lists