Async ops SOC compress issue

Async ops SOC compress issue

[b_lkasam]

Hi ALSA team,
Need inputs wrt one issue seen with soc-compress code.

Please help check below issue seen in soc-compress file wrt handling 
multiple BEs
with async ops ASYNC_DPCM_SND_SOC_HW_PARAMS set for given FE dailink/BE 
dailinks also.

Issue :
pcm_prepare failure when 2 BE's on same FE enabled during compress 
playback,
seen only when both BE's have SOC_HW_PARAM defined as an async_op.

Analysis:
- With SOC_HW_PARAMS defined as async_op on both BE's,
hw_params api for both of these BE's are scheduled for asynchronous 
execution.

- It is observed that dpcm_be_hw_params_prepare is getting invoked 
twice, but for the same BE.

Below are the issue logs taken for above scenario.

12-21 16:38:32.074     0     0 D SDM660 Compress1: connected new DPCM 
playback path SDM660 Compress1 -> INT4_MI2S_RX
12-21 16:38:32.075     0     0 D SDM660 Compress1: connected new DPCM 
playback path SDM660 Compress1 -> INT0_MI2S_RX

12-21 16:38:32.075     0     0 D INT0_MI2S_RX: ASoC: open playback BE 
INT0_MI2S_RX
12-21 16:38:32.076     0     0 D INT4_MI2S_RX: ASoC: open playback BE 
INT4_MI2S_RX

12-21 16:38:32.077     0     0 E soc_compr_set_params_fe: : async 
schedule hw_params for be INT0_MI2S_RX
12-21 16:38:32.077     0     0 E soc_compr_set_params_fe: : async 
schedule hw_params for be INT4_MI2S_RX

12-21 16:38:32.078     0     0 E dpcm_be_hw_params_prepare: : BE 
INT4_MI2S_RX -> dpcm_fe_dai_hw_params_be
12-21 16:38:32.079     0     0 E msm-dai-q6-mi2s soc: 
qcom,msm-dai-mi2s:qcom,msm-dai-q6-int-mi2s4: msm_dai_q6_mi2s_hw_params: 
dai id 11 dai_data->channels = 1

12-21 16:38:32.143     0     0 E dpcm_be_hw_params_prepare: : BE 
INT4_MI2S_RX -> dpcm_fe_dai_hw_params_be
12-21 16:38:32.173     0     0 E msm-dai-q6-mi2s soc: 
qcom,msm-dai-mi2s:qcom,msm-dai-q6-int-mi2s4: msm_dai_q6_mi2s_hw_params: 
ERROR    dai id 11 dai_data->channels = 1

It is not clear why dpcm_be_hw_params_prepare is happening for same BE 
twice even though async schedule was done for both.

- With async_synchronize call after scheduling of hw_param, the behavior 
is as expected.
hw_param for both BE's are success.


diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c
index ad3cc68..b0a1995 100644
--- a/sound/soc/soc-compress.c
+++ b/sound/soc/soc-compress.c
@@ -535,6 +535,7 @@ static int soc_compr_set_params_fe(struct 
snd_compr_stream *cstream,
                                 }
                         }
                 }
+               async_synchronize_full_domain(&async_domain); - Adding 
this code fixing the issue, but looks not correct way, please suggest
                 for (i = 0; i < j; i++) {
                         cstream->be = be_list[i];
                         dpcm_be_hw_params_prepare(cstream);



With regards
Laxminath Kasam

Re: Async ops SOC compress issue

[b_lkasam]

On 2019-01-29 12:55, b_lkasam@codeaurora.org wrote:
> Hi ALSA team,
> Need inputs wrt one issue seen with soc-compress code.
> 
> Please help check below issue seen in soc-compress file wrt handling
> multiple BEs
> with async ops ASYNC_DPCM_SND_SOC_HW_PARAMS set for given FE
> dailink/BE dailinks also.
> 
> Issue :
> pcm_prepare failure when 2 BE's on same FE enabled during compress 
> playback,
> seen only when both BE's have SOC_HW_PARAM defined as an async_op.
> 
> Analysis:
> - With SOC_HW_PARAMS defined as async_op on both BE's,
> hw_params api for both of these BE's are scheduled for asynchronous 
> execution.
> 
> - It is observed that dpcm_be_hw_params_prepare is getting invoked
> twice, but for the same BE.
> 
> Below are the issue logs taken for above scenario.
> 
> 12-21 16:38:32.074     0     0 D SDM660 Compress1: connected new DPCM
> playback path SDM660 Compress1 -> INT4_MI2S_RX
> 12-21 16:38:32.075     0     0 D SDM660 Compress1: connected new DPCM
> playback path SDM660 Compress1 -> INT0_MI2S_RX
> 
> 12-21 16:38:32.075     0     0 D INT0_MI2S_RX: ASoC: open playback BE
> INT0_MI2S_RX
> 12-21 16:38:32.076     0     0 D INT4_MI2S_RX: ASoC: open playback BE
> INT4_MI2S_RX
> 
> 12-21 16:38:32.077     0     0 E soc_compr_set_params_fe: : async
> schedule hw_params for be INT0_MI2S_RX
> 12-21 16:38:32.077     0     0 E soc_compr_set_params_fe: : async
> schedule hw_params for be INT4_MI2S_RX
> 
> 12-21 16:38:32.078     0     0 E dpcm_be_hw_params_prepare: : BE
> INT4_MI2S_RX -> dpcm_fe_dai_hw_params_be
> 12-21 16:38:32.079     0     0 E msm-dai-q6-mi2s soc:
> qcom,msm-dai-mi2s:qcom,msm-dai-q6-int-mi2s4:
> msm_dai_q6_mi2s_hw_params: dai id 11 dai_data->channels = 1
> 
> 12-21 16:38:32.143     0     0 E dpcm_be_hw_params_prepare: : BE
> INT4_MI2S_RX -> dpcm_fe_dai_hw_params_be
> 12-21 16:38:32.173     0     0 E msm-dai-q6-mi2s soc:
> qcom,msm-dai-mi2s:qcom,msm-dai-q6-int-mi2s4:
> msm_dai_q6_mi2s_hw_params: ERROR    dai id 11 dai_data->channels = 1
> 
> It is not clear why dpcm_be_hw_params_prepare is happening for same BE
> twice even though async schedule was done for both.
> 
> - With async_synchronize call after scheduling of hw_param, the
> behavior is as expected.
> hw_param for both BE's are success.
> 
> 
> diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c
> index ad3cc68..b0a1995 100644
> --- a/sound/soc/soc-compress.c
> +++ b/sound/soc/soc-compress.c
> @@ -535,6 +535,7 @@ static int soc_compr_set_params_fe(struct
> snd_compr_stream *cstream,
>                                 }
>                         }
>                 }
> +               async_synchronize_full_domain(&async_domain); - Adding
> this code fixing the issue, but looks not correct way, please suggest
>                 for (i = 0; i < j; i++) {
>                         cstream->be = be_list[i];
>                         dpcm_be_hw_params_prepare(cstream);
> 
> 
> 
> With regards
> Laxminath Kasam

HI ALSA team,
can you please help update on above query wrt soc compress issue.

Thanks
Laxminath Kasam

Re: Async ops SOC compress issue

[Charles Keepax]

On Fri, Feb 08, 2019 at 11:43:39AM +0530, b_lkasam@codeaurora.org wrote:
> On 2019-01-29 12:55, b_lkasam@codeaurora.org wrote:
> can you please help update on above query wrt soc compress issue.

Most of the code/definitions in your email don't seem to match
the code in the upstream kernel, so it's really hard for us to
comment you probably need to discuss the issue internally with
whoever added the changes into the compressed framework at your
end.

Thanks,
Charles