lkml.org 
[lkml]   [2020]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] coresight: dynamic-replicator: Fix handling of multiple connections
From
Date
On 04/07/2020 10:46 AM, Sai Prakash Ranjan wrote:
> Hi Mike,
>
> Thanks for taking a look.
>
> On 2020-04-06 16:25, Mike Leach wrote:
>> Hi,
>>
>> The programmable replicator hardware by design enables trace through
>> both ports on reset. (see 1, section 4.4, 9.11)  The replicator driver
>> overrides this functionality to disable output, until the Coresight
>> infrastructure chooses a path from source to sink.
>> Now given that the hardware design is such that we must be able to
>> allow trace to be sent to both ports, a generic patch to prevent this
>> does not seem appropriate here.
>>
>> I think this needs further investigation - to determine why this
>> appears to be failing in this particular instance.
>>
>
> Yes, this probably needs further investigation, but CPU hardlock stack
> trace doesnt help much. I could always trigger this hard lockup without
> this patch on SC7180 SoC and this is only seen when ETR is used as the
> sink.
>
> The only difference I could see between non working case (on SC7180 [1])
> and
> the working case (on SDM845 [2]) is the path from source to sink.


>
> SC7180 source to sink path(Not working):
> ----------------------------------------
>
>       etm0_out
>      |
>   apss_funnel_in0
>          |
>  apss_merge_funnel_in
>          |
>      funnel1_in4
>      |
>   merge_funnel_in1
>      |
>    swao_funnel_in
>          |
>        etf_in
>      |
>  swao_replicator_in
>          |
>   replicator_in
>      |
>        etr_in


There seems to be two replicators back to back here. What is connected
to the other output of both of them ? Are there any TPIUs ? What happens
if you choose a sink on the other end of "swao_replicator" (ETB ?)

After boot, what do the idfilter registers read for both the replicators ?


I believe we need to properly assign the TRACE_IDs for tracing sessions,
(rather than static ids) in a way such that we could filter them and use
the multiple sinks in parallel for separate trace sessions and this is
not simple (involves kernel driver changes and the perf tool to be able
to decode the trace id changes too).


So for the moment, we need to :

1) Disallow turning the replicator ON, when it is already turned ON
2) Do what your patch does. i.e, disable the other end while one end
is turned on.

Thoughts ?

Kind regards
Suzuki

\
 
 \ /
  Last update: 2020-04-07 12:20    [W:0.068 / U:3.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site