mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@arm.com>
To: Jie Gan <jie.gan@oss.qualcomm.com>
Cc: NoNine <chenmin83@gmail.com>,
	suzuki.poulose@arm.com, mike.leach@linaro.org,
	james.clark@linaro.org, alexander.shishkin@linux.intel.com,
	coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Min Chen <min.chen@siengine.com>
Subject: Re: [PATCH 1/1] coresight: tmc-etr: Sync the trace buffer for the device
Date: Wed, 16 Sep 2026 15:11:13 +0100	[thread overview]
Message-ID: <20260916141113.GI200420@e132581.arm.com> (raw)
In-Reply-To: <b803b63c-8278-4159-9305-f71ed001bdc7@oss.qualcomm.com>

On Wed, Sep 16, 2026 at 11:04:20AM +0800, Jie Gan wrote:

[...]

> > From: Min Chen <min.chen@siengine.com>
> > 
> > The flat ETR buffer comes from dma_alloc_noncoherent(), which zeroes it
> > with CPU stores.  The DMA API requires the caller to sync the buffer for
> > the device before the device writes into it, but the TMC driver only
> > ever syncs for the CPU afterwards.  On a non-coherent sink the zero fill
> > is therefore still dirty in cache when the ETR starts writing, and its
> > write-back lands on top of the trace data.

Good catch! I'm curious how you observed the dirty cache lines
overwriting trace data in DDR and causing corruption.

> Agree, without the sync, the dirty data may overwrites the trace data.

> > Add a sync_for_device() buffer operation and call it from
> > __tmc_etr_enable_hw() just before the TMC is enabled.

I don't think __tmc_etr_enable_hw() is the best place for the sync, as
it can be called frequently when an event is enabled, e.g. when a task
is scheduled in or migrated between CPUs. We should be able to sync
once after dma_alloc_noncoherent() instead.

The issue is not limited to buffer init. The driver also injects barrier
packets into the bounce buffer, which can race with the sink. Even
worse, the barrier packet write may collide with trace data when they
share a cache line.

I think we should consider writing barrier packets directly into the
AUX buffer. This would avoid stale cache data from barrier packet writes
and simplify the flow without additional sync operations.

Would you mind if I pick up this patch (keeping you as the author) and
add a second patch to address the barrier packet issue? That part may
need some several rounds refactoring so can have better shape, I think
it would be easier to consolidate the fixes on my side.

Thanks,
Leo

P.s. Please CC me on future CoreSight patches. If you're using the
mainline ./scripts/get_maintainer.pl, it should add me automatically.
I didn't receive this patch directly, which is why I'm replying to
Jie's email (also thanks Jie's review).

      reply	other threads:[~2026-09-16 14:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 13:05 [PATCH 0/1] " NoNine
2026-09-15 13:05 ` [PATCH 1/1] " NoNine
2026-09-16  3:04   ` Jie Gan
2026-09-16 14:11     ` Leo Yan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260916141113.GI200420@e132581.arm.com \
    --to=leo.yan@arm.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=chenmin83@gmail.com \
    --cc=coresight@lists.linaro.org \
    --cc=james.clark@linaro.org \
    --cc=jie.gan@oss.qualcomm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.leach@linaro.org \
    --cc=min.chen@siengine.com \
    --cc=suzuki.poulose@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®