[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250630110836.GT794930@e132581.arm.com>
Date: Mon, 30 Jun 2025 12:08:36 +0100
From: Leo Yan <leo.yan@....com>
To: Yuanfang Zhang <quic_yuanfang@...cinc.com>
Cc: James Clark <james.clark@...aro.org>,
Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach <mike.leach@...aro.org>, kernel@....qualcomm.com,
coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Subject: Re: [PATCH] coresight-tmc: Add configurable timeout for flush and
tmcready
On Mon, Jun 30, 2025 at 06:40:53PM +0800, Yuanfang Zhang wrote:
[...]
> >>> The current implementation uses a fixed timeout via
> >>> coresight_timeout(), which may be insufficient when multiple
> >>> sources are enabled or under heavy load, leading to TMC
> >>> readiness or flush completion timeout.
> >
> > I would suggest that we first make clear if this is a hardware quirk or
> > a common issue in Arm CoreSight.
> sure, now this issue has been found that not only CPU ETM, but also subsystem ETM.
As the commit log states, "sources are enabled or under heavy load,
leading to TMC readiness or flush completion timeout." I would like to
confirm how this situation can happen.
When disabling a CoreSight path, the driver follows a sequential
order: the source device is disabled first, followed by flushing and
disabling the TMC. We expect that there should be no contention
between source devices and the sink when disabling the path. For a
subsystem ETM, I expect we should also follow this sequence.
Leo
Powered by blists - more mailing lists