[jajanusz]

Implementation for #723

I used PLATFORM_HOST_DMA_TIMEOUT that looks to be defined for all platforms, but is unused - name looks good for this purpose, so I guess someone could even declare it for that use.
It's 50 microseconds for all platforms for now.

Signed-off-by: Janusz Jankowski janusz.jankowski@linux.intel.com

[lgirdwood]

@jajanusz CI still pending ?

[jajanusz]

@lgirdwood looks like someone introduced new 'feature' that triggers check on approval, because it restarted CI when you approved this PR

[jajanusz]

@lgirdwood also please wait for @keyonjie tests before merging this

[keyonjie]

sorry, didn't have enough time to test this on my UP2, now testing started.
basically, this can avoid dsp hang, though it doesn't return success and let copy continue at buffer not full case, and might be no use for helping on passing my simultaneous playback/capture stress test.

[keyonjie]

ah, it do taking effect, my stress test fails easily at iteration 27.

  0      1          IPC         215945354.843750       182.760422            apl-ipc.c:114 	ipc: msg rx -> 0x60040000, doing
    0      1          DMA         215945416.458333        61.614582             dw-dma.c:1219	dw_dma_interrupt_register(), irq:0x13050010
    0      1          IPC         215945430.885417        14.427083            apl-ipc.c:149 	ipc: msg rx -> 0x60040000 done
    0      1          IPC         215945669.166667       238.281250            apl-ipc.c:114 	ipc: msg rx -> 0x60010000, doing
    0      1          IPC         215945713.541667        44.375000            apl-ipc.c:149 	ipc: msg rx -> 0x60010000 done
    0      1          IPC         215946076.093750       362.552094            apl-ipc.c:114 	ipc: msg rx -> 0x60010000, doing
    0      1          IPC         215946123.385417        47.291668            apl-ipc.c:149 	ipc: msg rx -> 0x60010000 done
    0      1          IPC         215946224.479167       101.093750            apl-ipc.c:114 	ipc: msg rx -> 0x60040000, doing
    0      1          DMA         215946283.593750        59.114582             dw-dma.c:1219	dw_dma_interrupt_register(), irq:0x10050010
    0      1         HOST         215946358.906250        75.312500               host.c:716 	host_copy_int() error: dma_set_config() or dma_start() failed, ret = 4294967234
    0      1         PIPE         215946363.229167         4.322917           pipeline.c:922 	pipeline_copy_from_upstream() error: err = -62, current->comp.id = 1
    0      1         PIPE         215946367.239583         4.010417           pipeline.c:922 	pipeline_copy_from_upstream() error: err = -62, current->comp.id = 4
    0      1          IPC         215946374.062500         6.822917            apl-ipc.c:149 	ipc: msg rx -> 0x60040000 done
    0      1          IPC         215946586.875000       212.812500            apl-ipc.c:114 	ipc: msg rx -> 0x60040000, doing
    0      1          DMA         215946651.354167        64.479164             dw-dma.c:1219	dw_dma_interrupt_register(), irq:0x12050010
    0      1          IPC         215946687.447917        36.093750            apl-ipc.c:149 	ipc: msg rx -> 0x60040000 done
    0      1          DAI         215947251.093750       563.645813                dai.c:99  	dai_buffer_process() error: Insufficient bytes for next period. comp_underrun(), chan:0
    0      1          DMA         215947270.156250        19.062500             dw-dma.c:1237	dw_dma_interrupt_unregister(), irq:0x10050010
    0      1          DMA         215947413.229167       143.072922             dw-dma.c:1171	dw-dma: 0 chan 0 IRQ with no status
    0      1          DMA         215947420.572917         7.343750             dw-dma.c:1171	dw-dma: 0 chan 0 IRQ with no status
    0      1          DMA         215947427.864583         7.291667             dw-dma.c:1171	dw-dma: 0 chan 0 IRQ with no status
    0      1          DMA         215947435.208333         7.343750             dw-dma.c:1171	dw-dma: 0 chan 0 IRQ with no status
    0      1          DMA         215947442.500000         7.291667             dw-dma.c:1171	dw-dma: 0 chan 0 IRQ with no status
    0      1          DMA         215947449.791667         7.291667             dw-dma.c:1171	dw-dma: 0 chan 0 IRQ with no status
    0      1          DMA         215947457.083333         7.291667             dw-dma.c:1171	dw-dma: 0 chan 0 IRQ with no status
    0      1          DMA         215947464.375000         7.291667             dw-dma.c:1171	dw-dma: 0 chan 0 IRQ with no status
    0      1          DMA         215947471.614583         7.239583             dw-dma.c:1171	dw-dma: 0 chan 0 IRQ with no status
    0      1          IPC         137769682.343750              nan            apl-ipc.c:114 	ipc: msg rx -> 0x60040000, doing

[keyonjie]

that means we have about 4% possibility that the BF will never arrive at preload(e.g. trigger start), that is 4% possibility for FW hang at start a pipeline.

[keyonjie]

could you please only emit a warning or error, and still return success to let the trigger_start continue?
For user, 1/2 ms noise is tolerable, comparing to the start failed annoyance.

[jajanusz]

I'm not sure that it's a good idea. Maybe it solves your problem but looks like architectural/design flaw. Timeout is timeout - usually error caused by something external to the FW (HW or driver error), if you want to preload something it should happen, otherwise you get error. I guess we need something like start without preload.

What is root cause of your problem, why it cannot preload in time (or at all) ?

[keyonjie]

I'm not sure that it's a good idea. Maybe it solves your problem but looks like architectural/design flaw. Timeout is timeout - usually error caused by something external to the FW (HW or driver error), if you want to preload something it should happen, otherwise you get error. I guess we need something like start without preload.

What is root cause of your problem, why it cannot preload in time (or at all) ?

I don't know what is the root cause of the problem why buffer never full at some cases, we have followed the sequence Marcin suggested in driver side, haven't you met this issue with slim driver stress testing?

[mmaka1]

@keyonjie BF at the startup is the only way to control the flow and align the state of HW ptrs and sw ptrs. Could you re-test with the DMI L0 forced all the time? Do you hit the t/o again?

[keyonjie]

@mmaka1 how to do the DMI L0 forced?

[lgirdwood]

@keyonjie I think @mmaka1 means DMA forced to L0 state. Look at pm_runtime.c and disable the PM for DMA.

[mmaka1]

@keyonjie The current cavs/pm_runtime.c cavs_pm_runtime_force_host_dma_l1_exit() forces L0 for short time (PLATFORM_FORCE_L1_EXIT_TIME). Please do a quick test with the bit toggled early once and do not toggle it back.

[keyonjie]

@mmaka1 thanks for explain. I didn't get why it is named "L0 forced", I thought "L1 exit" means invalidate the L1 cached data and write it back to physical memory so couldn't imagine what L0 related there.

Thanks for the hints, I think it's better to merge this PR now and report any BF errors based on that for future debugging and fixes.

@mmaka1 @lgirdwood @jajanusz are you OK with it?

[jajanusz]

IMO it's good to merge. Timeout is better than freezing, so it's improvement anyway.

@keyonjie
I think it would be good to close old issue #723 when this is merged and create new issue that explains problem better (that it's going to be timeout) + what steps/env are needed to reproduce potential bug with BF.

[lgirdwood]

@jajanusz can you check the CI before I merge, it should have rerun last night but I still see an issue

[jajanusz]

@lgirdwood
1 of CIs was under maintenance when checks were running. Now everything works

[keyonjie]

hi @mmaka1 @slawblauciak @lgirdwood the new created item #856 is to track the remaining issue.