dma-trace: Fix reschedule bug to avoid dma buffer overflow

We have wrong logic in reschedule, we always reschedule the trace_work
once the buffer is half full and new trace coming. We will delay the old
schedule before the old scheduled trace_work is finally run.
Thus the trace_work will like the carrot in front of the DSP as the donkey,
the DSP will never run the trace_work that scheduled in the furture
while we are in busy state and lots of trace are coming continuously.

Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com>
Reviewed-by: Zhigang Wu <zhigang.wu@linux.intel.com>
Reviewed-by: Yan Wang <yan.wang@linux.intel.com>
Tested-by: Zhigang Wu <zhigang.wu@linux.intel.com>
This commit is contained in:
Pan Xiuli 2018-03-27 18:24:58 +08:00 committed by Liam Girdwood
parent 9112ee51b9
commit 3d8089ed0f
1 changed files with 8 additions and 2 deletions

View File

@ -115,7 +115,7 @@ out:
buffer->avail -= size;
}
/* DMA trace copying is done */
/* DMA trace copying is done, allow reschedule */
d->copy_in_progress = 0;
spin_unlock_irq(&d->lock, flags);
@ -335,9 +335,15 @@ void dtrace_event(const char *e, uint32_t length)
spin_unlock_irq(&trace_data->lock, flags);
/* schedule copy now if buffer > 50% full */
if (trace_data->enabled && buffer->avail >= (DMA_TRACE_LOCAL_SIZE / 2))
if (trace_data->enabled &&
buffer->avail >= (DMA_TRACE_LOCAL_SIZE / 2)) {
work_reschedule_default(&trace_data->dmat_work,
DMA_TRACE_RESCHEDULE_TIME);
/* reschedule should not be intrrupted */
/* just like we are in copy progress */
trace_data->copy_in_progress = 1;
}
}
void dtrace_event_atomic(const char *e, uint32_t length)