All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Guo Ren <guoren@kernel.org>, Icenowy Zheng <uwu@icenowy.me>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Samuel Holland <samuel@sholland.org>,
	Conor Dooley <conor.dooley@microchip.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/3] riscv: use VA+PA variant of CMO macros for DMA synchorization
Date: Wed, 04 Jan 2023 13:16:27 +0100	[thread overview]
Message-ID: <2135147.irdbgypaU6@diego> (raw)
In-Reply-To: <bcce507a31662004262fa3bbe911f1b1ff7f27af.camel@icenowy.me>

Hi,

Am Mittwoch, 4. Januar 2023, 10:27:53 CET schrieb Icenowy Zheng:
> 在 2023-01-04星期三的 17:24 +0800,Guo Ren写道:
> > On Wed, Jan 4, 2023 at 4:59 PM Icenowy Zheng <uwu@icenowy.me> wrote:
> > > 
> > > 在 2023-01-04星期三的 16:50 +0800,Guo Ren写道:
> > > > On Wed, Jan 4, 2023 at 3:43 PM Icenowy Zheng <uwu@icenowy.me>
> > > > wrote:
> > > > > 
> > > > > DMA synchorization is done on PA and the VA is calculated from
> > > > > the
> > > > > PA.
> > > > > 
> > > > > Use the alternative macro variant that takes both VA and PA as
> > > > > parameters, thus in case the ISA extension used support PA
> > > > > directly, the
> > > > > overhead for re-converting VA to PA can be omitted.
> > > > > 
> > > > > Suggested-by: Guo Ren <guoren@kernel.org>
> > > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
> > > > > ---
> > > > >  arch/riscv/mm/dma-noncoherent.c | 8 ++++----
> > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/arch/riscv/mm/dma-noncoherent.c
> > > > > b/arch/riscv/mm/dma-
> > > > > noncoherent.c
> > > > > index d919efab6eba..a751f4aece62 100644
> > > > > --- a/arch/riscv/mm/dma-noncoherent.c
> > > > > +++ b/arch/riscv/mm/dma-noncoherent.c
> > > > > @@ -19,13 +19,13 @@ void arch_sync_dma_for_device(phys_addr_t
> > > > > paddr, size_t size,
> > > > > 
> > > > >         switch (dir) {
> > > > >         case DMA_TO_DEVICE:
> > > > > -               ALT_CMO_OP(clean, vaddr, size,
> > > > > riscv_cbom_block_size);
> > > > > +               ALT_CMO_OP_VPA(clean, vaddr, paddr, size,
> > > > > riscv_cbom_block_size);
> > > > ALT_CMO_OP -> ALT_CMO_OP_VPA, is the renaming necessary?
> > > 
> > > I didn't rename the original ALT_CMO_OP, ALT_CMO_OP_VPA is
> > > something
> > > new.
> > The ##_VPA is really strange.
> > 
> > How about:
> > ALT_CMO_OP          -> ALT_CMO_OP_VA
> > ALT_CMO_OP_VPA -> ALT_CMO_OP
> 
> It's thus a much bigger change.
> 
> If you are not fond of _VPA, I can rename it to _VA_PA.

before you spend too much time on this, there is currently a parallel
discussion running about including all the other different vendor-
specific cache management.

See [0] and the thread before that for reference.

The consensus seems to be that cache-handling itself is not fast anyway,
and therefore to reduce complexity for the cache handling and move
non-zicbom cache-handling into a indirect function call that the can be
overridden at runtime.


Heiko

[0] https://lore.kernel.org/all/43aee000-5b89-4d94-98d2-b37b1a18a83e@app.fastmail.com/



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

WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Guo Ren <guoren@kernel.org>, Icenowy Zheng <uwu@icenowy.me>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Samuel Holland <samuel@sholland.org>,
	Conor Dooley <conor.dooley@microchip.com>,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/3] riscv: use VA+PA variant of CMO macros for DMA synchorization
Date: Wed, 04 Jan 2023 13:16:27 +0100	[thread overview]
Message-ID: <2135147.irdbgypaU6@diego> (raw)
In-Reply-To: <bcce507a31662004262fa3bbe911f1b1ff7f27af.camel@icenowy.me>

Hi,

Am Mittwoch, 4. Januar 2023, 10:27:53 CET schrieb Icenowy Zheng:
> 在 2023-01-04星期三的 17:24 +0800,Guo Ren写道:
> > On Wed, Jan 4, 2023 at 4:59 PM Icenowy Zheng <uwu@icenowy.me> wrote:
> > > 
> > > 在 2023-01-04星期三的 16:50 +0800,Guo Ren写道:
> > > > On Wed, Jan 4, 2023 at 3:43 PM Icenowy Zheng <uwu@icenowy.me>
> > > > wrote:
> > > > > 
> > > > > DMA synchorization is done on PA and the VA is calculated from
> > > > > the
> > > > > PA.
> > > > > 
> > > > > Use the alternative macro variant that takes both VA and PA as
> > > > > parameters, thus in case the ISA extension used support PA
> > > > > directly, the
> > > > > overhead for re-converting VA to PA can be omitted.
> > > > > 
> > > > > Suggested-by: Guo Ren <guoren@kernel.org>
> > > > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
> > > > > ---
> > > > >  arch/riscv/mm/dma-noncoherent.c | 8 ++++----
> > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/arch/riscv/mm/dma-noncoherent.c
> > > > > b/arch/riscv/mm/dma-
> > > > > noncoherent.c
> > > > > index d919efab6eba..a751f4aece62 100644
> > > > > --- a/arch/riscv/mm/dma-noncoherent.c
> > > > > +++ b/arch/riscv/mm/dma-noncoherent.c
> > > > > @@ -19,13 +19,13 @@ void arch_sync_dma_for_device(phys_addr_t
> > > > > paddr, size_t size,
> > > > > 
> > > > >         switch (dir) {
> > > > >         case DMA_TO_DEVICE:
> > > > > -               ALT_CMO_OP(clean, vaddr, size,
> > > > > riscv_cbom_block_size);
> > > > > +               ALT_CMO_OP_VPA(clean, vaddr, paddr, size,
> > > > > riscv_cbom_block_size);
> > > > ALT_CMO_OP -> ALT_CMO_OP_VPA, is the renaming necessary?
> > > 
> > > I didn't rename the original ALT_CMO_OP, ALT_CMO_OP_VPA is
> > > something
> > > new.
> > The ##_VPA is really strange.
> > 
> > How about:
> > ALT_CMO_OP          -> ALT_CMO_OP_VA
> > ALT_CMO_OP_VPA -> ALT_CMO_OP
> 
> It's thus a much bigger change.
> 
> If you are not fond of _VPA, I can rename it to _VA_PA.

before you spend too much time on this, there is currently a parallel
discussion running about including all the other different vendor-
specific cache management.

See [0] and the thread before that for reference.

The consensus seems to be that cache-handling itself is not fast anyway,
and therefore to reduce complexity for the cache handling and move
non-zicbom cache-handling into a indirect function call that the can be
overridden at runtime.


Heiko

[0] https://lore.kernel.org/all/43aee000-5b89-4d94-98d2-b37b1a18a83e@app.fastmail.com/



  reply	other threads:[~2023-01-04 15:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-04  7:41 [RFC PATCH 0/3] Support using physical addresses for RISC-V CMO Icenowy Zheng
2023-01-04  7:41 ` [RFC PATCH 1/3] riscv: errata: cmo: add CMO macro variant with both VA and PA Icenowy Zheng
2023-01-04  8:48   ` Guo Ren
2023-01-04  8:48     ` Guo Ren
2023-01-04  7:41 ` [RFC PATCH 2/3] riscv: use VA+PA variant of CMO macros for DMA synchorization Icenowy Zheng
2023-01-04  8:50   ` Guo Ren
2023-01-04  8:50     ` Guo Ren
2023-01-04  8:59     ` Icenowy Zheng
2023-01-04  8:59       ` Icenowy Zheng
2023-01-04  9:24       ` Guo Ren
2023-01-04  9:24         ` Guo Ren
2023-01-04  9:27         ` Icenowy Zheng
2023-01-04  9:27           ` Icenowy Zheng
2023-01-04 12:16           ` Heiko Stübner [this message]
2023-01-04 12:16             ` Heiko Stübner
2023-01-06  7:38             ` Icenowy Zheng
2023-01-06  7:38               ` Icenowy Zheng
2023-01-04  7:41 ` [RFC PATCH 3/3] riscv: use VA+PA variant of CMO macros for DMA page preparation Icenowy Zheng

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=2135147.irdbgypaU6@diego \
    --to=heiko@sntech.de \
    --cc=aou@eecs.berkeley.edu \
    --cc=conor.dooley@microchip.com \
    --cc=guoren@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=samuel@sholland.org \
    --cc=uwu@icenowy.me \
    /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.