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

From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>, mike.leach@linaro.org
Cc: mathieu.poirier@linaro.org, swboyd@chromium.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] coresight: dynamic-replicator: Fix handling of multiple connections
Date: Tue, 28 Apr 2020 17:53:17 +0530	[thread overview]
Message-ID: <668ea1283a6dd6b34e701972f6f71034@codeaurora.org> (raw)
In-Reply-To: <84918e7d-c933-3fa1-a61e-0615d4b3cf2c@arm.com>

On 2020-04-27 19:23, Suzuki K Poulose wrote:
> On 04/27/2020 10:45 AM, Mike Leach wrote:
[...]
>>> 
>>> This is not sufficient. You must prevent another session trying to
>>> enable the other port of the replicator as this could silently fail
>>> the "on-going" session. Not ideal. Fail the attempt to enable a port
>>> if the other port is active. You could track this in software and
>>> fail early.
>>> 
>>> Suzuki
>> 
>> While I have no issue in principle with not enabling a path to a sink
>> that is not in use - indeed in some cases attaching to unused sinks
>> can cause back-pressure that slows throughput (cf TPIU) - I am
>> concerned that this modification is masking an underlying issue with
>> the platform in question.
>> 
>> Should we decide to enable the diversion of different IDs to different
>> sinks or allow different sessions go to different sinks, then this has
>> potential to fail on the SC7180 SoC - and it will be difficult in
>> future to associate a problem with this discussion.
> 
> Mike,
> 
> I think thats a good point.
> Sai, please could we narrow down this to the real problem and may be
> work around it for the "device" ? Do we know which sink is causing the
> back pressure ? We could then push the "work around" to the replicator
> it is connected to.
> 
> Suzuki

Hi Suzuki, Mike,

To add some more to the information provided earlier, 
swao_replicator(6b06000) and etf are
in AOSS (Always-On-SubSystem) group. Also TPIU(connected to 
qdss_replicator) and EUD(connected
to swao_replicator) sinks are unused.

Please ignore the id filter values provided earlier.
Here are ID filter values after boot and before enabling replicator. As 
per
these idfilter values, we should not try to enable replicator if its 
already
enabled (in this case for swao_replicator) right?

localhost ~ # cat 
/sys/bus/amba/devices/6b06000.replicator/replicator1/mgmt/idfilter0
0x0
localhost ~ # cat 
/sys/bus/amba/devices/6b06000.replicator/replicator1/mgmt/idfilter1
0x0

localhost ~ # cat 
/sys/bus/amba/devices/6046000.replicator/replicator0/mgmt/idfilter0
0xff
localhost ~ # cat 
/sys/bus/amba/devices/6046000.replicator/replicator0/mgmt/idfilter1
0xff

I think the unused sink EUD(also in AOSS group) probably is causing the 
backpressure here.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation