linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Christoph Hellwig <hch@lst.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: Thu, 16 Jun 2022 11:46:45 +0200	[thread overview]
Message-ID: <1752040.TLkxdtWsSY@diego> (raw)
In-Reply-To: <20220615174910.GA26607@lst.de>

Hi,

Am Mittwoch, 15. Juni 2022, 19:49:10 CEST schrieb Christoph Hellwig:
> 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.

I "get" it now I think. I was somewhat struggling what you were aiming
at, but that was something of not seeing "the forest for the trees" on
my part. And of course you were right in recognizing that issue :-) .

Without CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE and friends
dev_is_dma_coherent() will always return true otherwise the dma_coherent
attribute. Hence the "coherent" value for every system not managing things
will suddenly show as non-coherent where it showed as coherent before.


As we already have detection-points for non-coherent systems (zicbom
detection, t-head errata detection) I guess just also switching some boolean
might solve that, so that arch_setup_dma_ops() will set the dma_coherent
attribute to true always except when some non-coherent system is detected.


void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
                const struct iommu_ops *iommu, bool coherent)
{
        /* only track coherent attributes, if cache-management is available */
        if (enable_noncoherency)
                dev->dma_coherent = coherent;
        else
                dev->dma_coherent = true;
}


Heiko



  reply	other threads:[~2022-06-16  9:47 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
2022-06-16  9:46         ` Heiko Stübner [this message]
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=1752040.TLkxdtWsSY@diego \
    --to=heiko@sntech.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=hch@lst.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).