Hi Morimoto-san,
> soc_get_playback_capture() is now handling DPCM and normal comprehensively
> for playback/capture stream. We can use playback/capture_only flag
> instead of using dpcm_playback/capture. This patch replace these.
This patch no longer applies since Mark merged
"[PATCH 00/21] ASoC: Intel: boards: updates for 6.10 - part1"
https://lore.kernel.org/linux-sound/20240325221059.206042-1-pierre-louis.bossart@xxxxxxxxxxxxxxx/
The odds of additional conflicts are very high due to the number of
queued changes in machine drivers, I really don't know how we're going
to find the time to solve those conflicts and test experimental
versions, while we're also busy checking the 6.9-rc1 transition.
In addition, I have a bit of heartburn with the concept of flipping the
logic from a clear description of playback or capture supported, to an
implicit 'both supported unless stated otherwise'. We are going to miss
some cases and have regressions, it's pretty much a given.
And then there are cases such as the following examples
> @@ -496,8 +494,6 @@ static struct snd_soc_dai_link cml_rt1011_rt5682_dailink[] = {
> */
> .name = "SSP1-Codec",
> .id = 6,
> - .dpcm_playback = 1,
> - .dpcm_capture = 1, /* Capture stream provides Feedback */
> .no_pcm = 1,
> .init = cml_rt1011_spk_init,
> .ops = &cml_rt1011_ops,
> @@ -293,8 +291,6 @@ int sof_intel_board_set_ssp_amp_link(struct device *dev,
>
> link->id = be_id;
> link->no_pcm = 1;
> - link->dpcm_capture = 1; /* feedback stream or firmware-generated echo reference */
> - link->dpcm_playback = 1;
>
> return 0;
> }
> diff --git a/sound/soc/intel/boards/sof_da7219.c b/sound/soc/intel/boards/sof_da7219.c
> index 6eb5a6144e97..c7cca3e47ed9 100644
> --- a/sound/soc/intel/boards/sof_da7219.c
> +++ b/sound/soc/intel/boards/sof_da7219.c
> @@ -296,8 +296,6 @@ static struct snd_soc_dai_link jsl_dais[] = {
> .id = 0,
> .ignore_pmdown_time = 1,
> .no_pcm = 1,
> - .dpcm_playback = 1,
> - .dpcm_capture = 1, /* IV feedback */
> SND_SOC_DAILINK_REG(ssp1_pin, max_98373_components, platform),
where we lose comments on what the capture stream is. That's not so
good, we added those comments on purpose to explain that the capture
stream isn't a regular PCM format, I don't see a good reason to see them go?
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]