[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260120104457.GG2732125@e132581.arm.com>
Date: Tue, 20 Jan 2026 10:44:57 +0000
From: Leo Yan <leo.yan@....com>
To: James Clark <james.clark@...aro.org>,
Mike Leach <mike.leach@...aro.org>,
John Garry <john.g.garry@...cle.com>, Will Deacon <will@...nel.org>,
Leo Yan <leo.yan@...ux.dev>, Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Thomas Falcon <thomas.falcon@...el.com>, coresight@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] perf cs-etm: Fix decoding for sparse CPU maps
On Mon, Jan 19, 2026 at 03:43:18PM +0000, Coresight ML wrote:
[...]
> > > > > > + auxtrace_fragment.auxtrace.idx = etmq->queue_nr;
> Indeed, per-thread mode needs to be handled separately.
>
> On the Juno board (6 CPUs), I see "etmq->queue_nr=6". It seems a bit
> odd that this value is used as the index. Even in per-thread mode, the
> index is still set to 6. For correctness, should we instead set the
> index to the CPU ID, and use 0 for per-thread mode?
Sorry I made a mistake.
I messed up "etm->queues.nr_queues" and "etmq->queue_nr". I can confirm
that "etmq->queue_nr" stores the CPU ID and 0 for per-thread mode. I
verified the patch:
Tested-by: Leo Yan <leo.yan@....com>
Powered by blists - more mailing lists