dma-trace.c: remove misunderstood trace_flush() after FW ABI banner

Fixes commit 6c14e76 ("trace: Log FW ABI and hash numbers").

In June 2020, PR #3195 added a tr_info() "banner" immediately after to
make sure tracing works.

That commit included a likely misunderstood trace_flush() call
immediately after the tr_info(). The very poorly named trace_flush()
function sounds like earlier scheduling of something that would the same
later anyway but that's absolutely not what it does. Instead it copies
pending DMA traces to the shared mailbox.

This was most likely why the FW ABI banner is randomly duplicated in the
etrace from time to time, see for instance:
https://sof-ci.01.org/linuxpr/PR2954/build5823/devicetest/?model=BYT_MB_NOCODEC&testcase=test-speaker
https://sof-ci.01.org/softestpr/PR666/build721/devicetest/?model=TGLH_RVP_HDA&testcase=check-sof-logger

Note this test failure is unrelated. For now this CI does not read
etrace unless there's a failure.

In August 2020, commit 67a0a69 ("trace: Trace initial message as
error logs") upgraded this banner from tr_info() to tr_err(). That made
sure it gets to both the mailbox and the DMA trace but it didn't remove
the trace_flush(). Remove it now.

Signed-off-by: Marc Herbert <marc.herbert@intel.com>

Author: marc-hb

src/trace/dma-trace.c

@@ -352,9 +352,6 @@ int dma_trace_enable(struct dma_trace_data *d)
 		goto out;
 #endif
 
-	/* flush fw description message */
-	trace_flush();
-
 	/* validate DMA context */
 	if (!d->dc.dmac || !d->dc.chan) {
 		tr_err_atomic(&dt_tr, "dma_trace_enable(): not valid");