[PATCH 1/4] ASoC: soc-pcm: dpcm: fix playback/capture checks

Pierre-Louis Bossart pierre-louis.bossart at linux.intel.com
Tue Jun 16 17:05:39 CEST 2020



On 6/16/20 9:52 AM, Mark Brown wrote:
> On Tue, Jun 16, 2020 at 09:23:25AM -0500, Pierre-Louis Bossart wrote:
>> On 6/16/20 4:02 AM, Stephan Gerhold wrote:
>>> On Tue, Jun 16, 2020 at 10:54:17AM +0200, Stephan Gerhold wrote:
> 
>>>> For the QCOM case it may be feasible to set dpcm_playback/dpcm_capture
>>>> appropriately because it is basically only used with one particular
>>>> DAI driver. But simple-audio-card is generic and used with many
>>>> different drivers so hard-coding a call into some other driver like
>>>> Srinivas did above won't work in that case.
> 
>> Doesn't simple-card rely on DT blobs that can also be updated?
> 
> DT is an ABI just like ACPI - it's just more featureful.  Many systems
> can easily update their DTs but not all of them and users don't always
> want to try to keep it in lock step with the kernel.  Stuff like this is
> why I've been dubious about putting DPCM things in there, it's too much
> of a hard coding of internal APIs.

ok, but is there any actual use of dpcm_playback/capture outside of C code?

simple-card.c and audio-graph-card do hard-code but that's done with C 
in the driver:

	ret = asoc_simple_parse_daifmt(dev, cpu_ep, codec_ep,
				       NULL, &dai_link->dai_fmt);
	if (ret < 0)
		goto out_put_node;

	dai_link->dpcm_playback		= 1;
	dai_link->dpcm_capture		= 1;


that that should be fixed based on the DAI format used in that dai_link 
- in other words we can make sure the capabilities of the dailink are 
aligned with the dais while parsing the DT blobs.


More information about the Alsa-devel mailing list