[Sound-open-firmware] [PATCH] trace: dma: remove disable DMA trace option

Pan, Xiuli xiuli.pan at linux.intel.com
Fri Mar 16 10:15:50 CET 2018



On 3/16/2018 17:04, Liam Girdwood wrote:
> On Fri, 2018-03-16 at 12:43 +0800, Keyon Jie wrote:
>> On 2018年03月16日 12:34, Keyon Jie wrote:
>>>
>>> On 2018年03月16日 11:40, Pan, Xiuli wrote:
>>>>
>>>> On 3/15/2018 23:09, Liam Girdwood wrote:
>>>>> DMA based trace is the standard default trace method. mailbox trace is
>>>>> no longer supported.
>>>>>
>>>>> Signed-off-by: Liam Girdwood <liam.r.girdwood at linux.intel.com>
>>>>> ---
>>>>>    configure.ac        | 10 --------
>>>>>    src/ipc/dma-copy.c  |  2 --
>>>>>    src/ipc/intel-ipc.c |  4 ---
>>>>>    src/lib/Makefile.am |  6 +----
>>>>>    src/lib/trace.c     | 70
>>>>> +----------------------------------------------------
>>>>>    5 files changed, 2 insertions(+), 90 deletions(-)
>>>>>
>>>>> diff --git a/configure.ac b/configure.ac
>>>>> index bb4d2e9f..9b74c6a9 100644
>>>>> --- a/configure.ac
>>>>> +++ b/configure.ac
>>>>> @@ -241,16 +241,6 @@ case "$with_dsp_core" in
>>>>>    esac
>>>>> -# dma trace support (Optional), dma trace by default
>>>>> -AC_ARG_ENABLE([dma-trace],
>>>>> -        AS_HELP_STRING([--disable-dma-trace], [Disabled dma trace
>>>>> and use fallback mailbox trace]))
>>>>> -
>>>>> -AS_IF([test "x$enable_dma_trace" != "xno"], [
>>>>> -    AC_DEFINE([CONFIG_DMA_TRACE], [1], [Configure DMA trace])
>>>>> -    ])
>>>>> -
>>>>> -AM_CONDITIONAL(BUILD_DMA_TRACE,  test "x$enable_dma_trace" != "xno")
>>>>> -
>>>>>    PLATFORM_BOOT_LDR_LDSCRIPT="boot_ldr.x"
>>>>>    AC_SUBST(PLATFORM_BOOT_LDR_LDSCRIPT)
>>>> Hi Liam,
>>>>
>>>> I think we should keep this feature. We may need this feature to debug
>>>> the dma related bugs.
>>>> If anything goes wrong with the DMA, or we need to enable DMA on new
>>>> platform, the DMA trace will not work and we may need fall back to
>>>> mail box trace to get the debug info.
>>> Agree to reserve the possibility for mailbox trace, we can set default
>>> to use dma trace, which may be helpful for debugging to special cases,
>> sorry, I mean that the 'mailbox trace' may be helpful for ...
>>
> We still have a "mailbox" trace mechanism via trace_err() calls. The error
> mailbox is persistent and low volume so it's unlikley to overflow too. This can
> be used for enabling DMA trace on future platforms.

Thus we need some hard code modify here to allow trace value output.
Keep this is the easiest way for us to switch between DAM trace and 
mailbox trace.
I hope we can keep this.

Thanks
Xiuli


> Liam



More information about the Sound-open-firmware mailing list