Repository navigation
hda-dma will timeout at waiting for DGCS_BF true #856
Description
On APL platforms, we are randomly failed at hda_dma_host_preload() where hda-dma will timeout at waiting for DGCS_BF true.
Using simultaneous pipelines stress test can duplicate this easily. Scrip here:
https://github.com/thesofproject/sof/blob/master/tools/test/qa/tests/stability_test/multiplex_pipeline-test.sh
Setting DGCS_L1ETP at hda_dma_set_config() or Force Host DMA to exit L1 make the reproduce rate change, but can't eliminate it.
Activity
keyonjie commentedon Jan 17, 2019
Setting it to P1 as it is blocker now.
lgirdwood commentedon Jan 17, 2019
@keyonjie #804 has been merged now, does it help ?. @slawblauciak fyi
keyonjie commentedon Jan 18, 2019
I have tried it, #804 is for link dma only(paired to #783 for host dma hang fix), no help for host dma BF waiting timeout issue.
please refer to #783, I commented there it only fixes hang issue, but not the DGCS_BF always false issue.
keyonjie commentedon Jan 18, 2019
@mmaka1 I have tried what Marcin suggested(#783 (comment)) -- Setting DGCS_L1ETP at hda_dma_set_config() or Force Host DMA to exit L1 -- the result is that:
it makes the reproduce rate change, but can't eliminate it.
@mmaka1 can you help to look in this issue?
lgirdwood commentedon Jan 18, 2019
@keyonjie you have provided two different solutions, but you have not said which one improved the result and by how much it improved ? Can you also try and add some delay after DMA L1 exit before the next IO operation.
2 remaining items
keyonjie commentedon Jan 21, 2019
@lgirdwood the result here looks random to me, so I can't say which one improve and by how much it improved? Then I realized I can't try that blindly, I need to understand how it should work, that's why I dropped an email about it.
keyonjie commentedon Jan 21, 2019
@wenqingfu yes, that's how the story happened, @dabekjakub can you help find a owner for it?
dabekjakub commentedon Jan 21, 2019
@keyonjie @wenqingfu I think that @slawblauciak is our specialist in hda-dma related issues. However i will reasign this after we sync on bugscrub.
keyonjie commentedon Jan 21, 2019
Add more info as below:
At this BF fail cases, usually buffer is not empty(DGCS_BNE==1), and write pointer(DGBWP) is at 0x20 offset(period size is 0xc0, that means, dgbwp==0x20 or 0xe0), such as:
dgcs: 0x86810120 dgbrp: 0x0, dgbwp: 0xe0
I have also checked and confirmed that data are already copied to the whole buffer(which means buffer full actually), the only strange thing to me is that the DGCS.BF and DGBWP are not reflact this fact.
dabekjakub commentedon Jan 22, 2019
@keyonjie Could You check this one with non-smp architecture ?
keyonjie commentedon Jan 23, 2019
@dabekjakub I actually checked this always with UP architeture.
lgirdwood commentedon Jan 23, 2019
@keyonjie is result the same with UP vs SMP ?
keyonjie commentedon Jan 24, 2019
I think SMP fails much easier comparing with UP.
slawblauciak commentedon Jan 29, 2019
@keyonjie how did you verify that the buffer has been in fact fully preloaded if the register values don't indicate it?
keyonjie commentedon Feb 18, 2019
@slawblauciak I dumped the contents of those buffers to verify them.
wenqingfu commentedon Mar 21, 2019
Should this issue be closed by thesofproject/linux#705? @RanderWang @keyonjie @slawblauciak . If so, please close it
RanderWang commentedon Mar 22, 2019
yes, it should be closed by thesofproject/linux#705