All of lore.kernel.org
 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 14:09:47 +0200	[thread overview]
Message-ID: <2041345.KlZ2vcFHjT@diego> (raw)
In-Reply-To: <20220616115342.GA11289@lst.de>

Am Donnerstag, 16. Juni 2022, 13:53:42 CEST schrieb Christoph Hellwig:
> On Thu, Jun 16, 2022 at 11:46:45AM +0200, Heiko Stübner wrote:
> > 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.
> 
> Yes.
> 
> > As we already have detection-points for non-coherent systems (zicbom
> > detection, t-head errata detection)
> 
> No, we don't.  There are plenty of reasons to support Zicbom without
> every having any non-coherent DMA periphals.  Or just some non-coherent
> ones.  So that alone is not a good indicator at all.
> 
> The proper interface for that in DT-based setups i of_dma_is_coherent(),
> which looks at the dma-coherent DT property.  And given that RISC-V
> started out as all coherent we need to follow the powerpc way
> (CONFIG_OF_DMA_DEFAULT_COHERENT) and default to coherent with an
> explcit propery for non-coherent devices, and not the arm/arm64 way
> where non-coherent is the default and coherent devices need the property.

I did look at the dma-coherent-property -> of_dma_is_coherent()
	 -> of_dma_configure_id() -> arch_setup_dma_ops() chain yesterday
which setups the value dev_is_dma_coherent() returns.

The Zicbom extension will only be in new platforms, so none of the currently
supported ones will have that. So my thinking was that we can default to
true in arch_setup_dma_ops() and only use the read coherency value when
actual cache-managment-operations are defined.

My guess was that new platforms implementing cache-management will want
to be non-coherent by default?

So if the kernel is running on a platform not implementing cache-management
dev_is_dma_coherent() would always return true as it does now, while on a
new platform implementing cache-management we'd default to non-coherent
and expect that new devicetree/firmware to specify the coherent devices.





WARNING: multiple messages have this Message-ID (diff)
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 14:09:47 +0200	[thread overview]
Message-ID: <2041345.KlZ2vcFHjT@diego> (raw)
In-Reply-To: <20220616115342.GA11289@lst.de>

Am Donnerstag, 16. Juni 2022, 13:53:42 CEST schrieb Christoph Hellwig:
> On Thu, Jun 16, 2022 at 11:46:45AM +0200, Heiko Stübner wrote:
> > 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.
> 
> Yes.
> 
> > As we already have detection-points for non-coherent systems (zicbom
> > detection, t-head errata detection)
> 
> No, we don't.  There are plenty of reasons to support Zicbom without
> every having any non-coherent DMA periphals.  Or just some non-coherent
> ones.  So that alone is not a good indicator at all.
> 
> The proper interface for that in DT-based setups i of_dma_is_coherent(),
> which looks at the dma-coherent DT property.  And given that RISC-V
> started out as all coherent we need to follow the powerpc way
> (CONFIG_OF_DMA_DEFAULT_COHERENT) and default to coherent with an
> explcit propery for non-coherent devices, and not the arm/arm64 way
> where non-coherent is the default and coherent devices need the property.

I did look at the dma-coherent-property -> of_dma_is_coherent()
	 -> of_dma_configure_id() -> arch_setup_dma_ops() chain yesterday
which setups the value dev_is_dma_coherent() returns.

The Zicbom extension will only be in new platforms, so none of the currently
supported ones will have that. So my thinking was that we can default to
true in arch_setup_dma_ops() and only use the read coherency value when
actual cache-managment-operations are defined.

My guess was that new platforms implementing cache-management will want
to be non-coherent by default?

So if the kernel is running on a platform not implementing cache-management
dev_is_dma_coherent() would always return true as it does now, while on a
new platform implementing cache-management we'd default to non-coherent
and expect that new devicetree/firmware to specify the coherent devices.





_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2022-06-16 12:10 UTC|newest]

Thread overview: 36+ 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 ` Heiko Stuebner
2022-06-10  0:43 ` [PATCH 1/3] dt-bindings: riscv: document cbom-block-size Heiko Stuebner
2022-06-10  0:43   ` Heiko Stuebner
2022-06-17 20:37   ` Rob Herring
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  0:43   ` Heiko Stuebner
2022-06-10  3:22   ` Randy Dunlap
2022-06-10  3:22     ` Randy Dunlap
2022-06-10  5:56   ` Christoph Hellwig
2022-06-10  5:56     ` Christoph Hellwig
2022-06-15 16:56     ` Heiko Stübner
2022-06-15 16:56       ` Heiko Stübner
2022-06-15 17:49       ` Christoph Hellwig
2022-06-15 17:49         ` Christoph Hellwig
2022-06-16  9:46         ` Heiko Stübner
2022-06-16  9:46           ` Heiko Stübner
2022-06-16 11:53           ` Christoph Hellwig
2022-06-16 11:53             ` Christoph Hellwig
2022-06-16 12:09             ` Heiko Stübner [this message]
2022-06-16 12:09               ` Heiko Stübner
2022-06-16 12:11               ` Christoph Hellwig
2022-06-16 12:11                 ` Christoph Hellwig
2022-06-17  8:30                 ` Heiko Stübner
2022-06-17  8:30                   ` Heiko Stübner
2022-06-12 19:15   ` Samuel Holland
2022-06-12 19:15     ` Samuel Holland
2022-06-13  5:50     ` Christoph Hellwig
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  0:43   ` Heiko Stuebner
2022-06-10  1:04   ` Guo Ren
2022-06-10  1:04     ` Guo Ren
2022-06-12 19:18   ` Samuel Holland
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=2041345.KlZ2vcFHjT@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.