Re: [RFC PATCH] coresight: dynamic-replicator: Fix handling of multiple connections

From: Suzuki K Poulose
Date: Tue Apr 07 2020 - 06:19:58 EST


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