[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