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?
