[PATCH 0/4] ASoC: Intel: Mark BE DAIs as nonatomic for hsw and
Pierre-Louis Bossart
pierre-louis.bossart at linux.intel.com
Mon Jun 27 16:45:30 CEST 2022
On 6/25/22 03:29, Cezary Rojewski wrote:
> On 2022-06-24 3:52 PM, Pierre-Louis Bossart wrote:
>> On 6/24/22 08:43, Cezary Rojewski wrote:
>>> Address the warning: "Codec: dpcm_be_connect: FE is nonatomic but BE is
>>> not, forcing BE as nonatomic" by marking BE DAI as nonatomic. Aligns
>>> with what is already done for FE DAIs.
>>>
>>> This patchset iterates the change over all HSW and BDW related machine
>>> board drivers.
>>
>> I don't think this is necessary, I was planning to demote this warning
>> to a simple dev_dbg or possibly remove this message entirely.
>>
>> The BE DAIs can perfectly be declared as non-atomic in all Intel machine
>> drivers, except for SoundWire where there's a known delay during the
>> .trigger.
>
>
> Hmm.. that's a good feedback. Isn't ASoC's FE<->BE treated as a single
> PCM substream in sound/core/pcm_native.c though? If so, does it even
> make sense for card's BE DAI to be atomic, if it's FE counterpart is
> nonatomic already? Especially if it is specifying platform and cpu_dai
> that matches Intel's components which we know communicate using IPCs.
I guess it depends on the cpu_dai implementation. Not all
implementations implement a delay in the .trigger callback and/or rely
on IPCs.
> Warning is one thing, but will you be also getting rid of the
> if-statement in soc-pcm.c that actually forces nonatomic=1 on BE when FE
> is already declared as such? If the if-statement stays, I believe the
> declaring BE DAIs 'correctly' in the way to go.
I meant just removing the dev_warn() only.
See https://github.com/thesofproject/linux/pull/3723
More information about the Alsa-devel
mailing list