ASoC:sof:hda: fix hda preload issue by RanderWang · Pull Request #705 · thesofproject/linux

RanderWang · 2019-03-08T08:03:15Z

This issue could be reproduced by multiplex_pipeline-test.sh with two
pipelines. The hda preload would be in unexpected status sometimes
and this results ipc timeout. It is a HW restriction and the solution is
advised by Marcin:

Put DMA into coupled mode by clearing PPCTL.PROCEN bit
for corresponding stream index before the time of writing
format to SDxFMT register.
Write SDxFMT
Set PPCTL.PROCEN bit for corresponding stream index to
enable decoupled mode

I reproduced this issue on Apollolake UP2 a few times and validated the fix
a few times. I can't reproduce it on Icelake because this platform is not
stable with multiple threads test for other reasons, but this patch
didn't make any negative effect with single thread test of playback
or capture.

It fixes #670 and thesofproject/sof#1050
Signed-off-by: Keyon Jie yang.jie@linux.intel.com
Signed-off-by: Rander Wang rander.wang@linux.intel.com

plbossart

Thanks @RanderWang. Please see comments below, this looks quite good.

plbossart · 2019-03-08T14:58:37Z

for consistency with the code below move this line above so that you have a pattern BAR, register , mask, value.

yes, I will refine it

RanderWang · 2019-03-11T09:04:13Z

update my PR and tested it on Apollolake UP2.

Clarify the solution by Marcin: clearing PPCTL.PROCEN bit for a stream would decouple HDA host & link dma for that stream, so I refine the solution to 3 steps.

RanderWang · 2019-03-11T09:55:51Z

please hold on for I find a ipc timeout after 780 cycles. I will test it tonight.

RanderWang · 2019-03-12T08:16:38Z

Validate it a few times again : without this patch, IPC got timeout less than 200 cycles of start-exit while with it, UP2 survived in 1000 cycles test. So this patch is effective.

keyonjie · 2019-03-12T10:32:31Z

Validate it a few times again : without this patch, IPC got timeout less than 200 cycles of start-exit while with it, UP2 survived in 1000 cycles test. So this patch is effective.

So are you meaning that the patch can only improve(from <200 to 1000 iterations passed) but doesn't eliminate the timeout issue?

Please do more stress test to confirm that, if configuring SOF_HDA_PPCTL_GPROCEN is actually needed according to your test, let's change the comment to mention about that also.

lgirdwood · 2019-03-12T11:09:37Z

@RanderWang see thesofproject/sof#1050 and align, this also may need FW changes too.

RanderWang · 2019-03-13T08:46:00Z

Validate it a few times again : without this patch, IPC got timeout less than 200 cycles of start-exit while with it, UP2 survived in 1000 cycles test. So this patch is effective.

So are you meaning that the patch can only improve(from <200 to 1000 iterations passed) but doesn't eliminate the timeout issue?

Please do more stress test to confirm that, if configuring SOF_HDA_PPCTL_GPROCEN is actually needed according to your test, let's change the comment to mention about that also.

The maximum loop count in the test file is 1000, so it would stop at 1000.

RanderWang · 2019-03-13T09:54:01Z

@keyonjie I modify the script and the UP2 is still alive after 1700 cycles.

plbossart · 2019-03-13T21:32:06Z

@lgirdwood the commit message states this PR fixes issues #1050 so I will trust Rander's statement.

plbossart

Minor nit-pick below.

plbossart · 2019-03-13T21:34:22Z

there are never hw restrictions, only undocumented features :-)

Please change to : recommended hardware programming sequence for HDAudio DMA format.

thank, this is a topic our team has discussed how to deal with this type of issue.
This is another solution.

This issue could be reproduced by multiplex_pipeline-test.sh with two pipelines. The hda preload would be in unexpected status sometimes and this results ipc timeout. The recommended hardware programming sequence for HDAudio DMA format is: 1. Put DMA into coupled mode by clearing PPCTL.PROCEN bit for corresponding stream index before the time of writing format to SDxFMT register. 2. Write SDxFMT 3. Set PPCTL.PROCEN bit for corresponding stream index to enable decoupled mode I reproduced this issue on Apollolake UP2 a few times and validated the fix a few times. I can't reproduce it on Icelake because this platform is not stable with multiple threads test for other reasons, but this patch didn't make any negative effect with single thread test of playback or capture. Signed-off-by: Keyon Jie <yang.jie@linux.intel.com> Signed-off-by: Rander Wang <rander.wang@linux.intel.com>

RanderWang · 2019-03-14T02:33:09Z

@lgirdwood the commit message states this PR fixes issues #1050 so I will trust Rander's statement.

Yes, I reproduced 1050 and fixed it, so I added it to my list.

plbossart

Thanks @RanderWang

wenqingfu · 2019-03-20T00:30:50Z

@lgirdwood the commit message states this PR fixes issues #1050 so I will trust Rander's statement.

Yes, I reproduced 1050 and fixed it, so I added it to my list.

Looks like the 'fixes' keyword can only close on Issue. Since your patch merged, please follow up with a comment and close thesofproject/sof#1050 accordingly, thanks!

Wiphy should be locked before calling rdev_get_station() (see lockdep assert in ieee80211_get_station()). This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814) This happens because STA has time to disconnect and reconnect before batadv_v_elp_throughput_metric_update() delayed work gets scheduled. In this situation, ath10k_sta_state() can be in the middle of resetting arsta data when the work queue get chance to be scheduled and ends up accessing it. Locking wiphy prevents that. Fixes: 7406353 ("cfg80211: implement cfg80211_get_station cfg80211 API") Signed-off-by: Remi Pommarel <repk@triplefau.lt> Reviewed-by: Nicolas Escande <nico.escande@gmail.com> Acked-by: Antonio Quartulli <a@unstable.cc> Link: https://msgid.link/983b24a6a176e0800c01aedcd74480d9b551cb13.1716046653.git.repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com>

RanderWang requested review from keyonjie, mmaka1 and plbossart March 8, 2019 08:03

RanderWang force-pushed the hda_preload branch 2 times, most recently from e72ccd5 to f272869 Compare March 8, 2019 08:34

keyonjie reviewed Mar 8, 2019

View reviewed changes

Comment thread sound/soc/sof/intel/hda-stream.c Outdated

plbossart reviewed Mar 8, 2019

View reviewed changes

RanderWang force-pushed the hda_preload branch 5 times, most recently from 05ddd88 to 112686a Compare March 11, 2019 08:54

lgirdwood mentioned this pull request Mar 12, 2019

[Stress test] HDA-DMA preload timeout causes IPC timeout when running multiple pipelines thesofproject/sof#1050

Closed

plbossart reviewed Mar 13, 2019

View reviewed changes

RanderWang force-pushed the hda_preload branch from 112686a to 3b9eda5 Compare March 14, 2019 02:30

plbossart approved these changes Mar 14, 2019

View reviewed changes

plbossart merged commit dca70eb into thesofproject:topic/sof-dev Mar 14, 2019

This was referenced Mar 20, 2019

[S3] HDA-DMA preload timeout after 42 suspend/resume cycles on APL UP^2 thesofproject/sof#1113

Closed

hda-dma will timeout at waiting for DGCS_BF true thesofproject/sof#856

Closed

RanderWang mentioned this pull request Mar 15, 2021

[CML] [BUG] "suspend-resume-with-capture" test failed with kernel errors #2761

Closed

Conversation

RanderWang commented Mar 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

plbossart Mar 8, 2019

Choose a reason for hiding this comment

Uh oh!

RanderWang Mar 11, 2019

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

RanderWang commented Mar 11, 2019

Uh oh!

RanderWang commented Mar 11, 2019

Uh oh!

RanderWang commented Mar 12, 2019

Uh oh!

keyonjie commented Mar 12, 2019

Uh oh!

lgirdwood commented Mar 12, 2019

Uh oh!

RanderWang commented Mar 13, 2019

Uh oh!

RanderWang commented Mar 13, 2019

Uh oh!

plbossart commented Mar 13, 2019

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

plbossart Mar 13, 2019

Choose a reason for hiding this comment

Uh oh!

RanderWang Mar 14, 2019

Choose a reason for hiding this comment

Uh oh!

RanderWang commented Mar 14, 2019

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

wenqingfu commented Mar 20, 2019

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

RanderWang commented Mar 8, 2019 •

edited

Loading