From: Christoph Hellwig <hch@lst.de>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Christoph Hellwig <hch@lst.de>,
palmer@dabbelt.com, paul.walmsley@sifive.com,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
wefu@redhat.com, guoren@kernel.org, cmuellner@linux.com,
philipp.tomsich@vrull.eu, samuel@sholland.org,
atishp@atishpatra.org, anup@brainfault.org, mick@ics.forth.gr,
robh+dt@kernel.org, krzk+dt@kernel.org,
devicetree@vger.kernel.org, drew@beagleboard.org,
Atish Patra <atish.patra@wdc.com>
Subject: Re: [PATCH 2/3] riscv: Implement Zicbom-based cache management operations
Date: Wed, 15 Jun 2022 19:49:10 +0200 [thread overview]
Message-ID: <20220615174910.GA26607@lst.de> (raw)
In-Reply-To: <110361853.nniJfEyVGO@diego>
On Wed, Jun 15, 2022 at 06:56:40PM +0200, Heiko Stübner wrote:
> If I'm reading things correctly [0], the default for those functions
> is for those to be empty - but defined in the coherent case.
That's not the point.
Zicbom is just an extension that allows the CPU to support managing
cache state. Non-coherent DMA is just one of the use cases there
are others like persistent memory. And when a CPU core supports
Zicbom it might or might not have any non-coherent periphals. Or
even some coherent and some non-coherent ones, something that
is pretty common in arm/arm64 CPUs, where PCIe is usually cache
coherent, but some other cheap periphals might not be.
That is why Linux ports require the plaform (usually through
DT or ACPI) to mark which devices are coherent and which ones
are not.
next prev parent reply other threads:[~2022-06-15 17:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 0:43 [PATCH v3 0/3] riscv: implement Zicbom-based CMO instructions + the t-head variant Heiko Stuebner
2022-06-10 0:43 ` [PATCH 1/3] dt-bindings: riscv: document cbom-block-size Heiko Stuebner
2022-06-17 20:37 ` Rob Herring
2022-06-10 0:43 ` [PATCH 2/3] riscv: Implement Zicbom-based cache management operations Heiko Stuebner
2022-06-10 3:22 ` Randy Dunlap
2022-06-10 5:56 ` Christoph Hellwig
2022-06-15 16:56 ` Heiko Stübner
2022-06-15 17:49 ` Christoph Hellwig [this message]
2022-06-16 9:46 ` Heiko Stübner
2022-06-16 11:53 ` Christoph Hellwig
2022-06-16 12:09 ` Heiko Stübner
2022-06-16 12:11 ` Christoph Hellwig
2022-06-17 8:30 ` Heiko Stübner
2022-06-12 19:15 ` Samuel Holland
2022-06-13 5:50 ` Christoph Hellwig
2022-06-10 0:43 ` [PATCH 3/3] riscv: implement cache-management errata for T-Head SoCs Heiko Stuebner
2022-06-10 1:04 ` Guo Ren
2022-06-12 19:18 ` Samuel Holland
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=20220615174910.GA26607@lst.de \
--to=hch@lst.de \
--cc=anup@brainfault.org \
--cc=atish.patra@wdc.com \
--cc=atishp@atishpatra.org \
--cc=cmuellner@linux.com \
--cc=devicetree@vger.kernel.org \
--cc=drew@beagleboard.org \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mick@ics.forth.gr \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=philipp.tomsich@vrull.eu \
--cc=robh+dt@kernel.org \
--cc=samuel@sholland.org \
--cc=wefu@redhat.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;
as well as URLs for NNTP newsgroup(s).